I try to run coreboot + opensbi + linux kernel on HiFive Unleashed and separate hardware-initiated code for a simpler upgrade. To do this, a loader called riscv-gptl was added to load opensbi and linux from the sdcard and run as a coreboot payload.
However, I have encountered a strange problem. After running the specific firmware, I ran the normal firmware again (without re-powering) and the normal firmware could run. The button reset has no effect and cannot be runned after power-on again.
normal firmware, please refer to https://github.com/hardenedlinux/embedded-iot_profile/blob/master/docs/ri...
Specific firmware (coreboot which payload is opensbi FW_JUMP) create by the following command
# get source code
git clone email@example.com:hardenedlinux/coreboot-HiFiveUnleashed.git -b gptl coreboot
git clone firstname.lastname@example.org:wxjstz/opensbi.git -b gptl
# build opensbi
make CROSS_COMPILE=riscv64-elf- PLATFORM=sifive/fu540
# build coreboot
# Mainboard->Mainboard vendor, select **SiFive**
# Mainboard->Mainboard model, select **HiFive Unleashed**
# Payload->Add a payload, select **An ELF executable payload**
# Payload->Payload path and filename, Use default value **payload.elf**
cp ../opensbi/build/platform/sifive/fu540/firmware/fw_jump.elf ./payload.elf
sudo dd if=coreboot/build/coreboot.rom of=/dev/sdX; sync
Recently I had an interesting discussion with a system administrator
who is responsible for several hundred PCs, Routers etc.
His argument was: Imagine it would take you 15 minutes to install a
patch on a computer (all windows machines of course...). If your
company has 1000 computers and you send one admin to install the
patches, it will take him >31 work days, working 8h a day.
That's why, he said, companies are interested in software allowing them
to install stuff on the OS / hard drive remotely through the firmware
I, not dealing with large networks, had never thought about it this
way. But it does make a lot of sense to me, it's about real money (as
So I guess that's indeed a huge reason why Intel and AMD created
Frankenstein, running below UEFI and Kernel. It probably doesn't
explain so much why it's necessary to disallow you switching IME off or
why it needs control about absolutely everything, but that's a
So I'm wondering: What would you do about this reality? Could there be
a different solution other than software in Ring -1 having its sausage
fingers on everything?
Sure, the programmers in a company could install their stuff on their
own, but the office folks, the HR and PR guys and the lawyers? Hmm.
And whether we like it or not, even awesome companies almost
exclusively supply their employees with windows machines and they just
demand solutions allowing their IT-departements to fix everything as
cheap and as easy as possible
with this mail I'm officially starting the 4.10 release process.
As per the first step of our checklist
(Documentation/releases/checklist.md), I hereby announce the intent to
release coreboot 4.10 in about 2 weeks. I'm aiming for May 28th to avoid
releasing into the weekend or on Memorial Day in the US, but I'll likely
lock down the commit we'll designate 4.10 during those days to give some
room for testing.
I created a copy of the checklist on
https://piratenpad.de/p/coreboot4.10-release-checklist, also including the
current state of the 4.10 release notes.
Please test the boards you have around and provide fixes, please be careful
with intrusive changes (and maybe postpone them until after the release)
and please update the release notes (Documentation/releases/
coreboot-4.10-relnotes.md or near the bottom of the etherpad doc, I'll
carry them over into our git repo then).
As promised with the 4.9 release there won't be deprecations after 4.10.
However we need to finalize our set of deprecations we want to announce
with 4.10 that will happen after the 4.11 release (those also belong in the
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
After upgrading my Debian Stretch installation to Buster, i experienced
acpi=off lets the kernel boot, but the system is still unusable as some
controller do not work correctly.
So i guess its something ACPI related.
Also wrote an bugreport to debian.
I can not give any usable debug output as the kernel hangs before giving