coreboot December 2014

coreboot@coreboot.org

33 participants
53 discussions

Start a nNew thread

coreboot acpi apei support
by Magnus Johansson E 16 Dec '14

16 Dec '14

Are there any support for APEI in current coreboot and if not, will there be?

2 1

Re: [coreboot] LOCK prefix
by Patrick Georgi 16 Dec '14

16 Dec '14

Am 2014-12-16 03:54, schrieb ron minnich: > Notwithstanding the merits of the idea, does anyone know if this is > doable or I am just misremembering? Since even LOCK REP ... is not allowed, I think you're misremembering. LOCK provides atomicity guarantees for the single instruction it covers, nothing else. What's typically used in situations like your example is cmpxchg: load the value, copy it, modify, then atomically exchange ram and register content. compare exchanged value with copy to make sure there was no interference, otherwise restart. Patrick

1 0

LOCK prefix
by ron minnich 16 Dec '14

16 Dec '14

Somewhere in the back of my memory is buried the idea that you can do this: LOCK mov a, %ax LOCK add $1, %ax LOCK mov %ax, a I.e implement a compound indivisible instruction with a sequence of instructions prefixed with LOCK. Notwithstanding the merits of the idea, does anyone know if this is doable or I am just misremembering? ron

1 0

Gigabyte GA-J1900N-D3V-1.x data
by Matt Taggart 16 Dec '14

16 Dec '14

Hi coreboot and flashrom, I recently got a Gigabyte GA-J1900N-D3V-1.x board. This board is interesting to me because A) it's Bay Trail, B) it's got dual NICs and real serial ports, and C) it's inexpensive. I followed the guide at http://www.coreboot.org/Motherboard_Porting_Guide I put the logs and a README with more info at http://lackof.org/taggart/hacking/coreboot/GA-J1900N-D3V-1.x/ (and a tarball of that dir in the parent dir) The flashrom output is from SVN trunk as of today to ensure latest chip support. In particular flashrom reports untested: Found chipset "Intel Bay Trail" with PCI ID 8086:0f1c. Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI). I haven't yet attempted anything beyond that. I don't yet have an off-board way to flash the chips, I'm hoping to order something soon. If you have ideas of other things to try please let me know. Thanks, -- Matt Taggart matt(a)lackof.org

1 0

Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
by Kevin O'Connor 15 Dec '14

15 Dec '14

