Today in a meeting with Via OLPC received go ahead to begin to release the code for vx855 NorthSouth support in coreboot. We also are clear to push up OpenFirmware support.
OFW will go out when Mitch decides he's happy with what he has. Could be today might be sometime next week.
The code OLPC has for coreboot-v2 needs some work before its going to be acceptable for coreboot upstream.
TAKE NOTE!!!
This is NOT an official Via release. Via has not fully qualified things yet and does not want it to be seen as officially supported in any way. This is a release from OLPC and we are responsible for any ommisions, bugs, etc.
The documentation is also not yet available publicly and won't be for a while. It is coming though.
Via recognizes that OLPC is capable of managing code on our own and does not want to slow us down by having to wait for the official release. Kudos to Via. They have been a pleasure to work with so far.
To err on the safe side I also don't want to just push up the tarball of the code I have. Its a snapshot of a development tree. Supposed to be clean but I've not yet given it a thorough look. There's lots of stuff in there thats #if 0 that looks like it needs to be deleted.
So for now I'd like to only submit it to people who are already under NDA with Via.
I've ported it up to the latest V2 but I don't yet have cbfs working on it nor does make full use of some of the new enhancements recently added.
Unfortunately, I'm running out of time to work on coreboot. My duties of working on the OLPC EC code will soon consume me. I'm also about to lose the spare board I have with a vx855 on it (its going off to another developer). I'll have to mux in any coreboot testing on the hardware with what the 1 board OLPC will have left. Further limiting my time will be that when OFW reaches a point where its a full replacement for the COTS bios provided I'll have little reason to use coreboot for anything.
Since only engineering samples of this chipset exist right thats not a big deal. But soon (RSN) there will be hardware available. An official OLPC announcement of what we are up to is in the pipeline. It will hit the wire as soon as the wordsmiths are happy.
So I'm looking for a few developers (just as a precaution) who are under NDA with Via and want to start helping with integrating this code into upstream.
Once some other eyballs have looked at it and we have cleaned it up a bit then we can push up the patch for the general public.
Its possible that this will also work on the vx800 as they are very similar. Again, not supported, might kick your dog, etc...
When vx855 hardware becomes available I'll make sure at least one coreboot person gets a board.
I also have a question on the fitness level for V3. Is it worth it to port the code to V3 and try to use that as the primary development path?
On Wed, Apr 15, 2009 at 3:35 PM, Richard Smith smithbone@gmail.com wrote:
I also have a question on the fitness level for V3. Is it worth it to port the code to V3 and try to use that as the primary development path?
I think it's ok to stick with v2.
ron
On Wed, Apr 15, 2009 at 6:56 PM, ron minnich rminnich@gmail.com wrote:
On Wed, Apr 15, 2009 at 3:35 PM, Richard Smith smithbone@gmail.com wrote:
I also have a question on the fitness level for V3. Is it worth it to
port
the code to V3 and try to use that as the primary development path?
I think it's ok to stick with v2.
Any idea what ever happened with Via's vx800 port?
Thanks, Corey
Corey Osgood wrote:
Any idea what ever happened with Via's vx800 port?
From looking at the code I suspect that the code bases are very similar.
I know it boots and runs on the vx855 and I'm sure there will be differences so for now I have to assume that there are vx855 specific bits in this code.
Someone with a vx800 would have to test and see.
Richard Smith wrote:
Corey Osgood wrote:
Any idea what ever happened with Via's vx800 port?
From looking at the code I suspect that the code bases are very similar.
I know it boots and runs on the vx855 and I'm sure there will be differences so for now I have to assume that there are vx855 specific bits in this code.
Someone with a vx800 would have to test and see.
The vx855 and vx800 are very similar. Jason worked on the vx800 first and then later on the vx855 using his earlier work. We lost contact after the patch got tied up in red tape at VIA.
-Bari
Hello,
So I'm looking for a few developers (just as a precaution) who are under NDA with Via and want to start helping with integrating this code into upstream.
Well perhaps thats me. I have a VIA NDA with them. Ask Bruce Chang for details. I think I can find some time for this. I just don't want to loose that code.
When vx855 hardware becomes available I'll make sure at least one coreboot person gets a board.
Yes that would be nice!
Rudolf
Rudolf Marek wrote:
So I'm looking for a few developers (just as a precaution) who are under NDA with Via and want to start helping with integrating this code into upstream.
Well perhaps thats me. I have a VIA NDA with them. Ask Bruce Chang for details.
I trust you. Its really just caution. If for some reason there is still non-public code in the tree and we find it then there is no harm since only NDA people are looking at it. We just cut it and go on. Just trying to respect Via's willingness to let us release whats essentially a tarball snapshot of Jason's tree.
I think I can find some time for this. I just don't want to loose that code.
Ok Stefan is also working on this. He's going to set up a private repo for us to work against. Keeping code in the private tree should not take too long depending on how deep you want to get in to reworking the things.
They seem to have implemented a whole slew of custom Via ways of doing config space writes. I think those all need to be unified. Not sure if you want that done before or after the public push.
One thing is that we can't release it as a Via board. Currently there is a new Via board called the 6413e which is the engineering board. We have to change that to be OLPC/Gen_1.5A so that it appears this is for the OLPC board and not an official Via release. Via just wants it to be clear that this is a customer release and not a Via release.
The gen 1.5 Atest board will for the most part be the same as the 6413e but its Got EC code tacked on the front. ATest1 is going to have a SPD on board so that its easier for quanta to use COTS bios when testing. Atest2 boards probably won't have spd and will need to choose from a few fixed tables based on some gpios. Depending on how Atest goes we might delay the spd removal until BTest.
Richard Smith wrote:
Rudolf Marek wrote:
So I'm looking for a few developers (just as a precaution) who are under NDA with Via and want to start helping with integrating this code into upstream.
I'd be happy to take a look. I've been waiting to see which EC the Samsung cn20 uses with Nano+vx800.
If for some reason there is still non-public code in the tree and we find it then there is no harm since only NDA people are looking at it. We just cut it and go on. Just trying to respect Via's willingness to let us release whats essentially a tarball snapshot of Jason's tree.
Not a problem.
Ok Stefan is also working on this. He's going to set up a private repo for us to work against. Keeping code in the private tree should not take too long depending on how deep you want to get in to reworking the things.
They seem to have implemented a whole slew of custom Via ways of doing config space writes. I think those all need to be unified. Not sure if you want that done before or after the public push.
One thing is that we can't release it as a Via board. Currently there is a new Via board called the 6413e which is the engineering board. We have to change that to be OLPC/Gen_1.5A so that it appears this is for the OLPC board and not an official Via release. Via just wants it to be clear that this is a customer release and not a Via release.
The gen 1.5 Atest board will for the most part be the same as the 6413e but its Got EC code tacked on the front. ATest1 is going to have a SPD on board so that its easier for quanta to use COTS bios when testing. Atest2 boards probably won't have spd and will need to choose from a few fixed tables based on some gpios. Depending on how Atest goes we might delay the spd removal until BTest.
I'm waiting for the vx855 netbooks to hit the shelves, preferably with a Renasas EC. Can you tell us which EC the gen 1.5 is going to use? ENE or?
-Bari
Hi Richard,
Richard Smith schrieb:
Unfortunately, I'm running out of time to work on coreboot. My duties of working on the OLPC EC code will soon consume me.
Is the next OLPC embedded controller based on/close to an ENE controller? And if so would it make sense to reanimate the OpenEC project? ( http://wiki.laptop.org/go/OpenEC )
Greetings, Frieder
Hi,
Richard Smith wrote:
This is a release from OLPC and we are responsible for any ommisions, bugs, etc.
Yes indeed! The other contributors are also responsible for their coreboot support that exists for older VIA hardware.
Kudos to Via. They have been a pleasure to work with so far.
I am glad to hear that!
I also have a question on the fitness level for V3. Is it worth it to port the code to V3 and try to use that as the primary development path?
V3 is still in the design test phase.
The design is proven on Geode, but not on anything else.
VIA hardware seems to be less special than the Geode so I don't think it would be a lot of work to get it running on v3.
Nothing in v3 is anywhere close to being polished though. It is in a bit of disarray with some targets not building, not very optimal dependencies, and so on.
I want to continue the design testing, on something else than Geode.
(I would also like to really clean up the Geode stuff. That SPD parsing matter remains, but I think that's just one of many things to look at.)
Corey has been doing great work with C7 so far.
I also think there are some things that we wanted to put into v3 which aren't even started.
On the flip side there are all the things in v3 that have been started and work well. I think they are great improvements, and they are there now. They may make their way into v2 as well, but that will take more time.
I would love it if you did go to v3, but my honest opinion is that it is not very fit at the moment.
Design testing has to finish at whatever pace it needs. If on any kind of project deadline, testing the v3 design probably isn't the best way to spend your time.
Yes, it may take a while to get v3 out of design testing. Yes, money would make it happen sooner.
//Peter
-
bari -
Corey Osgood -
Frieder Ferlemann -
Peter Stuge -
Richard Smith -
ron minnich -
Rudolf Marek