coreboot March 2015

coreboot@coreboot.org

62 participants
166 discussions

Enabling SeaBIOS
by Matthias Apitz 20 Mar '15

20 Mar '15

Hello, I'm running FreeBSD 11CURRENT on an Acer C720 Chromebook which uses Coreboot and SeaBIOS to boot from SSD. Before installing FreeBSD I switched Coreboot to boot to SeaBIOS as default as described here: https://wiki.archlinux.org/index.php/Chromebook#Enabling_SeaBIOS I plan to install a 2nd C720 and my question is if tools mentioned in this page are available as source too to see if I could use them from within FreeBSD, or if there is any other method to make this switch without ChromeOS or without making a Linux USB bootkey. Thanks matthias -- Matthias Apitz, guru(a)unixarea.de, http://www.unixarea.de/ +49-170-4527211 "Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden." "Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias", Karl Marx in Die heilige Familie / La sagrada familia

2 1

Re: [coreboot] GCC update broke AMD Fam10h boot
by Julius Werner 19 Mar '15

19 Mar '15

> You are right that it would work, but back solving for which alignment > the compiler decided is hard. It's definitely whack-a-mole in that > case. It could have very well decided 16 too. Without any insight as > to why that breaks down. Or you go the route of putting alignments on > structures just for that behavior which I consider not the best > approach. Well, we only need to pick an alignment *larger* than what the compiler decides, right? I'd hazard a guess that 8 would be enough for a long time (GCC probably just got confused between 32 and 64 bit modes or something... there's no other reason I could think of to explain this). >> From that I'd conclude that if you did: >> >> extern struct boot_state_init_entry _bs_init_begin[]; >> extern struct boot_state_init_entry _bs_init_end[]; >> >> for (cur = _bs_init_begin; cur < _bs_init_end; cur++) ... >> >> the compiler shouldn't be able to guarantee that the first array >> wasn't empty and therefore pointing to "one after the end" which is >> the start of the next array in the first iteration. > > I think you are right on that point -- using '<' instead of equality. > But those aren't pointer types. Not sure if the spec things arrays > like that are poitners or a separate type. Either way, hopefully there > isn't some language in the spec that suggests comparisons like that > can be optimized away. The array degenerates to a pointer at that point AFAIK. You could also write &_bs_init_begin... for an array type the two should be pretty much equivalent.

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Aaron Durbin 19 Mar '15

19 Mar '15

On Thu, Mar 19, 2015 at 5:29 PM, Julius Werner <jwerner(a)chromium.org> wrote: > Sounds like this could've been solved with a simple ALIGN(8) in the > ldscript, right? I don't know what made the compiler think that it > would have to align i386 pointers to 8 byte (which seems to be what > happened), but if it makes that decision then it should also conclude > that sizeof(struct boot_state_init_entry) == 0x20 and the array > traversal should still work. If those structures need to be writable > we could simply move them from .rodata to .data in the ldscript. You are right that it would work, but back solving for which alignment the compiler decided is hard. It's definitely whack-a-mole in that case. It could have very well decided 16 too. Without any insight as to why that breaks down. Or you go the route of putting alignments on structures just for that behavior which I consider not the best approach. They do need to be writable since our linked list is within them. > > Aaron, do you have a definitive source for the "no two symbols may be > the same" rule? Because that's a pretty common pattern, I would be > surprised if it was incorrect (especially since there's things like > __attribute__((alias)) that explicitly allow you to do it even in C). > I can't find anything in a cursory glance at the standard... in fact, > 6.5.9.6 (of some weird 2007 draft version I found, at least) says: I don't have a pointer. I only remember clang doing something because of that behavior. I think Patrick may remember the details. > > "Two pointers compare equal if and only if [...] or one is a pointer > to one past the end of an array object and the other is a pointer to > the start of a different array object that happens to immediately > follow the first array object in the address space." > > From that I'd conclude that if you did: > > extern struct boot_state_init_entry _bs_init_begin[]; > extern struct boot_state_init_entry _bs_init_end[]; > > for (cur = _bs_init_begin; cur < _bs_init_end; cur++) ... > > the compiler shouldn't be able to guarantee that the first array > wasn't empty and therefore pointing to "one after the end" which is > the start of the next array in the first iteration. I think you are right on that point -- using '<' instead of equality. But those aren't pointer types. Not sure if the spec things arrays like that are poitners or a separate type. Either way, hopefully there isn't some language in the spec that suggests comparisons like that can be optimized away. -Aaron

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Julius Werner 19 Mar '15

19 Mar '15

Sounds like this could've been solved with a simple ALIGN(8) in the ldscript, right? I don't know what made the compiler think that it would have to align i386 pointers to 8 byte (which seems to be what happened), but if it makes that decision then it should also conclude that sizeof(struct boot_state_init_entry) == 0x20 and the array traversal should still work. If those structures need to be writable we could simply move them from .rodata to .data in the ldscript. Aaron, do you have a definitive source for the "no two symbols may be the same" rule? Because that's a pretty common pattern, I would be surprised if it was incorrect (especially since there's things like __attribute__((alias)) that explicitly allow you to do it even in C). I can't find anything in a cursory glance at the standard... in fact, 6.5.9.6 (of some weird 2007 draft version I found, at least) says: "Two pointers compare equal if and only if [...] or one is a pointer to one past the end of an array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space." >From that I'd conclude that if you did: extern struct boot_state_init_entry _bs_init_begin[]; extern struct boot_state_init_entry _bs_init_end[]; for (cur = _bs_init_begin; cur < _bs_init_end; cur++) ... the compiler shouldn't be able to guarantee that the first array wasn't empty and therefore pointing to "one after the end" which is the start of the next array in the first iteration.

1 0

VGA doesn't work on Mohon Peak
by Kuzmichev Viktor 19 Mar '15

19 Mar '15

Hello, I'm using coreboot + SeaBIOS on Mohon Peak CRB. And I've tried to make VGA work for a while now. I used this article as a guide: http://www.coreboot.org/VGA_support Extracting VGA BIOS from vendor BIOS image did not work: $ ./bios_extract EDVLCRB1.86B.0043.R00.1408290947_MPK.bin Using file "EDVLCRB1.86B.0043.R00.1408290947_MPK.bin" (8192kB) Error: Unable to detect BIOS Image type. Then, I've downloaded VGA BIOS from here: http://www.aspeedtech.com/support.php Mohon Peak uses Aspeed VGA controller AST1300. And also, I've extracted Video ROM from /dev/mem: # dd if=/dev/mem of=vgabios.bin bs=1k count=32 skip=768 Neither of them worked. Here's what I've tried. I've tried to add them via coreboot's menuconfig (' Add VGA BIOS image' option). I've tried to add them manually via cbfstool as an optionrom and as a raw file. I've tried to put them in CBFS under vgaroms/ directory. Here's my latest ROM-file layout: $ ./build/cbfstool build/coreboot.rom print coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset 0x600000 alignment: 64 bytes, architecture: x86 Name Offset Type Size cmos_layout.bin 0x600000 cmos_layout 1352 pci1a03,2000.rom 0x600580 optionrom 32768 fallback/romstage 0x6085c0 stage 26616 fallback/ramstage 0x60ee00 stage 59904 fallback/payload 0x61d840 payload 56100 config 0x62b3c0 raw 4532 revision 0x62c5c0 raw 708 pci8086,1f41.rom 0x62c8c0 raw 61952 vgaroms/pci1a03,2000.rom 0x63bb00 raw 32768 img/Memtest86+(5.01) 0x643b40 payload 159492 (empty) 0x66aa80 null 939288 mrc.cache 0x74ffc0 (unknown) 65536 cpu_microcode_blob.bin 0x760000 microcode 83968 (empty) 0x774840 null 46936 fsp.bin 0x77ffc0 (unknown) 372736 (empty) 0x7db000 null 150424 The entries pci1a03,2000.rom are the VGA ROMs there. I also tried to remove either of them. I've tested with coreboot option 'Run VGA Option ROMs' checked and unchecked without any difference. In SeaBIOS I set 'VGA Hardware Type (coreboot linear framebuffer)' as the other options are None, GeodeGX2 and GeodeLX, so coreboot linear framebuffer seemed more logical. I saw this mailing list: http://www.seabios.org/pipermail/seabios/2015-January/008588.html but found no solution there and it seems not to be my case as my board does not hang. I put coreboot and SeaBIOS output in the attachment. Debug levels set to 7 for both. In coreboot only 'Output verbose CBFS debug messages' checked in 'Debugging' submenu. Is there anything I'm doing wrong or simply missing? Viktor

3 2

0xE0000/0xF0000 segment issue
by Naresh G. Solanki 19 Mar '15

19 Mar '15

Hi All, I'm trying to port coreboot with seabios payload. Everything goes fine till the control is transferred to payload. Since payload is loaded between memory range 0xC_0000 - 0x10_0000. The problem I was facing was that the board was going to auto reboot mode while executing payload.. Once it reboot then I'm not able to control the processor through XDP until I manually do CPU reset. It keeps on rebooting once control is transferred to payload. To find out the cause I did detailed memory test & found out that the memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF always reads 0xFF. since payload is loaded in the same region so before jmp_payload, I tried to read this region through XDP & found payload code exist. so I introduced wbinvd instruction just before jmp_payload & I found that the XDP started reading 0xFF in the memory range 0xE0000 - 0xFFFFF. Thus from this I conclude that before the payload was able to execute because of cached copy of it in CPU cache & it didn't really existed in RAM. Also to enable memory range 0xE_0000 to 0xF_FFFF I have followed the guidlines as per table 15 of the document http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-… Is that OK. What I can do to successfully enable the memory range 0xE_0000 to 0xF_FFFF for read write operation so that my payload execution goes undisturbed. My ultimate aim is to load Windows by Seabios as payload. Thanks N Solanki

1 0

Re: [coreboot] [Intel Atom C2000 Rangeley] SPI Descriptor issue related to coreboot
by WANG FEI 18 Mar '15

18 Mar '15

Guo Jia, It's not easy to figure out the problem in your case, it would be great if you can have an ITP hooked on your system to debug coreboot instead of guessing. I'm glad you've tried to dump descriptor bin from ADI's binary, but I remember even without descriptor binary, Mohon Peak platform can still boot up. I would suggest you checking the microcode, making sure the processor revision matching the microcode included in coreboot, system will halt itself If they does not match. -Fei On Wed, Mar 18, 2015 at 2:17 AM, 郭佳 <yunyuaner(a)gmail.com> wrote: > Hi buddies, > > I'm porting coreboot to Intel Atom C2000 board provided from ADI. > I've retrieved the source code released by ADI from github. > ADI's coreboot source code requires SegaBIOS SDK to build, since I > don't have one, I've modified the Makefile to use toolchain provided by > original coreboot(xgcc). > When building done, there is a coreboot.rom(8M) under coreboot/build > directory, and flashing this file to boot rom doesn't bring the system up, > even no serial outputs. > I found that there is no descriptor segment at the beginning of > coreboot.rom. > And in Makefile, there are following lines: > "dd > if=../intel/mainboard/intel/mohon_peak/unlocked_descriptor/descriptor.bin > of= > build/coreboot.pre conv=notrunc > /dev/null 2>&1;" > Unfortunately, ADI doesn't release descriptor.bin. > So, I use ifdtool to dump the descriptor from ADI's coreboot binary file. > Firstly, I unlock the descriptor, then extract descriptor.bin, and > after that, reassembly > my own coreboot.rom file, but still fail to bring system up (no serial > output, > cpu core seems to fall into some infinite loop, when debugging with > SourcePoint) > I don't know if I've made my question clear, I'm new to x86/coreboot. > Can someone help me? Thank you in advance. > > Regards, > Hook Guo > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

SeaBIOS boot menu key changed to ESC
by Kevin O'Connor 18 Mar '15

18 Mar '15

In the past, F12 was the default SeaBIOS boot menu key. This was typically seen with a boot message of: Press F12 for boot menu. Do to several issues with the F12 key on both real and emulated machines, the development branch of the SeaBIOS repository has now changed the default key to the ESC key. This means the prompt in the future will show as: Press ESC for boot menu. If the old key is desired, one can still activate it by placing 0x86 in the CBFS file "/etc/boot-menu-key" (cbfstool build/coreboot.rom add-int -i 0x86 -n etc/boot-menu-key) along with the old boot message in "/etc/boot-menu-message". The wiki documentation has futher details. -Kevin

2 3

Re: [coreboot] Automated test system: Nominations wanted
by Timothy Pearson 18 Mar '15

18 Mar '15

On 03/18/2015 02:49 AM, Carl-Daniel Hailfinger wrote: > [off-list] > > Hi Timothy, > > On 16.03.2015 18:15, Timothy Pearson wrote: >> On 03/16/2015 08:17 AM, Alexander Couzens wrote: >>> On Mon, 16 Mar 2015 01:20:17 -0500 >>> Timothy Pearson<tpearson(a)raptorengineeringinc.com> wrote: >>> >>>> Just wanted to mention that Raptor Engineering now has an automated >>>> test >>>> stand for the ASUS KFSN4-DRE board, run nightly with automatic bricking >>>> recovery. It has two Opteron 2431 (AMD Family 10h, 6 core @ >>>> 2.4GHz)CPUs >>>> and 6GB of DDR2-667 memory installed on Node 0. >>>> >>>> Each successful test result is recorded to the board-status repository, >>>> and each failure is reported to this list. >>> >>> can you please write down (wiki?) how your system is setted up? >>> How do you do automatic bricking recovery? >> >> Bricking recovery uses the fallback mechanism. There is a supervisory >> board attached to the target; it controls physical power on/power >> off/CMOS reset and also sends build/flash/test commands to the target >> as needed. >> >> The exact code/details for the controller are not public at this time, > > Understood. What is needed for you to make this public and/or provide > more information about it? Money? Time? PR? Some combination of the above, primarily the first two. Right now the system is functional but its code is not exactly up to our normal FOSS configurability / maintainability standards. I could clean it up, make it easy to configure for other test systems, and generate documentation, but that would require time + proper motivation (e.g. put the work under contract with my company). I also want to let the test stand run for a month or two to make sure some unforeseen corner case doesn't take it out--this delay can be decreased significantly by throwing random Gerrit changesets at it (including failures to build, NVRAM layout changes, etc.) until I'm confident it won't break under normal use. One of my main concerns is that unless the test rig is 1.) inexpensive and 2.) almost fully plug + play people won't bother to set it up / make it available for use. Right now the test stand requires an external NFS server and SMTP access, along with a 24/7 Internet connection. It doesn't use Java at all; only needing around 500 lines of Python. The test coreboot image is built on the target itself, which is only powered on for compilation and test, thus saving energy. > My main motivation is that I'd like to avoid reinventing this from > scratch now that I've started to order parts for my automated test system. Understood. > Stefan Reinauer had a test system running in the past, but he dismantled > it because nobody used it. That was during a time when we didn't have > Jenkins and hooking up tests was impossible: Manual submission and > manual reaction to the result was the only way. I think he published how > he set up his test system back then, but your test system looks like it > is fully automated and thus way easier to use and integrate. This is one of my main concerns ATM. If this is something the coreboot community wants badly enough I can provide a professional open-source solution. If not, I'll continue to run the test stand here as both a courtesy to the community and a double-check on bootability for the systems in use here. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

1 0

New flashrom logo
by Stefan Tauner 18 Mar '15

18 Mar '15

Hello, we have used two logos in the past for flashrom. The one most are familiar with is actually a generic icon stemming from coreboot's "Related Tools" section, i.e.: http://www.coreboot.org/images/a/ae/Chip_tools.png This is not only set up as the "Mediawiki" icon on flashrom.org but is also used on our Twitter account and other sites like openhub (https://www.openhub.net/p/flashrom) The second logo was specifically designed for this purpose and was used at various occasions in presentation slides and on marketing materials (e.g. posters). Namely http://3.bp.blogspot.com/_PTt3TWYKjnQ/TI_oZ3cqvaI/AAAAAAAAALY/eLvM6K16Glw/s… (the one described as "Different style of bolt" on http://kmacphail.blogspot.de/2010/09/flashrom-logos.html) I think that one is way lesser known since even I was not really aware about the fact that it kind of the "official" logo at the moment. I am not too happy with either. The hammer logo has grown dear to me... the hammer perfectly symbolizes the force we have to exert to get some systems to work and the logo as such is very recognizable. But... I only have it in very low quality... is there a better source for it? It also does not represent our generally gentle and cautious approach when dealing with hardware and our focus on stability. The DIP logo on the other hand is available in SVG (at least Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major problems I have with it are that it is not even nearly rectangular and it is very complex. There is the text with the lightning bolt replacing the h character and the DIP32 chip. Both is ok for posters and other big displays but sucks for other uses where simple, rectangular icons are required. I have spent the last weekend with playing around with Blender and its freestyle renderer that is able to output SVG directly. I have managed to render a 3D model of a SOIC8 chip that way as a base for a possible new logo. It required some cleanup afterwards but it looks way better than everything I could draw by hand ;) I have made two logos that I think are worth sharing. They are quite similar and the only major difference is the orientation of the chip... I have created 3 versions of each: one fully colored, one with outlines only and a two-colored simple version (e.g. for PCB silkscreens). I have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I have not decided on an appropriate license... probably something similar to how the coreboot hare is licensed. What do you think about my suggestions and the whole matter? I would love to see proposals for alternatives as well! -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

6 24

← Newer
1
...
5
6
7
8
9
10
11
...
17
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 March 2015