On Mon, Dec 15, 2014 at 09:06:51AM +0100, Werner Zeh wrote: > Hi Kevin. > > I have tried your fix but it doesn't help. > You can find a (huge) log with loglevel 5 here: http://pastebin.com/21rrAhfA > Thanks. I obtained a USB3 hub and it works for me on both my c720 and e350m1 with the updated patch below. Please CC the seabios mailing list on replies. -Kevin >From 9b244e4a887adba2281d46c0fb366823111ba4bc Mon Sep 17 00:00:00 2001 From: Kevin O'Connor <kevin(a)koconnor.net> Date: Fri, 12 Dec 2014 14:16:43 -0500 Subject: [PATCH] usb: Testing of USB3 hub support Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/usb-hub.c | 36 ++++++++++++++++++++++++++++++++++-- src/hw/usb-hub.h | 6 +++++- 2 files changed, 39 insertions(+), 3 deletions(-) diff --git a/src/hw/usb-hub.c b/src/hw/usb-hub.c index c21cbfb..54e341b 100644 --- a/src/hw/usb-hub.c +++ b/src/hw/usb-hub.c @@ -17,13 +17,28 @@ get_hub_desc(struct usb_pipe *pipe, struct usb_hub_descriptor *desc) struct usb_ctrlrequest req; req.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_DEVICE; req.bRequest = USB_REQ_GET_DESCRIPTOR; - req.wValue = USB_DT_HUB<<8; + if (pipe->speed == USB_SUPERSPEED) + req.wValue = USB_DT_HUB3<<8; + else + req.wValue = USB_DT_HUB<<8; req.wIndex = 0; req.wLength = sizeof(*desc); return usb_send_default_control(pipe, &req, desc); } static int +set_hub_depth(struct usb_pipe *pipe, u16 depth) +{ + struct usb_ctrlrequest req; + req.bRequestType = USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_DEVICE; + req.bRequest = HUB_REQ_SET_HUB_DEPTH; + req.wValue = depth; + req.wIndex = 0; + req.wLength = 0; + return usb_send_default_control(pipe, &req, NULL); +} + +static int set_port_feature(struct usbhub_s *hub, int port, int feature) { struct usb_ctrlrequest req; @@ -105,7 +120,9 @@ usb_hub_reset(struct usbhub_s *hub, u32 port) ret = get_port_status(hub, port, &sts); if (ret) goto fail; - if (!(sts.wPortStatus & USB_PORT_STAT_RESET)) + if (!(sts.wPortStatus & USB_PORT_STAT_RESET) + && (hub->usbdev->speed != USB_SUPERSPEED + || !(sts.wPortStatus & USB_PORT_STAT_LINK_MASK))) break; if (timer_check(end)) { warn_timeout(); @@ -119,6 +136,8 @@ usb_hub_reset(struct usbhub_s *hub, u32 port) // Device no longer present return -1; + if (hub->usbdev->speed == USB_SUPERSPEED) + return USB_SUPERSPEED; return ((sts.wPortStatus & USB_PORT_STAT_SPEED_MASK) >> USB_PORT_STAT_SPEED_SHIFT); @@ -154,6 +173,19 @@ usb_hub_setup(struct usbdevice_s *usbdev) hub.portcount = desc.bNbrPorts; hub.op = &HubOp; + if (usbdev->speed == USB_SUPERSPEED) { + int depth = 0; + struct usbdevice_s *parent = usbdev->hub->usbdev; + while (parent) { + depth++; + parent = parent->hub->usbdev; + } + + ret = set_hub_depth(usbdev->defpipe, depth); + if (ret) + return ret; + } + // Turn on power to ports. int port; for (port=0; port<desc.bNbrPorts; port++) { diff --git a/src/hw/usb-hub.h b/src/hw/usb-hub.h index 5b09947..880378c 100644 --- a/src/hw/usb-hub.h +++ b/src/hw/usb-hub.h @@ -11,6 +11,9 @@ int usb_hub_setup(struct usbdevice_s *usbdev); ****************************************************************/ #define USB_DT_HUB (USB_TYPE_CLASS | 0x09) +#define USB_DT_HUB3 (USB_TYPE_CLASS | 0x0a) + +#define HUB_REQ_SET_HUB_DEPTH 0x0C struct usb_hub_descriptor { u8 bDescLength; @@ -48,7 +51,8 @@ struct usb_port_status { #define USB_PORT_STAT_SUSPEND 0x0004 #define USB_PORT_STAT_OVERCURRENT 0x0008 #define USB_PORT_STAT_RESET 0x0010 -#define USB_PORT_STAT_L1 0x0020 +#define USB_PORT_STAT_LINK_SHIFT 5 +#define USB_PORT_STAT_LINK_MASK (0x7 << USB_PORT_STAT_LINK_SHIFT) #define USB_PORT_STAT_POWER 0x0100 #define USB_PORT_STAT_SPEED_SHIFT 9 #define USB_PORT_STAT_SPEED_MASK (0x3 << USB_PORT_STAT_SPEED_SHIFT) -- 1.9.3

1 0

Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
by Kevin O'Connor 15 Dec '14

15 Dec '14

On Wed, Dec 10, 2014 at 07:21:54AM +0100, Werner Zeh wrote: > Hi all. > > I have made some tests with SeaBIOS and XHCI and found, that on my board (which is baytrail-based) > a USB3.0 hub won't work. For those who are familar with SeaBIOS I have attached two > logfiles from SeaBIOS. One of them is with the USB3.0 flash drive directly connected to one of the root ports of SoC > (in which case the boot process starts from the flash drive) and the other is with the same flash drive but a USB3.0 hub in between > (I have used a hub from Delock #62534, http://www.delock.de/produkte/F_247_extern_62534/merkmale.html). In the hub-case, I see the > "No bootable device" screen and no boot will happen. > > Maybe someone more experienced can see the cause from the logs. > ?SeaBIOS (version rel-1.7.5-116-g56b252e-dirty-20141210_064921-deerlf0x73) [...] > |1ad7d000| xhci_process_events: ring 0x1adcb200 [trb 0x1adcb200, evt 0x1adcb300, type 32, eidx 1, cc 1] > |1ad7d000| device rev=0300 cls=09 sub=00 proto=03 size=512 > |1ad7d000| xhci_realloc_pipe: usbdev 0x1ad82bc0, ring 0x1adba600, slotid 4, epid 1 [...] > |1ad7f000| xhci_process_events: ring 0x1adba600 [trb 0x1adba6c0, evt 0x1adba700, type 32, eidx 13, cc 6] It looks like the hub is found, but responds with a "stall" error on the get_hub_desc() request. Looks like usb3 hubs use a different descriptor id. You could try the patch below - it's a lot of guess work though. -Kevin diff --git a/src/hw/usb-hub.c b/src/hw/usb-hub.c index c21cbfb..7688ef2 100644 --- a/src/hw/usb-hub.c +++ b/src/hw/usb-hub.c @@ -17,7 +17,10 @@ get_hub_desc(struct usb_pipe *pipe, struct usb_hub_descriptor *desc) struct usb_ctrlrequest req; req.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_DEVICE; req.bRequest = USB_REQ_GET_DESCRIPTOR; - req.wValue = USB_DT_HUB<<8; + if (pipe->speed == USB_SUPERSPEED) + req.wValue = USB_DT_HUB3<<8; + else + req.wValue = USB_DT_HUB<<8; req.wIndex = 0; req.wLength = sizeof(*desc); return usb_send_default_control(pipe, &req, desc); @@ -105,7 +108,9 @@ usb_hub_reset(struct usbhub_s *hub, u32 port) ret = get_port_status(hub, port, &sts); if (ret) goto fail; - if (!(sts.wPortStatus & USB_PORT_STAT_RESET)) + if (!(sts.wPortStatus & USB_PORT_STAT_RESET) + && (hub->usbdev->speed != USB_SUPERSPEED + || !(sts.wPortStatus & USB_PORT_STAT_LINK_MASK))) break; if (timer_check(end)) { warn_timeout(); @@ -119,6 +124,8 @@ usb_hub_reset(struct usbhub_s *hub, u32 port) // Device no longer present return -1; + if (hub->usbdev->speed == USB_SUPERSPEED) + return USB_SUPERSPEED; return ((sts.wPortStatus & USB_PORT_STAT_SPEED_MASK) >> USB_PORT_STAT_SPEED_SHIFT); diff --git a/src/hw/usb-hub.h b/src/hw/usb-hub.h index 5b09947..f7436a5 100644 --- a/src/hw/usb-hub.h +++ b/src/hw/usb-hub.h @@ -11,6 +11,7 @@ int usb_hub_setup(struct usbdevice_s *usbdev); ****************************************************************/ #define USB_DT_HUB (USB_TYPE_CLASS | 0x09) +#define USB_DT_HUB3 (USB_TYPE_CLASS | 0x0a) struct usb_hub_descriptor { u8 bDescLength; @@ -48,7 +49,8 @@ struct usb_port_status { #define USB_PORT_STAT_SUSPEND 0x0004 #define USB_PORT_STAT_OVERCURRENT 0x0008 #define USB_PORT_STAT_RESET 0x0010 -#define USB_PORT_STAT_L1 0x0020 +#define USB_PORT_STAT_LINK_SHIFT 5 +#define USB_PORT_STAT_LINK_MASK (0x7 << USB_PORT_STAT_LINK_SHIFT) #define USB_PORT_STAT_POWER 0x0100 #define USB_PORT_STAT_SPEED_SHIFT 9 #define USB_PORT_STAT_SPEED_MASK (0x3 << USB_PORT_STAT_SPEED_SHIFT)

2 1

Re: [coreboot] Success in booting the kernel in less that 1 second on the x60
by Carl-Daniel Hailfinger 13 Dec '14

13 Dec '14

Hi Charles, the main talk deadline and lightning talk deadline for FOSDEM are over, but maybe some of the developer rooms somewhat fit the topic and still accept the talk? Not sure. In any case, it would be great to have you there at FOSDEM at our booth if we get a booth this year. Regards, Carl-Daniel On 13.12.2014 08:47, ron minnich wrote: > If you all get this take it to FOSDEM! > > BTW I need a tiny kernel for u-root, how small can you get it at this point? > > ron > > On Fri Dec 12 2014 at 9:51:46 PM Charles Devereaux <coreboot(a)guylhem.net> > wrote: > >> On Wed, Jul 2, 2014 at 10:48 AM, ron minnich <rminnich(a)gmail.com> wrote: >>> This is great. We've gotten an acer c720 down to 1.7 seconds from power >>> button to chromeos login screen. I've always wanted to get it done in under >>> a second. I hope you can get there! >>> >> It looks quite possible. >> >> I couldn't sleep much last night, so I burned the midnight oil to achieve >> my goal of a *real fast* boot, building on the i915.fastboot improvements. >> >> It may have taken 4 months, but I could finally trim the kernel boot time >> to about 0.8s after further hackish fixes - like starting the scsi and sata >> drivers before the tty and char drivers, enabling paralllel probe for ahci, >> making psmouse a module because it was delaying boot too much, etc. >> >> If you use systemd with the configuration files I suggested before, your >> system should now be ready 1.4s after coreboot started grub. >> [...]

2 1

Re: [coreboot] Success in booting the kernel in less that 1 second on the x60
by ron minnich 13 Dec '14

13 Dec '14

If you all get this take it to FOSDEM! BTW I need a tiny kernel for u-root, how small can you get it at this point? ron On Fri Dec 12 2014 at 9:51:46 PM Charles Devereaux <coreboot(a)guylhem.net> wrote: > On Wed, Jul 2, 2014 at 10:48 AM, ron minnich <rminnich(a)gmail.com> wrote: >> >> This is great. We've gotten an acer c720 down to 1.7 seconds from power >> button to chromeos login screen. I've always wanted to get it done in under >> a second. I hope you can get there! >> > > It looks quite possible. > > I couldn't sleep much last night, so I burned the midnight oil to achieve > my goal of a *real fast* boot, building on the i915.fastboot improvements. > > It may have taken 4 months, but I could finally trim the kernel boot time > to about 0.8s after further hackish fixes - like starting the scsi and sata > drivers before the tty and char drivers, enabling paralllel probe for ahci, > making psmouse a module because it was delaying boot too much, etc. > > If you use systemd with the configuration files I suggested before, your > system should now be ready 1.4s after coreboot started grub. > > If you trim further (ex: turning more things into modules, removing the > initrd) you can get the kernel ready in about 0.6s, so that'll mean about > 1.2 seconds. > > It should be possible to beat the c720 boot time if coreboot could finish > in about 0.5s on the x60, but I don't know how plausible this is. Ideas or > suggestions would be welcome. > > If anyone is interested in replicating or improving these results, please > use the following kernel patch on a vanillla 3.14.25 to compile a kernel > using x60.config, then use the following command line in grub: > libahci.ignore_sss=1 raid=noautodetect i915.fastboot=1 > i915.lvds_downclock=1 i915.i915_enable_rc6=7 nohz=on nmi_watchdog=0 > pcie=aspm thinkpad_acpi.brightness_enable=0 thinkpad_acpi.force_load=1 > thinkpad_acpi.fan_control=1 snd-hda-intel.index=0 > snd_hda_intel.power_save=10 snd_hda_intel.model=thinkpad > snd-hda-intel.probe_mask=0x103 snd-pcsp.index=1 btusb.reset=1 > ath9k.ps_enable=1 ath9k.btcoex_enable=1 swap=/dev/sda2 tpm_tis.force=1 > tpm_tis.interrupts=0 tpm_tis.hid=PNP0C31 quiet systemd.unit=graphical.target > > Turning say alsa and firewire into modules you can shave another 0.1 to > 0.2s. I just tested that before posting. However, I'm not sure it's worth > the trouble for now. Coreboot takes more time than the kernel+systemd, so > it has become the limiting factor for further improvements. > > BTW, to demonstrate other optimisations (ex: obtaining a dhcp lease > quickly) I will try to upload a minimal distribution based on > debian-testing but making heavy use of clean systemd scripts, for those who > want to have the quick boot without wasting too much time on configuration. > > Enjoy, > Charles > >

1 0

Success in booting the kernel in less that 1 second on the x60
by Charles Devereaux 13 Dec '14

13 Dec '14

On Wed, Jul 2, 2014 at 10:48 AM, ron minnich <rminnich(a)gmail.com> wrote: > > This is great. We've gotten an acer c720 down to 1.7 seconds from power > button to chromeos login screen. I've always wanted to get it done in under > a second. I hope you can get there! > It looks quite possible. I couldn't sleep much last night, so I burned the midnight oil to achieve my goal of a *real fast* boot, building on the i915.fastboot improvements. It may have taken 4 months, but I could finally trim the kernel boot time to about 0.8s after further hackish fixes - like starting the scsi and sata drivers before the tty and char drivers, enabling paralllel probe for ahci, making psmouse a module because it was delaying boot too much, etc. If you use systemd with the configuration files I suggested before, your system should now be ready 1.4s after coreboot started grub. If you trim further (ex: turning more things into modules, removing the initrd) you can get the kernel ready in about 0.6s, so that'll mean about 1.2 seconds. It should be possible to beat the c720 boot time if coreboot could finish in about 0.5s on the x60, but I don't know how plausible this is. Ideas or suggestions would be welcome. If anyone is interested in replicating or improving these results, please use the following kernel patch on a vanillla 3.14.25 to compile a kernel using x60.config, then use the following command line in grub: libahci.ignore_sss=1 raid=noautodetect i915.fastboot=1 i915.lvds_downclock=1 i915.i915_enable_rc6=7 nohz=on nmi_watchdog=0 pcie=aspm thinkpad_acpi.brightness_enable=0 thinkpad_acpi.force_load=1 thinkpad_acpi.fan_control=1 snd-hda-intel.index=0 snd_hda_intel.power_save=10 snd_hda_intel.model=thinkpad snd-hda-intel.probe_mask=0x103 snd-pcsp.index=1 btusb.reset=1 ath9k.ps_enable=1 ath9k.btcoex_enable=1 swap=/dev/sda2 tpm_tis.force=1 tpm_tis.interrupts=0 tpm_tis.hid=PNP0C31 quiet systemd.unit=graphical.target Turning say alsa and firewire into modules you can shave another 0.1 to 0.2s. I just tested that before posting. However, I'm not sure it's worth the trouble for now. Coreboot takes more time than the kernel+systemd, so it has become the limiting factor for further improvements. BTW, to demonstrate other optimisations (ex: obtaining a dhcp lease quickly) I will try to upload a minimal distribution based on debian-testing but making heavy use of clean systemd scripts, for those who want to have the quick boot without wasting too much time on configuration. Enjoy, Charles

1 0

problem with: vendorcode/amd/agesa/fam15: Build as a static library
by Scott Duplichan 12 Dec '14

12 Dec '14

While trying to get abuild working from Windows I found a coreboot makefile problem. File src/vendorcode/amd/agesa/f15/Makefile.inc is be processed twice. While this doesn't break a Linux build, it does break the Windows build. The Windows problem is because the ar command line contains each object file twice, and the Windows 32KB command line length is exceeded. As a temporary work around, I bracket the contents if Makefile.inc with: ifeq ($(F15_MAKE_INCLUDED),) export F15_MAKE_INCLUDED=y ... endif What is the correct solution? Thanks, Scott

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2014