Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Vagrant Cascadian]

On 2024-01-12, Michael Fladischer wrote:
> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no
> longer able to see any NVME drives:
...
> U-Boot 2024.01+dfsg-1 (Jan 10 2024 - 21:34:04 +0000)
>
> CPU: rv64imafdc
> Model: SiFive HiFive Unmatched A00
> DRAM: 16 GiB
> Core: 34 devices, 21 uclasses, devicetree: separate
> MMC: spi@10050000:mmc@0: 0
> Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
> *** Warning - bad CRC, using default environment
>
> EEPROM: SiFive PCB EEPROM format v1
> Product ID: 0002 (HiFive Unmatched)
> PCB revision: 4
> BOM revision: B
> BOM variant: 0
> Serial number: SF105SZ233800886
> Ethernet MAC address: 70:b3:d5:92:fe:ea
> CRC: d2ac1d5b
> pwren_gpio is invalid
> In: serial@10010000
> Out: serial@10010000
> Err: serial@10010000
> Model: SiFive HiFive Unmatched A00
> Net: eth0: ethernet@10090000
> Working FDT set to ff72f630
> Hit any key to stop autoboot: 0
> pwren_gpio is invalid
>
> Device 0: unknown device
> pwren_gpio is invalid
>
> Device 1: unknown device
> starting USB...
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
> pwren_gpio is invalid
> scanning bus for devices...

I am getting this too. I had tested with a local build of
2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of
the very few commits between v2024.01-rc6 and v2024.01 seem relevent.

I also wonder about opensbi, which was fairly recently upgraded,
although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had
done...

Hrm. Will look a little deeper.

I doubt it ws the removed
unmatched-prevent-relocating-initrd-and-fdt.patch, as it is not even
detecting the NVMe device... and the symptoms that necessitated that
patch are after extlinux.conf is already loaded and the kernel attempts
to boot...

live well,
vagrant

[Vagrant Cascadian]

On 2024-01-12, Vagrant Cascadian wrote:
> On 2024-01-12, Michael Fladischer wrote:
>> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
>> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no
>> longer able to see any NVME drives:
...

> I am getting this too. I had tested with a local build of
> 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of
> the very few commits between v2024.01-rc6 and v2024.01 seem relevent.

I should also note that I am testing with u-boot on microSD, so it is
not specific to u-boot from SPI.

> I also wonder about opensbi, which was fairly recently upgraded,
> although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had
> done...

I verified u-boot-sifive 2024.01~rc6+dfsg-2 (formerly in experimental)
works, which was built with the same opensbi version. In fact, the only
difference in the installed build-dependencies were perl related:

- libperl5.36 (= 5.36.0-10+b1),
+ libperl5.38 (= 5.38.2-2),
- perl (= 5.36.0-10+b1),
- perl-base (= 5.36.0-10+b1),
- perl-modules-5.36 (= 5.36.0-10),
+ perl (= 5.38.2-2),
+ perl-base (= 5.38.2-2),
+ perl-modules-5.38 (= 5.38.2-2),

I am attempting a local rebuild, will see how that goes...

live well,
vagrant

[Vagrant Cascadian]

Well, rebuilding and just adding a new debian/changelog
entry... worked. both from a reboot and from a cold start.

That does not leave much to investigate, so is a bit worrying, but
perhaps a binNMU would "fix" it?

live well,
vagrant

[Aurelien Jarno]

I tried to do a build from the sources using sbuild, and I ended up with
exactly the same binaries, so unfortunately I doubt a binNMU would fix
it.

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://aurel32.net

[Aurelien Jarno]

control: tag -1 + upstream

I have spent some time on that, I haven't found the issue, but here are
my findings:

- Rebuilding the package with the current packages from sid, leads to a
slightly different issue: reset_gpio is invalid

- The issue is reproducible building the upstream version 2024.01

- The actual error message changes with the value of
CONFIG_LOCALVERSION:
- If the final version is "2024.01", I get:
__wrpll_calc_filter_range: post-divider reference freq out of range: 4294967295__wrpll_calc_filter_range: post-divider reference freq out of range: 4294967295__wrpll_calc_filter_range: post-divider reference freq out of range: 4294967295__wrpll_calc_filter_range: post-divider reference freq out of range: 4294967295initcall failed at call 00000000fff5920e (err=-34)

- If the final version is "2024.01+test-1", I get:
reset_gpio is invalid

- If the final version is "2024.01+test-1+abc", I get:
pwren_gpio is invalid

- So far I have not been able to reproduce the issue with gcc-12, which
doesn't mean that the bug is gcc-13 specific.

- This seems to be the same bug as: https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2054091

[Heinrich Schuchardt]

Related Launchpad bug:

HiFive Unmatched: __wrpll_calc_filter_range: post-divider reference freq
out of range: 4294967295
https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2054091