coreboot August 2018

coreboot@coreboot.org

43 participants
110 discussions

Re: [coreboot] USB cannot work
by Nico Huber 22 Aug '18

22 Aug '18

Hello Hilbert, Am 21.08.18 um 12:09 schrieb Hilbert Tu(杜睿哲_Pegatron): > From BWG(BIOS Write Guide), there are two steps needed to be done for USB to work: > > 1. Pre-Operating Software Initialization > > 2. EHCI Initialization for Pre-OS Software Usage > > Does anyone know where these steps are implemented in Coreboot? > Thanks. I don't but my educated guess is: 1. In FSP. 2. Your payload. Though, there is a pitfall I guess. If the public datasheet for Den- verton is correct, there is *no* EHCI. And this might be your actual problem: If you only have an xHCI controller, it doesn't work with GRUB simply because GRUB doesn't have a driver for xHCI. AFAIK, nobody wrote one yet. > > -Hilbert > This e-mail and its attachment may contain information that is > confidential or privileged, and are solely for the use of the individual > to whom this e-mail is addressed. If you are not the intended recipient > or have received it accidentally, please immediately notify the sender > by reply e-mail and destroy all copies of this email and its attachment. > Please be advised that any unauthorized use, disclosure, distribution or > copying of this email or its attachment is strictly prohibited. This footer makes absolutely no sense when you address a mailing list. I wouldn't be surprised if you get less answers because of it. Nico

2 1

Fwd: USB to Serial Converters
by zahra rahimkhani 21 Aug '18

21 Aug '18

