Re: [microblaze-uclinux] RE: SystemAce and mb-uClinux

[John Williams <jwilliams@itee.uq.edu.au>]

Hi Eric,

Hansen Eric wrote:
> thanks to the hints from john and peter I am now 
> able to access the data an the systemace's cf.

excellent

> Just the reboot funtion is still deactivated.

Yep - add it to the wishlist :)

> I will try to commit a path for systemAce tomorrow.
> (I am slowly beginning to understand how the kernel
> works :) )

There's a few good books from O'Reilly that can help there - Linux 
Device Drivers by Rubini and Corbet, and Understanding the Linux Kernel 
by Bovet and Cesati.

> My next step will be to put data from romfs onto
> the cf, so that the cf can be used as root.

This could get tricky - maybe you could put a romfs image on the CF, 
then create some kind of virtual device node that maps to just that 
image file in the CF, but ...

You'd probably be better trying to use fat native as the rootfs, like 
you suggest below.

> As we are not handing over any kernel parameters
> I guess mounting dev/root is hard coded?

I haven't investigated any means of passing boot parameters to the 
kernel - but it shouldn't be diffucult.  SnapGear use something called 
flatfs, which is a flash based configuration manangement thing, looks 
pretty easy to use.

> I already located do_mounts.c, but I haven't
> gone thought all the code. So if somebody can
> point me to the important section that will 
> be a great help for me. Thanks in advance.

In the absence of a "rootfstype=" parameter, do_mounts goes through all 
registered file system types, and "asks" them if they know how to mount 
on /dev/root.

If rootfstype is present, then only that filesystem is tested.

> By the way.. is it possible to have fat as root
> system?

I don't know - can't think of any reason why not.  You'd change the 
platform build process a bit (vendors/.../Makefile)- instead of running 
genromfs, you'd use mkfs.fat or something similar.

At this stage I might recommend you also subscribe to uclinux-dev - or 
search the archives at least.  This sort of thing is discussed quite often.

> john> Have you just hardcoded the IRQ for now, in adapter.c (similar to
> my 
> john> kludge in xemac/adapter.c)?
> 
> Yes, I have done so. But why not put the irq stuff into
> xparameters.h like they have done in the ppc port.

No good reason :-)

> I have changed the includes in xilinx_sysace to point
> at asm/xparameters as the sysacedriver uses stuff from
> that file. The definitions of the irqs would fit quite
> nicely into the file from a logical point of view, though
> they are not automatically generated by XPS.

I originally hoped the xparameters.h file could be pullked straight from 
an EDK project build, and used directly without manual changes. 
However, right now that is not possible, basically because it would 
enfore a peripheral naming scheme to be consistent between the MHS 
kernel, which is not very elegant at all.

> But there is a script in the ml300-linux demo from
> xilinx which modifies xparameters according to their
> need. May be something like that is possible for 
> uClinux as well?

It's definitely possible, and probably essential really.  I haven't seen 
it, but would be surprised if that script required more than trivial 
changes to work with microblaze.

Longer term, I am thinking about ways of auto configuring the kernel 
according to the MHS file, basically automate the entire procedure.  But 
for now it's mostly ideas, and a few experiments.

> I will try to do so tomorrow. I will have to do some
> clean-ups beforhand as there are a lot of useless
> printk's in there. Is there anything special to take
> care of when generating the patch - I haven't done 
> such a thing before.

Well, new files that you've added, should be tarred and gzipped, 
probably from the linux-2.4.x root

[me@myhost linux-2.4.x]$ tar -oxzf sysace-patch.tar.gz 
drivers/block/xsysace/ ....

Then generate a diff from CVS

[me@myhost linux-2.4.x]$ cvs diff -u > sysacepatch.diff

Finally edit the diff file to remove all lines that start with a '?', 
and also make sure that all the changes described in that diff, are the 
ones you want to submit.

it's scary at first, but soon becomes second nature :)

once again - well done.

john

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/