coreboot July 2013

coreboot@coreboot.org

45 participants
108 discussions

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

3 years, 10 months

#95: Run coreboot in VirtualBox

by coreboot

#95: Run coreboot in VirtualBox ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: misc | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ It would be nice if we could test coreboot images in VirtualBox, see http://virtualbox.org/. VirtualBox does not (yet) provide a simple mechanism to use a different BIOS in their emulated machines (something like "-L" in qemu). Instead the BIOS image (a custom bochs BIOS + LGPL'g VGABIOS) is converted to C code (an array of bytes, or the like) and merged into the VirtualBox executable. The relevant files are {{{ src/VBox/Devices/PC/DevPcBios.cpp bldprogs/bin2c.c }}} if someone want to hack VirtualBox to easily support using coreboot images instead of their usual BIOS. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/95> coreboot <http://www.coreboot.org/>

6 years, 7 months

EHCI debug port finder

by Carl-Daniel Hailfinger

I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user. Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M The output can be improved, but it's a good start. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 years, 1 month

Dual SPI Flash adapter attempt 2.0

by Oliver Schinagl

Hi list(s), Here's my second attempt at routing the previously mailed png of my schema. It was a lot trickier to route then my previous version, but I think it worked out! As mentioned, S1 and S2 need to be shorted if U3 is to be omitted. RN1 should be 10k or ideally 100k, as Peter mentioned earlier. Hopefully there's no obvious mistakes and can start working on alternative layouts (so it is insert-able in different angles). DRC Check fails on S1, S2 and U3. It thinks the distance is to shallow. That said, DRC check passes when I set the copper width/distance to 7mil's instead of the current 8 mils. I'm planning on having these PCB's manufactured by Seeed studio and their minimal width is much smaller. Minimum trace width: 6mil Minimum trace/vias/pads space : 6mil Minimum silkscreen width : 4mil Minimum silkscreen text size : 32mil I've used a grid size of 10mil and distances of 8 mils, as I didn't want to rely on the minimum of seed. The silkscreen I positioned using a grid size of 5 mil's however. Not sure what they mean with a 'minimum silkscreen text size' however. Anyhow, feedback greatly appreciated, so I can start working on alternative layouts :)

7 years, 4 months

fixed AMD SPI speed settings (leading to problems on E350M1/USB3)

by Stefan Tauner

Hi, andor reported a problem where flashrom does reproducibly not work with coreboot but does with the vendor BIOS http://paste.flashrom.org/view.php?id=1614 Apparently it is related to fast reads and/or the frequency. We have forced the fastReadEnable bit in the SPI_Cntrl0 from 1 to 0 and also set NormSpeed in SPI_Cntrl1 to 16.5 Mhz (previously was 0 i.e. 66 MHz) in flashrom and the problem vanished. Coreboot hard codes the fast read setting in src/southbridge/amd/cimx/sb800/bootblock.c: static void enable_spi_fast_mode(void) { u8 byte; u32 dword; device_t dev = PCI_DEV(0, 0x14, 0x03); // set temp MMIO base volatile u32 *spi_base = (void *)0xa0000000; u32 save = pci_io_read_config32(dev, 0xa0); pci_io_write_config32(dev, 0xa0, (u32) spi_base | 2); // early enable of SPI 33 MHz fast mode read byte = spi_base[3]; spi_base[3] = (byte & ~(3 << 14)) | (1 << 14); spi_base[0] = spi_base[0] | (1 << 18); // fast read enable pci_io_write_config32(dev, 0xa0, save); } Marc suggested that this should be configurable in the devicetree or by a kconfig setting. Also, the statements using "byte" do not make a lot of sense to me. Shouldn't that be a u32 instead? The public documentation of the fastReadEnable is lacking any detail and I don't have access to the NDAed version of the RRG. Is my theory correct that the controller uses the 0x0B opcode with a fixed frequency (33 MHz?) instead of 0x03 with the frequency set by NormSpeed? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

