coreboot August 2017

coreboot@coreboot.org

59 participants
132 discussions

Lenovo X220t variants with SMD-Flash-ROMs
by Philipp Stanner 07 Aug '17

07 Aug '17

Hi list, I don't know if it's common yet (the wiki article doesn't mention it) but today I discovered that there are Lenovo Thinkpads with very flat SMD-Flash-ROMs which make it impossible to access them with a SOIC-Clip or flash them by soldering wires to the pins directly. I aborted the flashing but am going to try finding a work-around. About the laptop: Type 4298-W28 S/N R9-E4CFC 11/06 (so probably manufactured in 2011) Product ID: 4298W28 Maybe we should write one sentence in the wiki mentioning that not all chips are accessable very comfortably. Greetings, P. PS: Rantmode: Why the hell don't they just solder a socket? It's not that unrealistic that someone bricks the BIOS while updating the firmware from time to time. Being able to replace the ROM with a fresh one is a huge plus.

5 8

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 06 Aug '17

06 Aug '17

The ASUS KGPE-D16 fails verification for branch master as of commit ad29ec351e52b9d326d50c558c3af4b54a2e61d4 The following tests failed: BOOT_FAILURE Commits since last successful test: ad29ec3 sb/intel/i82801gx: Implement smbus block r/w functions 16fe790 sb/intel/*: Use common SMBus functions 12d0103 sio/smsc/kbc1100: Fix some style issues 7c5eb07 rockchip: gpio: Correct rk3399 pmu gpio pull setting 589474f rockchip: gpio: add gpio_pull argument in gpio_input_irq() function See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by Zoran Stojsavljevic 06 Aug '17

06 Aug '17

> RAM1 stage: Since some RAM Physical mapping (AFTER *CRB*) MUST be done at the > beginning of the RAM stage, lookalike BIOS one (in PEI phase, I assume), CB will proceed > with the usual activities, set in Protected Mode. And, as we know so far how it works, it'll > finish this phase, looking for Payload. Meant *MRC* (Memory Reference Code), but for some reason wrote CRB??? These damned INTEL abbreviations will kill me...Indeed?! On Sat, Aug 5, 2017 at 7:12 PM, ron minnich <rminnich(a)gmail.com> wrote: > in the akaros virtual machine code, we set up a simple 1:1 map and start > linux at the 64-bit entry point, at which point it builds its own page > tables. So entering a payload in long mode is certainly possible and IMHO > ought to be the standard on amd64 -- not that anyone cares what I think > anyway :-) > > Anyway, I'm going to be working on replacing ramstage with linux again, so > I'm not as concerted with coreboot ramstage just now ;-) > YUP, understood. You have to have RAM stage (before Linux), where you'll do the first 4GB of Physical Memory Mapping (you know, MTRR init and such kind of work), but as I see you'll try to make minimization of it: [image: Inline image 1] Anyway, after this you must do table init since you are, after all, switching in 64 bit Long Mode (so tables are required). Them you switch to 64b Linux, ASAP. Well, you are trying to boot within 300 to 500 msec, I see. It is a tough requirement, since these critical embedded applications MUST have rebooting times virtually set to 0. Imagine unmanned plane hit by fire, but still flying, or missile (cruse one, or you name it) hit by fire... Not a pretty picture for the inside system control! ;-) Zoran

1 0

Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?
by Nico Huber 05 Aug '17

05 Aug '17

Hi Zheng, On 04.08.2017 04:35, Zheng Bao wrote: > I need to clarify my question. > > For Broadwell-U, are there internal 3 display ports? Is the first one set > statically as eDP? the first (DDI0 or DDI-A) is eDP only. The other two can be used for DP, HDMI/DVI or both (aka DP++ or dual-mode DP). What you can actually con- nect depends on your board and the physical connectors of course. Broadwell-U doesn't provide analog VGA. If your board has a VGA connec- tor, there's supposedly a converter chip onboard that is either attached via HDMI or DP to the SoC. > > How can these ports be set as other type like VGA, HDMI? That depends on the software you use. Traditionally, display bringup is done in a separate program in the firmware (e.g. VGA BIOS, GOP). core- boot does this as well on most platforms. Also the OS driver should be able to detect and enable external displays automatically. At which stage do you want to enables these ports? in the OS? or during boot? if the latter, which payload do you use? > > Can all these 3 ports be enabled at same time? Yes. Nico

2 1

Re: [coreboot] About Paging, Realmode and what is going on
by ron minnich 05 Aug '17

05 Aug '17

in the akaros virtual machine code, we set up a simple 1:1 map and start linux at the 64-bit entry point, at which point it builds its own page tables. So entering a payload in long mode is certainly possible and IMHO ought to be the standard on amd64 -- not that anyone cares what I think anyway :-) Anyway, I'm going to be working on replacing ramstage with linux again, so I'm not as concerted with coreboot ramstage just now ;-) On Thu, Aug 3, 2017 at 9:16 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > OK Ron, > > I needed some time to reconcile my thoughts. So,as Aaron pointed, it is > impossible to do any long mode paging in ROM stage. > > And here we come to the Mystery of CB Organism (hmmmm... It is very close > to some other term). ;-) > > Now, here is how it will play for you and Coreboot, after ROM stage (I'll > call it RON stage, since it is RAM stage, divided in two sections). > > Why RON? Ready Or Not, that is the question! > > So RON stage = RAM1 stage + RAM2 stage. > > RAM1 stage: Since some RAM Physical mapping (AFTER CRB) MUST be done at > the beginning of the RAM stage, lookalike BIOS one (in PEI phase, I > assume), CB will proceed with the usual activities, set in Protected Mode. > And, as we know so far how it works, it'll finish this phase, looking for > Payload. > > Now, instead of payload stage, here we go with the RAM2 stage. Now the CB > will switch to the Long Mode (flat x86_64), addressing at maximum of 48 > bits of the physically available CPU address memory bus - 256 TB of DDRAM > memory (I'll drop here 64 bit PAE extension (additional 4 bits of physical > address space), for clarity). > > Here, you'll start initializing MMU, with 4 TLB tables: CR3 -> PML4 (512 > entries) -> PDTP (512 entries) -> PDT (512 entries) -> PT (512 entries + > last 12 bits freed for the MMU attributes). So, if your HW have in average > 8GB of memory, you'll need ONLY 1 entry in PML4, 8 entries in PDTP -> and > full tables for these 8 entries. I see that you'll do NOT a Virtualization, > rather a logical address shift for the constant address offset. With proper > init of the attributes in the PE tables, per 4KB page - your finest > granularity). > > And, YES, you'll have your memory protection in full swing (just for the > de-referencing the NULL pointers), since you do NOT have more that one > process working, in linear mode (so the bus error will appear ONLY for NULL > pointers). > > Now, after you've done this, what is the next step, somebody will ask? > [A] Reverting to Protected Mode prior Payload stage? > [B] Proceeding with the Long Mode passing thread of execution to > payloads... Which need to operate in Long Mode!? Really??? > [C] Reverting to Virtual x86 Mode??? > [D] Reverting to Real Mode??? > > Seems that you will do scenario [A]. But if you choose to have payload as > 64b Linux [B], then I see where you are pointing/going with this > approach... To fast Server (?!) boot-ups, but you need to reconsider, since > 64b Linux still will reconfigure MMU, doesn't it??? > > Or you would like to skip kernel MMU init while booting 64b kernel. > Letting kernel to pick up (already) hot MMU, on fly? > > As far, it'll be: Boot stage + ROM stage + RON stage (RAM1 stage in > Protected Mode, + RAM2 stage in 64b Long Mode) + 64b kernel payload. Solely > out of FLASH (smells as DOD MIL RT applications, drones, unmanned planes, > missiles)... Interesting scenario, anyway! > > (Mysteries of CB organisms) ;-) > > Zoran > > On Wed, Aug 2, 2017 at 9:45 PM, ron minnich <rminnich(a)gmail.com> wrote: > >> right, Aaron, you keep reminding me of that and I keep forgetting it :-) >> >> so, ok, ramstage it is for paging. The x86 is so darned annoying. We had >> paging in the bootblock for PPC on linuxbios. >> >> On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin <adurbin(a)google.com> wrote: >> >>> On Wed, Aug 2, 2017 at 1:36 PM, ron minnich <rminnich(a)gmail.com> wrote: >>> > >>> > >>> > On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic >>> > <zoran.stojsavljevic(a)gmail.com> wrote: >>> >> >>> >> >>> >> >>> >> So, turning on the Virtual Mode (paging ON), you'll also imply that >>> >> Coreboot will initialize and use MMU, don't you? >>> > >>> > >>> > sure. >>> > >>> >> >>> >> >>> >> Am I correct, or you can use paging without MMU?! >>> > >>> > >>> > MMU must be on. >>> > >>> >> >>> >> I doubt that, perhaps. So, then, I would like to see this code in >>> Coreboot >>> >> where MMU is initialized. And how it is initialized (maybe there is a >>> some >>> >> over-simplified mode of operation using 2MB pages). >>> > >>> > >>> > yep. >>> > >>> >> >>> >> >>> >> And my question is: what for? Or I did not get the idea... Who really >>> >> needs to use paging in boot-loaders? Even INTEL, which (on purpose) >>> makes >>> >> things way over-dimensioned and over-complicated, does NOT use paging >>> in >>> >> UEFI BIOSes, so far??? >>> >> >>> > >>> > it's trivial to turn on paging. In harvey I've got it down to 160 >>> lines, >>> > including comments and white space. I made it much more compact in my >>> CL >>> > from 1/2014. >>> > >>> > If you turn on paging you can capture null pointer derefs, and all >>> other out >>> > of range address references. And relocatable modules are much easier.. >>> > >>> > My question is, why not do it? I don't see any harm. All the other >>> platforms >>> > in coreboot use paging. What's so special about x86 that it should not >>> use >>> > paging? >>> >>> You can't use it for CAR so that sorta throws out romstage and before. >>> It's up to the implementation of how CAR works within the hierarchy, >>> but with hardware page walkers that pull things through the cache >>> things can go badly. So then you could enable paging for ramstage. >>> Need to locate storage for the page tables, but that's not an >>> impossible thing either. >>> >>> > >>> > ron >>> > >>> > -- >>> > coreboot mailing list: coreboot(a)coreboot.org >>> > https://mail.coreboot.org/mailman/listinfo/coreboot >>> >> >

1 0

Support for AMD family f17h in coreboot
by Аладышев Константин 04 Aug '17

04 Aug '17

Hello! Is there any plans to support AMD family f17h processors in coreboot any time soon? Or it can be possible only if AMD will decide to provide AGESA code for this new cpu family and nobody here knows what will AMD do? Does AMD still support coreboot in any way? What are chances that f17h processors will be supported by coreboot?

2 1

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 04 Aug '17

04 Aug '17

The ASUS KGPE-D16 fails verification for branch master as of commit 5cb2263004c2068090ecdf955d3da01fd46daee7 The following tests failed: BOOT_FAILURE Commits since last successful test: 5cb2263 util/scripts: Add script to update submodules f3bf7d0 soc/intel/common: Add lpss.c to ramstage 1679c42 drivers/uart: Use baudrate of 115200 by default c4f60f3 AGESA f15 f15tn f16kb: Add extra checks for incorrect SPD data 1cda0d0 mainboard/google/poppy: Decrease link-frequencies for OV13858 and OV5670 <20 commits skipped> 1ac0aa9 soc/nvidia/tegra*: force using our headers instead of compiler's/system's d42eb37 util/cbfstool: Fix build with armv7-eabi cross compiler 8656914 AGESA: Correct PCI function number for MEM_GET(SET)REG outputs 14c8f71 AGESA f15: Support DMI generation for Opteron 63XX family 903ce25 binaryPI: Introduce BINARYPI_LEGACY_WRAPPER and its counterpart See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] qemu to launch coreboot
by Iru Cai 04 Aug '17

04 Aug '17

On Fri, Aug 04, 2017 at 04:17:29PM +0000, ron minnich wrote: > Sorry, don't know what sh4 is ... > Some kind of architecture... (https://en.wikipedia.org/wiki/SuperH#SH-4) > > > On Fri, Aug 4, 2017 at 9:09 AM ingegneriaforense(a)alice.it < > ingegneriaforense(a)alice.it> wrote: > > > Hello everybody, > > > > > > I've used > > > > atp-get install qemu > > > > to install qemu on my Ubuntu 16.04 PC. Is it right ? > > > > Now i have several qemu file in /usr/bin. > > > > For coreboot i need to use qemu-sh4 ? > > You should use the right QEMU of the right architecture (for most of beginners it's x86 or x86_64), and emulate the bare metal system. So you need to use qemu-system-i386 or qemu-system-x86_64. > > Is it right the command that i found on the coreboot wiki > > > > $ qemu -bios path/to/coreboot.rom -hda disk.img -nographic > > > > to launch coreboot on qemu-sh4 ? > > > > > > Thanks very much. > > > > Regards. > > > > Vincenzo. > > > > > > Forensic Consultant > > Tribunale di Lecce > > > > Studio: Strada di Garibaldi - Contrada Paradisi > > 73010 Lequile (LE) > > > > cell: 339.7968555 <(339)%20796-8555> > > skype: vincenzo.di_salvo > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

qemu to launch coreboot
by ingegneriaforense＠alice.it 04 Aug '17

04 Aug '17

Hello everybody, I've used atp-get install qemu to install qemu on my Ubuntu 16.04 PC. Is it right ? Now i have several qemu file in /usr/bin. For coreboot i need to use qemu-sh4 ? Is it right the command that i found on the coreboot wiki $ qemu -bios path/to/coreboot.rom -hda disk.img -nographic to launch coreboot on qemu-sh4 ? Thanks very much. Regards. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo

3 2

Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC
by Аладышев Константин 04 Aug '17

04 Aug '17

Does a windows driver (for host PC where I want to see coreboot log) exist for this solution with BeagleBone? -----Original Message----- From: Andrey Korolyov [mailto:andrey@xdel.ru] Sent: Friday, August 04, 2017 3:58 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC On Fri, Aug 4, 2017 at 3:14 PM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: > What is the easiest and most stable way to do debug through EHCI USB > port instead of COM port? Is there any EHCI dongles on market that > supports both Linux and Windows as a host PC? > The answer varies depending on your exact needs. If you are targeting only on coreboot log obtainment, the RaspberryPI/BeagleBone with dwc2 is probably cheapest cross-platform thing to use. For kgdb, this setup *should* work, but this would add another level of complexity due to gdbserver spatial localization :) I`ve never tried working with combination of the RPI and usb-ip to pass dwc2 port over cdc-ethernet connection, this is the only major difference between 'real' dongle and cheap board-based setup.

2 1

← Newer
1
...
7
8
9
10
11
12
13
14
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 August 2017