coreboot November 2013

coreboot@coreboot.org

53 participants
117 discussions

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)
by Scott Duplichan 05 Nov '13

05 Nov '13

Anthony Ross wrote: ]Thanks for the heartiest reply. Well I have gone through the pros & cons of DUET & haven' t faced any hurdles thus ]successfully building it. Similarly getting to the EDK2 project I have successfully built OVMF 32 & 64 with secure boot ]configuration, integrating them with seabios as csm and initializing them in QEMU-kvm. I have also successfully built & ]booted the Coreboot Pkg IA32 encapsulating it in the coreboot.rom and booting it under QEMU-kvm except for the X64 ]architectures I faced certain toolchain errors. ] ]So if the Coreboot Pkg can boot so should DUET. I know there are both different but any how they both follow the same ]basis of the UEFI platform. I say this because the Coreboot Pkg (coreboot.rom) during its boot up shows signs of errors & ]debugging messages are worth noting but DUET (coreboot.rom) seems just absent.It also does not indicate any low ]memory problems in real mode, frankly speaking the coreboot.rom just boots as if it was built with just a seabios ]payload. Yes one thing can be noted when I had earlier booted DUET directly under QEMU it indicated something as ]'executing code out of memory' and it aborted there.Secondly taking again into concern the Coreboot Pkg it follows lzma ]compression and also DUET so any issue about that? & what about QEMU does it require any changes as for DUET It is good to hear you are you are building successfully. Here is an alternative method of booting the EDK2 Duet project. It uses the publically available AMD simnow in place of qemu. Simnow has the benefit of booting unmodified BIOS and other code. It boots the same BIOS image that is used on the real hardware. You can use simnow to ensure you have a working image. Then you can try it on real hardware. Simnow can be downloaded from here: http://developer.amd.com/tools-and-sdks/cpu-development/simnow-simulator/ I tested using the simnow model for an old AMD reference board named Solo. The limited virtual address space of the processor used in the Solo model avoids a memory overwrite bug in the Duet code. The limited DRAM of the Solo model avoids pointer truncation problems in the Duet code. Here is how I tested: 1) get EDK2 SVN version 14796 from one of the public servers. 2) build the Duet project and use the output to make a bootable hard disk image. 3) boot the hard disk image using the simnow solo model. The simulation will stop with a red screen register dump. This is due to a Duet bug where initialization of the 8254 timer while it is already running causes a spurious interrupt. Use the built-in debugger to continue out of the exception handler's hang loop. The simulation will continue and boot the UEFI shell. If you exit the shell, the UEFI menu system will run. Here it the bootable hard disk image and a Windows batch file for starting simnow. Some screen shots are also included. http://notabs.org/edk2-duet/ Once you have this much working, you could try real hardware or a different simnow model. This will expose some problems that need to be fixed in order to run on systems with larger memory and on processors with larger virtual address space. I have no experience with making SeaBIOS boot an embedded floppy image. I may be able to give this a try, but I would have to first overcome Windows build problems that have crept into both SeaBIOS and coreboot. Thanks, Scott On Wed, Oct 23, 2013 at 1:00 AM, Scott Duplichan <spambucket(a)notabs.org> wrote: Neo wrote: ]Hello ] ] There has been no response to my thread [Help required to initialize ]coreboot as Seabios (floppy mechanism for DUET) payload] since a long ]time.I have eagerly waited but no solutions have turned up. ] If Im mistaken in any way or the other please let know. ] ]Regards.... ] ]Neo. Hello, If this is really something you want I may be able to help. Be aware that Duet is not an active EDK2 project. Duet has many problems that you must solve before it is usable. The Duet concept is sound, and is a good match for coreboot. But it is not in general a usable project as it exists in the public EDK2 archive. Building Duet should be easy, relative to other EDK2 projects. Can you successfully build other EDK2 projects? From EFI's beginning in 1999 to recently, the only supported build toolset was Microsoft. Recently gnu build tool support was added. But because Duet is not an active project, it may not build easily with gnu tools. In addition, EDK2 does not properly support any Windows port of the gnu tools. So try building with Microsoft tools for a reference point. But be aware that EDK2 actually uses a hard-coded absolute path to the Microsoft tools. So unless your Microsoft build tools are installed in the same location as theirs, you will have to modify Basetools\Conf\ tools_def.template. Once Duet builds, there are some basic bugs to fix. There is a memory overlap problem for example. Duet cannot work with more than 4GB of RAM if I remember correctly. These are all easy to fix. Another problem is a limitation on the DXE image size. This limitation is due to the DOS 640 KB memory limit. The DOS 640 KB limit is relevant because the image is read from disk in 16-bit mode and low memory is the most convenient place to put it. This limitation must be removed before a full featured DXE can be used. Once all the problems are fixed, the reliance on legacy BIOS INT 13h can be removed. The image can be kept in flash and then copied to DRAM instead of reading it from a file. One of the bigger problems is that UEFI needs a large amount of NVRAM. The size is too big to fit into CMOS. That means you need to add code to write this data to flash memory. Normally a 64-KB block of the BIOS flash chip is set aside for this use. There are several more problems in addition to these. They can all be overcome, but it takes some time. The good thing about Duet is that it uses only the generic portion of UEFI, so it is easy to run on an emulator such as simnow or qemu for development and debug. Duet requires that DRAM init and any other chipset initialization be complete. Duet finds DRAM by calling E820, though passing the info directly is possible. Duet does not supply ACPI tables. It finds existing ACPI tables and uses those. Same for SMBIOS. Thanks, Scott

