From: Tobias N. <tob...@t-...> - 2006-09-21 08:01:33
|
Hi all, as the linux kernel version 2.6.18 is now released and with it the reworking of the Macintosh specific code has been finished (or almost finished?), now it would be a good time to update to the 2.6 kernel. However in order to manage to update at least two or three persons would be needed. At least two of them should know a little bit about kernel drivers. Everyone who would like to volunteer should reply to this message. Tobias |
From: Daniel G. <da...@gi...> - 2006-09-23 02:40:12
|
Be forewarned: The release candidates for this version have had endless problems for many people on x86. On Thu, 21 Sep 2006 11:01:29 +0200, Tobias Netzel wrote: > Hi all, > > as the linux kernel version 2.6.18 is now released and with it the > reworking of the Macintosh specific code has been finished (or almost > finished?), now it would be a good time to update to the 2.6 kernel. > However in order to manage to update at least two or three persons > would be needed. At least two of them should know a little bit about > kernel drivers. > > Everyone who would like to volunteer should reply to this message. > > > Tobias > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV |
From: Florian B. <eup...@ar...> - 2006-09-25 19:57:35
|
Daniel Gimpelevich wrote: > Be forewarned: The release candidates for this version have had endless > problems for many people on x86. Thanks for the warning. I am using it (final version, and RC7 before) on a x86 for a few days now and didn't ran into any problems yet. Cheers, Florian |
From: Florian B. <eup...@ar...> - 2006-09-25 19:54:43
|
Count on me this time :) Cheers, Florian |
From: Florian B. <eup...@ar...> - 2006-09-27 22:56:11
|
Hi, I guess one of the very first things is to setup a flat device tree. Did you got any further insight what other building blocks are required? Florian |
From: Tobias N. <tob...@t-...> - 2006-09-28 05:09:09
|
Hi Florian, I didn't have time yet to look into the sources. I don't even know what a "flat" device tree is. Does it mean that all nodes are on the same level? Is that flat tree later converted into a "real" device tree? I remember something like that when I first tried to make the 2.6 kernel boot some months ago. We also have to decide whether we should invest into building a complete device tree that does contain only valid information and also contains information about every expansion card (we would have to probe for cards first). Until now the information in the fake tree isn't always correct and doesn't contain any expansion cards or something like that. We also need to decide whether we should make an own platform or whether we hack us into the powermac platform. Tobias Am 28.09.2006 um 00:56 schrieb Florian Boelstler: > Hi, > > I guess one of the very first things is to setup a flat device tree. > Did you got any further insight what other building blocks are > required? > > Florian > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Nubus-pmac-users mailing list > Nub...@li... > https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users > |
From: Florian B. <eup...@ar...> - 2006-09-28 20:07:50
|
Hi Tobias, Tobias Netzel wrote: > I didn't have time yet to look into the sources. Me neither. > I don't even know what a "flat" device tree is. Does it mean that all > nodes are on the same level? AFAIK the "flattened device tree" is a replacement for systems that do not build on Open Firmware. I am also affected about this change at work, though I didn't had a chance to thoroughly investigate it. An initial documentation can be found in <linux source>/Documentation/powerpc/booting-without-of.txt Florian |
From: Raylynn K. <aud...@sp...> - 2006-09-29 06:46:48
|
On Thu, 2006-09-28 at 22:07 +0200, Florian Boelstler wrote: > Hi Tobias, > > Tobias Netzel wrote: > > I didn't have time yet to look into the sources. > > Me neither. > > > I don't even know what a "flat" device tree is. Does it mean that all > > nodes are on the same level? > > AFAIK the "flattened device tree" is a replacement for systems that do > not build on Open Firmware. > I am also affected about this change at work, though I didn't had a > chance to thoroughly investigate it. > > An initial documentation can be found in <linux > source>/Documentation/powerpc/booting-without-of.txt > > Florian > We might want to ask Benjamin Herrenschmidt's opinion on the approach we should take. The document states " new 32-bit platforms and 32-bit platforms which move into arch/powerpc will be required to use these rules". But the document seems to be addressing mostly embedded platforms. Also, I do believe Ben will have to review any code we wish to get into the mainstream kernel tree. |
From: Tobias N. <tob...@t-...> - 2006-09-30 07:28:03
|
Am 29.09.2006 um 08:46 schrieb Raylynn Knight: > On Thu, 2006-09-28 at 22:07 +0200, Florian Boelstler wrote: >> Hi Tobias, >> >> Tobias Netzel wrote: >>> I didn't have time yet to look into the sources. >> >> Me neither. >> >>> I don't even know what a "flat" device tree is. Does it mean that all >>> nodes are on the same level? >> >> AFAIK the "flattened device tree" is a replacement for systems that do >> not build on Open Firmware. >> I am also affected about this change at work, though I didn't had a >> chance to thoroughly investigate it. >> >> An initial documentation can be found in <linux >> source>/Documentation/powerpc/booting-without-of.txt >> >> Florian >> > We might want to ask Benjamin Herrenschmidt's opinion on the approach > we > should take. > The document states " new 32-bit > platforms and 32-bit platforms which move into arch/powerpc will be > required to use these rules". But the document seems to be addressing > mostly embedded platforms. Also, I do believe Ben will have to review > any code we wish to get into the mainstream kernel tree. We would have to post to the ppc kernel developer mailing list at ozlabs.org then. I now studied the document about booting without OF. In order to go the "right" way we would have to change the bootloader to provide a device tree for NuBus machines. That would mean that we won't be able to use the MkLinux bootloader any more. And we would need the possibility to build a bootloader. Daniel Gimpelevich is able to build miboot but he isn't sure of BootX yet. Until now - in the 2.4 kernel - the kernel itself builds the fake device tree. This would be easily portable and the MkLinux bootloader could be used as usual. It was also easy to have the kernel build the device tree at first and later have the bootloader doing that task once it is able to. We then won't need to build a flat device tree because the current code builds an already unflattened tree. During my efforts with the 2.6.17 (or has it been 2.6.16?) kernel I got till the point where the kernel correctly recognizes NuBus machines and where it needs a device tree to go on. @Daniel: Would you like to make miboot provide a fake device tree for NuBus machines? In order to build a device tree you could use DTC (Device Tree Compiler) from http://dtc.ozlabs.org . And what about BootX? > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Nubus-pmac-users mailing list > Nub...@li... > https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users > |
From: Tobias N. <tob...@t-...> - 2006-09-29 15:32:40
|
Am 29.09.2006 um 08:46 schrieb Raylynn Knight: > On Thu, 2006-09-28 at 22:07 +0200, Florian Boelstler wrote: >> Hi Tobias, >> >> Tobias Netzel wrote: >>> I didn't have time yet to look into the sources. >> >> Me neither. >> >>> I don't even know what a "flat" device tree is. Does it mean that all >>> nodes are on the same level? >> >> AFAIK the "flattened device tree" is a replacement for systems that do >> not build on Open Firmware. >> I am also affected about this change at work, though I didn't had a >> chance to thoroughly investigate it. >> >> An initial documentation can be found in <linux >> source>/Documentation/powerpc/booting-without-of.txt >> >> Florian >> > We might want to ask Benjamin Herrenschmidt's opinion on the approach > we > should take. The document states " new 32-bit > platforms and 32-bit platforms which move into arch/powerpc will be > required to use these rules". But the document seems to be addressing > mostly embedded platforms. Also, I do believe Ben will have to review > any code we wish to get into the mainstream kernel tree. > It would be hard and a lot of work to get our patches into the mainstream kernel - too much for just 2 persons. Or is there anyone who would like to communicate with the ppc kernel developers list? > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Nubus-pmac-users mailing list > Nub...@li... > https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users > |
From: Raylynn K. <aud...@sp...> - 2006-09-29 17:46:46
|
On Fri, 2006-09-29 at 17:32 +0200, Tobias Netzel wrote: > Am 29.09.2006 um 08:46 schrieb Raylynn Knight: > > > On Thu, 2006-09-28 at 22:07 +0200, Florian Boelstler wrote: > >> Hi Tobias, > >> > >> Tobias Netzel wrote: > >>> I didn't have time yet to look into the sources. > >> > >> Me neither. > >> > >>> I don't even know what a "flat" device tree is. Does it mean that all > >>> nodes are on the same level? > >> > >> AFAIK the "flattened device tree" is a replacement for systems that do > >> not build on Open Firmware. > >> I am also affected about this change at work, though I didn't had a > >> chance to thoroughly investigate it. > >> > >> An initial documentation can be found in <linux > >> source>/Documentation/powerpc/booting-without-of.txt > >> > >> Florian > >> > > We might want to ask Benjamin Herrenschmidt's opinion on the approach > > we > > should take. The document states " new 32-bit > > platforms and 32-bit platforms which move into arch/powerpc will be > > required to use these rules". But the document seems to be addressing > > mostly embedded platforms. Also, I do believe Ben will have to review > > any code we wish to get into the mainstream kernel tree. > > > It would be hard and a lot of work to get our patches into the > mainstream kernel - too much for just 2 persons. > Or is there anyone who would like to communicate with the ppc kernel > developers list? > > I'm all for making the effort. The advantage if we do it right, would be support from the debian and Ubuntu distributions at a minimum. Also taking this route might get us more than 2 developers. Perhaps we have more than 2 already?? Florian appears to be interested, if you count you and I and him that's already 3 developers!!! I have some experience with NuBus and the Ethernet drivers having done work on both for m68k Mac in the past. I'm currently working on updating the SMC driver to support PDS and CommSlot cards on the 6290 and the Asante 100MB Nubus card on the x100 boxes. I'm also working on getting Doc support for the 2300 working by perusing the NetBSD code, I think I can at least get the Ethernet on the Newer UltraDock and MicroDock working in the next couple of weeks. Getting the SCSI port working would be great, but even NetBSD hasn't seemed to have figured that out yet. Ray |
From: Tobias N. <tob...@t-...> - 2006-09-30 07:08:50
|
Am 29.09.2006 um 19:46 schrieb Raylynn Knight: > On Fri, 2006-09-29 at 17:32 +0200, Tobias Netzel wrote: >> Am 29.09.2006 um 08:46 schrieb Raylynn Knight: >> >>> On Thu, 2006-09-28 at 22:07 +0200, Florian Boelstler wrote: >>>> Hi Tobias, >>>> >>>> Tobias Netzel wrote: >>>>> I didn't have time yet to look into the sources. >>>> >>>> Me neither. >>>> >>>>> I don't even know what a "flat" device tree is. Does it mean that >>>>> all >>>>> nodes are on the same level? >>>> >>>> AFAIK the "flattened device tree" is a replacement for systems that >>>> do >>>> not build on Open Firmware. >>>> I am also affected about this change at work, though I didn't had a >>>> chance to thoroughly investigate it. >>>> >>>> An initial documentation can be found in <linux >>>> source>/Documentation/powerpc/booting-without-of.txt >>>> >>>> Florian >>>> >>> We might want to ask Benjamin Herrenschmidt's opinion on the approach >>> we >>> should take. The document states " new 32-bit >>> platforms and 32-bit platforms which move into arch/powerpc will be >>> required to use these rules". But the document seems to be >>> addressing >>> mostly embedded platforms. Also, I do believe Ben will have to >>> review >>> any code we wish to get into the mainstream kernel tree. >>> >> It would be hard and a lot of work to get our patches into the >> mainstream kernel - too much for just 2 persons. >> Or is there anyone who would like to communicate with the ppc kernel >> developers list? >>> > I'm all for making the effort. The advantage if we do it right, would > be support from the debian and Ubuntu distributions at a minimum. Also > taking this route might get us more than 2 developers. Perhaps we have > more than 2 already?? Florian appears to be interested, if you count > you and I and him that's already 3 developers!!! I have some > experience with NuBus and the Ethernet drivers having done work on both > for m68k Mac in the past. That's great! > > I'm currently working on updating the SMC driver to support PDS and > CommSlot cards on the 6290 and the Asante 100MB Nubus card on the x100 > boxes. I'm also working on getting Doc support for the 2300 working by > perusing the NetBSD code, I think I can at least get the Ethernet on > the > Newer UltraDock and MicroDock working in the next couple of weeks. > Getting the SCSI port working would be great, but even NetBSD hasn't > seemed to have figured that out yet. I found some dock support in the NetBSD sources, too. Did you get a PB 500 PPC yet? You once mentioned you will get one. > Ray > > > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Nubus-pmac-users mailing list > Nub...@li... > https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users > |
From: Raylynn K. <aud...@sp...> - 2006-10-01 06:35:32
|
On Sat, 2006-09-30 at 09:08 +0200, Tobias Netzel wrote: > Am 29.09.2006 um 19:46 schrieb Raylynn Knight: > > > On Fri, 2006-09-29 at 17:32 +0200, Tobias Netzel wrote: > >> Am 29.09.2006 um 08:46 schrieb Raylynn Knight: > >> > >>> On Thu, 2006-09-28 at 22:07 +0200, Florian Boelstler wrote: > >>>> Hi Tobias, > >>>> > >>>> Tobias Netzel wrote: > >>>>> I didn't have time yet to look into the sources. > >>>> > >>>> Me neither. > >>>> > >>>>> I don't even know what a "flat" device tree is. Does it mean that > >>>>> all > >>>>> nodes are on the same level? > >>>> > >>>> AFAIK the "flattened device tree" is a replacement for systems that > >>>> do > >>>> not build on Open Firmware. > >>>> I am also affected about this change at work, though I didn't had a > >>>> chance to thoroughly investigate it. > >>>> > >>>> An initial documentation can be found in <linux > >>>> source>/Documentation/powerpc/booting-without-of.txt > >>>> > >>>> Florian > >>>> > >>> We might want to ask Benjamin Herrenschmidt's opinion on the approach > >>> we > >>> should take. The document states " new 32-bit > >>> platforms and 32-bit platforms which move into arch/powerpc will be > >>> required to use these rules". But the document seems to be > >>> addressing > >>> mostly embedded platforms. Also, I do believe Ben will have to > >>> review > >>> any code we wish to get into the mainstream kernel tree. > >>> > >> It would be hard and a lot of work to get our patches into the > >> mainstream kernel - too much for just 2 persons. > >> Or is there anyone who would like to communicate with the ppc kernel > >> developers list? > >>> > > I'm all for making the effort. The advantage if we do it right, would > > be support from the debian and Ubuntu distributions at a minimum. Also > > taking this route might get us more than 2 developers. Perhaps we have > > more than 2 already?? Florian appears to be interested, if you count > > you and I and him that's already 3 developers!!! I have some > > experience with NuBus and the Ethernet drivers having done work on both > > for m68k Mac in the past. > That's great! > > > > I'm currently working on updating the SMC driver to support PDS and > > CommSlot cards on the 6290 and the Asante 100MB Nubus card on the x100 > > boxes. I'm also working on getting Doc support for the 2300 working by > > perusing the NetBSD code, I think I can at least get the Ethernet on > > the > > Newer UltraDock and MicroDock working in the next couple of weeks. > > Getting the SCSI port working would be great, but even NetBSD hasn't > > seemed to have figured that out yet. We don't need Dock support for the UtlraDock or the MicroDock ethernet support. The Ethernet show up in slot E address space and the current SMC code finds the registers just fine. However, they don't appear to use the slot E interrupt so I'll have to do more digging to see which interrupt they use. I'll also have to change the Mac8390 driver as it thinks it can drive the Ethernet on the UltraDock and MicroDock, but they definitely have SMC chips and not 8390 chips. > I found some dock support in the NetBSD sources, too. > Did you get a PB 500 PPC yet? You once mentioned you will get one. > I have the following PPC hardware: PowerBook 540c w/ 603e upgrade 40MB RAM, 1GB SCSI disk - partitioned for Linux, will boot kernel but gets no response to keyboard. PowerBook Duo 2300c w/ 56MB RAM, 4.3GB disk, MicroDock, UtlraDock 16sce, UltraDock 16sc, MiniDock, Duo Dock II - Currently boots Debian 3.1 w/KDE 3.3 desktop (very slowly) PowerBook 5300c - w/ 40MB RAM, 5 GB disk, onboard Focus MVE16 Ethernet - Currently boots Debian 3.1 no graphics. PowerBook 5300ce w/ 56MB RAM, 10GB disk, Zip Disk, onboard Focus MVE16 Ethernet - Currently boots Debian 3.1 w/ Gnome Desktop (very slowly) PowerBook 1400cs133 w/ 64MB RAM, 10 GB disk, 8x CDROM - Currently boots Debian 3.1 w/ Gnome Desktop PowerBook 1400c Newer Tech 250Mhz G3, 64MB RAM, 20GB disk, 12x CDROM, onboard Farallon Ethernet (haven't tried patch yet), - Currently boots Debian 3.1 w/ XFCE Desktop PowerBook 1400cs Newer Tech 216Mhz G3, 64MB RAM, needs disk, 6x CDROM. Also have a Zip Drive and a VST 1.4GB Expansion Bay drive for the 1400s. PowerBook 3400c-200 w/ 144MB RAM, 10GB disk, 6x CDROM, built-in Ethernet - Currently running Ubuntu 5.10 2 - Performa 6290 w/ 64MB RAM and ~4GB disk running Debian 3.1 1 - Performa 6116 w/ 72 MB RAM running Debian 3.1 1 - PowerMac 6100 - Newer Tech 230Mhz G3, 72 MB RAM running Debian 3.1 1 - PowerMac 7100 - Newer Tech 250Mhz G3, Maxed out RAM, ready for Linux install (previously had Yellow Dog 2.3) 1 - PowerMac 8100-100 Maxed out RAM, ready for Linux install (Hard disk died) 1 - PowerMac 8600-200 w/ 272 MB RAM running Debian 3.1 no graphics 1 - 266Mhz Beige G3 Tower w/ 384 MB RAM running Ubuntu 5.10 I also have a boxful of Nubus, PDS and CommSlot Ethernet cards that I use for testing the drivers for both m68k and Nubus PPC Linux. |
From: Daniel G. <da...@gi...> - 2006-10-06 20:19:59
|
On Sat, 30 Sep 2006 10:27:51 +0200, Tobias Netzel wrote: > And we would need the possibility to build a bootloader. Daniel > Gimpelevich is able to build miboot but he isn't sure of BootX yet. I will likely be involved with people from the Debian Project regarding that. The biggest technical obstacle for me ATM is the lack of a working recent Subversion client capable of handling AppleDouble. You can catch up here: http://lists.alioth.debian.org/pipermail/debootloaders-miboot/2006-September/000030.html > @Daniel: Would you like to make miboot provide a fake device tree for > NuBus machines? In order to build a device tree you could use DTC > (Device Tree Compiler) from http://dtc.ozlabs.org . And what about BootX? As it stands, miBoot passes a "BootX-style" device tree, which the kernel has always special-cased. I have not looked at DTC, but you make it sound like the longstanding device-tree problem has come full circle. One of the arguments against the use of BootX has long been the lack of access to the real device tree, although BootX's approach is probably the best possible under the circumstances. If DTC does the same thing, but better, using its mechanism should definitely go on the BootX TODO list. |
From: Tobias N. <tob...@t-...> - 2006-10-06 21:02:31
|
Am 06.10.2006 um 22:19 schrieb Daniel Gimpelevich: > On Sat, 30 Sep 2006 10:27:51 +0200, Tobias Netzel wrote: > >> And we would need the possibility to build a bootloader. Daniel >> Gimpelevich is able to build miboot but he isn't sure of BootX yet. > > I will likely be involved with people from the Debian Project regarding > that. The biggest technical obstacle for me ATM is the lack of a > working > recent Subversion client capable of handling AppleDouble. You can > catch up > here: > > http://lists.alioth.debian.org/pipermail/debootloaders-miboot/2006- > September/000030.html > >> @Daniel: Would you like to make miboot provide a fake device tree for >> NuBus machines? In order to build a device tree you could use DTC >> (Device Tree Compiler) from http://dtc.ozlabs.org . And what about >> BootX? > > As it stands, miBoot passes a "BootX-style" device tree, which the > kernel > has always special-cased. I have not looked at DTC, but you make it > sound > like the longstanding device-tree problem has come full circle. One of > the > arguments against the use of BootX has long been the lack of access to > the > real device tree, although BootX's approach is probably the best > possible > under the circumstances. If DTC does the same thing, but better, using > its > mechanism should definitely go on the BootX TODO list. Unfortunately on NuBus machines BootX/miBoot doesn't provide a device tree at all. So currently the kernel itself has to build a device tree early in the boot process. Such things will hardly make it into the official kernel source. Using DTC one could compile special device trees for the PDM, Performa and PowerBook NuBus machines that only have to be copied into memory the kernel can access. That would free us from messing around with device tree building in the kernel itself. > > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Nubus-pmac-users mailing list > Nub...@li... > https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users > |
From: Raylynn K. <aud...@sp...> - 2006-10-12 01:56:28
|
On Fri, 2006-10-06 at 13:19 -0700, Daniel Gimpelevich wrote: > On Sat, 30 Sep 2006 10:27:51 +0200, Tobias Netzel wrote: > > > And we would need the possibility to build a bootloader. Daniel > > Gimpelevich is able to build miboot but he isn't sure of BootX yet. > > I will likely be involved with people from the Debian Project regarding > that. The biggest technical obstacle for me ATM is the lack of a working > recent Subversion client capable of handling AppleDouble. You can catch up > here: > > http://lists.alioth.debian.org/pipermail/debootloaders-miboot/2006-September/000030.html > Would it be possible to eliminate some of the tool-chain problems by integrating the work done by Laurent Vivier for the Early Macintosh Image Loader (EMILE) at http://emile.sourceforge.net/ This code currently works great on most of the m68k Macintosh systems and there is some preliminary support for PowerPC in the source repository. |
From: Daniel G. <da...@gi...> - 2006-10-06 22:29:03
|
On Sat, 07 Oct 2006 00:02:24 +0200, Tobias Netzel wrote: > Unfortunately on NuBus machines BootX/miBoot doesn't provide a device > tree at all. > So currently the kernel itself has to build a device tree early in the > boot process. Such things will hardly make it into the official kernel > source. > Using DTC one could compile special device trees for the PDM, Performa > and PowerBook NuBus machines that only have to be copied into memory > the kernel can access. > That would free us from messing around with device tree building in the > kernel itself. I don't like the idea of static device trees. If you currently build them dynamically in the kernel, that could just be moved to the bootloader. |
From: Tobias N. <tob...@t-...> - 2006-10-07 05:50:46
|
Am 07.10.2006 um 00:28 schrieb Daniel Gimpelevich: > On Sat, 07 Oct 2006 00:02:24 +0200, Tobias Netzel wrote: > >> Unfortunately on NuBus machines BootX/miBoot doesn't provide a device >> tree at all. >> So currently the kernel itself has to build a device tree early in the >> boot process. Such things will hardly make it into the official kernel >> source. >> Using DTC one could compile special device trees for the PDM, Performa >> and PowerBook NuBus machines that only have to be copied into memory >> the kernel can access. >> That would free us from messing around with device tree building in >> the >> kernel itself. > > I don't like the idea of static device trees. If you currently build > them > dynamically in the kernel, that could just be moved to the bootloader. > The current code also builds a static tree at first and later modifies it where needed. Those modifications are model dependant so one could make them in the beginning as well. So the same Mac models would always have nearly the same device tree - if one leaves out any expansion cards (even PCI cards don't need to be in the device tree). The memory node appears to be the only one that is really modified (according to what BootX passes as memory configuration) - but BootX could as well set up that node directly. One should also detect the CPU type and modify the CPU node accordingly, I think. In order to get rid of the special case of BootX/miBoot one could also change them to create a flat device tree that the kernel can directly work with. Then one wouldn't need to convert the device tree in the kernel any more and one also wouldn't need to detect BootX/miBoot any more. That solution would also be appreciated by the ppc kernel maintainers I think. |