Latest Ubuntu u-boot and kernel images

U-boot 2021-07. Boot from TFTP and DHCP now works. 1.4 GHz seems to work on all Unmatched boards.

https://www.w6rz.net/u-boot-2021-07-1200mhz.itb
https://www.w6rz.net/u-boot-spl-2021-07-1200mhz.bin

https://www.w6rz.net/u-boot-2021-07-1400mhz.itb
https://www.w6rz.net/u-boot-spl-2021-07-1400mhz.bin

https://www.w6rz.net/u-boot-2021-07-1500mhz.itb
https://www.w6rz.net/u-boot-spl-2021-07-1500mhz.bin

On the Unmatched, install with:

sudo dd if=u-boot-2021-07-1400mhz.itb of=/dev/mmcblk0p14 bs=4k oflag=direct
sudo dd if=u-boot-spl-2021-07-1400mhz.bin of=/dev/mmcblk0p13 bs=4k oflag=direct

Latest Linux kernel with the Ubuntu configuration. Real-time clock is enabled. LEDs are enabled. CONFIG_DEBUG_INFO is not set. Power-down and reboot are not enabled. Device tree files (.dtb) are installed in the correct directory (/lib/firmware/5.13.12/device-tree/sifive).

https://www.w6rz.net/linux-image-5.13.12_5.13.12-1_riscv64.deb
https://www.w6rz.net/linux-headers-5.13.12_5.13.12-1_riscv64.deb
https://www.w6rz.net/linux-libc-dev_5.13.12-1_riscv64.deb

LED configuration:

cat << EOF | sudo tee /etc/udev/rules.d/99-pwm-leds.rules
# D12 LED: heartbeat
SUBSYSTEM=="leds", KERNEL=="green:d12", ACTION=="add", ATTR{trigger}="heartbeat"

# D12 RGB LED: boot status
SUBSYSTEM=="leds", KERNEL=="green:d2", ACTION=="add", ATTR{trigger}="default-on", ATTR{brightness}="25"
SUBSYSTEM=="leds", KERNEL=="red:d2", ACTION=="add", ATTR{trigger}="default-on", ATTR{brightness}="25"
SUBSYSTEM=="leds", KERNEL=="blue:d2", ACTION=="add", ATTR{trigger}="default-on", ATTR{brightness}="25"
EOF


cat << EOF | sudo tee /etc/systemd/system/led-bootstate-green.service
[Unit]
Description="Change the color of D2 LED to green"
ConditionPathIsReadWrite=/sys/class/leds/green:d2/trigger
ConditionPathIsReadWrite=/sys/class/leds/red:d2/trigger
ConditionPathIsReadWrite=/sys/class/leds/blue:d2/trigger

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/bin/echo "default-on" > /sys/class/leds/green:d2/trigger'
ExecStart=/bin/bash -c '/bin/echo "25" > /sys/class/leds/green:d2/brightness'
ExecStart=/bin/bash -c '/bin/echo "none" > /sys/class/leds/red:d2/trigger'
ExecStart=/bin/bash -c '/bin/echo "none" > /sys/class/leds/blue:d2/trigger'
EOF

cat << EOF | sudo tee /etc/systemd/system/led-bootstate-green.timer
[Unit]
Description=timer to turn-on green LED
After=getty.target

[Timer]
OnActiveSec=30sec
Unit=led-bootstate-green.service

[Install]
WantedBy=timers.target
EOF
1 Like

Does this include the changes that fix the invalid opcode mentioned here? U-Boot says Unhandled exception: Illegal instruction - #14 by xnox

Yes. As @xnox mentioned, that’s been fixed in 5.12 kernels and later.

I believe it’s also fixed in the official Ubuntu linux-image-5.11.0-1017 that was pushed out yesterday.

2 Likes

Many thanks for sharing these. Regarding:

To enable these is it necessary to build a kernel with the DA9063 options as per this thread:

And possibly apply the patch in this too?

Those patches are in. You can enable power down by editing the file /usr/lib/modprobe.d/blacklist_linux-riscv_5.11.0-10xx-generic.conf (10xx because it will be different depending on the version of the last Ubuntu kernel that was installed) and remove the line blacklist da9063_wdt. Then add da9063_wdt to /etc/modules.

However, the power down will happen with sudo shutdown -r and not sudo shutdown.

The reboot patch is just too ugly. It’s not a soft reset. It’s actually powering down momentarily and restarting. Since the ATX power supply is also being commanded to shutdown, it’s a race to restart before the voltage sags. So sometimes it powers down all the way instead of resetting.

There’s also a side effect to these less than stellar power down routines. The NVME drive doesn’t get shut down properly. Here’s my WD Black SN750 stats. Many unsafe shutdowns (although I haven’t had any problems).

Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning			: 0
temperature				: 43 C
available_spare				: 100%
available_spare_threshold		: 10%
percentage_used				: 0%
endurance group critical warning summary: 0
data_units_read				: 612214
data_units_written			: 1761640
host_read_commands			: 5812685
host_write_commands			: 6242552
controller_busy_time			: 45
power_cycles				: 147
power_on_hours				: 1915
unsafe_shutdowns			: 92
media_errors				: 0
num_err_log_entries			: 0
Warning Temperature Time		: 0
Critical Composite Temperature Time	: 0
Thermal Management T1 Trans Count	: 0
Thermal Management T2 Trans Count	: 0
Thermal Management T1 Total Time	: 0
Thermal Management T2 Total Time	: 0

Thanks for the clarification. Curious what the reason behind requiring -r for shutdown is? Also whether you’re aware of more correct patches possibly being in the pipeline?

Unrelated to the above, are you aware of any steps to enable the temperature sensor? Couldn’t seem to read this with the stock Ubuntu install.

I don’t think the da9063_wdt kernel module is the correct way to power down the system. I’m guessing it just works by accident after a sudo shutdown -r.

The entire power down and reboot stuff needs to be ironed out. I’m just a hobbyist, so I don’t know what the SiFive or Ubuntu folks are up to.

As for the temperature sensor, it should work with the kernel and u-boot files I linked above. Here’s what it looks like on my system with a NVME.

ubuntu@riscv64:~$ sensors
nvme-pci-0600
Adapter: PCI adapter
Composite:    +40.9°C  (low  =  -5.2°C, high = +79.8°C)
                       (crit = +84.8°C)

tmp451-i2c-0-4c
Adapter: i2c-ocores
temp1:        +39.1°C  (low  =  +0.0°C, high = +85.0°C)
                       (crit = +85.0°C, hyst = +75.0°C)
temp2:        +41.8°C  (low  =  +0.0°C, high = +85.0°C)
                       (crit = +85.0°C, hyst = +75.0°C)

ubuntu@riscv64:~$ 
2 Likes

While complaints about a general lack of grace are fine, I’m wondering if your description of “a race to restart before the voltage sags” is really accurate. AFAIU the process is controlled by a timer in the DA9063, which is powered by the “5VSB” rail. Which means that it gets power even when the PSU is “off”.
I’d be more worried about the voltage not sagging long enough to trigger a system reset…

Yes, I’ll admit that wasn’t the most well thought out post. As you say, the 5VSB/VSYS rail is always on.