coreboot July 2012

coreboot@coreboot.org

35 participants
639 discussions

Patch set updated for coreboot: 8980d15 fixed cbfs_find_file() type mismatch
by Alexandru Gagniuc 28 Jul '12

28 Jul '12

Alexandru Gagniuc (mr.nuke.me(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1371 -gerrit commit 8980d151f06bd0c3ae2b83d422987e3ac49218ef Author: David Griffith <dave(a)661.org> Date: Fri Jul 27 02:26:54 2012 -0700 fixed cbfs_find_file() type mismatch Change-Id: I630000d4466d1cadc8519ad2cc9a4e840e2685e8 Signed-off-by: David Griffith <dave(a)661.org> --- payloads/libpayload/include/cbfs_core.h | 2 +- payloads/libpayload/libcbfs/cbfs_core.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/payloads/libpayload/include/cbfs_core.h b/payloads/libpayload/include/cbfs_core.h index 70368f8..66df50e 100644 --- a/payloads/libpayload/include/cbfs_core.h +++ b/payloads/libpayload/include/cbfs_core.h @@ -172,7 +172,7 @@ struct cbfs_file *cbfs_find(const char *name); void *cbfs_get_file(const char *name); /* returns pointer to file data inside CBFS after if type is correct */ -void *cbfs_find_file(const char *name, int type); +struct cbfs_stage *cbfs_find_file(const char *name, int type); /* returns 0 on success, -1 on failure */ int cbfs_decompress(int algo, void *src, void *dst, int len); diff --git a/payloads/libpayload/libcbfs/cbfs_core.c b/payloads/libpayload/libcbfs/cbfs_core.c index 4bf755b..9468fce 100644 --- a/payloads/libpayload/libcbfs/cbfs_core.c +++ b/payloads/libpayload/libcbfs/cbfs_core.c @@ -137,7 +137,7 @@ void *cbfs_get_file(const char *name) return (void*)CBFS_SUBHEADER(file); } -void *cbfs_find_file(const char *name, int type) +struct cbfs_stage *cbfs_find_file(const char *name, int type) { struct cbfs_file *file = cbfs_find(name);

1 0

Re: [coreboot] QEMU version step-by-step (Actually, just hints here)
by Dan Connelly 28 Jul '12

28 Jul '12

Start with "QEMU Build Tutorial" http://www.coreboot.org/QEMU_Build_Tutorial Unfortunately, that write up is sketchy and certainly not newbie-proof. For instance, Tutorial does not point out that, of course, you do need to build coreboot BIOS for the Qemu virtual machine (Emulator), not your target physical machine. I suppose this is obvious once you get your head around it. Wasn't obvious to me as a newbie until Peter Stuge clued me in. But, you do not appear to be having that particular problem. Use FILO as your payload. Depending on your gcc version, you may have a problem with the defined configuration for FILO under a Coreboot ROM build. gcc issues can be hacked around fairly easily in the Makefile.inc setups. Note that either of 2 versions of FILO will be offered in the coreboot menu. Neither one is guaranteed free of gcc issues. But, the rest of FILO configuration will be pre-defined. This is a bit over-cooked. It can be hacked around easily. But don't. Just go vanilla. I suggest you avoid multiboot until you get Linux kernels and initial ram disk images to load using FILO. Using FILO will make it easier for you to work around kernel compression issues, such as the one you appear to have. (But I am guessing since I don't have experience with multiboot set-up and I am not completely clear what you are attempting to boot.) Once you get the "filo>" prompt on your guest (Qemu) console, you are ready to diagnose problems with your disk.img (the "hda" disk image that filo will use). You will need to understand Grub syntax here. Root device is hda. Tutorial says you need to umount this hda image from the loop mount on /mnt/rootfs before calling Qemu. Not so. Just make sure you do a "sync" before running Qemu. Also, you really don't have to mount this image in the root of your host filesystem as shown (/mnt/rootfs). A mount point local to your Coeboot/Qemu project on host machine may be more appropriate. For FILO, you can set up a menu.lst for a selection of OS boots as you would do using Grub in your host environment. You will boot-up kernels and, likely, initial ram disk images as appears on this disk image, depending on your selection from FILO menu selection list. This works nicely with either VGA console or -nographic. Note that example screen for the Tutorial shows FILO loading a Linux kernel image and an initrd for the kernel to use. Last line on this screen says "Jumping to entry point...". That is a far into Linux as you are likely to get using this tutorial. You might not get any further than that because the kernel you are told to use is one stolen from your host Linux. Different distros will boot the same Linux kernel differently using kernel customizations. Your kernel may not like running in the Qemu guest machine due to hardware naming mis-matches. It will probably die trying to mount a physical disk that is unknown to Qemu. This is not a Coreboot issue, of course. Once, you are "Jumping" bios is done (more or less). Its a kernel issue. but the Coreboot Tutorial would be much easier to use if the kernel loading mechanism was clearer. Getting a Linux kernel to run under Qemu was left outside the scope of the Tutorial I am on a personal side-track of using "dracut" to get kernel and init ram disk images that can adapt to the hardware it finds itself being booted into. Again, this is well outside the scope of coreboot, but may be useful when you re-target to new hardware using Qemu. Nice if you mainboard selections under Coreboot were all you you needed to work-out for a hardware port, i.e., if there were a dracut integration. If your bios builds are strictly for qemu or strictly for your host hardware, then you may not want to delve into dracut. Qemu comes with kernel. So does your host Linux. On the other hand, dracut testing code is all about running Linux kernel under qemu under a variety of hardware constraints. Dracut testing uses the default qemu bios. However, using coreboot bios instead of the qemu bios should work and is an interesting exercise in itself. If coreboot bios does work for full dracut testing, that might suggest a coreboot rom bios problem. Good luck. -- Dan Connelly

1 0

Re: [coreboot] 64bit PCI support in coreboot and CRS methods
by Denis 'GNUtoo' Carikli 28 Jul '12

28 Jul '12

On Sat, 2012-07-28 at 18:32 +0000, Alexey Korolev wrote: > a. Status of 64bit support Under GNU/Linux, on the M4A785T-M: * USB fails to work with 64bit..., since my test setup uses an USB key for booting the 64bit GNU/Linux I didn't test a lot of things... it mounts the initramfs and fails to find the rootfs. * SATA works (tested with cat /proc/partitions + mounting + writing dmesg to the /boot partition) Denis.

1 0

Re: [coreboot] 64bit PCI support in coreboot and CRS methods
by Peter Stuge 28 Jul '12

28 Jul '12

Alexey Korolev wrote: > Sorry I'm not familiar with coreboot, so I probably asking obvious things. > > I have questions about the status of 64bit PCI support in coreboot. Why not look this up yourself in the source code? > I ask these questions because there is a BSOD issue on Win2003 with > 64bit PCI mem resources in Seabios. > The issue is caused by CRS method in ACPI dsdt code of seabios. > Unfortunately I don't know how to fix this bug. Probably you can > suggest something if there is no such a problem in coreboot. I > would very much appreciate any ideas! It sounds like you have a problem with another project, like you do not want to learn about the technology involved (which I understand, ACPI is no fun), and like you hope that some coreboot folks will tell you how to fix the problem. Nothing works like that. I suggest to learn more about the technology you are stuck with, or to hire someone who already has. You haven't even shown a boot log from SeaBIOS, much less the checked windows error. Did you even try a checked windows build? Can you interpret the errors it throws? Did you investigate the problem in WinDbg? There are numerous things that you could do in order to gather information about the problem, and you don't seem to have done any single one of them, yet you ask people you don't know on the internet to help you. Come on.. //Peter

2 1

New patch to review for coreboot: 17dea8e sandybridge: reinitialize usbdebug after MRC
by Sven Schnelle 28 Jul '12

28 Jul '12

Sven Schnelle (svens(a)stackframe.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1377 -gerrit commit 17dea8e61861022ee7174b80b585e279a8af2de2 Author: Sven Schnelle <svens(a)stackframe.org> Date: Sat Jul 28 09:28:56 2012 +0200 sandybridge: reinitialize usbdebug after MRC MRC messes with USB devices, so we have to reinitialize USB debug after MRC has finished. Change-Id: I45c0a687cebd69d0a31235bb870f8c455f42d4f2 Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/northbridge/intel/sandybridge/raminit.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/northbridge/intel/sandybridge/raminit.c b/src/northbridge/intel/sandybridge/raminit.c index bb8b25c..840bf75 100644 --- a/src/northbridge/intel/sandybridge/raminit.c +++ b/src/northbridge/intel/sandybridge/raminit.c @@ -265,6 +265,10 @@ void sdram_initialize(struct pei_data *pei_data) die("UEFI PEI System Agent not found.\n"); } +#if CONFIG_USBDEBUG + early_usbdebug_init(); +#endif + /* For reference print the System Agent version * after executing the UEFI PEI stage. */

1 0

New patch to review for coreboot: 7dd46ab bd82x6x: Fix CONFIG_USBDEBUG
by Sven Schnelle 27 Jul '12

27 Jul '12

Sven Schnelle (svens(a)stackframe.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1376 -gerrit commit 7dd46ab494b0efa77e629a9e747542391aeb325b Author: Sven Schnelle <svens(a)stackframe.org> Date: Sat Jul 28 08:52:44 2012 +0200 bd82x6x: Fix CONFIG_USBDEBUG Compilation fails with set_debug_port undeclared in ramstage and smm code. Fix that by adding usb_debug.c to the appropriate stages. Change-Id: I2a037d3c5fab76ae6ea65c3a7f4d4e7561bb6d34 Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/southbridge/intel/bd82x6x/Makefile.inc | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/southbridge/intel/bd82x6x/Makefile.inc b/src/southbridge/intel/bd82x6x/Makefile.inc index f9aade8..c588341 100644 --- a/src/southbridge/intel/bd82x6x/Makefile.inc +++ b/src/southbridge/intel/bd82x6x/Makefile.inc @@ -41,5 +41,7 @@ smm-$(CONFIG_HAVE_SMI_HANDLER) += smihandler.c me.c me_8.x.c finalize.c romstage-y += early_usb.c early_smbus.c early_me.c me_status.c gpio.c romstage-$(CONFIG_USBDEBUG) += usb_debug.c +ramstage-$(CONFIG_USBDEBUG) += usb_debug.c +smm-$(CONFIG_USBDEBUG) += usb_debug.c romstage-y += reset.c

1 0

New patch to review for coreboot: 8e19fa4 USBDEBUG: retry harder for slow devices
by Sven Schnelle 27 Jul '12

27 Jul '12

Sven Schnelle (svens(a)stackframe.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1375 -gerrit commit 8e19fa4fc269682c98b5b2a63c6b6e0153979deb Author: Sven Schnelle <svens(a)stackframe.org> Date: Wed Jul 25 14:19:45 2012 +0200 USBDEBUG: retry harder for slow devices Some usb debug devices don't respond fast enough. The linux kernel (which uses almost the same usbdebug code) added a bit more retry code, so let's copy that. Even if it might look stupid, i pass the DBG_LOOPS argument through all functions to keep the code at least a bit in sync with the linux kernel code. Change-Id: I7c4b63b8bf1d2270fd6b8c8aa835e2cb324820bd Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/lib/usbdebug.c | 21 ++++++++++++--------- 1 files changed, 12 insertions(+), 9 deletions(-) diff --git a/src/lib/usbdebug.c b/src/lib/usbdebug.c index fd23426..24d7967 100644 --- a/src/lib/usbdebug.c +++ b/src/lib/usbdebug.c @@ -80,6 +80,7 @@ #define HUB_RESET_TIMEOUT 500 #define DBGP_MAX_PACKET 8 +#define DBGP_LOOPS 1000 static int dbgp_wait_until_complete(struct ehci_dbg_port *ehci_debug) { @@ -108,11 +109,10 @@ static void dbgp_breath(void) /* Sleep to give the debug port a chance to breathe */ } -static int dbgp_wait_until_done(struct ehci_dbg_port *ehci_debug, unsigned ctrl) +static int dbgp_wait_until_done(struct ehci_dbg_port *ehci_debug, unsigned ctrl, int loop) { u32 pids, lpid; int ret; - int loop = 3; retry: write32((unsigned long)&ehci_debug->control, ctrl | DBGP_GO); @@ -120,8 +120,11 @@ retry: pids = read32((unsigned long)&ehci_debug->pids); lpid = DBGP_PID_GET(pids); - if (ret < 0) + if (ret < 0) { + if (ret == -DBGP_ERR_BAD && --loop > 0) + goto retry; return ret; + } /* If the port is getting full or it has dropped data * start pacing ourselves, not necessary but it's friendly. @@ -190,7 +193,7 @@ static int dbgp_bulk_write(struct ehci_dbg_port *ehci_debug, write32((unsigned long)&ehci_debug->address, addr); write32((unsigned long)&ehci_debug->pids, pids); - ret = dbgp_wait_until_done(ehci_debug, ctrl); + ret = dbgp_wait_until_done(ehci_debug, ctrl, DBGP_LOOPS); return ret; } @@ -202,7 +205,7 @@ int dbgp_bulk_write_x(struct ehci_debug_info *dbg_info, const char *bytes, int s } static int dbgp_bulk_read(struct ehci_dbg_port *ehci_debug, unsigned devnum, - unsigned endpoint, void *data, int size) + unsigned endpoint, void *data, int size, int loops) { u32 pids, addr, ctrl; int ret; @@ -222,7 +225,7 @@ static int dbgp_bulk_read(struct ehci_dbg_port *ehci_debug, unsigned devnum, write32((unsigned long)&ehci_debug->address, addr); write32((unsigned long)&ehci_debug->pids, pids); - ret = dbgp_wait_until_done(ehci_debug, ctrl); + ret = dbgp_wait_until_done(ehci_debug, ctrl, loops); if (ret < 0) return ret; @@ -235,7 +238,7 @@ static int dbgp_bulk_read(struct ehci_dbg_port *ehci_debug, unsigned devnum, int dbgp_bulk_read_x(struct ehci_debug_info *dbg_info, void *data, int size) { return dbgp_bulk_read(dbg_info->ehci_debug, dbg_info->devnum, - dbg_info->endpoint_in, data, size); + dbg_info->endpoint_in, data, size, DBGP_LOOPS); } static void dbgp_mdelay(int ms) @@ -279,13 +282,13 @@ static int dbgp_control_msg(struct ehci_dbg_port *ehci_debug, unsigned devnum, i dbgp_set_data(ehci_debug, &req, sizeof(req)); write32((unsigned long)&ehci_debug->address, addr); write32((unsigned long)&ehci_debug->pids, pids); - ret = dbgp_wait_until_done(ehci_debug, ctrl); + ret = dbgp_wait_until_done(ehci_debug, ctrl, DBGP_LOOPS); if (ret < 0) return ret; /* Read the result */ - ret = dbgp_bulk_read(ehci_debug, devnum, 0, data, size); + ret = dbgp_bulk_read(ehci_debug, devnum, 0, data, size, DBGP_LOOPS); return ret; }

1 0

FILO STABLE branch doesn't build
by David Griffith 27 Jul '12

27 Jul '12

I narrowed down my flailing from last night to the fact that FILO itself at the STABLE branch just will not build. The master branch, however, will. Perhaps is it time to make a new stable branch? -- David Griffith dave(a)661.org

1 0

Patch set updated for coreboot: 24a3100 Fix mainboard level enable_dev()
by Kyösti Mälkki 27 Jul '12

27 Jul '12

Kyösti Mälkki (kyosti.malkki(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1374 -gerrit commit 24a31006d5089550f08076b78e51d92d687ae77a Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Fri Jul 27 19:22:26 2012 +0300 Fix mainboard level enable_dev() Commit 188e3c2ff06a82f61d7d71e610b32b1a250c0a45 dropped mainboard out of the static device tree. This left dev_root->chip_ops unset, and mainboard_ops.enable_dev() was no longer called. Change-Id: I6d447c8049a66041b8bb36ec9aac3e7e0d20a99b Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> --- src/devices/device.c | 4 ++-- src/include/device/device.h | 1 + src/mainboard/emulation/qemu-x86/chip.h | 4 ---- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/src/devices/device.c b/src/devices/device.c index 92a4447..d0e801b 100644 --- a/src/devices/device.c +++ b/src/devices/device.c @@ -922,8 +922,8 @@ void dev_enumerate(void) printk(BIOS_SPEW, "Compare with tree...\n"); show_devs_tree(root, BIOS_SPEW, 0, 0); - if (root->chip_ops && root->chip_ops->enable_dev) - root->chip_ops->enable_dev(root); + if (mainboard_ops.enable_dev) + mainboard_ops.enable_dev(root); if (!root->ops || !root->ops->scan_bus) { printk(BIOS_ERR, "dev_root missing scan_bus operation"); diff --git a/src/include/device/device.h b/src/include/device/device.h index 1515b45..58e92d5 100644 --- a/src/include/device/device.h +++ b/src/include/device/device.h @@ -166,6 +166,7 @@ void show_all_devs_resources(int debug_level, const char* msg); #define DEVICE_MEM_ALIGN 4096 extern struct device_operations default_dev_ops_root; +extern struct chip_operations mainboard_ops; void pci_domain_read_resources(struct device *dev); unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max); unsigned int scan_static_bus(device_t bus, unsigned int max); diff --git a/src/mainboard/emulation/qemu-x86/chip.h b/src/mainboard/emulation/qemu-x86/chip.h index 56a14ed..ff9301f 100644 --- a/src/mainboard/emulation/qemu-x86/chip.h +++ b/src/mainboard/emulation/qemu-x86/chip.h @@ -1,7 +1,3 @@ -extern struct chip_operations mainboard_ops; - -struct mainboard_config {}; - struct mainboard_emulation_qemu_x86_config {}; extern struct chip_operations mainboard_emulation_qemu_x86_ops;

1 0

New patch to review for coreboot: 8fd8052 Fix mainboard level enable_dev()
by Kyösti Mälkki 27 Jul '12

27 Jul '12

Kyösti Mälkki (kyosti.malkki(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1374 -gerrit commit 8fd805233a39512d85c3f49bf4527ad49637ba40 Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Fri Jul 27 19:22:26 2012 +0300 Fix mainboard level enable_dev() Commit 188e3c2ff06a82f61d7d71e610b32b1a250c0a45 dropped mainboard out of the static device tree. This left dev_root->chip_ops unset, and mainboard_ops.enable_dev() was no longer called. Change-Id: I6d447c8049a66041b8bb36ec9aac3e7e0d20a99b Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> --- src/devices/device.c | 4 ++-- src/include/device/device.h | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/devices/device.c b/src/devices/device.c index 92a4447..d0e801b 100644 --- a/src/devices/device.c +++ b/src/devices/device.c @@ -922,8 +922,8 @@ void dev_enumerate(void) printk(BIOS_SPEW, "Compare with tree...\n"); show_devs_tree(root, BIOS_SPEW, 0, 0); - if (root->chip_ops && root->chip_ops->enable_dev) - root->chip_ops->enable_dev(root); + if (mainboard_ops.enable_dev) + mainboard_ops.enable_dev(root); if (!root->ops || !root->ops->scan_bus) { printk(BIOS_ERR, "dev_root missing scan_bus operation"); diff --git a/src/include/device/device.h b/src/include/device/device.h index 1515b45..58e92d5 100644 --- a/src/include/device/device.h +++ b/src/include/device/device.h @@ -166,6 +166,7 @@ void show_all_devs_resources(int debug_level, const char* msg); #define DEVICE_MEM_ALIGN 4096 extern struct device_operations default_dev_ops_root; +extern struct chip_operations mainboard_ops; void pci_domain_read_resources(struct device *dev); unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max); unsigned int scan_static_bus(device_t bus, unsigned int max);

1 0

← Newer
1
2
3
4
5
6
7
8
...
64
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2012