coreboot April 2013

coreboot@coreboot.org

42 participants
125 discussions

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/>

5 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/

6 years, 2 months

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 :)

6 years, 5 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

6 years, 6 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/>

6 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/>

6 years, 9 months

unsupported mb questions (amd fam10h)

by Roman Elshin

I try to get coreboot working with asrock 880g pro3 board. First problem: spd eprom say that memory ddr1600 capable, but it is not so, is there are right way to limit memory frequency at ddr1333? Other problem, may be related as machine with broken memory are very unpredictable: boot process stop with "It is not SB800 or SB810" message. I try to enable sb850 by this patch, but looks like it is not enough, most of time coreboot does not detect hdd. Sometimes in very rare case it is possible to boot from sata. Are sb850 supported by coreboot? ----------------------------------------------------------------------- diff -urN a/src/southbridge/amd/sb800/early_setup.c b/src/southbridge/amd/sb800/early_setup.c --- a/src/southbridge/amd/sb800/early_setup.c 2012-07-14 19:00:40.000000000 +0400 +++ b/src/southbridge/amd/sb800/early_setup.c 2012-07-14 21:49:54.000000000 +0400 @@ -94,7 +94,10 @@ rev = REV_SB800_A11; } else if (rev_id == 0x41) { rev = REV_SB800_A12; - } else { + } else if (rev_id == 0x42) { + rev = REV_SB800_A13; + } + else { die("It is not SB800 or SB810\r\n"); } diff -urN a/src/southbridge/amd/sb800/sb800.h b/src/southbridge/amd/sb800/sb800.h --- a/src/southbridge/amd/sb800/sb800.h 2012-07-14 19:00:40.000000000 +0400 +++ b/src/southbridge/amd/sb800/sb800.h 2012-07-14 21:49:10.000000000 +0400 @@ -48,7 +48,7 @@ #define REV_SB800_A11 0x11 #define REV_SB800_A12 0x12 - +#define REV_SB800_A13 0x13 #ifdef __PRE_RAM__ void sb800_lpc_port80(void); -------------------------------------------------------------------------

7 years

Re: [coreboot] ASUS m5a88-v AGESA port (bulldozer)

by darkdefende＠gmail.com

Idwer Vollering writes: > Done. Thanks for attaching the log for me. Some recent commits to coreboot master seems to have solved my problem with the pci scan hang. Now I don't have to hack around it any more. However it still freezes after it's done (?) loading seabios. I have uploaded my changes to https://github.com/DarkDefender/coreboot if anyone want's to look at them. I've tried to enable more debugging options in the "OptionsIds.h" for AGESA but it doesn't seem to do anything. The asserts are triggered druing boot are still the same as before. I've tried to look at it but I didn't really understand what I should change to solve them.

7 years, 1 month

ASRock E350M1: Linux reports `piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use!`

by Paul Menzel

Dear coreboot folks, since [1] commit df729d7778a7e5878fac5545883f68e42372456a Author: Jens Rottmann <JRottmann(a)LiPPERTembedded.de> Date: Tue Feb 19 14:46:31 2013 +0100 AMD Fam14 boards: dimmSpd.c: Set `iobase` to `SMBUS0_BASE_ADDRESS` instead of `0xB00` which I expanded to the ASRock E350M1, overlooking the new error message, Linux complains about an already used base address index region. calling i2c_piix4_init+0x0/0x1000 [i2c_piix4] @ 559 piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use! piix4_smbus: probe of 0000:00:14.0 failed with error -16 The address 0xb00 was used before and this should not have been changed with the patch above. But it did. I looked through the code but could not find where 0xcd6 comes from. Any pointers would be very much appreciated. Thanks, Paul [1] http://review.coreboot.org/2453

7 years, 2 months

Re: [coreboot] On loongson CPU or MIPS ARCH

by ron minnich

OK, I took a look at the code. Nice to see such a simple startup, reminds of linuxbios v1 days. At least if this is the right one: http://fossies.org/linux/misc/grub-2.00.tar.gz:a/grub-2.00/grub-core/boot/m… I don't see a problem pulling this in to coreboot. We'd probably trim some bits out and let ramstage take over, but for a first cut it could be used as is. This code is very similar in how it works to many linuxbios/coreboot platforms and hence should fit into the coreboot structure with ease. The first step remains the same: set up crossgcc. I talked to stefan yesterday about incorporating extant loongson patches into a gcc build and he mentioned that the utility is designed to allow you to specify patches to be pulled at build time. So, let's start with crossgcc for mips/loongson. This is a minimum requirement. ron

7 years, 3 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2013