2025.01-rc2 fails to boot on VisionFive2
E Shattow
lucent at gmail.com
Thu Nov 21 22:42:02 CET 2024
On Thu, Nov 21, 2024 at 9:21 AM Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 21.11.24 17:22, Andreas Schwab wrote:
> > On Nov 21 2024, Heinrich Schuchardt wrote:
> >
> >> On 13.11.24 11:31, Andreas Schwab wrote:
> >>> "Error reading cluster" is the new error.
> >>> U-Boot SPL 2025.01-rc2 (Nov 08 2024 - 07:13:26 +0000)
> >>> DDR version: dc2e84f0.
> >>> Trying to boot from MMC2
> >>> U-Boot 2025.01-rc2 (Nov 08 2024 - 07:13:26 +0000)
> >>> CPU: sifive,u74-mc
> >>> Model: StarFive VisionFive 2 v1.2A
> >>> DRAM: 4 GiB
> >>> Core: 136 devices, 26 uclasses, devicetree: board
> >>> WDT: Not starting watchdog at 13070000
> >>> MMC: mmc at 16010000: 0, mmc at 16020000: 1
> >>> Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
> >>> *** Warning - bad CRC, using default environment
> >>> StarFive EEPROM format v2
> >>> --------EEPROM INFO--------
> >>> Vendor : StarFive Technology Co., Ltd.
> >>> Product full SN: VF7110A1-2249-D004E000-00000408
> >>> data version: 0x2
> >>> PCB revision: 0xa1
> >>> BOM revision: A
> >>> Ethernet MAC0 address: 6c:cf:39:00:16:8d
> >>> Ethernet MAC1 address: 6c:cf:39:00:16:8e
> >>> --------EEPROM INFO--------
> >>> starfive_7110_pcie pcie at 2b000000: Starfive PCIe bus probed.
> >>> starfive_7110_pcie pcie at 2c000000: Starfive PCIe bus probed.
> >>> In: serial at 10000000
> >>> Out: serial at 10000000
> >>> Err: serial at 10000000
> >>> Net: eth0: ethernet at 16030000, eth1: ethernet at 16040000
> >>> starting USB...
> >>> Bus xhci_pci: Register 5000420 NbrPorts 5
> >>> Starting the controller
> >>> USB XHCI 1.00
> >>> scanning bus xhci_pci for devices... 2 USB Device(s) found
> >>> scanning usb for storage devices... 0 Storage Device(s) found
> >>> Working FDT set to ff72ca10
> >>> Hit any key to stop autoboot: 0
> >>> Card did not respond to voltage select! : -110
> >>> ** Booting bootflow '<NULL>' with efi_mgr
> >>> Error reading cluster
> >>
> >> This is a message from the FAT file system driver.
> >
> > The file system is ok when read after interrupting the boot.
>
> That ls works does not mean that the file system is not corrupted.
>
> dosfsck will tell you if there is something wrong.
>
> >
> > StarFive # mmc dev 1
> > switch to partitions #0, OK
> > mmc1 is current device
> > StarFive # ls mmc 1:1
> > EFI/
> > 304 ubootefi.var
> >
> > 1 file(s), 1 dir(s)
> >
> > StarFive # ls mmc 1:1 EFI
> > ./
> > ../
> > BOOT/
> >
> > 0 file(s), 3 dir(s)
> >
> > StarFive # ls mmc 1:1 EFI/BOOT
> > ./
> > ../
> > 167936 BOOTRISCV64.EFI
> > 164 grub.cfg
> >
> > 2 file(s), 2 dir(s)
> >
> > But running boot will end with the above error, and mmc 1 no longer
> > works.
> >
> >> Which image reproduces the problem?
> >
> > I've built U-Boot here
> > <https://build.opensuse.org/project/show/home:Andreas_Schwab:riscv:u-boot>.
> >
>
> I was asking which SD-card image that was used, e.g. some Suse
> preinstalled image.
>
> Best regards
>
> Heinrich
Hi Andreas,
There is an offset (1GB?) in address space to DRAM. On boards having
4GB DRAM and more there is a failure to load data with mmc driver to
the 4GB memory address. . If you load data smaller than the length of
the offset to the 4GB address it is a valid action, however the MMC
driver limitation will cause this to fail. Similarly you can load that
same data to $loadaddr (2GB+320MB) or $kernel_addr_r (1GB+2MB) and
that does not cause a problem.
Try 'load' from mmc storage and experiment with addresses above and
below 0x100000000 (1024*1024*1024*4) this way to get a failure and a
success. When there is a failure then the mmc storage appears to not
respond in future requests. The content of data being transferred (OS
image, EFI app, ...) does not matter there, so it should be easy to
test for.
-E
More information about the U-Boot
mailing list