On Thu, Nov 21, 2024 at 9:21 AM Heinrich Schuchardt <heinrich.schucha...@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@13070000 > >>> MMC: mmc@16010000: 0, mmc@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@2b000000: Starfive PCIe bus probed. > >>> starfive_7110_pcie pcie@2c000000: Starfive PCIe bus probed. > >>> In: serial@10000000 > >>> Out: serial@10000000 > >>> Err: serial@10000000 > >>> Net: eth0: ethernet@16030000, eth1: ethernet@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