---------- Forwarded message --------- From: zahra rahimkhani <zrahimkhani2014(a)gmail.com> Date: Sat, Aug 18, 2018 at 12:47 PM Subject: Re: [coreboot] USB to Serial Converters To: David Hendricks <david.hendricks(a)gmail.com> Hello David Thank you very much for your help . I used version 4.8 but it shows this message on consol and do not boot usb flash or sata. Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version rel-1.11.2-0-gf9626cc) EHCI init on dev 00:1d.0 (regs=0xd061e020) WARNING - Timeout at i8042_flush:71! AHCI controller at 00:13.0, iobase 0xd061d000, irq 10 Searching bootorder for: /pci@i0cf8/*@12 Found 0 lpt ports Found 1 serial ports Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/storage@1/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/usb-*@1 USB MSC vendor='UFD 2.0' product='Silicon-Power8G' rev='1100' type=0 removable=1 USB MSC blksize=512 sectors=15730688 Initialized USB HUB (1 ports used) All threads complete. Scan for option roms Press ESC for boot menu. Searching bootorder for: HALT drive 0x000f62c0: PCHS=0/0/0 translation=lba LCHS=979/255/63 s=15730688 Space available for UMB: cd800-ed800, f5b60-f62c0 Returned 253952 bytes of ZoneHigh e820 map has 18 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000020000000 = 1 RAM 4: 0000000020000000 - 0000000020100000 = 2 RESERVED 5: 0000000020100000 - 000000007ad9c000 = 1 RAM 6: 000000007ad9c000 - 0000000080000000 = 2 RESERVED 7: 00000000e0000000 - 00000000f0000000 = 2 RESERVED 8: 00000000feb00000 - 00000000fec01000 = 2 RESERVED 9: 00000000fed01000 - 00000000fed02000 = 2 RESERVED 10: 00000000fed03000 - 00000000fed04000 = 2 RESERVED 11: 00000000fed05000 - 00000000fed06000 = 2 RESERVED 12: 00000000fed08000 - 00000000fed09000 = 2 RESERVED 13: 00000000fed0c000 - 00000000fed10000 = 2 RESERVED 14: 00000000fed1c000 - 00000000fed1d000 = 2 RESERVED 15: 00000000fee00000 - 00000000fee01000 = 2 RESERVED 16: 00000000fef00000 - 00000000ff000000 = 2 RESERVED 17: 00000000ff800000 - 0000000100000000 = 2 RESERVED enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 I would be grateful if you guide me . I should set a special config or no? Best , Zahra On Sun, Aug 5, 2018 at 4:35 PM David Hendricks <david.hendricks(a)gmail.com> wrote: > Hi Zahra, > Yes, I used the 6-pin serial port header. Also, make sure the microcode > header(s) you include correspond to the CPUID of your processor. The E3825 > and E3826 use different microcode headers, so M0130679901.h will not work > for you. > > Please keep the coreboot mailing list CC'd. I haven't done anything with > Minnowboard in several months and others may be able to help. > > On Thu, Aug 2, 2018 at 5:01 PM, zahra rahimkhani < > zrahimkhani2014(a)gmail.com> wrote: > >> Hi David >> >> Thank you for your help. >> I extract your file and got M0130679901.h as Microcode but my board does >> not work it did not show anything. >> I use E3825. >> In previous notes, you told "My guess is that you don't have >> CONFIG_ENABLE_BUILTIN_COM1 selected >> (under "Chipset"), which is an option you have to set in addition to >> the stuff under "Console." >> but in your config, you had not enabled this option. >> Could you help me with this and Did you use 6 pins that are separated >> on board for console port? >> I do not know what is my problem .it did not show anything log. >> >> >> >> Thank you for your time. >> Zahra >> >> >> >> On Wed, Aug 1, 2018 at 2:04 AM David Hendricks <david.hendricks(a)gmail.com> >> wrote: >> >>> Hi Zahra, >>> That header may be out of date >>> (https://mail.coreboot.org/pipermail/coreboot/2017-August/084800.html). >>> >>> I had to manually download the microcode file corresponding to my >>> processor SKU from Intel. Use the link I sent you earlier to download >>> Baytrail_FSP_Gold4.tgz and see if the microcode headers included in >>> that tarball match your processor. The Atom on my Minnowboard Turbot >>> has a CPUID of 30679, so I needed to use M0130679901.h. >>> >>> (note that the Minnowboard Max uses an Atom E3825, while the Turbot >>> uses an E3826 dual-core SoC or E3845 quad-core SoC) >>> >>> On Mon, Jul 30, 2018 at 2:36 AM, zahra rahimkhani >>> <zrahimkhani2014(a)gmail.com> wrote: >>> > >>> > Dear David >>> > >>> > for Microcode file I just it from coreboot source from this path >>> > coreboot/3rdparty/blobs/soc/intel/baytrail/microcode_blob.h >>> > >>> > Is that good ? >>> > >>> > Thanks , >>> > >>> > >>> > On Sun, Jul 29, 2018 at 1:18 PM zahra rahimkhani < >>> zrahimkhani2014(a)gmail.com> >>> > wrote: >>> >> >>> >> Hi David, >>> >> >>> >> Thank you very much for your guide. >>> >> >>> >> I got this comments on my config and changes it based on your config. >>> >> But I can not see any thing on output. >>> >> Could you tell me which Uart pins do you use on Minnowboard max >>> >> >>> >> I used it 6 pin that are separately on board . >>> >> >>> >> I would be grateful if you guide me . >>> >> I got my new config here . >>> >> https://paste.flashrom.org/view.php?id=3097 >>> >> >>> >> Also , Could you tell me what is this parameter >>> >> CONFIG_UART_FOR_CONSOLE=0 >>> >> and >>> >> CONFIG_DRIVERS_UART_8250IO >>> >> >>> >> Cheers! >>> >> Zahra >>> >> >>> >> >>> >> >>> >> On Fri, Jul 27, 2018 at 11:06 AM David Hendricks >>> >> <david.hendricks(a)gmail.com> wrote: >>> >>> >>> >>> Hi Zahra, >>> >>> >>> >>>> I got my config file here >>> >>>> https://paste.flashrom.org/view.php?id=3096 >>> >>> >>> >>> >>> >>> Thanks, that helps a lot! >>> >>> >>> >>> The last config that I tested is >>> >>> >>> https://review.coreboot.org/cgit/board-status.git/plain/intel/minnowmax/4.6… >>> >>> >>> >>> If you diff my config and yours, it seems you have several options >>> >>> disabled which I think you should try enabling: >>> >>> CONFIG_HAVE_IFD_BIN >>> >>> CONFIG_HAVE_ME_BIN >>> >>> CONFIG_TTYS0_LCS >>> >>> CONFIG_DRIVERS_UART_8250IO >>> >>> CONFIG_IFD_BIN_PATH >>> >>> CONFIG_ME_BIN_PATH >>> >>> CONFIG_LOCK_MANAGEMENT_ENGINE >>> >>> CONFIG_DRIVERS_UART >>> >>> CONFIG_CONSOLE_SERIAL >>> >>> CONFIG_CONSOLE_SERIAL_115200 >>> >>> >>> >>> You can find these by using the search function in `make menuconfig`. >>> >>> Press '/' and type a Kconfig option. >>> >>> >>> >>>> I would be grateful if you check my config and tell me what is >>> ifdtool >>> >>>> in Coreboot and how >>> >>>> I use it. >>> >>>> and How I find Intel ME file for my board and GBE for a network on >>> my >>> >>>> board. >>> >>> >>> >>> >>> >>> ifdtool is a tool for viewing and manipulating an Intel Flash >>> Descriptor >>> >>> binary. The flash descriptor is a 4KB data structure at the start of >>> the >>> >>> ROM's address space (offset 0x000000-0x000fff). >>> >>> >>> >>> To build it: `make -C util/ifdtool` >>> >>> To run it: `util/ifdtool/ifdtool` >>> >>> >>> >>> You'll probably want to use the '-x' option to extract the individual >>> >>> modules from an existing Minnowboard Max firmware image (e.g. the >>> UEFI image >>> >>> that comes with the board). That will give you the ME and GBE files. >>> >>> >>> > >>> >> >

1 0

Re: [coreboot] Using linux as payload
by Jorge Fernandez Monteagudo 21 Aug '18

21 Aug '18

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 <kakaroto(a)kakaroto.homelinux.net> 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 <jorgefm(a)cirsa.com> 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 > 1. 0000000000001000-000000000009ffff: RAM > 2. 00000000000c0000-000000008fdd9fff: RAM > 3. 000000008fdda000-000000008fffffff: CONFIGURATION TABLES > 4. 0000000090000000-00000000cfffffff: RESERVED > 5. 00000000f8000000-00000000fbffffff: RESERVED > 6. 00000000fed40000-00000000fed44fff: RESERVED > 7. 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! > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 21 Aug '18

21 Aug '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1395106: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/soc/intel/apollolake/chip.c: 681 in configure_xhci_host_mode_port0() ________________________________________________________________________________________________________ *** CID 1395106: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/soc/intel/apollolake/chip.c: 681 in configure_xhci_host_mode_port0() 675 676 printk(BIOS_INFO, "Putting xHCI port 0 into host mode.\n"); 677 res = find_resource(xhci_dev, PCI_BASE_ADDRESS_0); 678 cfg0 = (void *)(uintptr_t)(res->base + DUAL_ROLE_CFG0); 679 cfg1 = (void *)(uintptr_t)(res->base + DUAL_ROLE_CFG1); 680 reg = read32(cfg0); >>> CID 1395106: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> The expression "reg && 1 /* 1 << 21 */" is suspicious because it performs a Boolean operation on a constant other than 0 or 1. 681 if (!(reg && SW_IDPIN_EN_MASK)) 682 return; 683 684 reg &= ~(SW_IDPIN_MASK | SW_VBUS_VALID_MASK); 685 write32(cfg0, reg); 686 ** CID 1395105: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1395105: Insecure data handling (TAINTED_SCALAR) /src/lib/fit.c: 400 in fit_update_compat() 394 struct fdt_header *fdt_header = (struct fdt_header *)fdt_blob; 395 uint32_t fdt_offset = be32_to_cpu(fdt_header->structure_offset); 396 size_t i = 0; 397 398 if (!fdt_find_compat(fdt_blob, fdt_offset, &config->compat)) { 399 list_for_each(compat_node, compat_strings, list_node) { >>> CID 1395105: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "config->compat.size" to a tainted sink. 400 int pos = fit_check_compat(&config->compat, 401 compat_node->compat_string); 402 if (pos >= 0) { 403 config->compat_pos = pos; 404 config->compat_rank = i; 405 config->compat_string = ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] USB cannot work
by Hilbert Tu(杜睿哲_Pegatron) 21 Aug '18