3 3

Re: [coreboot] BadBIOS Thoughts
by Alex 05 Nov '13

05 Nov '13

On 11/04/2013 11:02 AM, ron minnich wrote: > I don't like the situation any more than you do, but the fact is, a > blob free future is very unlikely unless people are willing to pay > more money for it. And, so far, very few organizations (save BSI!) > have been willing to put their money where their mouth is. Especially, > sadly, the free software community: given a choice between better > performance/lower cost and more freedom, they pick performance and > cost every single time -- well, save for the few of us who care. > > ron > Is there a chromebook/(laptop shipping with CB) with a backlit keyboard, a decent size screen, and sturdy aluminium case? I see chromebooks targeting either the cheapo market, or the fancy gadget market, but not the mainstream or rugged markets. Is this because of a lack in demand, or a lack in supply? I am among those that can reconcile with a higher cost, but not a lower performance, and I am looking for a new laptop, BTW. Alex

3 2

Re: [coreboot] BadBIOS Thoughts
by Alex 04 Nov '13

04 Nov '13

On 11/04/2013 07:13 PM, ron minnich wrote: > I really like the haswell chromebooks. The acer is small, light, cool, > long battery. The HP is bigger, still cool, long battery. > What about backlit keyboard (will not do without) or aluminium casing? Upgradeable RAM and upgradeable 2.5" storage drive? Alex Apropos, I'm kinda sick of HP. The last laptop I got from them has had issue after issue after issue; they just don't make them like they used to.

2 1

Re: [coreboot] BadBIOS Thoughts
by ron minnich 04 Nov '13

04 Nov '13

I really like the haswell chromebooks. The acer is small, light, cool, long battery. The HP is bigger, still cool, long battery. You have to pop into dev mode and run a chroot. ron

1 0

Re: [coreboot] BadBIOS Thoughts
by Alex 04 Nov '13

04 Nov '13

On 11/04/2013 12:35 PM, ron minnich wrote: > what is it you intend to use it for? > All-day round laptop. Research (Calculations, Scilab/Maxima stuff). Having something to work on while on the bus. Running KDE with fancy graphics. Maybe some gaming (Nexuiz/Xonotic) > what's your budget? > $600 to $1000. It's not a hard limit. > ron > Alex

3 3

Re: [coreboot] [RFC] Board status script
by Paul Menzel 04 Nov '13

04 Nov '13

Am Montag, den 04.11.2013, 08:05 -0800 schrieb ron minnich: > well, now that this has come up here, I might as well put the full plan out. Thanks. Very much appreciated. > The mainboard status repo needs repair. I did not know that we had one. Or do you mean the status page in the coreboot Wiki? > We want to make a script that produces concise results that make it > easy for a potential OEM to make a go/no-go decision. Right now, they > can't do this, and we've been asked to fix that problem. > > The vendors want to know two things: > - can I build it > - will it boot [my os] -- where that may not be linux. > > So we need a simple script that produces this information. It needs to > be easy to run, have very few dependencies, and communicate the key > information without drowning the user in a bunch of extraneous data. > > How do we answer those questions? > > We need to present results that are current. So, starting Nov. 15, the > static mainboard status page will be more dynamic. The table will > become a waterfall of tables, updated each week. Older results will be > found in older tables. > > So the 'Can I build it' will be answered by looking at the table. > How will be answered by seeing what date a build was reported, getting > the hash and config, and then trying to build it. Doesn’t our build bot Jenkins already answer this question? Every board builds with the default configuration. > Will it boot can only be answered by trying to boot it, but the log > might be helpful. Booting an operating system still does not give you the information, if all devices are supported and work. Especially suspend and resume, which does not work on the ASRock E350M1 for example. > The huge amount of detail Paul is proposing doesn't help that much > with these questions. This is not about regressions. This is about > whether a board worked for someone. The mainboard status page is full > of errors and if I could remove it today, I would. If you mean the Wiki, then in my experience it is pretty accurate. > And, again, the value of dmesg is quite overstated. Linux dmesg is so > variable that for the most part it's one bit of information: 'got a > dmesg/did not get a dmesg'. For me as a non-professional having the Linux messages for comparisons helped me several times to improve things or figure out problems. > What this means is we're going to make work for our community. If you > have a working board, YOU need to run that script and push the > results. The pressure to run the script will increase each week, as > your results fall lower down on the waterfall :-) What I have seen so far, I have no incentive to run that script just to help some vendor, whoever that is. I am looking forward to November 15th and try to stay open minded, but from the non-corporate community, I am again disappointed to be left out and just have probably a non-optimal end product. Also, you pushed David’s patch with the errors and leave the boring, stupid work to clean it up to the community. Uwe Hermann did a lot of clean up work too in the past and moved to a different project. I think committing the patch was rushed again. The same with the Lenovo X60 native VGA init patch, which you pushed [2]. Thanks, Paul [2] http://review.coreboot.org/2998

