Re: [coreboot] Using linux as payload
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 0009, 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 0x9 memsize 0x1080 srcaddr 0xff8c7d60 filesize 0x1080 because 0x9 + 0x1080 > 0x91000 And no bounce buffer is used. All segments has something like dest 0009, end 00091080, bouncebuffer Finally in both coreboots the jump is to 0004 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 0xc7a80simple elf5244700 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 0004(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 con
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 0xc7a80simple elf5244700 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 0004(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 0x0cbfs header32 none > fallback/romstage 0x80 stage 32220 none > fallback/ramstage 0x7ec0 stage 56689 none > cmos_layout.bin0x15c80cmos_layout 1516 none > fallback/dsdt.aml 0x162c0raw 6673 none > (empty)0x17d40null32856 none > apu/amdfw 0x1fdc0raw622592 none > pci1002,9874.rom 0xb7e00optionrom 64512 none > fallback/payload 0xc7a80simple elf5244700 none > (empty)0x5c8200 null 228248 none > AGESA 0x5ffdc0 raw690436 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 0x0500 > Wrote coreboot table at: 0500, 0x10 bytes, checksum 5ffd > Writing coreboot table at 0x8fe11000 > 0. -0fff: CONFIGURATION TABLES > 1. 1000-0009: RAM > 2. 000c-8fdd9fff: RAM > 3. 8fdda000-8fff: CONFIGURATION TABLES > 4. 9000-cfff: RESERVED > 5. f800-fbff: RESERVED > 6. fed4-fed44fff: RESERVED > 7. 0001-00022eff:
[coreboot] Using linux as payload
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 0x0cbfs header32 none fallback/romstage 0x80 stage 32220 none fallback/ramstage 0x7ec0 stage 56689 none cmos_layout.bin0x15c80cmos_layout 1516 none fallback/dsdt.aml 0x162c0raw 6673 none (empty)0x17d40null32856 none apu/amdfw 0x1fdc0raw622592 none pci1002,9874.rom 0xb7e00optionrom 64512 none fallback/payload 0xc7a80simple elf5244700 none (empty)0x5c8200 null 228248 none AGESA 0x5ffdc0 raw690436 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 0x0500 Wrote coreboot table at: 0500, 0x10 bytes, checksum 5ffd Writing coreboot table at 0x8fe11000 0. -0fff: CONFIGURATION TABLES 1. 1000-0009: RAM 2. 000c-8fdd9fff: RAM 3. 8fdda000-8fff: CONFIGURATION TABLES 4. 9000-cfff: RESERVED 5. f800-fbff: RESERVED 6. fed4-fed44fff: RESERVED 7. 0001-00022eff: RAM Board ID: 70 CBFS: 'Master Header Locator' located CBFS at [100:7fffc0) FMAP: Found "FLASH" version 1.1 at 0. FMAP: base = ff80 size = 80 #areas = 3 Wrote coreboot table at: 8fe11000, 0x2f4 bytes, checksum 6365 coreboot table: 780 bytes. IMD ROOT0. 8000 1000 IMD SMALL 1. 8fffe000 1000 ROMSTG STCK 2. 8ffe6000 00018000 RAMSTAGE3. 8feff000 000e7000 57a9e1004. 8fe19000 000e51f0 COREBOOT5. 8fe11000 8000 IRQ TABLE 6. 8fe1 1000 SMP TABLE 7. 8fe0f000 1000 ACPI8. 8fdeb000 00024000 TCPA LOG9. 8fddb000 0001 SMBIOS 10. 8fdda000 0800 IMD small region: IMD ROOT0. 8fffec00 0400 CAR GLOBALS 1. 8fffeac0 0140 ROMSTAGE2. 8fffeaa0 0004 57a9e0003. 8fffea80 0018 COREBOOTFWD 4. 8fffea40 0028 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 0x9 memsize 0x1080 srcaddr 0xff8c7d60 filesize 0x1080 Loading segment from ROM address 0xff8c7cd4 code (compression=0) New segment dstaddr 0x100 memsize 0x2836f0 srcaddr 0xff8c8de0 filesize 0x2836f0 Loading segment from ROM address 0xff8c7cf0 code (compression=0) New segment dstaddr 0x4 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 0x400 memsize 0x27be00 srcaddr 0xffb4c58d filesize 0x27be00 Loading segment from ROM address 0xff8c7d44 Entry Point 0x0004 Loading Segment: addr: 0x0009 memsz: 0x1080 filesz: 0x1080 lb: [0x8ff0, 0x8ffe51f0) Post relocation: addr: 0x0009 memsz: 0x1080 filesz: 0x1080 it's not compressed! [ 0x0009, 00091080, 0x00091080) <- ff8c7d60 dest 0009, end 00091080, bouncebuffer Loading Segment: addr: 0x0100 memsz: 0x002836f0 filesz: 0x002836f0 lb: [0x8ff0,
