coreboot support for netbooks has come back up again.
The VIA vx700 and vx800 chipsets have recently become popular in many netbook designs. Most of these netbooks are being produced by Quanta for several different OEM's.
VIA has recently released open documentation for the vx700 and vx800 chipsets at the VIA Download Portal: http://linux.via.com.tw/support/downloadFiles.action
and open documentation for the latest Unichrome graphics controllers: http://www.x.org/docs/via/
VIA has also released a binary unichrome driver for ubuntu 8.04 and 8.10
VIA is currently developing coreboot support for the vx800 chipset. Release should be along very soon!
openChrome support is also in the works for many new chipsets including the vx700 and vx800: http://www.openchrome.org/
The openChrome developers can also use lots of help. irc.freenode.net #unichrome
The remaining issue with supporting these and other similar netbooks is open firmware support for the Embedded Controller (EC). The most common EC's in these netbooks are the KB9110 or KB3886 from ENE Technology. The ENE EC's are 8051 based and are used to support keyboard scan, lid open/closed, battery charging, power management, etc.
There are also several AMD 690/600 laptops still available that may be candidates as well.
Let see what we can do to get this working!
For a list of netbook candidates and progress updates: http://www.coreboot.org/Laptop
-Bari
On Fri, Dec 12, 2008 at 7:36 PM, bari bari@onelabs.com wrote:
coreboot support for netbooks has come back up again.
The VIA vx700 and vx800 chipsets have recently become popular in many netbook designs. Most of these netbooks are being produced by Quanta for several different OEM's.
VIA has recently released open documentation for the vx700 and vx800 chipsets at the VIA Download Portal: http://linux.via.com.tw/support/downloadFiles.action
and open documentation for the latest Unichrome graphics controllers: http://www.x.org/docs/via/
VIA has also released a binary unichrome driver for ubuntu 8.04 and 8.10
VIA is currently developing coreboot support for the vx800 chipset. Release should be along very soon!
openChrome support is also in the works for many new chipsets including the vx700 and vx800: http://www.openchrome.org/
The openChrome developers can also use lots of help. irc.freenode.net #unichrome
The remaining issue with supporting these and other similar netbooks is open firmware support for the Embedded Controller (EC). The most common EC's in these netbooks are the KB9110 or KB3886 from ENE Technology. The ENE EC's are 8051 based and are used to support keyboard scan, lid open/closed, battery charging, power management, etc.
There are also several AMD 690/600 laptops still available that may be candidates as well.
Let see what we can do to get this working!
For a list of netbook candidates and progress updates: http://www.coreboot.org/Laptop
Probably the best place to start would be here: http://via.com.tw/en/products/notebook/notebook.jsp Find out if any of the manufacturers want to help out, if they'd be willing to provide hardware, and most importantly if they use a removable flash chip. I doubt any of them do, but it would really help things out if they did. IMO, the most likely ones to help would be ones that are already shipping linux by default, since it'd be a free upgrade for their users with almost no effort and minimal cost on their behalf. BTW, CN700 in v3 is coming along nicely, with enough commented code memtest86 runs, and I'm hoping to have linux at least attempting to boot this weekend. A nettop in v3 would be awesome :D
-Corey
On Fri, Dec 12, 2008 at 7:57 PM, Corey Osgood corey.osgood@gmail.comwrote:
On Fri, Dec 12, 2008 at 7:36 PM, bari bari@onelabs.com wrote:
coreboot support for netbooks has come back up again.
The VIA vx700 and vx800 chipsets have recently become popular in many netbook designs. Most of these netbooks are being produced by Quanta for several different OEM's.
VIA has recently released open documentation for the vx700 and vx800 chipsets at the VIA Download Portal: http://linux.via.com.tw/support/downloadFiles.action
and open documentation for the latest Unichrome graphics controllers: http://www.x.org/docs/via/
VIA has also released a binary unichrome driver for ubuntu 8.04 and 8.10
VIA is currently developing coreboot support for the vx800 chipset. Release should be along very soon!
openChrome support is also in the works for many new chipsets including the vx700 and vx800: http://www.openchrome.org/
The openChrome developers can also use lots of help. irc.freenode.net #unichrome
The remaining issue with supporting these and other similar netbooks is open firmware support for the Embedded Controller (EC). The most common EC's in these netbooks are the KB9110 or KB3886 from ENE Technology. The ENE EC's are 8051 based and are used to support keyboard scan, lid open/closed, battery charging, power management, etc.
There are also several AMD 690/600 laptops still available that may be candidates as well.
Let see what we can do to get this working!
For a list of netbook candidates and progress updates: http://www.coreboot.org/Laptop
Probably the best place to start would be here: http://via.com.tw/en/products/notebook/notebook.jsp
Erm, just to clarify before anyone yells at me, I'm not trying to put off AMD-based laptops, they'd be good candidates too for those that know how to make the K8 work its magic, I just tend to know more about Via's tech and nettops then AMD and full-blown laptops. Also, nettops are much cheaper, which is much more appealing on my budget ;)
-Corey
Corey Osgood wrote:
On Fri, Dec 12, 2008 at 7:36 PM, bari <bari@onelabs.com mailto:bari@onelabs.com> wrote:
Probably the best place to start would be here: http://via.com.tw/en/products/notebook/notebook.jsp
Thanks. I forgot about that link. I'll add it to the wiki.
Find out if any of the manufacturers want to help out, if they'd be willing to provide hardware, and most importantly if they use a removable flash chip. I doubt any of them do, but it would really help things out if they did. IMO, the most likely ones to help would be ones that are already shipping linux by default, since it'd be a free upgrade for their users with almost no effort and minimal cost on their behalf.
Many of us already have netbooks or laptops with the vx800 or vx700 chipset. Several are around ~$350, some bargains may be found for under $300.
Walmart still has the Everex Cloudbook (7" LCD, 30GB HD, C7 + vx700) for $299.
BTW, CN700 in v3 is coming along nicely, with enough commented code memtest86 runs, and I'm hoping to have linux at least attempting to boot this weekend. A nettop in v3 would be awesome :D
-Corey
Good news!
-Bari
This is a place where I'd like us to pick a common most-appropriate notebook and go for it.
So which of these is the most likely to be doable? We'll have to solve the EC problem.
ron
ron minnich wrote:
This is a place where I'd like us to pick a common most-appropriate notebook and go for it.
So which of these is the most likely to be doable? We'll have to solve the EC problem.
ron
The Quanta IL1 reference design (VIA C7 + vx800) is sold in a few minor variants (cosmetics, cpu speed, HD size, etc) from several different vendors. Maybe one of these?
* One Mini A120/A150 http://www.one.de/shop/product_info.php?products_id=2667
* Airis Kira 100/350/740 http://preview.tinyurl.com/5zbzl6
* Norhtec Gecko http://www.norhtec.com/products/gecko/index.html
* Pioneer DreamBook Light IL1 http://www.pioneercomputers.com.au/products/configure.asp?c1=3&c2=12&...
* CTL IL1 http://www.ctlcorp.com/v4/p-697-ctl-il1a-89-netbook-with-windows-xp-home.asp...
* ACi Ethos 7 http://www.aci-asia.com/html/Ethos_7.html
* BDSI Deep Blue H1 http://www.ilikeblue.net/products/umpc.htm
Let's see how well the vx800 patch from VIA works on one of these. This should give us an idea of how much work the EC firmware will be.
-Bari
ron minnich wrote:
This is a place where I'd like us to pick a common most-appropriate notebook and go for it.
So which of these is the most likely to be doable? We'll have to solve the EC problem.
I know the Intel Atom is probably a problem for coreboot but here at muppet labs we have gone through a Eee PC900A and an AOA-110
The ASUS uses a EnE KB3310 where the ACER has a Winbond WPCE775
Its highly likely that the KB3310 (and other EnE EC chips) will have a lot of similarity to the KB3700 http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf
Based on info in this thread
http://forum.eeeuser.com/viewtopic.php?pid=99076
and here:
http://code.google.com/p/eeetune/wiki/KBMemoryMap
A few people are already working on this for the Eee. You can certainly have some non-us person dissassemble the 8051 code and take a look at whats going on. With enough work you could even get OpenEC up an running. Which would be funny given that its pretty much halted on the OLPC [1].
The Winbond is a RISC based chip. Much newer and probably harder to figure out.
http://www.nuvoton.com/hq/enu/NewsAndEvents/News/ProductAndTechnology/200810...
My .02 would be that you choose one with an EnE chip in it.
--- [1] Nobody has taken up the challenge to reverse engineer the start up sequence. OpenEC boots and runs on the OLPC's KB3700 but the necessary info to turn on the voltage regulators is still missing.
ron minnich wrote:
This is a place where I'd like us to pick a common most-appropriate notebook and go for it.
So which of these is the most likely to be doable? We'll have to solve the EC problem.
But don't be confused as to what the "EC problem" really is. We've discussed this before on this very list: Open firmware for the EC would be great, but it is a problem on the scope of coreboot itself, since every platform would need a slightly "custom" variant of the firmware, and over time you would end up needing to support different "chips" for different "mainboards". Certainly that is an interesting problem to solve, but I don't think that it is _our_ problem to solve.
Coreboot would be much better served by operating with the "stock" firmware. Don't get me wrong - this is still a challenge because, like I said in IRC yesterday, we don't know what we don't know. Behavior at runtime is fairly standardized, but we don't know what we need to do for initialization - do we need to set up registers, put in tables, kick things, or will it all Just Work (TM)?
I guess the only way to find out is to start trying - enough documentation exists (especially for th ENE) that we can probably determine how large the firmware is and extract it from a stock ROM, and try it out. From what I have heard, I think the VIA processors are the best bet right now for experimentation. Intel of course, is out, and AMD processors aren't in any netbooks to speak of - and I'm sure if we go to this effort, we would rather have it pay off for a netbook rather then a dinosaur laptop.
Jordan
On 13.12.2008 17:14, Jordan Crouse wrote:
ron minnich wrote:
This is a place where I'd like us to pick a common most-appropriate notebook and go for it.
So which of these is the most likely to be doable? We'll have to solve the EC problem.
But don't be confused as to what the "EC problem" really is. We've discussed this before on this very list: Open firmware for the EC would be great, but it is a problem on the scope of coreboot itself, since every platform would need a slightly "custom" variant of the firmware, and over time you would end up needing to support different "chips" for different "mainboards". Certainly that is an interesting problem to solve, but I don't think that it is _our_ problem to solve.
Coreboot would be much better served by operating with the "stock" firmware. Don't get me wrong - this is still a challenge because, like I said in IRC yesterday, we don't know what we don't know. Behavior at runtime is fairly standardized, but we don't know what we need to do for initialization - do we need to set up registers, put in tables, kick things, or will it all Just Work (TM)?
There's also the interesting question about who owns the EC firmware. If the manufacturer owns it and has full rights for it, the situation is different compared to the BIOS. For example, Quanta (OLPC manufacturer) holds some (if not all) rights to the OLPC XO EC code and not BIOS vendor was involved.
I guess the only way to find out is to start trying - enough documentation exists (especially for th ENE) that we can probably determine how large the firmware is and extract it from a stock ROM, and try it out. From what I have heard, I think the VIA processors are the best bet right now for experimentation. Intel of course, is out, and AMD processors aren't in any netbooks to speak of - and I'm sure if we go to this effort, we would rather have it pay off for a netbook rather then a dinosaur laptop.
If I'm right about EC code copyrights and usage rights, a cooperating manufacturer could easily tell us about the interface for their EC code.
On a side note (or rather two): - I seem to remember that VIA manufactures ECs as well. If that is true, we could ask them nicely whether any netbooks have a VIA EC and start with that. - Some people here were successful in talking with Winbond about data sheets. While these data sheets were not for ECs, it can't hurt to ask.
As long as we can avoid time consuming reverse engineering, we should IMHO focus on getting stuff done.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
There's also the interesting question about who owns the EC firmware. If the manufacturer owns it and has full rights for it, the situation is different compared to the BIOS. For example, Quanta (OLPC manufacturer) holds some (if not all) rights to the OLPC XO EC code and not BIOS vendor was involved.
The bulk of the Copyright is by EnE. There are a handful of files that are Quanta only. I would not expect many of these in a mainstream implementation as they deal with some of the extra stuff we did at OLPC. Quanta has mentioned to me many times that they don't do anywhere near that level of work for a normal laptop.
EnE provides a framework and the OEM fills in the blanks.
From what I have heard, I think the VIA processors are the best bet right now for experimentation. Intel of course, is out, and AMD processors aren't in any netbooks to speak of - and I'm sure if we go to this effort, we would rather have it pay off for a netbook rather then a dinosaur laptop.
If I'm right about EC code copyrights and usage rights, a cooperating manufacturer could easily tell us about the interface for their EC code.
The interfaces themselves and the meanings are mostly described by ACPI. There's an interesting thread on a while back lmkl about data sent to port 80 actually being commands to the EC.
But for the parts that are not if I tell you command 0xAA is a private command and it toggles Port A IO bit n which controls xyx I may be telling you information that only lives in a schematic covered by an NDA. Its tricky. The legal clearance to release that info my fall back onto who owns the design IP rather than who the mfg is and could be hard to get. Doesn't hurt to ask though.
I agree with Jordan however that coreboot may not even need to interact with the EC at all. Just taking the stock stuff and embedding it in your image at the right place might Just Work for the things coreboot needs. The rest is all OS issues.
Do any of those netbooks previously ship with Linux?
On Sat, Dec 13, 2008 at 9:38 PM, Richard Smith smithbone@gmail.com wrote:
Carl-Daniel Hailfinger wrote:
There's also the interesting question about who owns the EC firmware. If the manufacturer owns it and has full rights for it, the situation is different compared to the BIOS. For example, Quanta (OLPC manufacturer) holds some (if not all) rights to the OLPC XO EC code and not BIOS vendor was involved.
The bulk of the Copyright is by EnE. There are a handful of files that are Quanta only. I would not expect many of these in a mainstream implementation as they deal with some of the extra stuff we did at OLPC. Quanta has mentioned to me many times that they don't do anywhere near that level of work for a normal laptop.
EnE provides a framework and the OEM fills in the blanks.
From what I have heard, I think the VIA processors are
the best bet right now for experimentation. Intel of course, is out, and AMD processors aren't in any netbooks to speak of - and I'm sure if we go to this effort, we would rather have it pay off for a netbook rather then a dinosaur laptop.
If I'm right about EC code copyrights and usage rights, a cooperating manufacturer could easily tell us about the interface for their EC code.
The interfaces themselves and the meanings are mostly described by ACPI. There's an interesting thread on a while back lmkl about data sent to port 80 actually being commands to the EC.
But for the parts that are not if I tell you command 0xAA is a private command and it toggles Port A IO bit n which controls xyx I may be telling you information that only lives in a schematic covered by an NDA. Its tricky. The legal clearance to release that info my fall back onto who owns the design IP rather than who the mfg is and could be hard to get. Doesn't hurt to ask though.
I agree with Jordan however that coreboot may not even need to interact with the EC at all. Just taking the stock stuff and embedding it in your image at the right place might Just Work for the things coreboot needs. The rest is all OS issues.
Do any of those netbooks previously ship with Linux?
Yes, the Sylvania G netbook ( http://www.compusa.com/applications/SearchTools/item-details.asp?EdpNo=37470...) and Everex Cloudbook ( http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=4...) both ship with gOS and sell for <$300.
-Corey
Richard Smith wrote:
Do any of those netbooks previously ship with Linux?
Several vx800 Quanta IL1 netbooks do ship with Linux:
* One Mini A110/A115/A140 http://www.one.de/shop/one-notebooks-one-mini-notebooks-c-213_214.html
* Norhtec Gecko http://www.norhtec.com/products/gecko/index.html
* ACi Ethos 7 http://www.aci-asia.com/html/Ethos_7.html
* BDSI Deep Blue H1 http://www.ilikeblue.net/products/umpc.htm
-Bari
bari wrote:
Do any of those netbooks previously ship with Linux?
Several vx800 Quanta IL1 netbooks do ship with Linux:
* One Mini A110/A115/A140http://www.one.de/shop/one-notebooks-one-mini-notebooks-c-213_214.html
* Norhtec Geckohttp://www.norhtec.com/products/gecko/index.html
* ACi Ethos 7http://www.aci-asia.com/html/Ethos_7.html
* BDSI Deep Blue H1
My suggestion for one to start with then is any one of these machines that use an EnE EC. (if any) If they ship Linux then I would assume that all the necessary communication between Linux and the EC is working. So inclusion of the factory EC code should Just Work. If you do end up needed to did deeper and you can't get any info from the manufacturer then EnE is your best bet for reverse engineering.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
do end up needed to did deeper and you can't get any info from the manufacturer then EnE is your best bet for reverse engineering.
I have taken a BIOS from Mini A110 (q1d25i.rom). The Quanta IL1 reference design seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code is on 0xFFF00000 length is 64KB. The file is called HOLE0.ROM inside BIOS.
The ENE KB3310 seems to be similar to ENE KB3920, which datasheet I found via google.
I have taken IDA and did the LST file. It has 8051 inside. Yesterday I spoke with Bari and got the s51 emulator from (SVN: https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk).
I fixed the serial port issue, and now the firmware runs inside emulator:
Serial output: 00, ec[ECFV]==80ac wake@z,ACOut Zttttttttttttttttttttttttttt
It prints 't' every second or so.
It seems that a flash can be flashed even unsoldered via serial interface of EC. (some other pins must be pulled low)
http://laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf
Here is a EC schematics from reference design. http://laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf
Rudolf
On Sun, Jan 4, 2009 at 6:36 AM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
do end up needed to did deeper and you can't get any info from the manufacturer then EnE is your best bet for reverse engineering.
I have taken a BIOS from Mini A110 (q1d25i.rom). The Quanta IL1 reference design seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code is on 0xFFF00000 length is 64KB. The file is called HOLE0.ROM inside BIOS.
The ENE KB3310 seems to be similar to ENE KB3920, which datasheet I found via google.
I have taken IDA and did the LST file. It has 8051 inside. Yesterday I spoke with Bari and got the s51 emulator from (SVN: https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk).
I fixed the serial port issue, and now the firmware runs inside emulator:
Serial output: 00, ec[ECFV]==80ac wake@z,ACOut Zttttttttttttttttttttttttttt
It prints 't' every second or so.
It seems that a flash can be flashed even unsoldered via serial interface of EC. (some other pins must be pulled low)
http://laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf
Here is a EC schematics from reference design. http://laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf
Those links are dead, any chance you know where they've moved to?
Thanks, Corey
On 08.01.2009 23:07, Corey Osgood wrote:
On Sun, Jan 4, 2009 at 6:36 AM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
do end up needed to did deeper and you can't get any info from the manufacturer then EnE is your best bet for reverse engineering.
I have taken a BIOS from Mini A110 (q1d25i.rom). The Quanta IL1 reference design seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code is on 0xFFF00000 length is 64KB. The file is called HOLE0.ROM inside BIOS.
The ENE KB3310 seems to be similar to ENE KB3920, which datasheet I found via google.
I have taken IDA and did the LST file. It has 8051 inside. Yesterday I spoke with Bari and got the s51 emulator from (SVN: https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk).
I fixed the serial port issue, and now the firmware runs inside emulator:
Serial output: 00, ec[ECFV]==80ac wake@z,ACOut Zttttttttttttttttttttttttttt
It prints 't' every second or so.
It seems that a flash can be flashed even unsoldered via serial interface of EC. (some other pins must be pulled low)
http://laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf
Here is a EC schematics from reference design. http://laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf
Those links are dead, any chance you know where they've moved to?
The whole team wiki seems to be dead. The google cache is somewhat helpful: http://209.85.129.132/search?q=cache:3Rz-90dw9JUJ:www.laptop.org/teamwiki/im... http://209.85.129.132/search?q=cache:bSz5-sskn5QJ:laptop.org/teamwiki/images... Get them while the google cache is still hot.
Regards, Carl-Daniel
On Sat, Dec 13, 2008 at 8:14 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
But don't be confused as to what the "EC problem" really is.
The EC issue is another case where we need vendor buy-in or we're going to have trouble getting the job done (absent significant reverse engineering work).
I'd much rather go via the vendor buy-in path.
ron
-
bari -
Carl-Daniel Hailfinger -
Corey Osgood -
Jordan Crouse -
Richard Smith -
ron minnich -
Rudolf Marek