Hi, I’m trying to boot the new Debian demo image (from the freedom-u-sdk GitHub repo) on my Unleashed board. ‘make DISK=(mydisk) format-demo-image’ ran without errors and the files seem to have been extracted correctly on the Linux partition, but when I try and boot it the only output I get on the console is ‘Error 0x1000000000000003’. Is there anything I can do to fix this? (It boots fine when the SD card’s formatted with format-boot-loader, so there’s nothing physically wrong with the board or the card.)
The msel switches are in mode 1111, and this is the info gdisk provides for the partition table (I haven’t modified the files or partitions at all since running make):
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15273950
Partitions will be aligned on 4-sector boundaries
Total free space is 3754906 sectors (1.8 GiB)
The new freedom-u-sdk with HiFive u-boot requires that the switches be set to 1101. See the readme.md file, just scroll down from the github freedom-u-sdk web site and read the text.
Thanks for your quick reply! I’d assumed the mode select switch diagram was intended for running from flash as it immediately followed that section. The board now boots but still into buildroot rather than debian. I’ve tried stopping the boot process and booting from the UBoot console:
mmcsetup ; fatenv; run boot2 also boots me into buildroot
Setting setupchosen to ‘run setupvml’ to boot straight to the root partition and then running boot2 gives me a kernel panic - it says the root variable needs to be set as it can’t find /dev/mmcblk0p2, but mmc info shows the correct partitions for device 0 with the root partition as #2.
I apologise as I am completely out of my depth here - I’ve never worked with bootloaders before. Accessing a more complete Linux distribution would be very useful for the project I’m working on, but if it’s going to take too long to troubleshoot this I can stick with buildroot.
This is the state of the environment variables after running mmcsetup and fatenv at the console, if that helps:
baudrate=115200
bbladdr=80000000
boot2=fatload mmc 0:1 ${fileaddr} ${fitfile}; bootm start ${fileaddr}; run setupfdt1; run setupchosen; run setupfdt2; bootm loados ${fileaddr}; echo “Booting kernel in”; run bootwait; go 80000000
bootargs=debug console=tty0 console=ttySIF0 root=/dev/mmcblk0p2
bootcmd=run mmcsetup; run fdtsetup; run fatenv; echo ‘running boot2…’; run boot2
bootdelay=2
bootfile=hifiveu.fit
bootwait=setenv _delay ${bootdelay}; echo ${_delay}; while test ${_delay} > 0; do sleep 1; setexpr _delay ${_delay} - 1; echo ${_delay}; done
ethact=gmac0
ethaddr=70:b3:d5:92:f2:c3
fatenv=setenv fileaddr a0000000; fatload mmc 0:1 ${fileaddr} uEnv.txt;env import -t ${fileaddr} ${filesize}
fdt_high=0xffffffffffffffff
fdtaddr=81f00000
fdtcontroladdr=fffaba10
fdtsetup=fdt addr ${fdtcontroladdr}; fdt chosen;fdt set /firmware sifive,uboot “2018.09-gca05d26”;fdt set /chosen bootargs console=ttySIF0,${baudrate}
fileaddr=a0000000
filesize=93f
fitfile=hifiveu.fit
ip_dyn=yes
irdaddr=82000000
irdsize=01000000
mmcsetup=mmc_spi 1 20000000 0; mmc part
newfdt=f0000000
serial#=00707
setupchosen=run setupvml; run setupird
setupfdt1=fdt addr ${newfdt}; fdt resize; fdt chosen
setupfdt2=fdt print /chosen; fdt set /chosen bootargs “${bootargs}”; fdt set /firmware uboot,ver ${ver}; fdt print /chosen
setupird=setexpr irdend ${irdaddr} + ${irdsize}; fdt set /chosen linux,initrd-start <0x0 0x${irdaddr}>; fdt set /chosen linux,initrd-end <0x0 0x${irdend}>
setupvml=setexpr vmlend ${vmladdr} + ${vmlsize}; fdt set /chosen riscv,kernel-start <0x0 0x${vmladdr}>; fdt set /chosen riscv,kernel-end <0x0 0x${vmlend}>
stderr=serial
stdin=serial
stdout=serial
uboot_version=“2018.09-gca05d26”
ver=U-Boot 2018.09-gca05d26 (Apr 07 2019 - 15:49:03 +0100)
vmladdr=80200000
vmlsize=00800000
Edit: I noticed the obvious that the image was hifiveu.fit rather than image.fit as described in the Readme. I just tried copying image.fit directly into the first partition (uEnv.txt has the contents it’s supposed to have) but that led to an infinite loop of illegal instruction exceptions when booting. I’ll try reformatting the card and setting it up again just in case.
I can confirm it still boots into buildroot after reformatting the SD card (first with make format-boot-loader and then make format-demo-image) and copying image.fit across. I also had to modify uEnv.txt as the fitfile variable is still hifiveu.fit by default (which was causing the infinite loop of illegal instructions I think, as it was trying to boot the non-existent file). The demo image files are all present on partition 2 of the SD card so I’m really not sure why it won’t boot into it.
If it boots into buildroot then it is working as intended.
The next step is to mount the first partition of the sdcard, if on HiFive1 Unleashed then something like
mount /dev/mmcblk0p1 /mnt
run ls and you will see a uEnv.txt file, make a backup copy of it if you don’t already have one, then edit the bootargs= line to boot from the partition that has your root filesystem on it, this may already be correct, and for the setupchosen= line you want the second one, the one that does not use setupird, because setupird forces you into the buildroot root filesystem via an initramfs. So you need setupvml, but you don’t want setupird. run sync, umount /mnt, poweroff, and then powercycle the board to reboot and it should come up with the OS that you want.
Brilliant, thanks! I’ve got it up and running now.
For anyone else looking to boot the demo image, I found I needed to modify the bootargs in order to boot. Add ‘rootwait’ before all other arguments so it waits long enough to recognise the SD card partition (otherwise I get a kernel panic with the message ‘Unable to mount root fs on unknown-block’), and ‘rw’ so root isn’t mounted as read-only. I’d also recommend removing the ‘debug’ argument as otherwise systemd spams the terminal with messages. So the full set of bootargs that worked for me are:
Hi, just to confirm - it does boot with that commit’s changes.
Without the ‘rw’ flag the root filesystem is mounted as read-only, which means quite a few services fail to start and any task requiring modifying system files fails (e.g. trying to update/install software with apt). Perhaps that’s an issue with my microSD card though if you’re not encountering that?
With the ‘debug’ flag I get hundreds of these messages from systemd:
I’m using the system via screen so the constant messages on the console make it borderline unusable. But if the debug flag is helpful for other messages, I tried adding the ‘systemd.log_level=info’ argument per this thread [1] and that works well - it’s just the systemd debug messages which interfere.
Thank you very much for the post. This really helped.
I was also stuck up which u-boot…
And it turns out that with the suggestion in this post, i could get it booted into buildroot, debian and fedora.
Thanks once again
