Overhauling the boot process

[flabbergast]

(Apologies for the verbosity/lack of organisation.)

A suggestion for a "new" booting setup for CFW

The goal of this suggested overhaul of Miyoo CFW boot process is to:

• make it easier to switch around kernels and test new ones
• work towards having a single image for all handhelds

Overview

All the changes compared to CFW 1.3.3 happen in the boot partition, and in the rootfs/etc/main script.

On of my goals was to have all the files that relate to boot up until running GUI (gmenu2x) in one place - meaning the kernel image (zImage), kernel modules, daemon program, miyooctl program, etc... Since they may differ between different handhelds, each handheld gets its own subdirectory in boot/variants/. Which one gets used is controlled by the contents of boot/handheld.txt file. (The only file outside this structure that needs to be copied over when switching kernel/handheld is boot/zImage.)

To make an image which would "work" on different handhelds, there is "firstboot" mechanism: if there exists a boot/firstboot script, it gets run instead of the "normal" boot. By default this script reads handheld.txt, copies zImage to the right place, then also copies some configuration files into the main partition, and then disables itself (so that it doesn't get run again). The point is that any of the kernels themselves actually boot without problems on every handheld (well - I hope. really not sure about the older ones, like bb v1) (but of course screen/keypad/sound/etc may not work). So the idea is that the image would boot (no screen) and fix up the image itself. All the subsequent boots then use the correct kernel and modules and configs.

So - to switch to another kernel/handheld, just create another subdirectory in boot/variants, copy the relevant files in, change handheld.txt to it, and rename firstboot.done to firstboot. Then boot and wait about ~30 secs (for the firstboot script to it its thing). Turn off. Turn on - should boot into the new kernel. (Alternatively, instead of running firstboot, just overwrite also boot/zImage and adjust any configs in the main partition manually.)

As far as a "single image" goes, the procedure would go: a) write the universal image, b) mount boot (it's FAT16 so it should work on windows as well), c) edit handheld.txt to the right handheld, d) turn on, wait ~30 secs, e) turn off. Done. (Or perhaps whip up some windows program that would do the above and have a drop-down for handheld. Or something.)

Installation

I haven't produced full images yet - there is no point until we also get a new rootfs (well maybe for L2/R2 support...)

So for the moment, grab the attached archive miyooboot.zip, which contains the new contents of the boot partition (it has the boot script(s) and kernels/modules harvested from several CFW 1.3.3 images). Get a CFW 1.3.3 image, write it to a micro SD card. Mount the boot partition, erase everything there, and copy everything from the miyooboot directory that you get by unpacking the boot pack you just downloaded from here. Edit the handheld.txt file so that it contains only the name of a subdirectory of variants that you want to use. (Case matters.) (I can make this a little more damage-proof if needed...)

Now the tricky bit. You will need to replace also the etc/main file on the ext4 partition called rootfs, by the one of the files from the boot pack, namely variants/backup/main. I have no idea how can one do this on windows.

I would appreciate if anyone could test this, but it does require messing with the existing image...

I tested both firstboot and normal boots with this on my V90 and Bittboy V3.5, but I have no other handhelds from this line.

Please also audit the whole boot process (i.e. etc/main and firstboot) if you can.

If you just want to have a look at main and firstboot, I made a temporary repository here - this one doesn't contain the binaries (meaning zImages, modules, daemons, etc).

Going forward

Need to find out what other config files differ between handhelds, and add them to variants/* and firstboot.

Currently there is a lot of duplication in variants/* - every subdir contains everything. Perhaps could move some of those to variants/common.

Check if this approach could be accepted.

Either build a whole image, or (better) see if I can create a working rootfs from sauce's buildroot.

Clear up kernel image building for various handhelds.

Automate automate automate.

[flabbergast]

OK got good a pretty nice simplification (if I can say so myself). miyooboot.zip and also in the non-binaries repo.

We can use u-boot's boot.scr to load handheld variant directly - so we do not need to copy zImage around anymore. It gets loaded from the appropriate variants/* subfolder using the information in handheld.txt.

In practice this means that switching kernels simplifies to: a) creating a subfolder in variants/ with the files, b) editing handheld.txt to point to the new directory.

This also means that depending on how much non-boot configs we need to copy to the main partition that differ between handhelds, we may be able to completely forego the firstboot mechanism.

(Oh and the v90_q90 kernel in the attachment has the fixed L2/R2 support enabled.)

[flabbergast]

I made an image if anyone wants to test, it is here. It is a barebones 1GB image. It has the new boot scheme, freshly compiled kernel for v90 and bittboy 3.5, old kernels for the rest; and rootfs, uboot, and gmenu2x from cfw 1.3.3.

How to use:

1. Write the img onto a micro sd card.
2. Mount the BOOT partition
3. Edit the handheld.txt file there. It should contain just one line: HANDHELD_TYPE=xxxx where xxxx is the name of one of the subdirectories in BOOT/variants.
4. Boot in your handheld.

On the first boot, it should do a few things, like copy some config files and write the correct u-boot. Please wait until it turns itself off. On BB3.5, V90/Q90, PocketGo you should see the progress on the screen, however on the older ones the screen will be most likely blank, so please wait about 1 minute (for safety) turning the handheld off.

If you want to swap the micro sd into another handheld, edit the handheld.txt file and rename firstboot.done to firstboot (this triggers the 'first boot' procedure above).

If you want to test another kernel, just create a new directory inside variants (probably copy an existing one), replace the files you want, and edit handheld.txt.

Any tests, especially on older handhelds are appreciated.

[TriForceX]

Ok ive tried the latest test image on a bb v3.5

Theres my check:

• First boot splash appears upside down (Maybe we can set a "first boot upside down image"?)
• After the boot splash screen the console start to load stuff and then the screen goes to black, idk if thats "the progress on the screen" you talked about, but it was fast and then the black screen, we may set an alert like "press any to restart" or if we cant trigger the system restart we can put something like "first setup finished, press any key to turn off"
• Then everyting goes as expected, correct screen direction, working keyboard, sound, etc...
• I may suggest to change the filename to "console.cfg" because due the language barrier the word "console" is more accurate (or understandable). Also the i think we should use ".cfg" extension as an standard of configuration files (like in other apps)

This is my thoughts for now. Do you have all of this in a different branch in your fork? so i can check some things.

Very nice job!

[TriForceX]

Ok now tested on a powkiddy V90.

• first boot logo has the correct orientation
• after first setup, in the second boot, the keyboard has problems, a forced shutdown was required to turn on again, then in the third boot the keyboard worked fine. but after more tests reseting the console (properly) sometimes the keyboard is has issues again (it seems to be random, i havent tried that on my bittboy)
• L2 and R2 works fine on the psx emulator
• vibration is not working (tested on circuit dude)

[flabbergast]

Thank you!

Ok ive tried the latest test image on a bb v3.5 First boot splash appears upside down (Maybe we can set a "first boot upside down image"?)

The image is embedded in u--boot and it is the first thing of code that runs off of the micro sd, without any external configuration... so the image is going to be upside-down on either bb3.5 or pg/v90/q90. We can perhaps do a symmetric image... This could also be specifically for the first run, because the firstbot scripts overwrite the whole u-boot anyway.

After the boot splash screen the console start to load stuff and then the screen goes to black, idk if thats "the progress on the screen" you talked about, but it was fast and then the black screen, we may set an alert like "press any to restart" or if we cant trigger the system restart we can put something like "first setup finished, press any key to turn off"

It should have written out some messages in green, then wait for 5 seconds, and then power off (black screen). If the screen was black right after the splash screen then it could be a brightness issue.

I may suggest to change the filename to "console.cfg" because due the language barrier the word "console" is more accurate (or understandable). Also the i think we should use ".cfg" extension as an standard of configuration files (like in other apps)

Yes that's a good idea. (EDIT: it's now in a new branch, i will switch to it for new test images.)

Do you have all of this in a different branch in your fork? so i can check some things.

The boot stuff is in this repo for now including some of the kernels as well.

[flabbergast]

Ok now tested on a powkiddy V90. after first setup, in the second boot, the keyboard has problems, a forced shutdown was required to turn on again, then in the third boot the keyboard worked fine. but after more tests reseting the console (properly) sometimes the keyboard is has issues again (it seems to be random, i havent tried that on my bittboy)

I've had that happen to me once. I do not know what's causing it. It may be that it's something with the new kernel. There is also v90_q90.orig variant which should be functionally equivalent to 1.3.3 (same kernel/daemon/etc from the 1.3.3 image).

(EDIT: if the keyboard is "messed up", it means that the miyoo_kbd driver doesn't get correctly set to "version 4" here. To shut down cleanly hold "D-pad down" (shows the shutdown popup), then press "X button" to confirm.)

L2 and R2 works fine on the psx emulator

👍

vibration is not working (tested on circuit dude)

My V90 has no motor (one of the later ones); this is likely to be a kernel config thing - I do get 'could not configure motor' message in dmesg.

[flabbergast]

I am also getting random "hiccups" (the handheld seems to freeze for a fraction of a second) on the new kernel on a V90 (v90_q90 variant). All seems fine on the old one (v90_q90.orig) variant.

[TriForceX]

The image is embedded in u--boot and it is the first thing of code that runs off of the micro sd, without any external configuration... so the image is going to be upside-down on either bb3.5 or pg/v90/q90. We can perhaps do a symmetric image... This could also be specifically for the first run, because the firstbot scripts overwrite the whole u-boot anyway.

Ive checked the script now, ure right... also that reminds me to merge my updates with the current miyoo logo on uboot source...

It should have written out some messages in green, then wait for 5 seconds, and then power off (black screen). If the screen was black right after the splash screen then it could be a brightness issue.

i also was thinking to add some delay between some important messages, a regular user may not notice about them because the process is fast sometime (atleast in the bb v3.5)

The boot stuff is in this repo for now including some of the kernels as well.

thanks i already checked now. btw we may think in a proper repo to have this under miyoo stuff (or maybe on a current of its repos)

My V90 has no motor (one of the later ones); this is likely to be a kernel config thing - I do get 'could not configure motor' message in dmesg.

The v90 where was tested has a motor working, mmm, maybe something was messed on the current source? idk, i will check the motor code later.

I am also getting random "hiccups" (the handheld seems to freeze for a fraction of a second) on the new kernel on a V90 (v90_q90 variant). All seems fine on the old one (v90_q90.orig) variant.

mmm, same as the other bb v2 white screen, the motor problem, and the hiccups, clearly the compiled kernel files included on the latest cfw was not taken from the latest source at that moment... and we have to deal with this now, nice lol. if you see more weird stuff take notes please.

[flabbergast]

New image here.

• Increased screen brightness in the firstboot script; this would hopefully make it clearer what is happening.
• Switched to the new naming scheme: the main config in BOOT is console.cfg and the variable is called CONSOLE_VARIANT. (Thanks, TriForce!)
• Rumble motor should be fixed (works on BB3.5, hopefully it will work on your V90 as well), because of the next point:
• Updated versions of daemon and miyooctl for v90_q90 and bittboy3.5 variants.

I am hoping that some of the issues may go away. I think some of the problems stemmed from the fact that the original daemon tried to initialise some values for keypad and motor, which were incorrect for these handhelds, and then I ran miyooctl to change them. The point is that it is actually the whole pair/triple of kernel/daemon/miyooctl that affects the low level behaviour of the system.

So I messed with daemon and miyooctl code. I removed the keypad and motor initialisation parts from daemon, and rewrote miyooctl so that now it can change various ioctls independently of each other (and has more standard boilerplate command line handling code). See the links to the daemon and miyooctl branches above. I wanted to basically separate the "initialisation" code (the ioctl calls that tell kernel drivers which versions of hardware it should expect) - that would be handled by miyooctl alone - and "daemon" code - like button shortcuts/combos, etc, that are supposed to be handled the whole time.

[flabbergast]

Ive checked the script now, ure right... also that reminds me to merge my updates with the current miyoo logo on uboot source...

That would be great! The current sources "sort of" work, in that they boot, but they don't have the screen driver enabled, and even when enabled the init code is a little different from the r61520fb driver...

i also was thinking to add some delay between some important messages, a regular user may not notice about them because the process is fast sometime (atleast in the bb v3.5)

Yes, that's certainly possible...

The boot stuff is in this repo for now including some of the kernels as well.

thanks i already checked now. btw we may think in a proper repo to have this under miyoo stuff (or maybe on a current of its repos)

I think it needs to mature somewhat for any official support. Once the setup stabilises, perhaps...

mmm, same as the other bb v2 white screen, the motor problem, and the hiccups, clearly the compiled kernel files included on the latest cfw was not taken from the latest source at that moment... and we have to deal with this now, nice lol. if you see more weird stuff take notes please.

Hopefully the new image will resolve some of this. Although I do not understand what's wrong with v2 - that should be functionally equivalent to cfw 1.3.3 - the same kernel+driver, the same daemon - i just took the files from cfw 1.3.3 image. Just the boot scripts are reshuffled a bit.

[flabbergast]

Another image for testing here (this is wetransfer, so only valid for a week).

• variants convention: .orig variants are binaries from CFW 1.3.3 release
• the freshly compiled kernels have version 4.14.0-miyoo to match the 1.3.3 ones
• all variants use either bittboy3.5 or v90/q90/pocketgo u-boot (!!) - this needs testing on older devices (it is adjustable in variants/VARIANT/firstboot.custom.sh)
• there is a resize mechanism on firstboot: if there is a file called resize (can be empty) on the BOOT partition, firstboot (should) resize the MAIN partition to max size. (I did not put it there by default for now, because resizing takes quite some time, especially on big micro sd cards.)

[TriForceX]

Very good! here are my tests:

• The resize mechanism works fine (testd on 8gb sd cards), but the MAIN partition lost the FAT format and gets recognized later as RAW partition on Windows (without label), so is not accesible anymore from there.
• On bittboy2x ive tested the image without changing the console.cfg (because i forgot) and everything worked using the v90 variable (obviously the keyboard was changed and screen was upsidedown), but im telling you this because when i installed again using bittboy2x the boot logo appeared as usual, but then some glitches appeared to the screen (instead the console stuff) and changed to black few seconds later, so i waited until the screen backlight turned off and then i turned on again, everything worked fine after that. (the glitched console at first boot is still weird, that didnt happened before)

EDIT: Checking with another partition tool, it says now FAT32 on MAIN format, but something happened that makes the partition unaccesible from windows (see pic)

[flabbergast]

The resize mechanism works fine (testd on 8gb sd cards), but the MAIN partition lost the FAT format and gets recognized later as RAW partition on Windows (without label), so is not accesible anymore from there. EDIT: Checking with another partition tool, it says now FAT32 on MAIN format, but something happened that makes the partition unaccesible from windows (see pic)

Thank you for the test - I don't have windows to test on ;)

Fsck on my linux after resize always gives "There is no label in boot sector, but there is volume label 'MAIN' stored in root directory" (which it fixes), so I suppose this is the issue. (My linux works with the partition no problem even without fixing it, I was hoping windows will as well.) The fsck in rootfs does not catch it however, so I will put a new fsck.vfat on the BOOT partition. So hopefully this issue will be fixed on the next image.

On bittboy2x ive tested the image without changing the console.cfg (because i forgot) and everything worked using the v90 variable (obviously the keyboard was changed and screen was upsidedown), but im telling you this because when i installed again using bittboy2x the boot logo appeared as usual, but then some glitches appeared to the screen (instead the console stuff) and changed to black few seconds later, so i waited until the screen backlight turned off and then i turned on again, everything worked fine after that. (the glitched console at first boot is still weird, that didnt happened before)

I had the same thing on my bittboy3.5, same glitch on the first boot after firstboot ;) Don't know, something in u-boot-bittboy3.5.bin? We should really fix and start using the actual u-boot sources rather than keep using the old binaries scavenged from 1.3.3 image...

(EDIT: formatting)

[TriForceX]

I will just left this info as a reminder.

To solve the the issue of the resized partition not accesible on windows, this linkes must be added to the firstboot script: More info about "the reason" here: https://paalijarvi.fi/tgblog/2019/09/18/fix-fat32-turning-raw-after-resize-in-linux-gparted/

It worked on bittboy v3.5 and windows 10