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:
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.
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
> 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
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
>> 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
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
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,
> 18.104.22.168 (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.
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,
22.214.171.124 (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.
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:
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:
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
$ ./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
I saw this mailing list:
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?
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
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.
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
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.
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
> And in Makefile, there are following lines:
> 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
> cpu core seems to fall into some infinite loop, when debugging with
> 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.
> Hook Guo
> coreboot mailing list: coreboot(a)coreboot.org
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
On 03/18/2015 02:49 AM, Carl-Daniel Hailfinger wrote:
> 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
>>>> stand for the ASUS KFSN4-DRE board, run nightly with automatic bricking
>>>> recovery. It has two Opteron 2431 (AMD Family 10h, 6 core @
>>>> 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.
> 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.
+1 (415) 727-8645
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.:
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
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
(the one described as "Different style of bolt" on
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
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