Re: [coreboot] Using linux as payload

[Jorge Fernandez Monteagudo]

Hi Youness! Thanks for your answer!

Yes, I thought about a video initialization problem and for that I set the command line:

console=ttyS0,115200n8 console=tty0 earlyprintk=ttyS0,115200n8

to be able to receive anything over the serial line. To confirm that this command

line is fine, I boot the demoboard from SeaBIOS and load the same bzImage and

initrd using grub2 to read them from a pendrive, and once the serial port is initialized

I start receiving messages over the serial port.

Today I've been comparing the coreboot output from a working QEMU and comparing

the output from my demoboard. You can see it in https://github.com/osresearch/heads/issues/440#issuecomment-414708461

The differences I can see. In the QEMU coreboot the CBF is located in 100100:

CBFS: 'Master Header Locator' located CBFS at [100100:7fffc0)

There is a Bounce Buffer (I don't know what is) and is used in every segment loaded. For instance:

Bounce Buffer at 07f57000, 363552 bytes
...
dest 00090000, end 00091080, bouncebuffer 7f57000

In the AMD Bettong coreboot the CBF is located in 100

CBFS: 'Master Header Locator' located CBFS at [100:7fffc0)

There is an additional segment in

Loading segment from ROM address 0xff8c7d0c
data (compression=0)
New segment dstaddr 0x91000 memsize 0xc srcaddr 0xffb4c581 filesize 0xc

which could overwrite the first segment loaded

New segment dstaddr 0x90000 memsize 0x1080 srcaddr 0xff8c7d60 filesize 0x1080

because 0x90000 + 0x1080 > 0x91000

And no bounce buffer is used. All segments has something like

dest 00090000, end 00091080, bouncebuffer ffffffff

Finally in both coreboots the jump is to 00040000

I'll give a try to your suggestion and I'll remove all video support from coreboot and

configure the kernel one...

Thanks!

Jorge

________________________________
De: Youness Alaoui 
Enviado: lunes, 20 de agosto de 2018 22:18:39
Para: Jorge Fernandez Monteagudo
Cc: coreboot
Asunto: Re: [coreboot] Using linux as payload

Hi,

I might not be the best one to answer your question, but here are my thoughts :
- the "unknown type 'payload'" error is probably because cbfs changed
the type name from "payload' to "simple elf" since you can add elfs in
there that are not actual 'payloads'. I think though that it
auto-changed the file type to 'simple elf', since you can see in the
cbfs print :
fallback/payload               0xc7a80    simple elf    5244700 none
So the payload is added, it has type "simple elf" and is 5.2MB (which
is the bzImage + initrd.cpio size).
Then in your cbmem log you can see that it did find the payload and
that it decompressed all the sections and everything seems fine :
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset c7b80 size 5006d5
[...]

And then it jumps into it (i.e: it executes the payload) :
Jumping to boot code at 00040000(8fe11000)

The reason that's the last messages you see is simply because linux
does not print any messages to cbmem (SeaBIOS does, and if you look at
your old logs, you'd see right after that "jumping to boot code"
there's the SeaBIOS debug messages starting).

So I think it's all good for you, but your problem is actually with
your linux (Heads) configuration itself, you probably simply do not
have the right graphics driver enabled in the kernel, so linux boots
but it doesn't initialize the GPU so nothing appears. You can either
find and enable your GPU driver in the kernel and rebuild Heads, or
you can tell coreboot to initialize the gpu (either with the GOP
driver+VBT or by running the option rom) and tell it to initialize the
VGA framebuffer (probably in text mode though I'm not sure) or
whatever is needed to actually get some graphics output.
I remember trying a few different options and configurations for the
Librem and in the end, I simply removed the vgabios/vbt from coreboot,
told coreboot not to initialize the graphics, and added the i915
kernel driver to heads and that was all that was needed. Once heads
booted, the kernel driver initialized the graphics and that's it.

I hope that helps,
Youness.

On Sat, Aug 18, 2018 at 4:51 AM Jorge Fernandez Monteagudo
 wrote:
> Hi all!
>
> I have a coreboot from master git working ok in my AMD Bettong demoboard with SeaBIOS and now
>
> I'm trying to use a bzImage (2651888 bytes) and initrd.cpio.xz (2604544 bytes) generated by Heads in
>
> order to test the linux payload.
>
> When I compile the coreboot I see:
>
> Created CBFS (capacity = 8388056 bytes)
>     CBFS       apu/amdfw
>     CBFS       AGESA
>     CBFS       fallback/romstage
>     CBFS       fallback/ramstage
>     CBFS       cmos_layout.bin
>     CBFS       pci1002,9874.rom
>     CBFS       fallback/dsdt.aml
>     CBFS       fallback/payload
> W: Unknown type 'payload' ignored
>     CBFS       coreboot.rom
>     CBFSLAYOUT  coreboot.rom
>
> This image contains the following sections that can be manipulated with this tool:
>
> 'COREBOOT' (CBFS, size 8388096, offset 512)
>
> It is possible to perform either the write action or the CBFS add/remove actions on every section listed above.
> To see the image's read-only sections as well, rerun with the -w option.
>     CBFSPRINT  coreboot.rom
>
> Name                           Offset     Type           Size   Comp
> cbfs master header             0x0        cbfs header        32 none
> fallback/romstage              0x80       stage           32220 none
> fallback/ramstage              0x7ec0     stage           56689 none
> cmos_layout.bin                0x15c80    cmos_layout      1516 none
> fallback/dsdt.aml              0x162c0    raw              6673 none
> (empty)                        0x17d40    null            32856 none
> apu/amdfw                      0x1fdc0    raw            622592 none
> pci1002,9874.rom               0xb7e00    optionrom       64512 none
> fallback/payload               0xc7a80    simple elf    5244700 none
> (empty)                        0x5c8200   null           228248 none
> AGESA                          0x5ffdc0   raw            690436 none
> (empty)                        0x6a8740   null          1405592 none
> bootblock                      0x7ffa00   bootblock         912 none
>
> Built amd/bettong (FP4)
>
> The "W: Unknown type 'payload' ignored" message is ok? Maybe the payload doesn't fit in the
>
> coreboot image?
>
> Now when I boot the board the last messages I can see on serial console are:
>
> ...
>
> Writing table forward entry at 0x00000500
> Wrote coreboot table at: 00000500, 0x10 bytes, checksum 5ffd
> Writing coreboot table at 0x8fe11000
>  0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
> 0000000000001000-000000000009ffff: RAM
> 00000000000c0000-000000008fdd9fff: RAM
> 000000008fdda000-000000008fffffff: CONFIGURATION TABLES
> 0000000090000000-00000000cfffffff: RESERVED
> 00000000f8000000-00000000fbffffff: RESERVED
> 00000000fed40000-00000000fed44fff: RESERVED
> 0000000100000000-000000022effffff: RAM
>
> Board ID: 70
> CBFS: 'Master Header Locator' located CBFS at [100:7fffc0)
> FMAP: Found "FLASH" version 1.1 at 0.
> FMAP: base = ff800000 size = 800000 #areas = 3
> Wrote coreboot table at: 8fe11000, 0x2f4 bytes, checksum 6365
> coreboot table: 780 bytes.
> IMD ROOT    0. 8ffff000 00001000
> IMD SMALL   1. 8fffe000 00001000
> ROMSTG STCK 2. 8ffe6000 00018000
> RAMSTAGE    3. 8feff000 000e7000
> 57a9e100    4. 8fe19000 000e51f0
> COREBOOT    5. 8fe11000 00008000
> IRQ TABLE   6. 8fe10000 00001000
> SMP TABLE   7. 8fe0f000 00001000
> ACPI        8. 8fdeb000 00024000
> TCPA LOG    9. 8fddb000 00010000
> SMBIOS     10. 8fdda000 00000800
> IMD small region:
>   IMD ROOT    0. 8fffec00 00000400
>   CAR GLOBALS 1. 8fffeac0 00000140
>   ROMSTAGE    2. 8fffeaa0 00000004
>   57a9e000    3. 8fffea80 00000018
>   COREBOOTFWD 4. 8fffea40 00000028
> BS: BS_WRITE_TABLES times (us): entry 0 run 207363 exit 0
> CBFS: 'Master Header Locator' located CBFS at [100:7fffc0)
> CBFS: Locating 'fallback/payload'
> CBFS: Found @ offset c7b80 size 5006d5
> Loading segment from ROM address 0xff8c7cb8
>   data (compression=0)
>   New segment dstaddr 0x90000 memsize 0x1080 srcaddr 0xff8c7d60 filesize 0x1080
> Loading segment from ROM address 0xff8c7cd4
>   code (compression=0)
>   New segment dstaddr 0x1000000 memsize 0x2836f0 srcaddr 0xff8c8de0 filesize 0x2836f0
> Loading segment from ROM address 0xff8c7cf0
>   code (compression=0)
>   New segment dstaddr 0x40000 memsize 0xb1 srcaddr 0xffb4c4d0 filesize 0xb1
> Loading segment from ROM address 0xff8c7d0c
>   data (compression=0)
>   New segment dstaddr 0x91000 memsize 0xc srcaddr 0xffb4c581 filesize 0xc
> Loading segment from ROM address 0xff8c7d28
>   data (compression=0)
>   New segment dstaddr 0x4000000 memsize 0x27be00 srcaddr 0xffb4c58d filesize 0x27be00
> Loading segment from ROM address 0xff8c7d44
>   Entry Point 0x00040000
> Loading Segment: addr: 0x0000000000090000 memsz: 0x0000000000001080 filesz: 0x0000000000001080
> lb: [0x000000008ff00000, 0x000000008ffe51f0)
> Post relocation: addr: 0x0000000000090000 memsz: 0x0000000000001080 filesz: 0x0000000000001080
> it's not compressed!
> [ 0x00090000, 00091080, 0x00091080) <- ff8c7d60
> dest 00090000, end 00091080, bouncebuffer ffffffff
> Loading Segment: addr: 0x0000000001000000 memsz: 0x00000000002836f0 filesz: 0x00000000002836f0
> lb: [0x000000008ff00000, 0x000000008ffe51f0)
> Post relocation: addr: 0x0000000001000000 memsz: 0x00000000002836f0 filesz: 0x00000000002836f0
> it's not compressed!
> [ 0x01000000, 012836f0, 0x012836f0) <- ff8c8de0
> dest 01000000, end 012836f0, bouncebuffer ffffffff
> Loading Segment: addr: 0x0000000000040000 memsz: 0x00000000000000b1 filesz: 0x00000000000000b1
> lb: [0x000000008ff00000, 0x000000008ffe51f0)
> Post relocation: addr: 0x0000000000040000 memsz: 0x00000000000000b1 filesz: 0x00000000000000b1
> it's not compressed!
> [ 0x00040000, 000400b1, 0x000400b1) <- ffb4c4d0
> dest 00040000, end 000400b1, bouncebuffer ffffffff
> Loading Segment: addr: 0x0000000000091000 memsz: 0x000000000000000c filesz: 0x000000000000000c
> lb: [0x000000008ff00000, 0x000000008ffe51f0)
> Post relocation: addr: 0x0000000000091000 memsz: 0x000000000000000c filesz: 0x000000000000000c
> it's not compressed!
> [ 0x00091000, 0009100c, 0x0009100c) <- ffb4c581
> dest 00091000, end 0009100c, bouncebuffer ffffffff
> Loading Segment: addr: 0x0000000004000000 memsz: 0x000000000027be00 filesz: 0x000000000027be00
> lb: [0x000000008ff00000, 0x000000008ffe51f0)
> Post relocation: addr: 0x0000000004000000 memsz: 0x000000000027be00 filesz: 0x000000000027be00
> it's not compressed!
> [ 0x04000000, 0427be00, 0x0427be00) <- ffb4c58d
> dest 04000000, end 0427be00, bouncebuffer ffffffff
> Loaded segments
> BS: BS_PAYLOAD_LOAD times (us): entry 0 run 317530 exit 0
> Jumping to boot code at 00040000(8fe11000)
> CPU0: stack: 8ff20000 - 8ff21000, lowest used address 8ff205e0, stack used: 2592 bytes
>
> But no more messages are displayed and the board do nothing. Anyone with a linux payload working already?
>
> I'm reporting in the heads github too with no luck...
>
> Any hint is welcome!
>
> Regards!