attached
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
Why is nrv2b needed specifically for geodelx? The VSA blob? Should that not use the same compression as the payload, if the user chooses one?
//Peter
On Jan 25, 2008 9:29 AM, Peter Stuge peter@stuge.se wrote:
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
Why is nrv2b needed specifically for geodelx? The VSA blob? Should that not use the same compression as the payload, if the user chooses one?
The VSA is distributed as nrv compressed. We can use/not use the compression, but I just figured i would keep it simple and use it.
But we don't have to. Comments welcome.
The intermediate files are my mistake, I thought I was modeling the mainboard tree, but maybe not.
Thanks for the corrections.
ron
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of ron minnich Sent: Friday, January 25, 2008 10:52 AM To: Coreboot Subject: Re: [coreboot] patch: add Kconfig support for v3 north
On Jan 25, 2008 9:29 AM, Peter Stuge peter@stuge.se wrote:
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
Why is nrv2b needed specifically for geodelx? The VSA blob? Should that not use the same compression as the payload, if the user chooses one?
The VSA is distributed as nrv compressed. We can use/not use the compression, but I just figured i would keep it simple and use it.
I like the idea of the binary blobs being compressed with whatever the user selects. It seems simpler for whoever gets the binary blob to decode it at the same time.
Myles
Actually, I did model the mainboard tree with the northbridge Kconfig tree.
If you all can help decide on this nrv2b issue, that would help me a lot.
Thanks
ron
* ron minnich rminnich@gmail.com [080125 19:06]:
Actually, I did model the mainboard tree with the northbridge Kconfig tree.
If you all can help decide on this nrv2b issue, that would help me a lot.
The simplest approach seems to me is to put the _uncompressed_ version of the vsa into the optionroms repository and get it from there. Then use the same mechanism that compresses all the other files in the lar. That seems pretty straight forward. Are you saying the above would not work for some reason?
On Jan 25, 2008 1:06 PM, Stefan Reinauer stepan@coresystems.de wrote:
- ron minnich rminnich@gmail.com [080125 19:06]:
Actually, I did model the mainboard tree with the northbridge Kconfig tree.
If you all can help decide on this nrv2b issue, that would help me a lot.
The simplest approach seems to me is to put the _uncompressed_ version of the vsa into the optionroms repository and get it from there. Then use the same mechanism that compresses all the other files in the lar. That seems pretty straight forward. Are you saying the above would not work for some reason?
That's the right move.
I'm just being thick-headed :-)
ron
Peter Stuge wrote:
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
Why is nrv2b needed specifically for geodelx? The VSA blob? Should that not use the same compression as the payload, if the user chooses one?
//Peter
At the time it seemed like the right way to handle the VSA binary distribution. We posted a binary blob that would just work when cat'd on to a Geode platform ROM. It was a painful to do by hand...
With the acceptance of buildrom and the new build configuration in v3, it seems as though we should change. The user/buildtool will have to handle the compression and padding to the correct size (don't need padding in v3 w/lar).
I am going to make an new VSA release soon so this would be a good time to make this change.
Thoughts?
Marc
On Jan 25, 2008 10:08 AM, Marc Jones marc.jones@amd.com wrote:
I am going to make an new VSA release soon so this would be a good time to make this change.
Thoughts?
Yes. Let's go ahead and make the change to uncompressed VSA. I will probably delete my Kconfig patch.
Thanks!
ron
On 25/01/08 11:08 -0700, Marc Jones wrote:
Peter Stuge wrote:
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
Why is nrv2b needed specifically for geodelx? The VSA blob? Should that not use the same compression as the payload, if the user chooses one?
//Peter
At the time it seemed like the right way to handle the VSA binary distribution. We posted a binary blob that would just work when cat'd on to a Geode platform ROM. It was a painful to do by hand...
With the acceptance of buildrom and the new build configuration in v3, it seems as though we should change. The user/buildtool will have to handle the compression and padding to the correct size (don't need padding in v3 w/lar).
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
Jordan
On Jan 25, 2008 10:15 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
We need a VSA.v3 and leave the old one as before. VSA.v3 is just the uncompressed VSA.
ron
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
We need a VSA.v3 and leave the old one as before. VSA.v3 is just the uncompressed VSA.
Fully agreed. Maybe pick another name (VSA.uncompressed or VSA.corebootv3.uncompressed), but let's simply add another download option, this time suited for v3. IIRC the VSA for v3 may also use some v3 infrastructure and be incompatible to v2 by definition.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
We need a VSA.v3 and leave the old one as before. VSA.v3 is just the uncompressed VSA.
Fully agreed. Maybe pick another name (VSA.uncompressed or VSA.corebootv3.uncompressed), but let's simply add another download option, this time suited for v3. IIRC the VSA for v3 may also use some v3 infrastructure and be incompatible to v2 by definition.
Regards, Carl-Daniel
I disagree. We will have an uncompressed solution that will work for both v2 and v3. VSA does simple hardware emulation so it should work for both. We are working out the details for buildrom now. I will also write down how to do it by hand on the wiki.
Marc
On 28.01.2008 21:55, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
We need a VSA.v3 and leave the old one as before. VSA.v3 is just the uncompressed VSA.
Fully agreed. Maybe pick another name (VSA.uncompressed or VSA.corebootv3.uncompressed), but let's simply add another download option, this time suited for v3. IIRC the VSA for v3 may also use some v3 infrastructure and be incompatible to v2 by definition.
I disagree. We will have an uncompressed solution that will work for both v2 and v3. VSA does simple hardware emulation so it should work for both. We are working out the details for buildrom now. I will also write down how to do it by hand on the wiki.
I was under the impression that VSA in v3 was using x86emu for BIOS INT services and using separate INT routines in v2. That's what led me to the conclusion about different VSAs for v2 and v3.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 28.01.2008 21:55, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
We need a VSA.v3 and leave the old one as before. VSA.v3 is just the uncompressed VSA.
Fully agreed. Maybe pick another name (VSA.uncompressed or VSA.corebootv3.uncompressed), but let's simply add another download option, this time suited for v3. IIRC the VSA for v3 may also use some v3 infrastructure and be incompatible to v2 by definition.
I disagree. We will have an uncompressed solution that will work for both v2 and v3. VSA does simple hardware emulation so it should work for both. We are working out the details for buildrom now. I will also write down how to do it by hand on the wiki.
I was under the impression that VSA in v3 was using x86emu for BIOS INT services and using separate INT routines in v2. That's what led me to the conclusion about different VSAs for v2 and v3.
VSA having int15 calls was bad. It made sense for a normal BIOS but not for coreboot. VSA can just as easily calculate what it was asking for. I am correcting that for this next release (real soon now). v2 patches also coming. Marc
Jordan Crouse wrote:
On 25/01/08 11:08 -0700, Marc Jones wrote:
Peter Stuge wrote:
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
Why is nrv2b needed specifically for geodelx? The VSA blob? Should that not use the same compression as the payload, if the user chooses one?
//Peter
At the time it seemed like the right way to handle the VSA binary distribution. We posted a binary blob that would just work when cat'd on to a Geode platform ROM. It was a painful to do by hand...
With the acceptance of buildrom and the new build configuration in v3, it seems as though we should change. The user/buildtool will have to handle the compression and padding to the correct size (don't need padding in v3 w/lar).
Hmm - probably the right move, but the changes in buildrom are not trivial for v2. We would need to figure out what the ROM size is (by greping Config.lb, probably), compress the VSA, calculate the difference and pad. Its not impossible, but there is lots that can go wrong if we are not careful.
Jordan
We can probably get away with hard coding the pad size since the binary won't change. It should still come out to 36K. I don't think you really need to figure the ROM size. The config.lb for geodes will still have to account the same way the do now.
Marc
On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
attached
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
This has been tested in build and behaves as we want it to: nrv decompression is enabled and the code compiled in.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
Breaks for me.
$ make menuconfig CHECK build/dochecklxdialog HOSTCC build/util/kconfig/lxdialog/checklist.o HOSTCC build/util/kconfig/lxdialog/menubox.o HOSTCC build/util/kconfig/lxdialog/textbox.o HOSTCC build/util/kconfig/lxdialog/yesno.o HOSTCC build/util/kconfig/lxdialog/inputbox.o HOSTCC build/util/kconfig/lxdialog/util.o HOSTCC build/util/kconfig/lxdialog/lxdialog.o HOSTCC build/util/kconfig/lxdialog/msgbox.o HOSTCC build/util/kconfig/lxdialog/lxdialog HOSTCC build/util/kconfig/mconf.o HOSTCC build/util/kconfig/zconf.tab.o HOSTCC build/util/kconfig/mconf northbridge/amd/geodelx/Kconfig:23: unexpected option "select" make: *** [menuconfig] Error 1
Index: Kconfig
--- Kconfig (revision 560) +++ Kconfig (working copy) @@ -63,6 +63,7 @@ endmenu
source mainboard/Kconfig +source northbridge/Kconfig
I think we removed the "middle layer" Kconfig files a while ago because they were not needed? Do we need to add them again? I'd try to avoid it.
source arch/x86/Kconfig source lib/Kconfig source device/Kconfig Index: northbridge/Kconfig =================================================================== --- northbridge/Kconfig (revision 0) +++ northbridge/Kconfig (revision 0) @@ -0,0 +1,24 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Segher Boessenkool segher@kernel.crashing.org +## Copyright (C) 2006-2007 coresystems GmbH +## (Written by Stefan Reinauer stepan@coresystems.de for coresystems GmbH) +## Copyright (C) 2007 Uwe Hermann uwe@hermann-uwe.de
Only Copyright (C) 2008 Ronald G. Minnich rminnich@gmail.com for such trivial files, please. If we continue to add (C) lines for each new copy of such one-liner files we'll end up with horribly long and useless lists of crap.
+## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; version 2 of the License. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +##
+source "northbridge/amd/Kconfig"
+select COMPRESSION_NRV2B
Uwe.
How about this? Seems to work, or at least it builds for me.
Index: mainboard/pcengines/Kconfig =================================================================== --- mainboard/pcengines/Kconfig (Revision 560) +++ mainboard/pcengines/Kconfig (Arbeitskopie) @@ -31,6 +31,7 @@ select NORTHBRIDGE_AMD_GEODELX select SOUTHBRIDGE_AMD_CS5536 select SUPERIO_WINBOND_W83627HF + select COMPRESSION_NRV2B help PC Engines ALIX1.C.
Yes, this one is per-board instead of per-chipset, but well...
Uwe.
On Jan 25, 2008 10:04 AM, Uwe Hermann uwe@hermann-uwe.de wrote:
Yes, this one is per-board instead of per-chipset, but well...
I think we need to get per-chipset settings into per-chipset Kconfigs. Anything else is going to drive us totally crazy :-)
Let's fix this thing I did which is broken :-)
ron
Sorry Ron, this is not meant as a rant against you. The patch you posted just fitted a pattern I'm seeing more and more often. Our problem is that we try to handle copyright issues with perfection. That sometimes causes us to go overboard with attributions.
On 25.01.2008 18:12, ron minnich wrote:
Add Kconfig files for the northbridge. Currently we only need this for the geodelx, so we can select nrv2b decompression.
This has been tested in build and behaves as we want it to: nrv decompression is enabled and the code compiled in.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
Index: northbridge/Kconfig
--- northbridge/Kconfig (revision 0) +++ northbridge/Kconfig (revision 0) @@ -0,0 +1,24 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Segher Boessenkool segher@kernel.crashing.org +## Copyright (C) 2006-2007 coresystems GmbH +## (Written by Stefan Reinauer stepan@coresystems.de for coresystems GmbH) +## Copyright (C) 2007 Uwe Hermann uwe@hermann-uwe.de
Three copyright holders for one line of code?!? And don't forget that the FSF holds the copyright of the majority of this file because the majority of the file is a GPLv2 header copyrighted by the FSF. Can we please agree to some sane attibution mechanism? (In German law, there is a concept called "notwendige Schöpfungshöhe", roughly translated "threshold of originality" below which it is very difficult to claim owning a copyright at all. Does one line of #include meet that threshold?)
+## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; version 2 of the License. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +##
+source "northbridge/amd/Kconfig"
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Marc Jones -
Myles Watson -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann