oled boot splash

[tehn]

https://github.com/notro/fbtft/wiki/Bootsplash

[tehn]

gah

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=145228&p=1249109#p1204224

[tehn]

initramfs.conf had to switch to COMPRESS=lzma

https://speakofthedevel.com/surviving-ubuntus-out-of-space-boot-partition/

[simonvanderveldt]

Hi all! :wave:

@tehn and myself have been exchanging some mails and he mentioned it would make sense to post suggestion/ideas in their respective issues, so here goes the first one :)

Note I have never tried a rpi3 before and I'm not fully aware of the full ecosystem and do's/don'ts regarding them. So if I say something crazy please let me know :)

Plymouth seems like a bit of a heavy beast to get a bootsplash going and I'm not sure if it'll be possible to start it early enough in the boot process to hide everything. I found the following alternative options, we can investigate if it makes sense to try them out?

The simplest seems to be to replace the in kernel raspberry image, although apparently it's pretty small (80x80 pixels?) Alternatively something like this might be enough to get an early splash screen https://github.com/ajstarks/openvg/pull/38 This is from http://blog.fraggod.net/2015/11/28/raspberry-pi-early-boot-splash-logo-screen.html Another similar super-simple approach uses fbi http://www.raspberry-projects.com/pi/pi-operating-systems/raspbian/custom-boot-up-screen

Alternatively this is also something that matches pretty much 100% with our use case, unfortunately it seems there wasn't enough interest on the LKML. It might be an idea to get in touch with the developer (Max) https://lists.freedesktop.org/archives/dri-devel/2018-January/162869.html

[tehn]

removing plymouth might help with https://github.com/tehn/norns-image/issues/4 as well.

static image is the first primary goal. stretch goal is a fade in. (dream-land would be just running a standalone app in a new thread that could do algorithmic animation!)

[ranch-verdin]

so I had a very quick look into the 'super-simple approach using fbi'...

discovered some code cairo.c lying around on the device which draws to screen (apparently using /dev/fb1). Would it be an acceptable solution to trigger this program from the init scripts, then adapt it so it draws the right kind of thing? (currently that program just draws some not-very-exciting cairo debug/testing)

[tehn]

actually cairo isn't even needed for screen drawing: http://raspberrycompote.blogspot.ie/2012/12/low-level-graphics-on-raspberry-pi-part_9509.html

the goal of this splash screen is to have it draw as soon as possible in the boot process, which will require getting the screen module loaded first.

there are many ways to load the module. best is probably with a dtoverlay, selected in config.txt -- but i don't know how early you can push it forward in priority

the other way (possibly how your unit is working now), is via init-norns.sh, with the line:

sudo modprobe fbtft_device custom name=fb_ssd1322 width=128 height=64 speed=16000000 gpios=dc:7,reset:6

now, the complication. the dtoverlay doesn't work with pin 7 as dc, because it's reserved for spi. i hot-wired dc to pin 5 (i hope i did this for your unit, you may need to peek inside) which then works, but i've seen some minor instability in the screen drawing that i'm thinking is mechanical. but i need to test further-- i'll prioritize this.

On Mon, Jan 29, 2018 at 7:58 PM, ranch-verdin notifications@github.com wrote:

so I had a look at the 'super-simple approach using fbi' - couldn't this be any userspace program that draws to screen?

I discovered some code cairo.c lying around on the device which draws to screen (apparently using /dev/fb1). Would it be an acceptable solution to trigger this program from the init scripts, and adapt it so it draws the right kind of thing?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tehn/norns-image/issues/3#issuecomment-361440319, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcLdI7mlER2pDZ7TatV45zmaRBxY7ks5tPmkggaJpZM4RHtg_ .

[ranch-verdin]

So before I start messing around with low-level boot stuff... If I soft-brick the device, assuming recovery is through a bootable USB stick? (don't actually have a stick with me right now to quickly test this, but no big deal to obtain one)

[ranch-verdin]

as for the hot-wire, I opened up the unit & took some pictures.

There's a red wire going from pin 9 of SOM1 (compute module - assuming pin1 is nearest to pcb edge) to pin 4 of T1 (screen ribbon - assuming pin1 is nearest the middle of board)

I guess this is not the gpio/spi fix? I'm staying with friends - no soldering iron here unfortunately...

Screen is working from userspace, /etc/init.d/init-norns.sh contains the line: sudo modprobe fbtft_device custom name=fb_ssd1322 width=128 height=64 speed=16000000 gpios=dc:7,reset:6

[tehn]

that red wire is the pin 5 jumper fix as i described, so you should be able to use the dtoverlay. more information on this after i retest.

On Tue, Jan 30, 2018 at 6:50 AM, ranch-verdin notifications@github.com wrote:

as for the hot-wire, I opened up the unit & took some pictures.

[image: img_1846] https://user-images.githubusercontent.com/35497435/35564795-548e0dae-05b3-11e8-81d7-1dcfa894cf34.JPG [image: img_1848] https://user-images.githubusercontent.com/35497435/35564796-550fc16e-05b3-11e8-9724-0102f0738eb9.JPG

There's a red wire going from pin 9 of SOM1 (compute module - assuming pin1 is nearest to pcb edge) to pin 4 of T1 (screen ribbon - assuming pin1 is nearest the middle of board)

So I guess this is not the gpio/spi fix? I'm staying with friends - no soldering iron here unfortunately...

Screen is working from userspace though - think I always ran init-norns.sh before norns/start.sh (will boot the device & check exactly what is required to draw to screen)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tehn/norns-image/issues/3#issuecomment-361570310, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcArgLcFF2YYZuKU4bzSHhlQJ9R6bks5tPwIIgaJpZM4RHtg_ .

[tehn]

@ranch-verdin regarding disk recovery.

the internal usb port seen at the top left of your first photo is the boot port. soon i'll put up instructions how to put the norns into usb-disk mode. so yes, don't worry too much about soft brick for now, it's all recoverable.

[ranch-verdin]

From reading up a bit on DTS & fbtft I believe that modprobe fbtft_device will likely cause a hard crash if the DTS method has already succeeded. So will comment that line in /etc/init.d/init-norns.sh before attempting the .dts way.

What is the status of this file? https://github.com/tehn/norns-image/blob/master/overlays/ssd1322-spi-overlay.dts Looks like at least a potential starting point!

[tehn]

that dts file is correct, set up for the red wire. it's also already compiled and copied to your /boot/overlays folder, so just uncomment the last line of /boot/config.txt to use it

On Tue, Jan 30, 2018 at 5:44 PM, ranch-verdin notifications@github.com wrote:

From reading up a bit on DTS & fbtft I believe that modprobe fbtft_device will likely cause a hard crash if the DTS method has already succeeded. So will comment that line in /etc/init.d/init-norns.sh before attempting the .dts way.

What is the status of this file? https://github.com/tehn/norns- image/blob/master/overlays/ssd1322-spi-overlay.dts Looks like at least a potential starting point!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tehn/norns-image/issues/3#issuecomment-361760141, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcMQvyYnrTlaOALZB-XDo-2HGNw8pks5tP5s9gaJpZM4RHtg_ .

[ranch-verdin]

right, sorry I had some stuff to attend to - in fact config.txt was already done & screen seems to work fine without explicit modprobe... quick experiment now to kick that cairo example from init

[ranch-verdin]

set up plymouth using the links @tehn originally posted - here are my findings.

• I haven't made plymouth's image-splash work properly - but it's spitting out scrolling text to screen. We can get a sense of timings.
• power-on to plymouth: ~16 seconds
• power-on to cairotest ~ 26 seconds
• the .deb patch to s/fb0/fb1/ was slightly different from the guide
• everything seems flaky after enabling plymouth (I can boot to usb-serial like every 1 in 3 but everything from network to USB-serial will intermittently die)

It doesn't look to me like this clunky beast will give us a quick win. I was able to disable plymouth & restore the system without emergency recovery this time, just by reverting the changes to /boot/config.txt & /boot/cmdline.txt

I guess next logical step is to return to kernel config/compilation? My current thinking is that the slow boot is as much kernel-level as systemd.

[tehn]

thanks for taking a look. yes i’d say we should pass on plymouth.

systemd and linux booting in general are not my specialty, perhaps simon will have some suggestions

[simonvanderveldt]

@ranch-verdin Don't know if you've already done so, but getting an overview of the boot sequence might give us some insight into which things take the most time. See https://wiki.archlinux.org/index.php/Improving_performance/Boot_process#Analyzing_the_boot_process for info on how to get that info.

Like you said it will probably boil down to kernel and systemd (unit) configuration/tweaking. Unfortunately I don't have my unit yet (it's at customs at the moment) so I can't do anything on the physical device myself. On my todo for this weekend is to start figuring out how to CI, which would include kernel builds. I could start with those so I can get a feeling for how the current kernel is configured and assess if there are issues with it/gains to be made?

