Geode LX/CS5536 VSA has been updated. The source and binary are attached. With this release we have changed how the binary is packaged. Previously it was posted alread compressed with nrv2b and padded to size. Going forward it is GZipd and will need to be compressed and padded by hand or by buildrom. Instructions available here: http://www.coreboot.org/AMD_Geode_Porting_Guide The following changes were made: Remove int15 callbacks removed. CPU and memory are calculated by VSA. VSA no longer takes all the MFGPTs. Two are now available for OS use. The VSA binary is always available here: http://www.amd.com/files/connectivitysolutions/geode/geode_lx/amd_vsa_lx_1.0... buildrom and v2 patches to follow. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors
Hi Marc, On 31.01.2008 18:04, Marc Jones wrote:
Geode LX/CS5536 VSA has been updated. The source and binary are attached. With this release we have changed how the binary is packaged. Previously it was posted alread compressed with nrv2b and padded to size. Going forward it is GZipd and will need to be compressed and padded by hand or by buildrom.
The following changes were made: Remove int15 callbacks removed. CPU and memory are calculated by VSA. VSA no longer takes all the MFGPTs. Two are now available for OS use.
Thank you very much for updating the VSA! Especially the int 15 callback removal reduces interaction complexity quite a bit. Are there any remaining BIOSINT callbacks in the new VSA or can we remove BIOSINT emulation altogether from the Coreboot VSA handler? Regards, Carl-Daniel
Marc Jones wrote:
The following changes were made: Remove int15 callbacks removed. CPU and memory are calculated by VSA. VSA no longer takes all the MFGPTs. Two are now available for OS use.
I have "ported" the previous VSA sources from the OLPC git tree, so that it builds under GNU tools. It is completely untested, but I plan to start testing it any time now. It has never been released. I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources? 2. the idea of permanently moving to a GNU-buildable version? 3. anyone interesting in helping to test the "port"? I also want to patch my "port" based on the newer sources you provided Marc. In looking at the diff's against the OLPC git, I see there are about 42 files with mostly-minor code changes, about 26 files removed. It should be easy to handle the patching, so I am inclined to do that before releasing and testing. One thing I'm wondering about: there are about 65 files that have no changes except the copyright notice was updated to 2008. Was that intended? Chris.
Hi Chris! First of all, welcome on board! On 01.02.2008 21:12, Chris Kilgour wrote:
Marc Jones wrote:
The following changes were made: Remove int15 callbacks removed. CPU and memory are calculated by VSA. VSA no longer takes all the MFGPTs. Two are now available for OS use.
I have "ported" the previous VSA sources from the OLPC git tree, so that it builds under GNU tools. It is completely untested, but I plan to start testing it any time now. It has never been released.
Great, thanks!
I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources?
Probably yes. The laptop.org GIT tree only has 2 revisions. Such an amount of change could easily be handled with subversion and coreboot.org surely could handle that. The final decision is made by Stefan, though.
2. the idea of permanently moving to a GNU-buildable version?
It would certainly make outside contributions easier.
3. anyone interesting in helping to test the "port"?
I'm pretty sure AMD is interested, although those people working on Geode targets for coreboot will want to test as well. The ability to tailor the VSA to do exactly the things we need and skip the rest is a really exciting prospect.
I also want to patch my "port" based on the newer sources you provided Marc. In looking at the diff's against the OLPC git, I see there are about 42 files with mostly-minor code changes, about 26 files removed. It should be easy to handle the patching, so I am inclined to do that before releasing and testing.
Please do. Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources?
Probably yes. The laptop.org GIT tree only has 2 revisions. Such an amount of change could easily be handled with subversion and coreboot.org surely could handle that. The final decision is made by Stefan, though.
Yes, we can add a seperate repository for that. Or even check it into the coreboot tree? Would that make sense? Whatever is preferred by you guys.
2. the idea of permanently moving to a GNU-buildable version?
It would certainly make outside contributions easier.
Yes, no need for MASM to build the whole thing is a great step forward. Congratulations! Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources?
Probably yes. The laptop.org GIT tree only has 2 revisions. Such an amount of change could easily be handled with subversion and coreboot.org surely could handle that. The final decision is made by Stefan, though.
Yes, we can add a seperate repository for that. Or even check it into the coreboot tree? Would that make sense? Whatever is preferred by you guys.
I think a separate repository would be better.
2. the idea of permanently moving to a GNU-buildable version?
It would certainly make outside contributions easier.
Yes, no need for MASM to build the whole thing is a great step forward. Congratulations!
If you would like to understand the architecture the VSA developers guide is helpful. http://www.amd.com/files/connectivitysolutions/geode/geode_gx/32664B_gx_vsa2... Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors
On 04.02.2008 17:28, Marc Jones wrote:
Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources?
Probably yes. The laptop.org GIT tree only has 2 revisions. Such an amount of change could easily be handled with subversion and coreboot.org surely could handle that. The final decision is made by Stefan, though.
Yes, we can add a seperate repository for that. Or even check it into the coreboot tree? Would that make sense? Whatever is preferred by you guys.
I think a separate repository would be better.
Fully agreed. There is one problem, though. We may run out of paths on the server side if we invent another base path for a repo. But I'm pretty sure Stefan can tell us about the general organization of different repos hosted at coreboot.org, so we may figure out something reasonable. Regards, Carl-Daniel
I have completed adopting the latest VSA update published at the start of this thread to my GNU-buildable VSA version. I placed a tarball of the sources at http://www.whiterocker.com/openvsa/openvsa_20080207.tar.gz Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk! I intend to keep publishing these tarballs until the coreboot.org SVN gets seeded. If anyone has another (better?) name besides 'openvsa' please proffer. Chris.
Hi Chris, this is really great work! Thanks! On 08.02.2008 09:09, Chris Kilgour wrote:
I have completed adopting the latest VSA update published at the start of this thread to my GNU-buildable VSA version. I placed a tarball of the sources at http://www.whiterocker.com/openvsa/openvsa_20080207.tar.gz
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I will try to take a look ASAP. The optimal case would be that the original and modified sources compile to an identical binary or at least a binary with perfectly explainable differences.
I intend to keep publishing these tarballs until the coreboot.org SVN gets seeded.
Thanks. I hope we can import them into coreboot svn before Monday.
If anyone has another (better?) name besides 'openvsa' please proffer.
Hm. I wonder whether we want to change the name at all since the code is formally (except toolchain adaptation) the same. Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I will try to take a look ASAP. The optimal case would be that the original and modified sources compile to an identical binary or at least a binary with perfectly explainable differences.
The VSA sources are a mix of assembly and C code. The binaries will be quite different because (naturally) gcc will produce different machine code than Microsoft C from the 16-bit era, and all the assembly-coded functions are now using GNU __attribute__((fastcall)) rather than "MS pascal" calling convention. Also, the final link output will have the various bits and pieces in different locations. So a straight binary diff will exhibit mostly differences. That said, I took the time of locating and disassembling the assembly functions from OLPC VSA blob and comparing against the output of the assembly functions from my build (by far the biggest risk because of all the manual modifications I made), and the differences were all explainable in light of the above. For the C code I felt it was way too hard to even attempt such an approach. Within the tarball there is a file modification_notes.txt that highlights what I have done. I'm hoping to foster some discussion on a testing approach that lays somewhere between manual inspection and slapping the open-tools blob into a coreboot ROM and crossing our fingers... Chris.
On 08.02.2008 17:21, Chris Kilgour wrote:
Carl-Daniel Hailfinger wrote:
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I will try to take a look ASAP. The optimal case would be that the original and modified sources compile to an identical binary or at least a binary with perfectly explainable differences.
The VSA sources are a mix of assembly and C code. The binaries will be quite different because (naturally) gcc will produce different machine code than Microsoft C from the 16-bit era, and all the assembly-coded functions are now using GNU __attribute__((fastcall)) rather than "MS pascal" calling convention. Also, the final link output will have the various bits and pieces in different locations. So a straight binary diff will exhibit mostly differences.
Understood.
That said, I took the time of locating and disassembling the assembly functions from OLPC VSA blob and comparing against the output of the assembly functions from my build (by far the biggest risk because of all the manual modifications I made), and the differences were all explainable in light of the above. For the C code I felt it was way too hard to even attempt such an approach.
Thanks for investing the time to verify the differences.
Within the tarball there is a file modification_notes.txt that highlights what I have done. I'm hoping to foster some discussion on a testing approach that lays somewhere between manual inspection and slapping the open-tools blob into a coreboot ROM and crossing our fingers...
I fear that for most of us the only way to test is to burn the generated VSA into a ROM and start the machine. However, I have to admit I didn't read the modification notes you supplied. I will read it. Regards, Carl-Daniel
On Feb 8, 2008 3:05 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
Within the tarball there is a file modification_notes.txt that highlights what I have done. I'm hoping to foster some discussion on a testing approach that lays somewhere between manual inspection and slapping the open-tools blob into a coreboot ROM and crossing our fingers...
I fear that for most of us the only way to test is to burn the generated VSA into a ROM and start the machine. However, I have to admit I didn't read the modification notes you supplied. I will read it.
Maybe AMD has some sort of test battery that they run against the old VSA, that someone could do on this one. :)
On 08/02/08 00:09 -0800, Chris Kilgour wrote:
I have completed adopting the latest VSA update published at the start of this thread to my GNU-buildable VSA version. I placed a tarball of the sources at http://www.whiterocker.com/openvsa/openvsa_20080207.tar.gz
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I intend to keep publishing these tarballs until the coreboot.org SVN gets seeded.
lets get this seeded then. Stefan, wield your +5 mace of SVN admin, please.
If anyone has another (better?) name besides 'openvsa' please proffer.
I would say gnuvsa, but that might not be appropriate for our FSF friends. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
Jordan Crouse wrote:
On 08/02/08 00:09 -0800, Chris Kilgour wrote:
I have completed adopting the latest VSA update published at the start of this thread to my GNU-buildable VSA version. I placed a tarball of the sources at http://www.whiterocker.com/openvsa/openvsa_20080207.tar.gz
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I intend to keep publishing these tarballs until the coreboot.org SVN gets seeded.
lets get this seeded then. Stefan, wield your +5 mace of SVN admin, please.
The mail erupts in a tower of flame! You smell a new repository nearby: svn co svn://coreboot.org/openvsa/trunk/openvsa Marc, Chris and you have write access to it. If anyone else needs write access there, please let me know. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
On 08.02.2008 18:53, Stefan Reinauer wrote:
Jordan Crouse wrote:
On 08/02/08 00:09 -0800, Chris Kilgour wrote:
I have completed adopting the latest VSA update published at the start of this thread to my GNU-buildable VSA version. I placed a tarball of the sources at http://www.whiterocker.com/openvsa/openvsa_20080207.tar.gz
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I intend to keep publishing these tarballs until the coreboot.org SVN gets seeded.
lets get this seeded then. Stefan, wield your +5 mace of SVN admin, please.
The mail erupts in a tower of flame! You smell a new repository nearby:
svn co svn://coreboot.org/openvsa/trunk/openvsa
Great, thanks! Regards, Carl-Daniel
On 08.02.2008 17:13, Jordan Crouse wrote:
On 08/02/08 00:09 -0800, Chris Kilgour wrote:
I have completed adopting the latest VSA update published at the start of this thread to my GNU-buildable VSA version. I placed a tarball of the sources at http://www.whiterocker.com/openvsa/openvsa_20080207.tar.gz
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I intend to keep publishing these tarballs until the coreboot.org SVN gets seeded.
lets get this seeded then. Stefan, wield your +5 mace of SVN admin, please.
If anyone has another (better?) name besides 'openvsa' please proffer.
I would say gnuvsa, but that might not be appropriate for our FSF friends.
Please don't call it gnuvsa. Either we don't change the name at all or we pick something less offensive than gnuvsa. OpenVSA (with whatever capitalization) would be fine for me. Then again, the VSA code is already open, no need to imply the version with Intel asm syntax is non-free. Regards, Carl-Daniel
On 01/02/08 21:22 +0100, Carl-Daniel Hailfinger wrote:
Hi Chris!
First of all, welcome on board!
On 01.02.2008 21:12, Chris Kilgour wrote:
Marc Jones wrote:
The following changes were made: Remove int15 callbacks removed. CPU and memory are calculated by VSA. VSA no longer takes all the MFGPTs. Two are now available for OS use.
I have "ported" the previous VSA sources from the OLPC git tree, so that it builds under GNU tools. It is completely untested, but I plan to start testing it any time now. It has never been released.
Great, thanks!
I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources?
Probably yes. The laptop.org GIT tree only has 2 revisions. Such an amount of change could easily be handled with subversion and coreboot.org surely could handle that. The final decision is made by Stefan, though.
The history on the GIT tree is really not interesting - it just shows when I pushed the original VSA code and the LX update.
2. the idea of permanently moving to a GNU-buildable version?
It would certainly make outside contributions easier.
Yes - that would be best. THe original code is nice for debugging behavior in the VSA blob, but really only serves a documentation / historical purpose. If anything, we can toss the original tarball for archival purposes.
3. anyone interesting in helping to test the "port"?
I'm pretty sure AMD is interested, although those people working on Geode targets for coreboot will want to test as well. The ability to tailor the VSA to do exactly the things we need and skip the rest is a really exciting prospect.
Absolutely, I'm interested. Also, we will want to teach buildrom to build the GNUified VSA. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
Hi Chris, Chris Kilgour wrote:
Marc Jones wrote:
The following changes were made: Remove int15 callbacks removed. CPU and memory are calculated by VSA. VSA no longer takes all the MFGPTs. Two are now available for OS use.
I have "ported" the previous VSA sources from the OLPC git tree, so that it builds under GNU tools. It is completely untested, but I plan to start testing it any time now. It has never been released.
This is great. We had hoped that someone in the community would do this.
I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources?
I think that makes sense since coreboot is the project that VSA is most closely associated with.
2. the idea of permanently moving to a GNU-buildable version? Yes! We would love to have more people working on this code and making it better. I am sure the size can be reduced even more. This would help it fit into the rom and take up less system memory. Both would be great helps to embedded LX designs.
3. anyone interesting in helping to test the "port"?
I think we should be able to get a few people to test the port, myself included.
I also want to patch my "port" based on the newer sources you provided Marc. In looking at the diff's against the OLPC git, I see there are about 42 files with mostly-minor code changes, about 26 files removed. It should be easy to handle the patching, so I am inclined to do that before releasing and testing.
That would be fine. We will check these changes into the OLPC git tree when Jordan gets back next week (or so).
One thing I'm wondering about: there are about 65 files that have no changes except the copyright notice was updated to 2008. Was that intended?
Due to laziness on my part, yes. Jordan and I were going to discuss if that really went into the git tree. Thanks for stepping up and starting this effort. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors
participants (7)
-
Carl-Daniel Hailfinger -
Chris Kilgour -
Jordan Crouse -
Marc Jones -
Marc Jones
-
Stefan Reinauer -
Tom Sylla