21 Aug '18

Hi, From BWG(BIOS Write Guide), there are two steps needed to be done for USB to work: 1. Pre-Operating Software Initialization 2. EHCI Initialization for Pre-OS Software Usage Does anyone know where these steps are implemented in Coreboot? Thanks. -Hilbert This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] Using linux as payload
by Youness Alaoui 20 Aug '18

20 Aug '18

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 <jorgefm(a)cirsa.com> 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 > 1. 0000000000001000-000000000009ffff: RAM > 2. 00000000000c0000-000000008fdd9fff: RAM > 3. 000000008fdda000-000000008fffffff: CONFIGURATION TABLES > 4. 0000000090000000-00000000cfffffff: RESERVED > 5. 00000000f8000000-00000000fbffffff: RESERVED > 6. 00000000fed40000-00000000fed44fff: RESERVED > 7. 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! > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How to send a patch?
by Th3Fanbus . 20 Aug '18

20 Aug '18

Hello Jorge, You can submit the patch yourself, check out https://doc.coreboot.org/lessons/index.html as a reference. Regards, Angel Pons Pons On Mon, Aug 20, 2018, 19:22 Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> wrote: > Hi > > I would like to contribute with some questions I've found trying to > running an AMD Bettong board. > > Attached is a little patch to enable the SATA and to set the > domain_acpi_name... If someone could review it and upload it to > repository... > > Thanks! > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

