RPi 3B+

[procount]

Will you be updating your gentoo64 images for the latest RPi 3B+ that just came out?

[sakaki-]

When I get my hands on one, yes ^-^ The CPU is (basically) the same, just clocked a bit faster, but the WiFi may need some tweaking, as it is dual-band. Hopefully nothing too major will need doing though.

[procount]

I'm just converting PINN. The 3B+ needs new firmware, wifi driver, LAN/USB driver and kernel is bumped to 4.9.80. Now I'm just converting my additional wifi drivers for buildroot.

[sakaki-]

OK, thanks. In fact, I was just about to bump the kernel to the 4.14.y branch on the image, as this has all the VC4 stuff backported; hopefully this will also work for the newer model. Hope to get my B+ by the end of this week.

[JaceAlvejetti]

I got three B+'s today, can't wait for your release, outside of the B+ requirements above, there iss nothing making general packages incompatible is there? was hoping to add these to my two Bs which already use each other for compiling (distcc) on top of what I intend them for.

[sakaki-]

@JaceAlvejetti,

Other than the necessary (additional) kernel config / drivers & (updated) firmware, the userland packages are fully binary compatible between the 3B and 3B+. So there's no problem mixing and matching in a distcc farm, for example.

I have a fully working 64-bit 3B+ system running locally now (see my note here) so I just need to package the changes and then I can test and release.

Hopefully within the next week, real-world commitments permitting ^-^

[sakaki-]

@procount - new images (v1.2.1) up now, if you have a B+ please could you check all looks OK at your end prior to bundling via PINN (seems to work this side but I may have missed something ><). Thanks!

[procount]

Are you still happy with slide1.png showing v1.2, or do you want to update it to v1.2.1?

[sakaki-]

Good point. I've updated the first slide to show 1.2.1, and also to note that it works with the RPi3 models B and B+. The rest of the deck is fine as is. Slide 1 may be found here.

[procount]

It boots on a 3B+ from a local PINN installation

[sakaki-]

Great, many thanks for confirming!

[sakaki-]

@procount,

one other quick question. If one of the operating systems installed by PINN updates its /boot components (kernel, boot firmware or config files) how does that sit with PINN? This wasn't an issue before with this image - the kernel has been static for a long time, so users running genup would just update userspace stuff, however, users upgrading to 1.2.1 from earlier versions are going to have a new binary kernel package and boot firmware package installed. This works OK on a direct microSD card image, but might it mess things up with PINN (cmdline.txt etc)?

[procount]

Use case 1) User has a RPI3b with old PINN and old Gentoo. User updates Gentoo using genup(?) & reboots. Worst case: Gentoo firmware is not compatible with PINN's, so PINN doesn't boot into Gentoo. Gets blank screen or rainbow screen. (Shouldn't be a problem at the moment, but not every OS has been tested). Solution: User is prompted to self-update PINN to latest version and can then switch between the old and new firmware appropriately to boot any OS.

Use case 2) User has a RPI3b and wants to upgrade to a RPI3B+ User updates Gentoo using genup(?)on 3B. Moves SD card to 3B+ and boots. Worst case: Old PINN firmware is not compatible with 3B+ and sits with a rainbow screen, yellow lightning bolt and red power light blinking 4 fast 4 slow. Solution: Put SD card back in pi3B and update PINN to latest version. On archival menu, make sure firmware is upgraded so the button shows 3B+ in red. Move SD card to pi3B+ and boot.

The only issue with PINN booting an OS with regards to updating an OS's firmware is the compatibility between PINN's bootcode.bin and the OS's start.elf. Unfortunately, the interface between these changed a while ago and some very old firmware in some OSes is not compatible with the latest version. It shouldn't be an issue with Gentoo64. I think I have done a "belt and braces" approach so the latest PINN will continue to work with as many OSes as possible. Users just need to let it self-update.

[sakaki-]

OK thanks, that's interesting. I've had a few reports of issues (stuck at boot) after 1.2.0 -> 1.2.1 upgrade; I've tried running this myself on a direct (2 partition) image, but I haven't tested the PINN variant yet. I'll try upgrading a PINN image this weekend and double-check it all goes through OK.

[sakaki-]

