Hi Folks,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
The first one that is noticeable is a bootmenu during the firmware init process where it will allow you to select the device/partition you wish to boot from, with the default selected and the usual time out. It should make things a little easier for things like reinstalling off a USB stick for devices that support that sort of install.
I've done some testing across a bunch of devices, various RPi, the Pinebook pro and numerous SBCs so I think it should work just fine, at least be no different than the usual process but I'd like to hear any feedback.
Regards, Peter
Hello, Peter.
On Saturday, 19 August 2023 at 19:53, Peter Robinson wrote:
Hi Folks,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
The first one that is noticeable is a bootmenu during the firmware init process where it will allow you to select the device/partition you wish to boot from, with the default selected and the usual time out. It should make things a little easier for things like reinstalling off a USB stick for devices that support that sort of install.
I've done some testing across a bunch of devices, various RPi, the Pinebook pro and numerous SBCs so I think it should work just fine, at least be no different than the usual process but I'd like to hear any feedback.
I copied the Pinebook Pro u-boot binaries from uboot-images-armv8-2023.10-0.4.rc3.fc39.noarch.rpm (https://koji.fedoraproject.org/koji/buildinfo?buildID=2277261) from /usr/share/uboot/pinebook-pro-rk3399/ to a μSD card (previously formatted using spi-flashing disk script). Then I did the steps from https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ "Write the firmware to flash" section.
Unfortunately, after reset (or power-off/power-on cycle), I get this: ... U-Boot SPL 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000) Trying to boot from SPI Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error Trying to boot from SPI Trying to boot from MMC2 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I checked the spi-flashing-disk script, and all it does is create a vfat formatted partition and copy the 4 binaries from the directory corresponding to the board model. I think I did everything correctly, so is the new u-boot broken on PBP?
Regards, Dominik
Hi Dominik,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
The first one that is noticeable is a bootmenu during the firmware init process where it will allow you to select the device/partition you wish to boot from, with the default selected and the usual time out. It should make things a little easier for things like reinstalling off a USB stick for devices that support that sort of install.
I've done some testing across a bunch of devices, various RPi, the Pinebook pro and numerous SBCs so I think it should work just fine, at least be no different than the usual process but I'd like to hear any feedback.
I copied the Pinebook Pro u-boot binaries from uboot-images-armv8-2023.10-0.4.rc3.fc39.noarch.rpm (https://koji.fedoraproject.org/koji/buildinfo?buildID=2277261) from /usr/share/uboot/pinebook-pro-rk3399/ to a μSD card (previously formatted using spi-flashing disk script). Then I did the steps from https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ "Write the firmware to flash" section.
Unfortunately, after reset (or power-off/power-on cycle), I get this: ... U-Boot SPL 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000) Trying to boot from SPI Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error Trying to boot from SPI Trying to boot from MMC2 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I checked the spi-flashing-disk script, and all it does is create a vfat formatted partition and copy the 4 binaries from the directory corresponding to the board model. I think I did everything correctly, so is the new u-boot broken on PBP?
I've confirmed a similar problem, I was testing some of this on the PBP against RC2 as I was developing it but never tested the RC3. Any chance you can grab one of the RC2 builds from koji [1] and see if you have better luck? Also maybe 2023.07 from koji too. I'll try and get to the bottom of this in the next week or so.
[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=10432
On Wednesday, 23 August 2023 at 09:25, Peter Robinson wrote:
Hi Dominik,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
The first one that is noticeable is a bootmenu during the firmware init process where it will allow you to select the device/partition you wish to boot from, with the default selected and the usual time out. It should make things a little easier for things like reinstalling off a USB stick for devices that support that sort of install.
I've done some testing across a bunch of devices, various RPi, the Pinebook pro and numerous SBCs so I think it should work just fine, at least be no different than the usual process but I'd like to hear any feedback.
I copied the Pinebook Pro u-boot binaries from uboot-images-armv8-2023.10-0.4.rc3.fc39.noarch.rpm (https://koji.fedoraproject.org/koji/buildinfo?buildID=2277261) from /usr/share/uboot/pinebook-pro-rk3399/ to a μSD card (previously formatted using spi-flashing disk script). Then I did the steps from https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ "Write the firmware to flash" section.
Unfortunately, after reset (or power-off/power-on cycle), I get this: ... U-Boot SPL 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000) Trying to boot from SPI Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error Trying to boot from SPI Trying to boot from MMC2 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I checked the spi-flashing-disk script, and all it does is create a vfat formatted partition and copy the 4 binaries from the directory corresponding to the board model. I think I did everything correctly, so is the new u-boot broken on PBP?
I've confirmed a similar problem, I was testing some of this on the PBP against RC2 as I was developing it but never tested the RC3.
I wish I had known that before trying the latest build. :(
Any chance you can grab one of the RC2 builds from koji [1] and see if you have better luck? Also maybe 2023.07 from koji too. I'll try and get to the bottom of this in the next week or so.
Unfortunately, it'll take some time, because the SPL is unable to load the next stage from SD and I have to enter the maskrom mode[1] to zero the SPI. Would you happen to have instructions on how to build an image that can be flashed in that mode using rkdeveloptool wl 0 newspi.bin ? That'd make things easier. I don't have time to open my PBP right now and probably won't have it for a couple of weeks.
[1] https://wiki.pine64.org/wiki/Pinebook_Pro_SPI
Regards, Dominik
Le sam. 19 août 2023 à 19:53, Peter Robinson pbrobinson@gmail.com a écrit :
Hi Folks,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
...
least be no different than the usual process but I'd like to hear any feedback.
I have an issue on jetson-tx1 (L4T 32.7.4) with this f39 u-boot build: Everything operates correctly under u-boot, but then after entering initramfs the CPU hard lockup.
Using a previous 2023.07 or self compiled u-boot 2023.10-rc3 (cross compiled under fc37) works as appropriate. I will try to reproduce a local build with fedora patches applied...
Here is the following output
Welcome to Fedora Linux 38 (Workstation Edition) dracut-059-3.fc38 (Initramfs)!
[ 135.415665] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 135.421756] rcu: 1-...!: (4 GPs behind) idle=2e28/0/0x0 softirq=270/270 fqs=0 (false positive?) [ 135.430532] rcu: 2-...!: (0 ticks this GP) idle=0a28/0/0x0 softirq=129/129 fqs=0 (false positive?) [ 135.439567] rcu: 3-...!: (3 GPs behind) idle=1c70/0/0x0 softirq=360/360 fqs=0 (false positive?) [ 135.448341] rcu: (detected by 0, t=60002 jiffies, g=549, q=7 ncpus=4) [ 135.454857] Task dump for CPU 1: [ 135.458077] task:swapper/1 state:R running task stack:0 pid:0 ppid:1 flags:0x00000008 [ 135.467985] Call trace: [ 135.470425] __switch_to+0xc8/0xf8 [ 135.473830] cpuidle_enter+0x40/0x60 [ 135.477404] cpuidle_idle_call+0x124/0x1a8 [ 135.481500] do_idle+0xa8/0xf8 [ 135.484552] cpu_startup_entry+0x30/0x40 [ 135.488470] secondary_start_kernel+0xe0/0x108 [ 135.492913] __secondary_switched+0xb8/0xc0 [ 135.497090] Task dump for CPU 2: [ 135.500309] task:swapper/2 state:R running task stack:0 pid:0 ppid:1 flags:0x00000008 [ 135.510213] Call trace: [ 135.512652] __switch_to+0xc8/0xf8 [ 135.516049] cpuidle_enter+0x40/0x60 [ 135.519618] cpuidle_idle_call+0x124/0x1a8 [ 135.523709] do_idle+0xa8/0xf8 [ 135.526759] cpu_startup_entry+0x30/0x40 [ 135.530677] secondary_start_kernel+0xe0/0x108 [ 135.535117] __secondary_switched+0xb8/0xc0 [ 135.539292] Task dump for CPU 3: [ 135.542510] task:swapper/3 state:R running task stack:0 pid:0 ppid:1 flags:0x00000008 [ 135.552413] Call trace: [ 135.554851] __switch_to+0xc8/0xf8 [ 135.558247] cpuidle_enter+0x40/0x60 [ 135.561816] cpuidle_idle_call+0x124/0x1a8 [ 135.565907] do_idle+0xa8/0xf8 [ 135.568956] cpu_startup_entry+0x2c/0x40 [ 135.572873] secondary_start_kernel+0xe0/0x108 [ 135.577312] __secondary_switched+0xb8/0xc0 [ 135.581489] rcu: rcu_preempt kthread timer wakeup didn't happen for 59999 jiffies! g549 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 [ 135.592774] rcu: Possible timer handling issue on cpu=2 timer-softirq=24 [ 135.599549] rcu: rcu_preempt kthread starved for 60002 jiffies! g549 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=2 [ 135.609880] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. [ 135.618992] rcu: RCU grace-period kthread stack dump: [ 135.624031] task:rcu_preempt state:I stack:0 pid:17 ppid:2 flags:0x00000008 [ 135.632370] Call trace: [ 135.634809] __switch_to+0xc8/0xf8 [ 135.638205] __schedule+0x284/0x730 [ 135.641688] schedule+0x64/0x108 [ 135.644910] schedule_timeout+0xa4/0x1b8 [ 135.648828] rcu_gp_fqs_loop+0x120/0x4c0 [ 135.652748] rcu_gp_kthread+0x180/0x1e8 [ 135.656576] kthread+0xf4/0x108 [ 135.659714] ret_from_fork+0x10/0x20 [ 135.663286] rcu: Stack dump where RCU GP kthread last ran: [ 135.668758] Task dump for CPU 2: [ 135.671977] task:swapper/2 state:R running task stack:0 pid:0 ppid:1 flags:0x00000008 [ 135.681879] Call trace: [ 135.684316] __switch_to+0xc8/0xf8 [ 135.687712] cpuidle_enter+0x40/0x60 [ 135.691282] cpuidle_idle_call+0x124/0x1a8 [ 135.695373] do_idle+0xa8/0xf8 [ 135.698422] cpu_startup_entry+0x30/0x40 [ 135.702339] secondary_start_kernel+0xe0/0x108 [ 135.706778] __secondary_switched+0xb8/0xc0 [ 135.712124] systemd[1]: No hostname configured, using default hostname. [ 135.719358] systemd[1]: Hostname set to <fedora>. [ 135.724708] systemd[1]: Initializing machine ID from random generator. [ 156.038664] watchdog: Watchdog detected hard LOCKUP on cpu 3 [ 156.044324] Modules linked in:
Le mer. 23 août 2023 à 14:01, Nicolas Chauvet kwizart@gmail.com a écrit :
Le sam. 19 août 2023 à 19:53, Peter Robinson pbrobinson@gmail.com a écrit :
Hi Folks,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
...
least be no different than the usual process but I'd like to hear any feedback.
I have an issue on jetson-tx1 (L4T 32.7.4) with this f39 u-boot build: Everything operates correctly under u-boot, but then after entering initramfs the CPU hard lockup.
Just some follow-up about this issue. I've tested again recently (with 2023.10 GA rebased from f39 packages). And the issue still arises with me. But it could be because of some mess with /boot/dtb symlink and device-tree location expectation. (my /boot/dtb wasn't updated
When I tried to report to #u-boot upstream, it's the first question that was raised (is device-tree rightly found ?). Of course our distro patch might help
The problem is that in-between I've broken my micro-usb port, so I cannot update u-boot anymore on the jetson-tx1 (and I'm stuck with fedora based u-boot 2023.07 there).
Anyway, I don't think it's a blocker for F39 GA, so if anyone is able to reproduce (or not) it is worth mentioning in the wiki.
Hi Nicolas,
Hi Folks,
The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements.
...
least be no different than the usual process but I'd like to hear any feedback.
I have an issue on jetson-tx1 (L4T 32.7.4) with this f39 u-boot build: Everything operates correctly under u-boot, but then after entering initramfs the CPU hard lockup.
Just some follow-up about this issue. I've tested again recently (with 2023.10 GA rebased from f39 packages). And the issue still arises with me. But it could be because of some mess with /boot/dtb symlink and device-tree location expectation. (my /boot/dtb wasn't updated
There was a bug with grub2 here, but it never made it to GA, of course with updates-testing enabled by default anyone running pre freeze F-39 got it: https://bugzilla.redhat.com/show_bug.cgi?id=2243060
When I tried to report to #u-boot upstream, it's the first question that was raised (is device-tree rightly found ?). Of course our distro patch might help
The Jetson (pre Xavier) devices won't boot without the kernel DT, the DT provided by U-Boot has some issue around the global timer and the kernel crashes in very early boot. It's something that I've been meaning to look into but haven't had the time.
The problem is that in-between I've broken my micro-usb port, so I cannot update u-boot anymore on the jetson-tx1 (and I'm stuck with fedora based u-boot 2023.07 there).
2023.07? That's still quite new.
Anyway, I don't think it's a blocker for F39 GA, so if anyone is able to reproduce (or not) it is worth mentioning in the wiki.
I can reproduce, and I have been looking into it along with the issues with the RPi4. I have currently 5 or 6 issues on my list including 3 with the RPi, these ones and possibly more. The issues for some reason which I'm unsure about are proving very difficult to bisect which is causing me issues around timing but overall I am hoping to get to the bottom of them all tomorrow and a new official build done, I was planning on replying on this thread when I have a new package for testing.
Peter
-
Dominik 'Rathann' Mierzejewski -
Nicolas Chauvet -
Peter Robinson