7 years, 5 months

#186: 3com 3c905tx / gpxe boot problem

by coreboot

#186: 3com 3c905tx / gpxe boot problem -----------------------------------+---------------------------------- Reporter: jeroenkrabbendam@… | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: gpxe Dependencies: | Patch Status: there is no patch -----------------------------------+---------------------------------- Although (or: just because) novice in the field, I encountered some problems with netbooting with coreboot. Mobo's tried: Asus P2B, VTech with bios id ITE8671-2A69KV3IC-00. All mobo's boot '''harddisk''' fine with Asus P2B / Gigabyte GA-6BX{CE} respectively. NIC ROM is started, and loads the kernel by tftp. This is vvvveeeerrrryyy slow! Although loading, the kernel is never able to start itself. Same kernel on HDU is no problem at all (GRUB2) Note: the gpxe-image is on the nic, coreboot payload is seabios. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/186> coreboot <http://www.coreboot.org/>

7 years, 6 months

#191: Coreboot:libpayload-size_t conflicting types compiler error

by coreboot

#191: Coreboot:libpayload-size_t conflicting types compiler error ---------------------------+---------------------------------- Reporter: Pradish | Owner: uwe@… Type: defect | Status: new Priority: blocker | Milestone: Component: libpayload | Keywords: Dependencies: | Patch Status: there is no patch ---------------------------+---------------------------------- Hi I have question related to libpayload, which I am trying to solve, but not able to. I have successfully build the coreboot.rom for QEMU x86. Now when I try to build the libpayload project it throws error. System configuration: Virtual Box –Ubuntu 11.10 version Building for X86 Paltform Earlier I have run the cross toolchain using the command ‘make crossgcc’ and it was succcessfull Error information: /coreboot/payloads/libpayload$ make install CC libpci/libpci.libpci.o In File included from include/libpayload.h:54:0, from libpci/libpci.c:30: include/x86/arch/types.h:56:22: error: conflicting types for 'size_t' In file included from include/libpayload.h:49:0, from libpci/libpci.c:30: /home/pradish/coreboot/util/crossgcc/xgcc/lib/gcc/i386-elf/4.7.2/include/stdded.h:213:23: note: previous declaration of 'size_t' was here make: ***[build/libpci/libpci.libpci.o] Error 1 pradish@pradish-VrtualBox:~/coreboot/paylaods/libpayload$ can you tell me, how to resolve this , I have not done any changes to the source code. Just performed ‘make’ regards pradish -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/191> coreboot <http://www.coreboot.org/>

7 years, 8 months

Re: [coreboot] Samsung 550 Chromebook own Coreboot

by John Lewis

