Joerg Schilling wrote:
> Cyril Plisko <cyril.plisko at gmail.com> wrote:
>
>
>>Yes, that is the list. I think we discussed it earlier ...
>
>
> I belioeve this was basically what we did discuss at the CeBit
Right.
>
>
>>>Kernel Space / boot:
>>>
>>>- GRUB
>>
>>GRUB2 works in it current state.
>>Needs to be augmented with UFS support from Legacy GRUB/Solaris x86.
>>GRUB2 network support for OpenFirmware limbo. Good thing is that GRUB2
>>community is actively working on it.
>
>
> UFS support is not needed as long as we put GRUB into the Linux partition ;-)
> The Boot archive may use hsfs.
You know what, I have a wild idea - how about ignoring UFS altogether
and jumping right into bootable ZFS, when it becomes available later
next year ? How does that sound ?
>
>
>>>- Kernel Virtual memory layout
>>>
>>>- HAT layer
>>>
>>>- Interrupt handler
>>>
>>>- Exception handler
>>>
>>>- Syscall handler
>>>
>>>- krtld
>>
>>All the above are quite a lot of work, but if we get help from the
>>SunLabs with the 2.5.1 sources we may march through this quite quickly.
>
>
> If we like to see a shell prompt, we need to be ready with this....
> For the time before, I have an unbuffered kernel printf that I needed to write
> in order to find the ATA/SCSI Bugs in Solaris 2.6 x86.
I recall there is some undocumented non-buffering printf already.
I used it once while debugging some weird hardware problem.
>
>>>- minimal drivers
>>
>>That is the part where we need _official_ documentation from Marvell.
>>Their chip is in the middle of the Pegasos and a lot of things require
>>exact knowledge of the chip to drive it correctly.
>
>
> Marvel is partially located in Berlin. I had a discussion with Marvell
> at CeBIT related to the port. It may need that we push them a bit together
> with Sun ;-)
Marvell is an Israel company, but it helped me not. They never returned
my emails. Whatever, I know we'll solve it that way or another.
>
>>>User Space:
>>>
>>>- ld.so
>>
>>Yeah, may be common in part with krtld.
>
>
> I hope that this is something where we get help from Sun
>
> We need to ass ld to this list as my memory tells me that gld has some
> problems.
+1. I do not really like GNU ld.
>
>>>- mdb
>>
>>Very important thing. In fact having a reliable debugger is
>>a most important thing, IMHO.
>
>
> I did not yet lookinto mdb sources, but if the disassembler is table
> driven and if the PPC Opcodes are cleanly defined, it should be doable
> within a week and then the work for kmdb has been done too.
>
>
>>>I propose the following way:
>>>
>>>- Start with GRUB installed on Linux - Grub should support
>>> the needed filesystems
>>>
>>>- Write multiboot for PPC ----> What is needed here?
>>
>>Dig GRUB2 ML archive - they have something.
>
>
> The Solaris x86 multiboot program has special knowledge on Solaris
Oh, you mean porting multiboot kernel to PPC. I thought you were talking
about adding something to GRUB. You are right. And of course it has
Solaris knowledge - it boots Solaris after all :) Frankly speaking I
didn't even look at it yet.
Any volunteers ?
>
>
>
>>>- Do not use a network boot (except for e.g. loading the boot archive)
>>> as this would create the need for a MAC driver.
>>
>>We are in somewhat good shape here since one of the Ethernet interfaces
>>on Pegasos II is Realtek. So driver shouldn't be a problem. And, frankly
>>speaking, I am a big fun of network boot :)
>
>
> If we finally toss the rtld driver out of Solaris and replace it with
> "rf" driver....
No one stops us from tossing rtls and using rf, right ? There is no rtls
for SPARC anyhow.
>
>
>
>>>- For everything that needs HW access in the first attempt, use
>>> callbacks to the Openboot drivers. This is e.g. /dev/console
>>> and the HD driver.
>>
>>console IO - yes, definitely. As for HD - I am not sure. As I said
>>I prefer to netboot until the HD driver chain is ready.
>
>
> Keep in mind that we have no ATA driver source.
Indeed. What about upcoming SATA framework ? Will it be useful for us ?
Can someone from Sun comment on this ?
>>>Questions:
>>>
>>>- who has skills in what?
>>
>>I can make pizzas. On the second thought it doesn't seem to
>>be relevant here ;) Kernel coding - that's where I can help
>>most.
>
>
> Do you like to contribute a pizza driver or a pizza syscall?
pizza boot loader I think :)
Regards,
Cyril