3 2

Re: [coreboot] BadBIOS Thoughts
by Alex 04 Nov '13

04 Nov '13

On 11/03/2013 02:19 PM, ron minnich wrote: > On Sun, Nov 3, 2013 at 2:47 PM, Alex <mr.nuke.me(a)gmail.com> wrote: > >> I'm sorry Ron, but you're just asking me to take your word for it. I can't >> do that. There's more secret code running on a Chromebook's firmware than >> there is free code. In fact, I would argue, most code where attack vectors >> could hide is secret. It's a foul's paradise. > > I can't argue with you on that one. > The argument that should be made with chromebooks is that they have a significant portion of their firmware opensourced, and they are "more free" than comparable systems. It should be argued they are a step in the right direction, and although the current generation of Chromebooks will most likely never be completely free, using a Chromebook sends the message that we want more libre stuff. Then, if the next generation is less blobby, this argument is believable and accurate. Keeping up this pace, ten generation in the future, we might actually see a completely libre system. In the end, a totalitarian system (most laptops) is much worse than an opressive system (Chromebooks). (sorry for the analogy) Alex

2 1

[RFC] Board status script (was: Change in coreboot[master]: Another pass at board status script)
by Paul Menzel 04 Nov '13

04 Nov '13

Dear coreboot folks, currently there are several patches in Gerrit for review introducing a board status script [1][2] and the output of Ron’s one [3][4]. Putting the board status data into the repository or somewhere else is great! The question remains what is needed exactly. Some things are already discussed in the review of David’s patch [2]. In my opinion, as log data is small, there is no problem getting much data, where it is unknown if it is needed or not in the future. The data should be gotten by a script and most of it machine parseable so regressions can be detected automatically. What do you all need? Think of the regressions you had in the past and how these could be detected with such a script. Does Ayush’s GSoC 2013 work include anything, we could use for this status script? Am Sonntag, den 03.11.2013, 10:06 -0800 schrieb ron minnich: > The document you cite is not applicable. The issue here is not 'will > coreboot work on my machine' but 'what is the status of a supported > mainboard'. Those are two very different things. there are a lot of intersections. > If you want to know what superio chip is on the board, for example, > look at the config which is provided in the status. Sure. But regarding the Super I/O we are also interested, if the register values changed. So getting `superiotool -deV` is useful in my opinion. > It's a git repo so I expect the log files get overwritten each time. If we put it in the same repository, it would of course be useful for review as the diff would be shown in Gerrit. On the other hand it would be more difficult to compare different versions and as written in the review to commit tests from older changes. > And nobody should be pushing a status that includes a hash that is not > available in a public repo. The question is, how we enforce that. > The goal is to provide the minimum amount of information needed for a > working mainboard, not a gigantic firehose of data. I even question > the value of the dmesg log, given the huge variance in linux kernels > out there, but we can do it for now. It is better to get more data, when it is small, because you never know what it can be used for. Thanks, Paul [1] http://review.coreboot.org/#/c/4011/ [2] http://review.coreboot.org/#/c/4021/ [3] http://review.coreboot.org/#/c/4005/ [4] http://review.coreboot.org/#/c/4010/ [5] http://blogs.coreboot.org/blog/author/ayushsagar/

3 2

Re: [coreboot] BadBIOS Thoughts
by David Hubbard 03 Nov '13

03 Nov '13

On Sun, Nov 3, 2013 at 4:50 PM, Gregg Levine <gregg.drwho8(a)gmail.com> wrote: > "Trust but verify." > "Trust but verify" became famous in the US after President Ronald Reagan's use of it during the Nuclear Disarmament treaty negotiations. It is originally a Russian proverb, "doveryai, no proveryai" I wonder what Mr. Reagan would do in the same position today? David

1 0

Re: [coreboot] BadBIOS Thoughts
by George M. Garner Jr. 03 Nov '13

03 Nov '13

> > of course, apropos your comment, do you use > - wifi cards > - usb sticks > - sata disks > > because in that case, you'fe a very trusting person :-) > > ron > You forgot bluetooth, which seems to be on everything nowadays. Any bluetooth stack in Coreboot yet (with a debug TTY that let's you take complete control of the system)?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2013