The LEON3 sparc linux bootloader generation process is awful

1. Uses a combination of make and perl scripts reading from a global config.
2. Includes including includes including includes.
   
3. Variables drawn directly from .config files and the aforementioned headers, some of which are written by perl scripts driven from variables as above.
   
4. Uses gcc to edit a text file and then calls the result a .o (it is plain ASCII) after hardcoding all of the paths.

I either choose to sanitise this system, or just package it and gingerly push options in its general direction. It is also unclear what license it is under, however as it is part of a linux distro build process I believe that puts it under the GPL whether it is explicit or not.

Broken DDR DIMM replaced, now to continue..

Replaced the broken DDR DIMM (which has a lifetimes warranty) and now to get on with things.

Trouble! Things that were working just fine, now are not

Basically the system now claims it cannot see the DDR! Which is a blow. I don't know why but I am getting the dreaded 'stack pointer not set' errors and the system doesn't seem to think it has any memory. I am wondering if I need to add in a bit more manual deskewing or whether I have actually broken something (I certainly hope not!).

More to follow....

Booted the Kernel built by Angstrom on LEON3

... but not the ramdisk. I seem to be having trouble with it at the moment. I shall investigate it properly tomorrow. Perhaps I haven't got enough RAM enabled, which can be a real problem apparently. Kernel hangs if you run out without error messages.

Just to be clear: I took the kernel from snapgear linux. I just created a single large patch against vanilla 2.6.21.1. The patch is quite large and I didn't want to care about such things.

However the version of glibc and the compiler are completely different. I don't yet know if this is going to cause stability problems, but I can just constrain Angstrom to use the right versions from the snapgear toolchain. Such is the power of OpenEmbedded.

Angstrom building for SPARC

By poaching files and diffs from snapgear, Angstrom is merrily building away.

Slowly debugging issues and learning more than I ever wanted to know about the linux boot process.
Issues:

• Does it work? Angstrom at the moment is building with gcc4 not 3.
• Are there necessary glibc patches? If so I haven't done anything to apply any.
• I need to fix the ramdisk builds.
• Will udev work?

Anyway, off home now!

Beginning work on modifying angstrom...

Seems that point 1 from below is already taken care of! Angstrom is setup for a sun4cdm with a supersparc CPU. I am building it now and hope to take care of packaging it for use in TSIM and GRMON as an image etc. (not that I have TSIM unfortunately).

Snapgear Linux or Angstrom..

I am currently building and deploying Snapgear linux onto a LEON3 system aboard a xilinx-xup board. However I have several issues with Snapgear:

1. Despite all the hard work that has gone into it, it feels poorly constructed. I think they are discovering just how hard it is to maintain and build embedded linux distros. I am thinking of the early days of OpenZaurus
   
2. Functionality that just doesn't work out of the box: dhclient, openssl, ssh and sshd. Pretty fundamental tools here. Not to complain about the good work of uCdot

I think I shall try to get Ångström up and running as it is much better at handling these things. The main effort will be:

1. Toolchain. Assembling the patches and CFLAGS etc for the toolchain (glibc in the first instance).
2. Backend: Packaging the system such that it will be able to build images for the various GR tools.

Further posts will follow as I address these issues. Overall I think it is more valuable than fixing problems in Snapgear.