On Sat, Feb 07, 2009 at 02:38:08PM -0500, Lennart Sorensen wrote: > On Thu, Feb 05, 2009 at 12:35:15PM -0500, wrote: > > I can confirm that first.b does in fact build correctly. I am not sure > > what I did wrong before while trying to debug it. Certainly second.b > > ends up much too large, and I have not managed to fix first.b to support > > a larger second.b, although I am not sure that is because my first.b > > changes are incorrect or if it is because second.b is broken due to the > > ext2 changes. > > > > I have been trying to change the load address of second.b from 3e000 to > > 3d000 to give it 128k instead of 64k. I was also changing the BAR setup > > to allow more than 16MB to be used by the initrd, which I pretty sure > > will work fine, if I could just manage to get a working second.b build. > > > > So which part of the ext2 headers is causing it to get too large? I > > would love to build with the old headers to try and see if my other > > changes are sane, so that I can solve one problem at a time. > > > > Changing the installer setting should at least permit installing, but > > being unable to rebuild quik is still a serious problem, which I am sure > > can be fixed, so I am working on it. > > So I now have a version of quik that works with larger than 64KB > second.b and hence works when built with a current version of > e2fslibs. > > It also doesn't have any warnings from the compiler when built either. > > It took some major change to the design, although not much code change > to do it. It now creates a /boot/second.map.x (where x is whatever > block device it is dealing with at the time, it seems to have something > to do with raid use) and then maps the single block of that file into > the first.b's data structure. first.b now loads the second.map data > into memory, and uses the up to 256 blocks worth of locations (1KB) to > load second.b. So the data structure in first.b is much smaller, but > the supported size of second.b is 4 times larger. The load address also > had to be moved down by 192KB to fir the larger second.b image without > globbering first.b's memory.
Great work. Could you please post the patch here, so that it can be reviewed an included in the next upload of the package? > Now given the large change and the change in behavior especially, I > think this deserves a new version number. Unfortunately I can't figure > out how to locate the author of quik, or whoever is the current > maintainer, so I am not sure what to do about that. Any suggestions? I there is not upstream maintainer anymore. Moreover if you look at the Debian package, you will see it differs a lot from the latest upstream version of the package. Therefore I think it's not fully necessary to update the version number. > I also have to go fix openbios since their way of detecting the QUIK > boot loader uses a hardcoded copy of the data structures from QUIK which > hence break when QUIK is changed like this. This wasted probably 3 days > of my time before I noticed there was nothing wrong with my changes, it > was entirely openbios doing the wrong thing and deciding I had no boot > loader as soon as I moved anything in QUIK. > Given it requires changes to OpenBIOS, I think it would be nice to also post your patch to the OpenBIOS mailing list. -- Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
