While I am not new to Linux Kernel work, or Board support, I am new
to uClinux.
There clearly seems to be a uClinux way to do things, that is
distinctly different from the normal Linux Kernel developers approach.
Had I started working on with uClinux, I might be demanding Linus to
explain why the Kernel proper takes a different approach.
But I did not. Now I am trying to build a BSP for a MicroBlaze
product that has a strong Linux PPC heritage.
What I am striving for is to get as close to my existing PPC BSP
approach as I can manage and still have things work.
If I change a device driver for the PPC, I want that benefit
immediately next time I build a MB kernel (and visa versa)
Since I am working with FPGA's much of hardware is going to be the
same. Much of my board support code
will be the same - though the uClinux Microblaze code
(understandably) does not have the breadth of BSP support
the PPC does. Partly because the MicroBlaze almost has to be in a
Virtex FPGA, and because it is less mature.
I just want Linux for a cpu without an MMU. While I am asking Why
alot. Please understand "Does this have to be this way ?"
Is not intended to be a judgement, I am just seeking to find out how
much grief I am in for when I defy the conventional uClinux
appoach in favor of what I am more familiar with.
Thus far I am fairly happy. We shall see if that lasts when I get
real hardware (actually MicroBlaze firmware for my existing hardware)
But aside from the elf loading issue - which will prove very
annoying if insurmountable, but still just an annoyance not an impediment,
and the initramfs issue, which I presume is just not knowing what I
am doing building for the MicroBlaze I am actually fairly happy.
I have managed to merge the critical elements of the uClinux
MicroBlaze code into my standard Linux 2.6.21-rcx development tree,
and I can build both MicroBlaze and PPC kernels - and the PPC ones
still work. That is not too far from my definition of bliss.
That said I do want a better understanding of the elf/flatfile issue.
John Williams wrote:
Our bootloader already handles elf files. Must I use flat files on a
MicroBlaze ?
Yes. Application binaries running under Linux w/NOMMU must be flat
files.
I'm not sure what this has to do with your bootloader.
Can I ask why ? I beleive that I am aware that the standard Linux
elf file loader works by inducing page faults
which would not work without an MMU.
The reference to our boot loader, is because in our systems we have
a bootloader that loads and eexecutes PPC elf files.
There is very little about it that is PPC specific, and there is
nothing about that loader that requires an MMU. The MMU in the PPC
is not even enabled when we are loading.
It is entirely possible our embedded elf loader has fundimental
limitations. but it loads, Linux, GreenHills, as well as standalone
programs.
I know that is not as broad a task as loading applications within
the OS. The Linux elf file is fairly simple, mostly a wrapper arround a
loader for
a compressed binary image. GreenHills on the other hand produces a
fairly complex elf file - though again OS's make less assumptions than
programs.
There is a huge collection of CONFIG_XILINX_ macros inside the
.config file that seem to correspond to xparameters.h.
First I can not seem to kill the ones I am not using, and second
don't these really belong in a header file not .config ?
How and where do I kill them off ?
I'm not sure why you would want to "kill them off". They are part of
the auto-config approach that lets us tailor the kernel to the HW build.
Being in .config they also end up in include/linux/autoconf.h. The
reason you need them in .config not jsut xparameres.h is, among other
things, that it lets the build system reason about your HW build.
Does the CPU have a multipler instruction? This affects the CFLAGS
you pass to the kernel build. xparameters.h won't help you there.
A few of the items such as whether the CPU has a multiplier - make
sense in .config.
But the instances in which setting hardware addresses, irq's etc in
Linux is done inside .config are extremely rare.
In my specific instance we go to a great deal of trouble to maintain
a high degree of uniformity across a spectrum of products.
My Pico E1X PPC405 Linux is a single binary that runs on multiple
platforms with differing features. Where possible the underlying
hardware such as PIC's
etc is identical. When it is not the kernel is configured either by
dynamically probing or by passed parameters.
When I get a better handle on them I will probably move to the
device tree's that are part of the ppc/powerpc Linux merge.
Maybe the compiler needs to know about the multiplier, but the whole
build process does not care what address the UartLite is at.
Anyway that issue is moot. I managed to coble together something I
am happy with.
The critical options that are really global are still in config.
Local and fairly static values are currently in a header and where
possible will disappear when I can.
Regards,
John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/