The CTL education chromebook has recently popped up on one of the
associated OLPC mailing lists.
Now that XO laptops are getting hard to come by it's being evaluated as
a replacement for the XO by smaller deployments.
Anyone know if these run coreboot and how locked down they are?
Richard A. Smith <richard(a)laptop.org>
Former One Laptop per Child
Hi guys, thanks for responding. I actually got it to boot DOS now, it was a mismatch device id for the northbridge. Once I change it to match the device, it got through fine. The GFX device id was also wrong so once I change that, video started working too.
Curiously, Intel's document states that the northbridge device id is 0x0F00 and the GFX is 0x0F31, but on my board it's 0x0000 and 0x0031. Wonder if it's a microcode mistake, any ideas? I have 2 boards to test with and apparently they both have this issue.
From: adurbin(a)google.com [adurbin(a)google.com] on behalf of Aaron Durbin [adurbin(a)chromium.org]
Sent: Thursday, July 10, 2014 4:15 PM
To: Tuan Vu
Subject: Re: [coreboot] BayleyBay FSP booting
On Tue, Jul 1, 2014 at 10:55 AM, Tuan Vu <tuan.vu(a)insyde.com> wrote:
> I’m trying to investigate Coreboot and FSP booting performance on the
> Intel’s Bayley Bay board and having trouble getting it to boot SeaBIOS. I
> had to modify some files to get it to the point of attempting to load the
> payload but it gets stuck here:
> Could not find a bounce buffer...
> Could not load payload
> Additional printfk reveals that none of the memory ranges described in
> bootmem has the tag LB_MEM_RAM; they all have the LB_MEM_RESERVED,
> LB_MEM_TABLE and LB_MEM_UNUSABLE. Any ideas what went wrong here?
> Typically, what creates the memory ranges?
Could you provide all the logs?
In src/soc/intel/fsp_baytrail/northcluster.c there is a function
nc_read_resources() which should add the appropriate resources. See if
that is being called. If not, maybe another PCI device id needs to be
added to that file to match on the appropriate driver.
> Tuan Vu
> Software Engineer
> Insyde Software, Inc.
> coreboot mailing list: coreboot(a)coreboot.org
When will support the new Atom E38XX
Vice President Sales
Note: This message and any attachment hereto is intended solely for the use
of the designated recipient(s) and their appointed delegates and may contain
confidential information. Any unauthorized use, disclosure,copying, or
distribution of its contents is strictly prohibited. If you have received
this message in error, please destroy it and advise Nolam Embedded Systems
immediately by phone, email, or fax.Thank you for your cooperation.
Пацев Антон wrote:
> Dear developers! As usual simple user can help you?
Unfortunately not really.
Testing of existing support is always helpful, but already for
testing you need to have at least some development tools, in
order to work efficiently, and to be able to recover from when
tests fail, which they will do.
> Creating dumps, trace or something?
Not really something that is needed in the general case. Specific
analysis is required sometimes, but only rarely, and for that one
usually needs to have even more development tools.
Dear developers! As usual simple user can help you? Creating dumps, trace or
something? As such, the developers did nouveau instruction
С уважением, Антон Пацев.
Best regards, Anton Patsev.
it's possible. i've worked on haswell cpu e3 series and c226 and booted win7 and linux OS.
you should get rc code from intel under NDA first，then make mrc.bin，port some pch rc code（sata，pcie，usb，etc）.
then it could boot.
i use the basking ridge CRB code.
and i got some help from aaron on this porting.
> 在 2014年7月3日，下午3:04，David Hendricks <david.hendricks(a)gmail.com> 写道：
>> On Wed, Jul 2, 2014 at 5:58 PM, Paul Wilcox-Baker <wilcoxbaker(a)gmail.com> wrote:
>> Dear coreboot,
>> We have done some more research on the differences between the
>> supported Haswell processors and PCH parts and what we have
>> used in our design.
>> We have designed a board with the E3-1268Lv3 device with the
>> 82C226 PCH part. It appears that all Haswell devices that
>> have been ported are the mobile variety where the PCH device is
>> packaged with the processor.
>> Do the files to support the parts we wish to use exist anywhere
>> else? Is there a repository for non-GPL code perhaps?
>> Can we use any of the coreboot utilities on a system with the
>> same processor and PCH device to generate code for a coreboot
>> that will support this CPU and PCH?
>> Does Intel have the required files to generate coreboot for the
>> processor and PCH part that we wish to use? If they do how do
>> we get them? Perhaps they have some coreboot code that can be
>> obtained under NDA or licence.
>> Thanks, Paul.
>> coreboot mailing list: coreboot(a)coreboot.org
> coreboot mailing list: coreboot(a)coreboot.org
Martin T wrote:
> What is the correct definition of my flash chip in flashchips.c file?
> .name = "MX25L1605D/MX25L1608D",
> I wasn't able to find the exact data sheet.
Look for MX25L1605D.
Am 08.07.2014 20:57, schrieb ron minnich:
> Might work on your x60. Not recommended on more recent chipsets. Yes,
> you might get it to boot. That's almost worse than having it fail.
For a not-so-recent example, some of the later Via processors require a
microcode update lest they hang when you change the processor clock.
Similar non-obvious issues can happen with caches (I think Intel alluded
to potential issues in that general area every now and then, maybe even
on the Core/Core2 things you find in the X60 - I hope they're just being
cautious here), and these issues might not be as prominent - you really
are lucky if your system hangs hard instead of probabilistically
flipping every 200000th bit it processes.
Since we really rely on caches when we enable _Cache_-as-RAM, having
them fully functional is a good thing. Since Microcode usually comes
without a (useful) change log (bad, bad CPU-vendors!), we have to be
Like many computing products, CPUs these days are banana-ware: shipped
still "green", they mature at the customer's.
If possible, apply the newest update you can find as soon as possible.
Since people are so bad with updating their firmware, Linux can do a
second run if necessary.
ron minnich wrote:
> To be honest, I'm trying a little bit to discourage the idea that it's safe
> to build coreboot without microcode blobs on modern CPUs. Might work on
> your x60. Not recommended on more recent chipsets. Yes, you might get it to
> boot. That's almost worse than having it fail.
I think very specific details would strengthen this argument. I'm not
saying that the argument is wrong, I'm saying that it would be great
to learn about specific experience.