Hi all,

I've been working at cleaning up some lingering loose ends on the i386
architecture. This patch series cleans up the bulk of them. This series
in itself is really a number of smaller incemental steps needed to get to
where I wanted to be.

Patches 1 though 6 only effect i386 specific code (cpu/i386, lib_i386 etc)
these patches are needed to get my development platform (eNET board) up
and running again (mainline has drifted away a little since I last worked
on this board and a new gcc caused some compile issues as well)

Patches 7 through 9 effect drivers outside the i386 build tree, however
as far as I can tell, these drivers are only used by the sc520_cdp and
sc520_spunk boards

Patches 10 and 11 fix up the sc520_cdp and sc520_spunk boards. I did not
include these fixes in the above patches because:
  a) The boards were already broken, and;
  b) It made more sense to me for this patch series to be a series of
     little steps towards the end fix rather than one big jumbled jump

As of patch 11, all i386 boards build clean. sc520_cdp and sc520_spunk
could probably work now, but without either board available to test, I
cannot confirm.

Patches 12 and 13 bring a couple of i386 components inline with u-boot
design philosophy

Patch 14 adds PCI support to the eNET board in preparation for getting
networking up and running

At this point, I noticed that my board would sometimes hang during Flash
initialisation - looked like probing the Boot Flash was conflicting with
the execute in place. I don't really know why it started to happen, but
I decided it was about time to move u-boot into RAM which is what patches
15 through 17 do. I have not implemented proper relocation. Sorry
Wolfgang, I know you'll hate what I have done, but it is the next step
towards what will hopefully one day be real relocation.

_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to