[U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

[Chris Packham]

Hi Wolfgang,

On Thu, May 20, 2010 at 1:35 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Chris Packham,
>
> In message <loom.20100520T005209-871 at 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