How to send a patch?
by Jorge Fernandez Monteagudo 20 Aug '18

20 Aug '18

Hi I would like to contribute with some questions I've found trying to running an AMD Bettong board. Attached is a little patch to enable the SATA and to set the domain_acpi_name... If someone could review it and upload it to repository... Thanks!

1 0

F2A85M coreboot+seabios Radeons Cards
by kinky_nekoboi 20 Aug '18

20 Aug '18

I can not get any Radeons Addon card working together with Coreboot+Seabios on this board. The cards are listed in lspci output but no signal to the monitor. A GF 8400GS works just fine. Any Ideas ?

2 1

undefined reference to '__udivmoddi4'
by hybris＠e2m.io 19 Aug '18

19 Aug '18

Hello, I am trying to build coreboot for a Lenovo Thinkpad x201. I followed the instructions from the following documents: https://doc.coreboot.org/lessons/lesson1.html https://www.coreboot.org/Build_HOWTO When using the crossgcc-x64 toolchain building works fine but linking fails with the following error: coreboot/src/console/vtxprintf.c:102: undefined reference to '__udivmoddi4' As far is i could find out this error should not even get thrown for x64, since `__udivmoddi4` is an optimization for i386. [0] Building (and linking) with the crossgcc-i386 toolchain works fine though. But I guess x64 features will then be missing in the build. Is there currently a way to build a x64 version of coreboot or do I have to go with i386 for now? [0] https://stackoverflow.com/questions/51457851/building-coreboot-undefined-re… best regards Norman Wilms

2 1

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2018