[ranch-verdin]

systemd-analyze is currently borked, I think because some bit of cruft is crashing or somehow stuck - couldn't see immediately which service needed disabling/fixing, but didn't try very hard. hang on, no it seems to work now, but pretty sure it was broken last night.

I will read the rest of that article carefully & try to understand more about this low-level stuff!

[tehn]

just to reiterate, the primary goal is getting something on the screen asap after power on. after that it’s ok if boot to app takes a while, though shorter is best. ideally if the splash can be just an application then there can be some algorithmic animation.

so the issue will be getting the screen driver loaded right away.

On Fri, Feb 2, 2018 at 8:37 AM ranch-verdin notifications@github.com wrote:

systemd-analyze is currently borked, I think because some bit of cruft is crashing or somehow stuck - couldn't see immediately which service needed disabling/fixing, but didn't try very hard.

I will read the rest of that article carefully & try to understand more about this low-level stuff!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tehn/norns-image/issues/3#issuecomment-362588379, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcI8rVBkEyXtB32JfWMVCf6hhpPKzks5tQw-wgaJpZM4RHtg_ .

[simonvanderveldt]

just to reiterate

Good point, getting slightly sidetracked :P

the primary goal is getting something on the screen asap after power on.

We should be able to do this using just the kernel's built-in logo option, as long as the display is available as a framebuffer device and we create an image that matches the display's size it should work. See https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/video/fbdev/core/fbmem.c#L501 for reference

[tehn]

by default doesn't this draw to /dev/fb0 though? need to figure out how to get the oled driver loaded first and then put the logo on /dev/fb1

[ranch-verdin]

I think adding fbcon=map:10 to /boot/cmdline.txt solves the fb0/fb1 part of the problem. Certainly this on it's own (without the rest of the plymouth recipe) results in scrolling boot text on the OLED shortly before systemd runs the cairotest splash.

However the power-on -> scrolling-text pause still seems way too long even with the dtoverlay module load. To load OLED driver earlier than with dtoverlay, it must be a case of building it into the kernel rather than as a module, possibly with the tweak to kernel Makefile @simonvanderveldt suggested:

Doing built-in drivers gives us the option to patch the kernel Makefile to change the order of the drivers so the one for the display is loaded sooner :) See https://stackoverflow.com/a/11645715 for some examplanation

[ranch-verdin]

building on @simonvanderveldt's latest kernel work & buildroot I was able to get a much-earlier userspace splash: http://rickvenn.com/splash.img

you get like half a second of kernel-text on the framebuffer before the splash kicks in. Think this is now very close to optimal for a kernel/userspace solution.

[tehn]

we're just going to let matron do its splash so the goal is to boot fast. we can revisit this some other day if there is a passion.