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

[Rene M. <re...@dr...>]

"M. R. Brown" wrote:

<snip>

> Where's the kernel?
> ===================
> 
> Good question :).  I admit I haven't been spending a lot of time working
> on foolproofing the kernel, but there are a couple of other issues that
> need to be addressed as well.  First off, if you are subscribed to
> LinuxSH's development list (lin...@so...) you'd have seen a
> message from Mitch Davis regarding status of the toolchains (GNU binutils
> and GNU gcc are what I'm most concerned with).  I'm currently working with
> binutils and gcc from cygnus's CVS from Dec. 21st, which appear to be
> mostly stable.  There have been some patches to LinuxSH's kernel (on which
> our LinuxDC kernel is derived), which also help building the kernel with
> the new tools.  I've been taking notes and testing with the procedures
> I've been using to build the kernel, so I'm drafting a Tools-HOWTO and a
> Kernel-HOWTO independant of the ones you'll find on the LinuxSH site.
> Also, Rene, if you got some patches that allow the kernel to build, could
> you also post them to the list as well as committing them to CVS?

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.

> 
> So, to make a long story short, from my side of things, we need to get
> going on starting to add peripheral support to the Linux kernel for the
> DC, but I'm still a little unsure of where to start.  The framebuffer
> would be good for the demo effect, but there are things to consider when
> writing a FB such as acceleration and overall system performance.  So I've
> been reversing the kernel and gathering info in an attempt to map out the
> resources provided by the PowerVR2DC (G2) ASIC, so that low-level support
> for the G2 can go into the kernel first.

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. 

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.

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.

4 Documentasion. We nead better HOWTOs and FAQs

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

6 Tools, we nead better understanding and decription on the tools we
use. Most critecly now is the buggs in GCC and binutils. We also nead to
make nice .deb packages of all the tools to make life easier for
developers, and hopefully make debian policy complient. And ofcauser we
nead to supp other distributions aswell. Most notebley Redhat and
Mandrake RPM and slackware .tgz





--
/Rene