Hi Wolfgang, On Thu, May 20, 2010 at 1:35 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Chris Packham, > > In message <loom.20100520t005209-...@post.gmane.org> you wrote: >> >> While it would be possible to shuffle the memory map around there is one >> problem with the hardware design that I don't think can be overcome (I'd >> love to be proven wrong). The boot chip select is mapped to the _bottom_ >> of the first flash chip. It was done this way so that we could expand the >> flash in the future as a rolling production change (we're now shipping >> units with 64MB fitted). i.e. we knew we could rely on a fixed base >> address so thats where we pointed the boot chip select. > > I don't see why this should be relevant. Usually you can set up nearly > any memory map in software, independent of the CPU state at boot time. > > Which exact processor family are we talking about?
Freescale MPC8541. CS0 is mapped by an external CPLD to either the bottom block of flash _or_ to a plug in card which has physical EPROMs which we use when we're bringing the board up. On newer designs we actually use pre-programmed flash chips in the factory and JTAG in circuit debuggers for development. >> I think in hindsight we could have modified our flash detection code to >> start at the top and jump backwards looking for extra chips. Unfortunately > > What do you mean by "our flash detection code"? Are you using any > private code for that? Why? U-Boot already has all the needed stuff, > just use it. > This design was originally done for a proprietary boot loader before we saw the light and switched to u-boot. That was what I meant by "our flash detection code". Recently we've just switched to using the CFI driver in the latest u-boot version. Prior to this (based on version 1.1.4) we still had our own board/.../flash.c. >> we're not able to change the hardware design for this product but we can >> take this into account on future designs. > > I'm not convinced that any hardware changes would be needed. I think we'd need 2 different boot loaders configurations, one for running from EPROM, one for running from flash. If we ignore the EPROM it wouldn't be too hard to re-define the memory map such that we have flash arranged with the boot loader and environment in the bottom 1MB of the first flash chip with the file system in the top 31MB and optionally the second flash chip. The plug in EPROM card is still very useful when you accidentally brick your board so we'd still want to have that, which could be done easily with the existing configuration. I'll look into shuffling the memory map around. It'd also be a good opportunity to start using the mtd maps in Linux. - C _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot