[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] sources for microblaze-related software
John Williams wrote:
> Hi David,
>
> Personally, I hate hacking on gcc. For that reason I never do much
> with it other than rebuild the source tarballs distributed by Xilinx
> (see my forward of John McCluskey's email earlier today).
>
> I have tried to convince Xilinx to push microblaze into mainline GCC,
> but it's never happened. No doubt there's a fair effort there, but
> there are rewards as well.
>
> Anyway, in terms of patches for buildroot - it should be easy enough
> to take the tarball from Xilinx, do a diff -Naur against whatever
> original version Xilinx based theirs on, and there's your patch.
Not really looking to Hack GCC just looking to get Xilinx processor
support as part of a normal GCC distribution. I am pretty sure that Dan
Kegel - CrossTool offered to include Microblaze support into crosstool
if somebody would just give him a patch against a stock GCC source.
I do not use Cygwin or the Xilinx permutation. Purportedly TimeSys
has gotten Cygwin to a state where it can actually build Linux Kernel's
but my experiences with Cygwin and permutations have primarily involved
trying to figure out how to work arround/with its specific quirks - due
to Windows limitations, rather than solving my real problem.
>
> Can buildroot make noMMU (elf2flt) Linux toolchains happily? If not,
> there's another complication to consider for MicroBlaze.
You have lost me. I am not sure what Buildroot is ? I have a vague
thought that it is the predecessor to crosstool but I could be wrong.
Off the top of my head I can not think why not - GCC can be built
for x86 MSDOS, I can't see a MicroBlaze as being an issue.
How does noMMU effect the compiler ? Isn't the presence or absence
of an MMU an OS issue ?
>
> You are making a common confusion between uClinux, and uClinux-dist.
> One more time, for the archives:
Thank You. I was aware of the 2.4/2.6 changes - or atleast thought I
was.
I was unaware of the uCLinux-dist distinction.
>
> uClinux-2.4.x is essentially a patch against a regular Linux kernel to
> add support for CPUs without MMU, and various CPU architectures of
> that kind (including MicroBlaze). It's also distributed as a CVS tree
> from www.uclinux.org and other places.
>
> As of 2.6 the core NOMMU support is merged into mainline, but SnapGear
> still maintain linux-2.6.x-uc0 patches because the barrier for entry
> to mainline kernel.org is much higher, so there are always a bunch of
> patches (and NOMMU arches) waiting to be merged upstream.
>
> uClinux-dist is a build environment that inclues libs (uClibc, glibc,
> plus misc libraries) user apps, filesystem creation tools, and a whole
> lot of glue to build a single downloadable blob that is an embedded
> Linux system.
I have not tried to use crosstool to build a microblaze GCC -
technically it can't at the moment because microblaze is not part of the
normal GCC toolchain.
But crosstools typically builds whatever version you ask of gibc and
and binutils and ...
I am not looking for somebody else's idea of how to create a blob
for an embedded system. I already have a perfectly good working
environment/tools/etc for the ppc405 and a whole family of target
boards. I am looking to add MicroBlaze support as another component in
the same environment. I need very little more than a GCC toolchain to
compile the kernel, and busybox (glbc/uClibc,... for the moment I don't
really care)
>
> This is the "massive collection of software" of which you speak.
>
> Everyone has their preference, but for me the ability to type "make"
> at a toplevel and end up with a complete kernel, filesystem and binary
> blob at the end of it makes uClinux-dist (and our modified version,
> petalinux-dist), the tool of choice. \
You may be right. After playing with the uClinux-dist approach I may
feel the same as you. But we are not in the Windows world where there is
one and only one way to do things.
I think crosstool is the normal way to get a toolchain for about 50%
of embedded systems with and MMU - even when you get one from a vendor,
it probably was crosstool generated.
>
> I am currently unifying the microblaze and PPC 2.4 kernel trees - so
> you can build either microblaze or PPC systems in the same PetaLinux
> environment. This should be rolled out for public consumption in the
> next few weeks. The merge is relatively straight forward, but testing
> all shared devices on both CPUs on multiple boards is time consuming.
>
> This is in 2.4 space. 2.6 is on the way as well for MicroBlaze, and
> the unification of MicroBlaze and PPC trees for 2.6 is an obvious goal
> as well.
I am sure alot of people care, but 2.4 is pretty much dead for me.
When we started with Linux support, we made a deliberate decision to
skip 2.4. Overall I think that was wise. 2.6 has provend capable and
stable enough by the time our boards were actually ready for Linux. We
took advantage of a number of 2.6 features that are not in 2.4 and
trying to go back would be an enormous amount of work. We are small, we
can not support multiple concurrent Linux versions. That is also part of
my uCLinux-dist issues above. PicoComputing Embedded OS Support is Me.
That is ppc Linux, mircoblaze Linux, GreenHills, with other embedded
OS's in the pipeline. Not to mention that target OS support is only
about 60% of my responsibilities.
Doing MicroBlaze totally different from the ppc is a very heavy price to
get MicroBlaze Linux.
Prototypes for Pico's next generation of boards - Virtex based with
no PPC are due as preproduction samples in mid march. Once they show up,
the spotlight will be on me to bring up Linux on them.
Both Pico and I personally are really strong adherents to the KISS
principle. a Pico E12 is a radically simpler device than say an ml403.
The E14 (and forthcomming E15) is bigger faster and has more capability
than an E12 - but the same Linux (or GreenHills) binary will boot on it.
The E16 has no PPC, is faster and has more gates - but all the other
design parameters are the same as the others. I hope to do very little
more than build almost the same BSP for a different processor.
>
> I hope this clears things up somewhat.
Thanks alot, I am greatly appreciative - I am sure I still have alot
of misperceptions left, but you have clarified many things.
I am trying to DL the Xilinx GCC sources as I write. Of course I
"logon" to Xilinx site about once in a blue moon so I am waiting for
them to remind me of what my password was.
I am going to try to see about incorportating either a diff or their
source into the crosstool build process.
If I can succeed that gives me the best shot at retaining all the
build resources I already have.
Regardless, I think I now have a better understanding of the uClinux
process.
>
> 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/
>
>
___________________________
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/