Does PINN dynamically remap cmdline.txt to point to the correct root (i.e., each time the O/S is invoked), or does it rewrite this file only during the initial conversion / installation process for an OS? When the Gentoo image updates its firmware package, this file (/boot/cmdline.txt) will be overwritten (the user will be offered the chance to retain the pre-upgrade version, which is of course what they should do, but if they don't, it will be left pointing to the wrong root)...

[procount]

It only does it the once on install, so yes, your upgrade will break it. I had this issue when pinn updates itself so I remove cmdline from this process. However, there is another OS where it is a lot worse, so something is in the pipeline to address this.

[sakaki-]

It only does it the once on install, so yes, your upgrade will break it.

Agreed, and on investigation, I think that is what is happening.

Thinking about it, I should really refactor the boot code: at the moment, there are two relevant packages, bcmrpi3-kernel-bin, which supplies kernel8.img, the dtbs, and the modules, and rpi3-64bit-firmware, which supplies everything else in /boot. However, the latter package should probably not supply the /boot/*.txt files; instead, it should have a dep on a new package (call it rpi3-boot-config or something) which in turn supplies these files (i.e., config.txt and cmdline.txt). This new package would almost never need to be revbumped, so the kernel and other firmware could be upgraded without issue. As mentioned, right now, Gentoo does ask users to confirm they want to proceed with updates to those files (as they are CONFIG_PROTECTed), but it isn't fair to expect all users to know what to do in this case (and the wrong choice leaves them with a non-booting system).

It's too late now to do this for v1.2.1, but I'll try to refactor prior to the next release. In the meantime, I'll add a health warning to the update instructions, to warn users to retain the old version of cmdline.txt, when prompted.

[sakaki-]

Closing this, as the v1.2.1 image seems to work OK on the 3B+. @procount, I'll give you a heads up when the 1.2.2 is coming, so hopefully we can test that the (forthcoming) refactored {cmdline,config}.txt handling can survive a similar full upgrade (should one be required in the future).

[procount]

Ok. Thanks.

[procount]

Hi Sakaki,

I just released v2.8 of PINN. In the maintenance menu there is a new FIX option to repair installed OSes that have broken by optionally doing 1) an fsck on the filesystem and/or 2) re-running the partition_setup.sh script.

The latter option should fix up any changes that the Gentoo upgrade procedure makes like reverting cmdline.txt.

[sakaki-]

Thanks @procount!

Thinking about this, I wonder if it might be worthwhile for PINN to have the option (on an OS-specific basis) to always check, and then if necessary auto-edit, /boot/cmdline.txt at startup. Passwords and /etc/fstab are unlikely to be touched by system upgrades, but the RPi-specific /boot files often are (and even when users are offered the chance to selectively merge changes, as is the case with this image for example, often they will simply accept them wholesale - usually safe, but not if the kernel's root is changed!).

As you could grep /boot/cmdline.txt r/o to see if it needs modding (original image root UUID present or whatever), this would seem to be a reasonably low cost thing to add... and unfortunately the users who get themselves into this situation are also those less likely to find/use your FIX option ^-^

[procount]

Each OS is potentially very different. There are no enforced standards on how to boot them. Some even use Uboot (maybe I'll be able to support it some day). So each OS has its own partition_setup.sh script to fixup all the partition references after it has been moved to its new partitions.

I'm not sure I could make a generic script to detect when an OS has been upgraded and reverted to its original install cmdline.txt. WinIoT and RiscOS for example are quite different. I don't store the original cmdline.txt for comparison. There may not even be one! Some oses run from ramdisk or have more than 2 partitions.

The fixup menu is designed to add future os specific tools & scripts to it, so maybe there could be a specific custom script to check if the OS has been upgraded and will call the partition_setup.sh script (or another) to fix it up. This can run automatically before each boot if we give it a standard name.

Are you able to write a specific busybox shell script (ash/dash?) to detect when a fixup is required for gentoo64? I guess I would pass it the same arguments/env strings that I pass to partition_setup.sh.

[sakaki-]

Yes, I'd be happy to add an ash busybox script to do this auto-fixup-if-required into the next release of the image.

Just let me know the name, location, arguments and expected return values (assuming this is something you want to offer as an option for other O/S providers who use PINN), and I'll put something together for review.

PS if you want to open a fresh issue for this, feel free, it may make things easier to find for others.

Best, sakaki

[procount]

Ok, I'll have a think and a play and get back to you. Let me know if you have any good ideas for script names (auto-fixup-if-required, auto_fix, auto_update etc...)

[sakaki-]

@procount - FYI I've released v1.2.2 of the image. Slide 1 of the deck has been updated too. Thanks!

[procount]

Away in NYC atm, but I'll get onto it as soon as I can.

[Gerschtli]

Hey, maybe i should open a new issue but i have only a question: what did you do to port the kernel etc. to support the rpi3 b+? I can't find the repo or is it closed source?

Thank you!

[sakaki-]

@Gerschtli - apologies for the delay in replying, I have been travelling. The kernel itself requires no special tweaking for the 3B+, but you do need the current default (4.14.y) branch, and up-to-date support firmware. Full details may be found on my Gentoo forums post here ff. hth, sakaki

[procount]

I've now updated Gentoo64 & gentoo64pt in PINN to v1.2.2

[sakaki-]

Thanks!