Porting to a new board (AMD Bettong demoboard)

[jorgefm]

boot-heads-tpm2-lpc-linux.txt
boot-heads-tpm2-lpc-seabios.txt

Hi, I need a little help trying to run heads in my board.

I have an AMD Bettong demoboard. I've been able to run the coreboot-4.7 with a SeaBIOS payload but no luck with the kernel and initrd generated by heads (I'm using 1d27c93 commit from Mon Aug 13 06:33:51 2018)

Attached are the console output with the SeaBIOS and with the linux payload.

The linux payload has been generated with the linux-kgpe-d16.config. Are there some needed CONFIGs I need to set to generate a kernel to be a payload? The messages "it's not compressed!" are errors? For example in:

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

Any hint is welcome!
Thanks!

[osresearch]

In the Linux log it looks like it finds the payload as an uncompressed section:

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

It then jumps into the unpacked payload, although I'm not positive about the address:

Jumping to boot code at 00040000(8fe11000)
CPU0: stack: 8ff20000 - 8ff21000, lowest used address 8ff205e0, stack used: 2592 bytes

It looks like it should have been unpacked to 0x90000, but it jumps to 0x40000?

[jorgefm]

coreboot-amd-bettong.config.txt
linux-amd-bettong.config.txt
amd-bettong.config.txt

And, where can I set these values? Attached are the configuration files I'm using...
Where can I find a log with a correct boot in a linux payload?

Regards!

[jorgefm]

If I boot the board with the coreboot with SeaBIOS I can boot the bzImage and initrd.cpio.xz generated by Heads using a grub2 menu...
Anything specific with an AMD processor?

[osresearch]

I haven't tried using the KGPE build personally. They were added by @tlaurion in 23ae788#diff-cec1105804b84f95a331e40d15cde6b6 so perhaps they have some guidance?

[paulmenzel]

Am 17.08.2018 um 20:21 schrieb jorgefm: […]

And, where can I set these values? Attached are the configuration files I'm using... Where can I find a log with a correct boot in a linux payload?

You can build Heads for QEMU, which is the default, when just running `make`. Execute that image. Then you’ll also see the log with the Linux payload.

[jorgefm]

boot-heads-qemu.txt

Hi,
I've built Heads for QEMU enabling the console output for coreboot. Attached is the output.
The interesting part is:

CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 11680 size 58ae1d
Loading segment from ROM address 0xff9117b8
data (compression=0)
New segment dstaddr 0x90000 memsize 0x1080 srcaddr 0xff911844 filesize 0x1080
Loading segment from ROM address 0xff9117d4
code (compression=0)
New segment dstaddr 0x1000000 memsize 0x2b6c60 srcaddr 0xff9128c4 filesize 0x2b6c60
Loading segment from ROM address 0xff9117f0
code (compression=0)
New segment dstaddr 0x40000 memsize 0xb1 srcaddr 0xffbc9524 filesize 0xb1
Loading segment from ROM address 0xff91180c
data (compression=0)
New segment dstaddr 0x4000000 memsize 0x2d3000 srcaddr 0xffbc95d5 filesize 0x2d3000
Loading segment from ROM address 0xff911828
Entry Point 0x00040000
Bounce Buffer at 07f57000, 363552 bytes
Loading Segment: addr: 0x0000000000090000 memsz: 0x0000000000001080 filesz: 0x0000000000001080
lb: [0x0000000000100000, 0x000000000012c610)
Post relocation: addr: 0x0000000000090000 memsz: 0x0000000000001080 filesz: 0x0000000000001080
it's not compressed!
[ 0x00090000, 00091080, 0x00091080) <- ff911844
dest 00090000, end 00091080, bouncebuffer 7f57000
Loading Segment: addr: 0x0000000001000000 memsz: 0x00000000002b6c60 filesz: 0x00000000002b6c60
lb: [0x0000000000100000, 0x000000000012c610)
Post relocation: addr: 0x0000000001000000 memsz: 0x00000000002b6c60 filesz: 0x00000000002b6c60
it's not compressed!
[ 0x01000000, 012b6c60, 0x012b6c60) <- ff9128c4
dest 01000000, end 012b6c60, bouncebuffer 7f57000
Loading Segment: addr: 0x0000000000040000 memsz: 0x00000000000000b1 filesz: 0x00000000000000b1
lb: [0x0000000000100000, 0x000000000012c610)
Post relocation: addr: 0x0000000000040000 memsz: 0x00000000000000b1 filesz: 0x00000000000000b1
it's not compressed!
[ 0x00040000, 000400b1, 0x000400b1) <- ffbc9524
dest 00040000, end 000400b1, bouncebuffer 7f57000
Loading Segment: addr: 0x0000000004000000 memsz: 0x00000000002d3000 filesz: 0x00000000002d3000
lb: [0x0000000000100000, 0x000000000012c610)
Post relocation: addr: 0x0000000004000000 memsz: 0x00000000002d3000 filesz: 0x00000000002d3000
it's not compressed!
[ 0x04000000, 042d3000, 0x042d3000) <- ffbc95d5
dest 04000000, end 042d3000, bouncebuffer 7f57000
Loaded segments
ICH7 watchdog disabled
Jumping to boot code at 00040000(07fd5000)
CPU0: stack: 00123000 - 00124000, lowest used address 00123bfc, stack used: 1028 bytes
entry = 0x00040000
lb_start = 0x00100000
lb_size = 0x0002c610
buffer = 0x07f57000

Here we can see the same "It's not compressed!" messages but when jump the kernel is executed ok.
Do you find some differences with my demoboard output? How can I debug where the coreboot is jumping? Maybe print the first bytes before jumping to try to guess something...

[jorgefm]

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

[paulmenzel]

Interesting analysis. Please share that with the coreboot mailing list, by replying to your [message][1]. I believe your chances are higher to get help there. I guess you capture the logs over the serial console. Did you test changing the Linux kernel parameters to `console=tty0,115200` for example? PS: Could you please add the board name to the issue title? [1]: https://mail.coreboot.org/pipermail/coreboot/2018-August/087191.html

[jorgefm]

Well, I'm using the next command line to get traces in console and over serial:
console=ttyS0,115200n8 console=tty0 earlyprintk=ttyS0,115200n8

Yes, I think is better reporting in the coreboot mailing list for a coreboot problem :)

Thanks for your help!

[tlaurion]

@jorgefm Do you have any input to add to this issue?

[jorgefm]

@jorgefm Do you have any input to add to this issue?

Sorry, I didn't get it working...