Re: [coreboot] coreboot 4.4 release coming soon

[Jonathan Neuschäfer]

On Thu, Apr 14, 2016 at 04:46:06PM -0600, Martin Roth wrote:
> Hi Everyone,
>   We're planning on doing the coreboot 4.4 release in the next week or so.
>
> We'd like to request some help with testing platforms both ahead of
> the release and when the release actually happens.  If you have a
> board in the coreboot tree, please try doing a build to help us verify
> what's working and to let us know about anything that isn't working.

I did a few tests with coreboot 4.3-774-g7fae59b on virtual platforms,
because I don't have any hardware supported by coreboot.

QEMU 2.5.0, QEMU x86 i440fx/piix4 mainboard
-------------------------------------------

SeaBIOS/Linux boots fine, but cbmem fails with
"Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory".

I did all x86 tests with Debian's kernel 3.16.

QEMU 2.5.0, QEMU x86 q35/ich9 mainboard
---------------------------------------

SeaBIOS/Linux boots fine, but cbmem fails with
"Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory".

For some reason QEMU periodically generates NMIs:
 - In Linux this is printed every 30 seconds:
   [   36.836053] Uhhuh. NMI received for unknown reason 30 on CPU 0.
   [   36.836053] Do you have a strange power saving mode enabled?
   [   36.836053] Dazed and confused, but trying to continue
 - SeaBIOS prints handle_02
 - Coreinfo logs the NMI and dies.
 - If I first boot Linux and then reboot into coreinfo, the NMIs do not
   occur (maybe Linux disables them on reboot).

QEMU riscv (v2.5.0-9-gb0cf38d + a few patches)
----------------------------------------------

In short: It doesn't work.

I can get coreboot to boot in QEMU up to the "payload not loaded"
message with a few patches:
 - I patched QEMU to not trap unaligned memory accesses
 - I patched coreboot to use the HTIF console instead of a 8250 UART
   memory-mapped at 0x3f8.
   - Both the write_msr(tohost, ...) interface and the memory-mapped
     HTIF at 0xFFFFFFFFF0000000 work.
 - I patched QEMU to dump characters written to the HTIF console,
   because I couldn't figure out how to use it properly.

Coreboot fails to boot Linux (configured vmlinux as an ELF payload,
because I couldn't find a compressed kernel):

CBFS: Locating 'fallback/payload'
  CBFS: Found @ offset cbc0 size 136043
  Loading segment from rom address 0x000000000002ccf8
    code (compression=1)
    New segment dstaddr 0x0 memsize 0x35abe0 srcaddr 0x2cd30 filesize 0x13600b
  Loading segment from rom address 0x000000000002cd14
    Entry Point 0xffffffff80000000
  SELF Payload doesn't target RAM:
  Failed Segment: 0x0, 3517408 bytes
   0. 0000000000200000-0000000001fdafff: RAM
   1. 0000000001fdb000-0000000001ffefff: CONFIGURATION TABLES
   2. 0000000001fff000-00000000021fffff: RAM
  Payload not loaded.

Jonathan

coreboot 4.4 release coming soon

[ron minnich]

On Wed, Apr 20, 2016 at 10:21 AM Jonathan Neuschäfer 
wrote:
> I can get coreboot to boot in QEMU up to the "payload not loaded"
> message with a few patches:
> I patched QEMU to not trap unaligned memory accesses

we're supposed to handle these traps, so something is broken. I would only
trust spike however.
> I patched coreboot to use the HTIF console instead of a 8250 UART
> memory-mapped at 0x3f8.

I suspect htis means the qemu or qemu target is still out of date, but who
knows.
> Both the write_msr(tohost, ...) interface and the memory-mapped
> HTIF at 0xFFFFFFFFF0000000 work.

good.
> I patched QEMU to dump characters written to the HTIF console,
> because I couldn't figure out how to use it properly.
>
> Coreboot fails to boot Linux (configured vmlinux as an ELF payload,
> because I couldn't find a compressed kernel):
>
> CBFS: Locating 'fallback/payload'
>   CBFS: Found @ offset cbc0 size 136043
>   Loading segment from rom address 0x000000000002ccf8
>     code (compression=1)
>     New segment dstaddr 0x0 memsize 0x35abe0 srcaddr 0x2cd30 filesize
> 0x13600b
>   Loading segment from rom address 0x000000000002cd14
>     Entry Point 0xffffffff80000000
>   SELF Payload doesn't target RAM:
>   Failed Segment: 0x0, 3517408 bytes
>    0. 0000000000200000-0000000001fdafff: RAM
> 0000000001fdb000-0000000001ffefff: CONFIGURATION TABLES
> 0000000001fff000-00000000021fffff: RAM
>
> Payload not loaded.

we still only do uncompressed kernels. There are other problems with riscv
right now, so I'm holding off doing anything until they are done redoing
parts of the architecture spec.

ron