On 5/29/10 8:42 AM, Miro Kropacek wrote:
Well I think most linux boot loaders have a very small chunk of code in the mbr to find the real bootloader somewhere in the partiton or filesystem. This seems to be precisely how hd-driver works. Just having the hd-driver.sys file in C: is not enough but when you install hd-driver to the drive it probably writes the mbr. Doing the work you're doing, I think you're talking about reimplementing hd-driver in addition to other work. What COULD be ideal is - if for instance freemint gets all disk access drivers it needs, you could do thisyou wanted to boot off D: you just hold the D key in (or tap it repeatedly anyway). Again, I do see the practical application but hd-driver does offer some of this already.Wow, didn't know that! :) However, this still assumes you know what's on D and forces you to have hddriver.sys on boot partition. "My" boot loader is residing in MBR, i.e. in place where hddriver.sys is currently loaded& executed. Idea is to have this boot loader loading hddriver.sys, netbsd's boot sector or whatever makes sense to do.
mikroloader(tm) -> boot linux directly -> boot netbsd directly -> load freemint kernel directly -> chain load hd-driver.But doing this would require you write drive access stuff as well as a FAT driver as there's basically no way to fit a userful bootloader into the mbr. I see three main benefits to doing this:
1. Get rid of hd-driver.. Obviously I'd like to do this to replace pieces of the system with free open source, but at hte same time we should continue to support Uwe Seimet's developments by paying.
2. Boot linux or bsd faster for those that choose to do that.3. Boot freemint faster if we're just going to use freemint's drive detection and access logic anyway. 4. Integration of your boot loader directly into tos/emutos, both of which is probably possible on ct60/aranym/firebee.
I think Vincent Rivere already wrote IDE routines for the firebee so that could be a good start ;)