August 2013 - coreboot - mail.coreboot.org

Re: [coreboot] Could I replace memmove function?
by Peter Stuge Aug. 16, 2013

Aug. 16, 2013

David Hendricks wrote: > There is CONFIG_CPU_DMP_VORTEX86EX which might be useful. I disagree. > Maybe Andrew can try something like this: .. > +ifeq ($(CONFIG_CPU_DMP_VORTEX86EX),y) > +# Old memmove implementation from Linux always use REP MOVSL > +# which is much faster on some CPUs. > +ramstage-y += memmove_old.c > +romstage-y += memmove_old.c > +smm-y += memmove_old.c The file is called memmove_old.c and not memmove_DMP_VORTEX86EX.c, so if Kconfig should be involved the controlling variable really needs to be one with a meaningful name, and it would get selected (only) by the Vortex86 CPU Kconfig files. I would prefer a patch for our memmove, unless there is a strong reason not to use REP also in the general case. //Peter

1 0

Re: [coreboot] Could I replace memmove function?
by Gabe Black Aug. 16, 2013

Aug. 16, 2013

It wouldn't be terrible to have a generally better memmove implementation either. Gabe On Thu, Aug 15, 2013 at 6:23 PM, David Hendricks <dhendrix(a)google.com>wrote: > > > > On Thu, Aug 15, 2013 at 8:43 AM, ron minnich <rminnich(a)gmail.com> wrote: > >> It seems to me you could improve our memmove? >> >> Also, if we want to define another Kconfig variable this is pretty easy >> to fix. > > > There is CONFIG_CPU_DMP_VORTEX86EX which might be useful. > > Maybe Andrew can try something like this: > > diff --git a/src/arch/x86/lib/Makefile.inc b/src/arch/x86/lib/Makefile.inc > index 8588c76..b529d35 100644 > --- a/src/arch/x86/lib/Makefile.inc > +++ b/src/arch/x86/lib/Makefile.inc > @@ -6,7 +6,6 @@ ramstage-y += exception.c > ramstage-$(CONFIG_IOAPIC) += ioapic.c > ramstage-y += memset.c > ramstage-y += memcpy.c > -ramstage-y += memmove.c > ramstage-y += ebda.c > ramstage-y += rom_media.c > ramstage-$(CONFIG_COOP_MULTITASKING) += thread.c > @@ -16,16 +15,26 @@ romstage-$(CONFIG_EARLY_CONSOLE) += romstage_console.c > romstage-y += cbfs_and_run.c > romstage-y += memset.c > romstage-y += memcpy.c > -romstage-y += memmove.c > romstage-y += rom_media.c > > smm-y += memset.c > smm-y += memcpy.c > -smm-y += memmove.c > smm-y += rom_media.c > > rmodules-y += memset.c > rmodules-y += memcpy.c > rmodules-y += memmove.c > > +ifeq ($(CONFIG_CPU_DMP_VORTEX86EX),y) > +# Old memmove implementation from Linux always use REP MOVSL > +# which is much faster on some CPUs. > +ramstage-y += memmove_old.c > +romstage-y += memmove_old.c > +smm-y += memmove_old.c > +else > +ramstage-y += memmove.c > +romstage-y += memmove.c > +smm-y += memmove.c > +endif > + > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Could I replace memmove function?
by David Hendricks Aug. 16, 2013

Aug. 16, 2013

