On Wed, 2006-02-15 at 00:18 -0800, Daniel Gimpelevich wrote: > On Wed, 15 Feb 2006 01:06:09 +0100, Florian Boelstler wrote: > > > Daniel, > > > > do you think we should upload your version of miBoot to SF as the main > > miBoot version to use? > > Since miBoot is GPLed, I think a public release should wait until we can > set up some kind of system for others to to view the source and submit > patches, as I described in my message on 2006-01-25. The source currently > has several problems I would like to see taken care of, but I have not > really done anything to it because I don't really have machines I can test > it on. I would like to see each new build I make tested on NuBus with > HPV/AV, NuBus with PDM (as differentiated on the website), and OldWorld > PCI before it can be considered release-worthy. We should also post > instructions on how to use miBoot, perhaps on a wiki. > > Some initial improvements to the miBoot code can start with the following, > in order of decreasing priority: > > 1) The code Jeff Carr added is full of string literals with their length > specified as separate numeric literals for copy and compare operations. > There is at least one instance of the wrong length being supplied. > > 2) The code for unifying certain configuration lines with the "append=" > line into a string of kernel arguments does not take into account the > possibility that you may want more than one "video=" argument for more > than one GPU. Recently dealing with a Beige G3 Rev.2 "Silk" with a Radeon > 7000 card that had only a single monitor connected to the Radeon and > nothing to the on-board RagePro, I found the following temporary > workaround for 2.6 kernels: Do not supply any separate "video=" line, but > instead use the following line: > append = "video= video=atyfb:off video=radeonfb:vmode:17,cmode:8" > The first (empty) video argument is to fake out the problematic code, the > second is to shut off the RagePro, and the third is to configure the > Radeon for the console. > > 3) Jeff Carr put in many placeholders for code for improved functionality > that was never added, much of which would be fairly trivial to implement. > The whole release currently has the appearance of a quick & dirty hack. > > 3) It would be desirable to improve the code for finding files and decide > what to search for in what locations, possibly providing a way to specify > the paths. > > 4) Once kexec support exists for our platform, supply a general-purpose > miBoot image that would chain to the real kernel, which would reside on an > arbitrary filesystem or even on a network. > > There are two 3's because it is too early to decide which has higher > priority. > > What toolchain is required to build miboot? Is it possible to build it with GCC? The emile boot loader now used by 68k Mac Linux port can be built using GCC, and has some preliminary support for PPC code.
Ray ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Nubus-pmac-users mailing list Nubus-pmac-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users
