Hi Matt,
TL;DR you can simply compile a VGA BIOS with GCC/Clang. You don't have
to make the same mistakes as AMD and compile/interpret some byte code.
Which, IMHO, would only make it harder to implement an open-source
version.
On 05.06.19 02:38, Matt B wrote:
> I'm not talking about replacing a blob that nobody understands with a
> technically different but equally incomprehensible one. It sounds like your
> interpretation is to simply copy all the individual routines to a new blob.
> (Some sort of strange Theseus' ship exercise?) But you don't develop an
> open-source replacement for any a piece of software by a copying several
> sequences of instructions from the original ELF file to another.
well, I'm afraid that is what many people do. Most of the AtomBIOS code
will be like: write magic number A into magic register B. If you do that
too in your code, it works. If you don't do it, it doesn't work. I fear,
without an unreasonably huge effort, the open-source version won't get
much more comprehensible. I don't think the AMD hardware is worth it
when you can get documentation from many other vendors. Or maybe the
time is better spend on convincing AMD to release documentation.
> Presumably (one would hope) somewhere AMD has un-obfuscated
> (understandable) source code of some form that was compiled into the
> vgabios roms that are frequently used. I recognize that it would be a
> colossal pain to figure out how the chips work without documentation, but
> in order to go through that process, tooling would presumably be
> advantageous.
>
> Afaik, the only development tooling anyone has right now is a disassembler.
> Nothing which can turn the source code one might try to write into a
> vgabios blob that could be loaded into a build of coreboot and tried out.
> This is important as the painful process typically works when replacing any
> proprietary code is [1]:
> a) try to write something that's a little bit correct
> b) build and flash
> c) test the result and make a few changes
> d) go back to step B until a little bit more functionality is understood,
> then go back to step A for more
>
> For that to work it's a big help to have a compiler that can turn
> annotated, documented source code into the binary format that's stored in
> flash. That same compiler also sees use in builds once things are complete
> enough to start sharing source code. That's why I'm interested in the
> question of whether such a tooling is available.
Let's add some more background. AMD's VGA BIOS contains two code parts:
1. The AtomBIOS that is card/mainboard specific, compiled to some byte
code.
2. An interpreter for the AtomBIOS byte code.
There are already open-source implementations of 2. So I guess what you
are asking for is a compiler for the AtomBIOS. But I wonder why? A new,
clean implementation wouldn't have to keep this weird structure. You can
simply skip AtomBIOS byte code and write your VGA BIOS in C, Rust or
whatever you prefer; use GCC or Clang to compile it.
Nico
> [1] One example is the panfrost team's development of the panfrost GPU
> driver. They started by recording and replaying command streams to
> understand how things work, but to move beyond that they obviously had to
> start writing the skeleton of a driver in C.
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/risc…
Specific firmware (coreboot which payload is opensbi FW_JUMP) create by the following command
```
# get source code
git clone git@github.com:hardenedlinux/coreboot-HiFiveUnleashed.git -b gptl coreboot
git clone git@github.com:wxjstz/opensbi.git -b gptl
# build opensbi
cd opensbi
make CROSS_COMPILE=riscv64-elf- PLATFORM=sifive/fu540
cd -
# build coreboot
cd coreboot
make menuconfig
# 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
make
cd -
# Burn
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
usual).
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
different story.
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
P.
Hi everybody,
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
release notes).
Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
After upgrading my Debian Stretch installation to Buster, i experienced
this behaviour.
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
any output.