On Thu, Aug 15, 2013 at 8:43 AM, ron minnich <rminnich(a)gmail.com> wrote: > It seems to me you could improve our memmove? > > Also, if we want to define another Kconfig variable this is pretty easy to > fix. There is CONFIG_CPU_DMP_VORTEX86EX which might be useful. Maybe Andrew can try something like this: diff --git a/src/arch/x86/lib/Makefile.inc b/src/arch/x86/lib/Makefile.inc index 8588c76..b529d35 100644 --- a/src/arch/x86/lib/Makefile.inc +++ b/src/arch/x86/lib/Makefile.inc @@ -6,7 +6,6 @@ ramstage-y += exception.c ramstage-$(CONFIG_IOAPIC) += ioapic.c ramstage-y += memset.c ramstage-y += memcpy.c -ramstage-y += memmove.c ramstage-y += ebda.c ramstage-y += rom_media.c ramstage-$(CONFIG_COOP_MULTITASKING) += thread.c @@ -16,16 +15,26 @@ romstage-$(CONFIG_EARLY_CONSOLE) += romstage_console.c romstage-y += cbfs_and_run.c romstage-y += memset.c romstage-y += memcpy.c -romstage-y += memmove.c romstage-y += rom_media.c smm-y += memset.c smm-y += memcpy.c -smm-y += memmove.c smm-y += rom_media.c rmodules-y += memset.c rmodules-y += memcpy.c rmodules-y += memmove.c +ifeq ($(CONFIG_CPU_DMP_VORTEX86EX),y) +# Old memmove implementation from Linux always use REP MOVSL +# which is much faster on some CPUs. +ramstage-y += memmove_old.c +romstage-y += memmove_old.c +smm-y += memmove_old.c +else +ramstage-y += memmove.c +romstage-y += memmove.c +smm-y += memmove.c +endif + -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] [RFP/RFQ] contract to port coreboot to the ASRock IMB-161-D industrial motherboard
by David Hendricks Aug. 16, 2013

Aug. 16, 2013

Hi Luke, You may be in luck -- That chipset is similar to a couple others which are already supported for the "Stumpy" and "Lumpy" ChromeOS products. Of course, the devils are always in the details and this being an Intel-based product will likely require proprietary bits, so there might be other business considerations to take into account. I recommend getting in touch with Sage Engineering (http://www.se-eng.com/) On Thu, Aug 15, 2013 at 4:21 AM, Luke Leighton <luke.leighton(a)pathintel.com>wrote: > hi folks i'm working for path intelligence and we have a requirement > to use serial bios boot, on a motherboard which has an AMI standard > BIOS. the motherboard is being done by a new (independent) team > within ASRock who are using higher-quality components, longer lifetime > parts, and they're planning to keep this product going for at least > 3-5 years: it therefore makes sense for us to see if there's anyone > who would like to port - or help port - coreboot to it. > > our key requirements are: PXE-boot and Serial BIOS console access. > > if there is anybody who would like to contract to do that, please > contact me. feel free to discuss publicly if there are several people > who would prefer to collaborate on-list. any other suggestions > greatly appreciated. > > here's some information on the board: > > * 1155 sandy/ivy bridge > * intel cougar point q77 colay h61 > * spi flash > * nuvoton NCT6627UD (aka W83627UHG, yay! [*1]) which supports *six* > RS232/422/485 > * intel 82579V gigabit ethernet PCIe on-board > * intel 82583V gigabit ethernet PCIe on-board > > having done a bit of research on what's been committed recently, the > SPI flash was added in may/june ("leaked" docs on H61 SPI interface); > H61 cougar PCIe ids were added in may; the W83627UHG is a winbond > chipset supported by coreboot 4... > > ... i really don't see this as being particularly hard! only the > gigabit ethernet chips are not listed anywhere (google > site:coreboot.org 82579V gives nothing...) but here's the lspci > output: > > > # lspci > 00:00.0 Host bridge: Intel Corporation Device 0100 (rev 09) > 00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge > Integrated Graphics Controller (rev 09) > 00:16.0 Communication controller: Intel Corporation Cougar Point HECI > Controller #1 (rev 04) > 00:19.0 Ethernet controller: Intel Corporation Device 1503 (rev 05) > 00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced > Host Controller #2 (rev 05) > 00:1b.0 Audio device: Intel Corporation Cougar Point High Definition > Audio Controller (rev 05) > 00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root > Port 1 (rev b5) > 00:1c.1 PCI bridge: Intel Corporation Cougar Point PCI Express Root > Port 2 (rev b5) > 00:1c.2 PCI bridge: Intel Corporation Cougar Point PCI Express Root > Port 3 (rev b5) > 00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced > Host Controller #1 (rev 05) > 00:1f.0 ISA bridge: Intel Corporation Device 1c5c (rev 05) > 00:1f.2 IDE interface: Intel Corporation Cougar Point 4 port SATA IDE > Controller (rev 05) > 00:1f.3 SMBus: Intel Corporation Cougar Point SMBus Controller (rev 05) > 00:1f.5 IDE interface: Intel Corporation Cougar Point 2 port SATA IDE > Controller (rev 05) > 02:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network > Connection > 01) > # lspci -n > 00:00.0 0600: 8086:0100 (rev 09) > 00:02.0 0300: 8086:0102 (rev 09) > 00:16.0 0780: 8086:1c3a (rev 04) > 00:19.0 0200: 8086:1503 (rev 05) > 00:1a.0 0c03: 8086:1c2d (rev 05) > 00:1b.0 0403: 8086:1c20 (rev 05) > 00:1c.0 0604: 8086:1c10 (rev b5) > 00:1c.1 0604: 8086:1c12 (rev b5) > 00:1c.2 0604: 8086:1c14 (rev b5) > 00:1d.0 0c03: 8086:1c26 (rev 05) > 00:1f.0 0601: 8086:1c5c (rev 05) > 00:1f.2 0101: 8086:1c00 (rev 05) > 00:1f.3 0c05: 8086:1c22 (rev 05) > 00:1f.5 0101: 8086:1c08 (rev 05) > 02:00.0 0200: 8086:150c > > > [*1] > http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/CloudAndComputin… > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] Could I replace memmove function?
by ron minnich Aug. 15, 2013

Aug. 15, 2013

It seems to me you could improve our memmove? Also, if we want to define another Kconfig variable this is pretty easy to fix. ron

1 0

Could I replace memmove function?
by Andrew Wu Aug. 15, 2013

Aug. 15, 2013

Hi, I am developing coreboot on DMP/Vortex86EX board. I found recent updated coreboot source code made it boots slower on my board. That is because: >From commit c6b44162f5cccd72e9b4d9dbf071911249971846, src/lib/cbfs_core.c uses memmove instead of memcpy to load uncompressed ramstage. memmove function is in src/arch/x86/lib/memmove.c, which is from memcpy_32.c in the Linux kernel. You can see: http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/lib/… But this memmove seems over-optimized, it will only use x86 REP MOVSL instruction if memory is 256-byte aligned, otherwise it will failback to use slower MOV loop. MOV loop is much slower then REP MOVSL on Vortex86EX, because reading instructions from ROM is slow. How could I avoid this? I can: 1. Modify src/arch/x86/lib/memmove.c, to use another implementation. But it will interfere other module that uses memmove. I used grep to search memmove calls, only src/lib/cbfs_core.c and src/lib/gcov-io.c uses memmove. In fact I tried to use memmove from older Linux kernel, which always use REP MOVS and runs much better on my hardware. See : https://github.com/torvalds/linux/blob/59daa706fbec745684702741b9f5373142dd… 2. Write my own memmove module, and link this module only when building Vortex86EX target. But it seems current Makefile doesn't support this mechanism, I can only link either src/lib/mommove.c or src/arch/x86/lib/memmove.c, no third option. Any suggestion? :)

1 0

[RFP/RFQ] contract to port coreboot to the ASRock IMB-161-D industrial motherboard
by Luke Leighton Aug. 15, 2013

Aug. 15, 2013

hi folks i'm working for path intelligence and we have a requirement to use serial bios boot, on a motherboard which has an AMI standard BIOS. the motherboard is being done by a new (independent) team within ASRock who are using higher-quality components, longer lifetime parts, and they're planning to keep this product going for at least 3-5 years: it therefore makes sense for us to see if there's anyone who would like to port - or help port - coreboot to it. our key requirements are: PXE-boot and Serial BIOS console access. if there is anybody who would like to contract to do that, please contact me. feel free to discuss publicly if there are several people who would prefer to collaborate on-list. any other suggestions greatly appreciated. here's some information on the board: * 1155 sandy/ivy bridge * intel cougar point q77 colay h61 * spi flash * nuvoton NCT6627UD (aka W83627UHG, yay! [*1]) which supports *six* RS232/422/485 * intel 82579V gigabit ethernet PCIe on-board * intel 82583V gigabit ethernet PCIe on-board having done a bit of research on what's been committed recently, the SPI flash was added in may/june ("leaked" docs on H61 SPI interface); H61 cougar PCIe ids were added in may; the W83627UHG is a winbond chipset supported by coreboot 4... ... i really don't see this as being particularly hard! only the gigabit ethernet chips are not listed anywhere (google site:coreboot.org 82579V gives nothing...) but here's the lspci output: # lspci 00:00.0 Host bridge: Intel Corporation Device 0100 (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation Device 1503 (rev 05) 00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation Cougar Point High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 2 (rev b5) 00:1c.2 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 3 (rev b5) 00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation Device 1c5c (rev 05) 00:1f.2 IDE interface: Intel Corporation Cougar Point 4 port SATA IDE Controller (rev 05) 00:1f.3 SMBus: Intel Corporation Cougar Point SMBus Controller (rev 05) 00:1f.5 IDE interface: Intel Corporation Cougar Point 2 port SATA IDE Controller (rev 05) 02:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection 01) # lspci -n 00:00.0 0600: 8086:0100 (rev 09) 00:02.0 0300: 8086:0102 (rev 09) 00:16.0 0780: 8086:1c3a (rev 04) 00:19.0 0200: 8086:1503 (rev 05) 00:1a.0 0c03: 8086:1c2d (rev 05) 00:1b.0 0403: 8086:1c20 (rev 05) 00:1c.0 0604: 8086:1c10 (rev b5) 00:1c.1 0604: 8086:1c12 (rev b5) 00:1c.2 0604: 8086:1c14 (rev b5) 00:1d.0 0c03: 8086:1c26 (rev 05) 00:1f.0 0601: 8086:1c5c (rev 05) 00:1f.2 0101: 8086:1c00 (rev 05) 00:1f.3 0c05: 8086:1c22 (rev 05) 00:1f.5 0101: 8086:1c08 (rev 05) 02:00.0 0200: 8086:150c [*1] http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/CloudAndComputin…

1 0

Re: [coreboot] coreboot projects using GizmoSphere
by Iurie Aug. 13, 2013

Aug. 13, 2013

yes, but i was referring to adding some functions for coreboot, like those from here: http://www.coreboot.org/GSoC#Projects i would like to know if the gizmospher is suitable (or even complete kit) for easily making successfully some (or even all) of those projects. On 12 August 2013 18:59, Marc Jones <marcj303(a)gmail.com> wrote: > Hi, > > On Sat, Aug 10, 2013 at 2:33 PM, Iurie <iurcic(a)gmail.com> wrote: > > hello, > > i would like to know what coreboot projects could be done using > GizmoSphere. > > is somebody already using the GizmoSphere to make some coreboot projects? > > > > > > i thank you in advance for the answer > > best regards > > I don't understand your question. Gizmo uses coreboot as its firmware, > so everyone that is working with Gizmo is working with coreboot at > some level. Your questions might be better suited to the gizmosphere > forum. > > http://www.gizmosphere.org/forums/forum/support/sw-support/ > > > Marc > > > -- > http://se-eng.com >

1 0

Lenovo X60
by Eugen Leitl Aug. 12, 2013

Aug. 12, 2013

I've decided to buy a Lenovo X60 over Asrock E350M1 for Coreboot experimenting. I see you can boot to a desktop in under 10 seconds, what kind of a lean yet hacker-oriented environment do you people recommend for that? (I'll probably go with a 128 GByte SSD instead of stock HDD). Do you have a specific kernel/build suggestions for the X60 or will stock Debian do? Thanks.

2 1

Re: [coreboot] coreboot projects using GizmoSphere
by Marc Jones Aug. 12, 2013

Aug. 12, 2013

Hi, On Sat, Aug 10, 2013 at 2:33 PM, Iurie <iurcic(a)gmail.com> wrote: > hello, > i would like to know what coreboot projects could be done using GizmoSphere. > is somebody already using the GizmoSphere to make some coreboot projects? > > > i thank you in advance for the answer > best regards I don't understand your question. Gizmo uses coreboot as its firmware, so everyone that is working with Gizmo is working with coreboot at some level. Your questions might be better suited to the gizmosphere forum. http://www.gizmosphere.org/forums/forum/support/sw-support/ Marc -- http://se-eng.com

1 0