Back from holiday....

Spent a lovely week with my wife and other close family in the south west of England, all the way down to the Lizard Peninsula.

I get to attend the IDESA "Advanced Digital Physical Implementation flow" Course

IDESA is intended to kickstart the production of both analog and digital <=90nm CMOS among academia. I have got a place on the Advanced Digital Physical Implementation flow course hosted by Rutherford Appleton Laboratories in Didcot, Oxfordshire (the courses are available from other host institutions as well). The week looks very interesting:

• Day 1: Intro, design environment and toolchain + LAB
• Day 2: Leakage aware design and prevention, floorplanning LAB, design planning and libraries (including IP, soft and hard).
• Day 3: Low power flow including positioning to minimise dynamic and leakage power, physical synthesis placement and optimisation. Multiple Clock Tree Synthesis.
• Day 4: Physical Synthesis, Design for Test, Multimode and Multicorner, Routing to GDSII and labs.
• Day 5: IR drop analysys, dynamic power analysis, on chip validation and statistical static timing analysis. Lab on signoff, signoff and design finishing and layout verification. Tape-out.

Anyway I am keen to angle my way onto other courses of this quality that are on offer.

Need a SPARC version of "ARM System-on-chip Architecture"

"ARM System-on-chip Architecture", by Steve Furber is an excellent book for anyone wanting to get an OS or other software running well on the ARM range of microprocessor cores. Now if there is an equivalent for SPARC architectures please let me know as that is the current problem I am facing!

Coursework for Academics....

We are now discussing the changes to the courses for next academic year. The main push on at the moment is directed at enhancing our teaching of software to the electronics undergraduates.

COMP1010 Big changes here to alter how we teach this module. The previous course centered on teaching as much C as possible using Visual Studio, with a lab a week reinforcing the lecture topic. To improve things by engaging the students more we are moving a lot of the C syntax and content into the semester 2 course. This leaves room for the introduction of AVR microcontrollers along with a bit of computer architecture. Hopefully this will engage the students immediately. The programming will be done in AVRStudio with WinAVR as the compiler. The assessment will be significantly changed to favour two "Exam Labs" which will be open book individual assessments. The first will have a lot of direction and the second will be solving a problem. Appropriate assessment of any course is essential for its success, and I personally belive in problem based learning as one of the most enjoyable and effective techniques.

ELEC1013 The main change here is the labs have been shortened and there will be more of them. There is also an open question whether to include an AVR Microcontroller that can be used over USB or networked to encourage the Computer Science students who take this course to mess about with gadgets.

Do the multipathing first, and the mirroring afterwards!

If you are using a mirrored root under Disksuite and wish to enable mpxio I wish you well. It is a devil of a job, mainly due to the fact that stmsboot won't recognise your metadevice as a STMS device and so won't enable it.

So to fix it here is the answer:

1. Back everything up. EVERYTHING
2. Follow the guide here to undo the mirrored root
3. Run stmsboot -e and reboot immediately
4. Everything should now be correctly multipathed using mpxio
5. Rebuild all the mirrored root and other devices

and next time, do the multipathing first and the mirroring afterwards!

Adding a package called "leon-bootloader" to Angstrom

I wonder how to handle this. Typically Angstrom downloads source packages from the internet as needed, however in this case the bootloader is never supplied as a separate download. Downloading and extracting snapgear linux to get at it doesn't appeal, neither does distributing it by myself. I am also uncertain whether Angstrom would accept a complete source package in their download system for such a niche market.

Imagination Technologies Visit

I have just had the pleasure of hosting some representatives of Imagination Technologies.

It was a productive day, and I am looking forward to some really interesting projects and cooperation coming our way.

Writing Referral Exam Questions

Unfortunately not all students pass the exam, and this is their second chance. History suggests that some will work very hard and do well, and some will (despite hard work in some cases) not. In many ways this is quite a difficult part of being an academic - assessment.

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.