After some toing and froing with Aaron Durbin over the last 6 hours this is where we are: mrc.cache is now working but cold boot still takes roughly 5 seconds to get to SeaBIOS display. Warm boot/reset is instantaneous. Aaron says the mrc.bin blob is not happy (and we can't have an unhappy blob now, can we). In order to get mrc.cache working this is what's required: 1. Remove 'select CHROMEOS' from src/mainboard/samsung/lumpy/Kconfig. 2. Add this patch: diff --git a/src/vendorcode/google/chromeos/gnvs.h b/src/vendorcode/google/chrom index 00fe443..5384423 100644 --- a/src/vendorcode/google/chromeos/gnvs.h +++ b/src/vendorcode/google/chromeos/gnvs.h @@ -61,9 +61,13 @@ typedef struct { // dbe } __attribute__((packed)) chromeos_acpi_t; +#if CONFIG_CHROMEOS extern chromeos_acpi_t *vboot_data; void chromeos_init_vboot(chromeos_acpi_t *chromeos); void chromeos_set_me_hash(u32*, int); void acpi_get_vdat_info(uint64_t *vdat_addr, uint32_t *vdat_size); +#else +static inline void chromeos_init_vboot(chromeos_acpi_t *chromeos) {} +#endif #endif 3. make oldconfig 4. make clean 5. make (obviously) Additionally, to get timing information in cbmem -c and cbmem -t the following was necessary: 1. Add 'select LAPIC_MONOTONIC_TIMER' to src/mainboard/samsung/lumpy/Kconfig 2. make oldconfig 3. make (again obviously) The cbmem output is attached. Where to go from here? Many thanks to Aaron for all his help.

7 years, 11 months

Generate microcode from tree not working

by Alec Ari

Hello! Someone recently contacted me directly about my MA785GM-US2H coreboot port, and they weren't able to get the microcode to generate: HOSTCC cbfstool/cbfstool (link) LD cpu_microcode_blob.o coreboot/util/crossgcc/xgcc/bin/i386-elf-ld: no input files make: *** [build/cpu_microcode_blob.o] Error 1 I've tested the compilation process here too and I get the same problem, not sure how to fix it. It doesn't work for me no matter what board I select in Kconfig. Please note I am not subscribed to the coreboot mailing list so if you have a response, I kindly suggest you CC the email to me directly. Alec Ari <neotheuser(a)ymail.com>

7 years, 11 months

Re: [coreboot] Samsung 550 Chromebook own Coreboot

by Aaron Durbin

On Wed, Jul 31, 2013 at 1:48 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: > On 31/07/2013 19:36, Aaron Durbin wrote: > >> On Wed, Jul 31, 2013 at 1:27 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> >>> On 31/07/2013 17:51, Aaron Durbin wrote: >>> >>>> On Wed, Jul 31, 2013 at 11:42 AM, John Lewis <jlewis(a)johnlewis.ie >>>> [9]> wrote: >>>> >>>>> On 31/07/2013 17:11, Aaron Durbin wrote: >>>>> >>>>>> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <jlewis(a)johnlewis.ie >>>>>> [8][8]> wrote: >>>>>> >>>>>>> On 31/07/2013 16:56, Aaron Durbin wrote: >>>>>>> >>>>>>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis >>>>>>>> <jlewis(a)johnlewis.ie [7][7][7]> wrote: >>>>>>>> >>>>>>>>> On 31/07/2013 16:43, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis >>>>>>>>>> <jlewis(a)johnlewis.ie [6][6][6][6]> wrote: >>>>>>>>>> >>>>>>>>>>> On 31/07/2013 16:20, Aaron Durbin wrote: >>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin >>>>>>>>>>>> <adurbin(a)chromium.org [5][5][5][5][5]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >>>>>>>>>>>>> <jlewis(a)johnlewis.ie [4][4][4][4][4][4]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 31/07/2013 15:33, Aaron Durbin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis >>>>>>>>>>>>>>> <jlewis(a)johnlewis.ie [3][3][3][3][3][3]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, Just want to confirm where we are in >>>>>>>>>>>>>>>> terms of things working or not. The new >>>>>>>>>>>>>>>> system-agent binary works and recognises all >>>>>>>>>>>>>>>> 4 GB of RAM as long as an additional pei data >>>>>>>>>>>>>>>> field is added to Stefan's patches in >>>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3831/ [1] [1] >>>>>>>>>>>>>>>> [1] [1] [1] [1] [1] as detailed by Kyösti in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the comments. The patches in >>>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [2] [2] >>>>>>>>>>>>>>>> [2] [2] [2] [2] [2] don't appear to do >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> anything for mrc.cache (it's still zero size) >>>>>>>>>>>>>>>> and this (or perhaps something else) results >>>>>>>>>>>>>>>> in a time to SeaBIOS prompt of between 5 to 9 >>>>>>>>>>>>>>>> seconds. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I >>>>>>>>>>>>>>> didn't see >>>>>>>>>>>>>> >>>>>>>>>>>>>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache >>>>>>>>>>>>> >>>>>>>>>>>>> This is your problem. I was hoping for a build.log >>>>>>>>>>>>> that was completely clean. The build log attached >>>>>>>>>>>>> does not show mrc.cache being created. Can you try >>>>>>>>>>>>> the following and rebuilt? dd if=/dev/zero >>>>>>>>>>>>> of=mrc.cache bs=16K count=1 | tr '00' '377' > >>>>>>>>>>>>> mrc.cache >>>>>>>>>>>> >>>>>>>>>>>> Apologies. I am doing too many things at once. >>>>>>>>>>>> Remove the 'of=mrc.cache' parameter to dd. >>>>>>>>>>> >>>>>>>>>>> The good news is that cbfstool now reports a non-zero >>>>>>>>>>> mrc.cache, the bad news is it doesn't make any >>>>>>>>>>> difference. cbmem -c reports Updating MRC cache data. >>>>>>>>>>> No FMAP found at ffe70000. FMAP: area RW_MRC_CACHE not >>>>>>>>>>> found find_current_mrc_cache_local: No valid MRC cache >>>>>>>>>>> found. SF: Detected W25Q64 with page size 1000, total >>>>>>>>>>> 800000 Need to erase the MRC cache region of -1 bytes >>>>>>>>>>> at 0011037f SF: Erase offset/length not multiple of >>>>>>>>>>> erase size Finally: write MRC cache update to flash at >>>>>>>>>>> 0011037f ICH SPI: Data transaction error SF: Failed to >>>>>>>>>>> send write command (1 bytes): -1 SF: Winbond Page >>>>>>>>>>> Program failed >>>>>>>>>> >>>>>>>>>> CONFIG_CHROMEOS=y You have that option enabled. That's >>>>>>>>>> why you are seeing fm> erefore, it is not using >>>> the >>>>>> >>>>>> mrc.cache cbfs file. There's >>>>>>> >>>>>>> also the fact that >>>> certain variables are not initialized >>>>>>> properly and >>>> thinking the callee will initialize them. >>>>>>> cache_base >>>> should be set to NULL in update_mrc_cache() >>>>>>> before >>>> calling get_mrc_cahce_region(). You'll see more >>>>>>>>>>> >>>>>>>>>>> enlightening messages. That, or ensure >>>> >>>>>>> >>>>>>> get_mrc_cache_region NULL's out the parameter>>> don't >>>> >>>>>>> enable >> CONFIG_CHROMEOS. > Menuconfig enables it by >> >>> >>>>>>> default, and there is no option to > uncheck. If I set it >>> >>>>>>> to 'n' or comment >> get: > build/generated/crt0.romstage.o: In >>>>>>> function `main': >>> >> > >>>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215: >>>>>>>>>> >>>>>>>>>> undefined refe >>>>>> >>>>>> e_chromeos_gpios' > >> > >>>>>> >>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:362: >>>>>>>>> >>>>>>>>> undefined reference to `init_chromeos' > >> >>>>>> >>>>>> build/northbridge/intel/sandybridge/mrccache.romstage.o: In > >> >>>>>> function `get_mrc_cache_region': >>>>>> >>>>> >>>> >>>> /home/john/coreboot/src/northbridge/intel/sandybridge/mrccache.c:71: >>>>>> >>>>>> >>>>>> >>>>>>>>> undefined reference to `find_fmap_entry' >>>>>>>>> build/northbridge/intel/sandybridge/raminit.romstage.o: In >>>>>>>>> function `sdram_initialize': >>>>>> >>>>>> >>>>> >>>> >>>> /home/john/coreboot/src/northbridge/intel/sandybridge/raminit.c:240: >>>>>> >>>>>> undefined reference to `recovery_mode_enabled' collect2: error: >>>>>> ld returned 1 exit status make: *** >>>>>> [build/cbfs/fallback/romstage_null.debug] Error 1 Fantastic. In >>>>>> src/mainboard/samsung/lumpy/Kconfig remove 'select CHROMEOS'. >>>>>> You'll need to do a 'make oldconfig' then rebuild. Fwiw, you >>>>>> can't set it to 'n'. It needs to be '# CONFIG_CHROMEOS is not >>>>>> set'. But since you did set it to 'n' the dependency object files >>>>>> weren't included in the link. Anyway, do a clean build after >>>>>> removing 'select CHROMEOS'. hth. -Aaron Okay. We are getting a >>>>>> bit further along now but: CC cbfs/fallback/coreboot_ram.debug >>>>>> build/generated/coreboot_ram.o: In function `acpi_create_gnvs': >>>>>> >>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/acpi_tables.c:102: >>>>>> >>>>>> undefined reference to `chromeos_init_vboot' collect2: error: ld >>>>>> returned 1 exit status make: *** >>>>>> [build/cbfs/fallback/coreboot_ram.debug] Error 1 Try the >>>>>> following patch: diff --git >>>>>> a/src/vendorcode/google/chromeos/gnvs.h >>>>>> b/src/vendorcode/google/chrom index 00fe443..5384423 100644 --- >>>>>> a/src/vendorcode/google/chromeos/gnvs.h +++ >>>>>> b/src/vendorcode/google/chromeos/gnvs.h @@ -61,9 +61,13 @@ >>>>>> typedef struct { // dbe } __attribute__((packed)) >>>>>> chromeos_acpi_t; +#if CONFIG_CHROMEOS extern chromeos_acpi_t >>>>>> *vboot_data; void chromeos_init_vboot(chromeos_acpi_t *chromeos); >>>>>> void chromeos_set_me_hash(u32*, int); void >>>>>> acpi_get_vdat_info(uint64_t *vdat_addr, uint32_t *vdat_size); >>>>>> +#else +static inline void chromeos_init_vboot(chromeos_acpi_t >>>>>> *chromeos) {} +#endif #endif Or wrap the call in >>>>>> lumpy/acpi_tables.c with '#if CONFIG_CHROMEOS/#endif'. >>>>> >>>>> Okay, that worked, but cold reboot takes 5 secs to SeaBIOS, warm >>>>> reboot is instantaneous. cbmem -c output looks pretty healthy to >>>>> me. I'll attach it anyway. What do you think? >>>> >>>> Was the log from a warm or cold reboot? Also, what do you mean by >>>> cold reboot? Could you set CONFIG_LAPIC_MONOTONIC_TIMER=y? Also, if >>>> you select CONFIG_COLLECT_TIMESTAMPS=y as well that will provide >>>> times that can be read by the cbmem utility (-t option, I think). >>>> With that data we can do an A/B comparison of boot times for your >>>> warm vs cold. -Aaron >>> >>> Cold, I think. Cold boot - power off and switch on again after a few >>> seconds. If I try to use both those options I get: >>> src/lib/timestamp.c:35:31: error: unknown type name 'tsc_t' static >>> uint64_t tsc_to_uint64(tsc_t tstamp) ^ src/lib/timestamp.c:41:1: error: >>> expected identifier or '(' before '{' token { ^ >>> src/lib/timestamp.c:59:1: error: expected identifier or '(' before '{' >>> token { ^ src/lib/timestamp.c:76:1: error: expected identifier or '(' >>> before '{' token { ^ make: *** [build/lib/timestamp.romstage.o] Error 1 >> >> >> Hrmm. I don't understand why that is failing. cpu/x86/tsc.h should be >> included from timestamp.h. No idea why tsc_t isn't being defined. >> Well, removing CONFIG_COLLECT_TIMESTAMPS should make your build work. >> And we can at least see ramstage boot times. > > > Attached. Cold was much slower this time. > > John. Your cold logs has the following: find_current_mrc_cache_local: No valid MRC cache found. I take it that was after a fresh reprogram? If you do another cold boot it should use the MRC cache. I was going to compare the boot state times, but it seems these logs don't have CONFIG_LAPIC_MONOTONIC_TIMER enabled? -Aaron

7 years, 12 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2013