Re: [linuxdc-dev] State of the Kernel 1/1/1

[M. R. B. <ma...@uw...>]

On Tue, 2 Jan 2001, Rene Malmgren wrote:

> 
> Well I have a uploaded my kernel to ftp.dreamcastlinux.org/pub/ And
> added a Mini-HOWTO on how I have done. I would love to se the
> Tools-HOWTO and Kernel-HOWTO, just to compare notes. Its basicly ths
> sh-kernel witch DC RTC added. If your kernel does n't do anything more.
> I think we should start with this one as a starting point. And then add
> your stuff on top. Since my kernel is out there and I think its a doable
> start for many newbies. And it uses the new shlinux standard and has
> Dreamcast as a configurable option.
>

What version of the LinuxSH kernel are you using?  I would still like to
see your patches, especially the ones for DC RTC, I'm curious to see how
you implemented this.
 
> 
> Personaly I belive that the FB and keyboard should get priorety. There
> are lots of people who arn't kernel-hackers but whos contribution to
> this project depends on a working kernel. Its hard to write software
> without a kernel, but you can make do with a slow one. Why cant we
> simply use dans work here for a quick fix.
> 

> As for the Roadahead, from my kernel so to speak. (Taken from a doc I am
> working on)
> 
> Well heres my 2 cents. Right now we can advance on 6 fronts.
> 
> 1 We need a alternative lunch vehile to gdb. A dclilo so to speak. There
> are some alternatives. Also we nead to be able to boot compressed
> kernels, zImage and bzIamge. 
> 

GDB? It looks like we're using completely different methods of uploading
:).  I've been using andrewk's dcload 1.0.0 to upload zImages, which goes
pretty fast.  Unfortunately, the sh tools over at ftp.m17n.org don't
really apply to DC development (kernel or otherwise), so others have been
working to forge our own tools (incl. myself) and so far, dcload is the
best.

> 2 We nead to make this lonely crashing krenel a initrd image. So that we
> an boot an entire OS. Preferbly in a ramdisk or ramfs of some sort. And
> then start moving over user space programs. Now there are some good code
> over at the m17n that would make a good start. This work require little
> skill in programing but could take quite some time.
> 

I'm still trying to calculate where to place initrd in RAM and provide the
right kernel parameters (in empty_zero_page @ 8c011000).  As for bootable
CD/GD-ROM kernels, my idea was that we load zImage and initrd.img using
the scrambled 1ST_READ mechanism, therefore when the DC boots all the
1ST_READ has to do is relocate zImage and initrd (which has already been
loaded into RAM) and boot the kernel.  This would result in a MUCH faster
load IMHO :).

> 3 We nead to expand the driver support for this kernel. Most urgen is
> ofcause mapelbus (keryboard and pad) support and FB support. In the near
> future Modem, CDROM support and NIC support, and then alsa support for
> sound and possebly GDROM.
> 

I disagree here.  The FB and Maple support would be easy enough to write
(based on current KOS/libdream sources), but we wouldn't have "real"
hardware support for the PowerVR2DC ASIC such as interrupts (i.e. instead
of hacked maple/fb support, we would _know_ when we have vert. refresh or
if Maple DMA has completed), external DMA for sound, GD-ROM, and the
expansion port, etc.  The reason I haven't patched this in already is that
I'm still researching how everything works, instead of just having *bits*
and *pieces* I'm going for the big picture.

> 4 Documentasion. We nead better HOWTOs and FAQs
> 

I'm with you there, my HOWTOs are almost finished.

> 5 Integration and testing. So that we can eventualy remerge this kernel
> with the linuxsh and eventualy the linux kernel.
> 

This should be simple enough, I already plan on merging the current
LinuxSH kernel with ours at least once a week.  And by submitting our
patches back to LinuxSH means that they'll eventually make it into Linus'
Kernel.

M. R.