[U-Boot] Segmented RAM, big userspace.

[Wolfgang Denk <wd@denx.de>]

Dear Sergey Lapin,

In message <20111213165113.GA27964@build.ihdev.net> you wrote:
>
> > > So we could have only 64MB as one piece; Due to u-boot reloaction code we
> > > need to have u-boot in first 64MB also. ...
> > 
> > Why would that be the case?
> 
> If we specify memory size as 128MB (gd->ram_size) u-boot reloacates itself to unused
> part of first memory bank instead of the end of second bank, which
> actually makes it fail badly.

You are not supposed to "specify" RAM sizes.  You should use
get_ram_size() to auto-detect the installed size, and do this
separately for each bank of memory.

I'm not sure if the relocation code on ARM makes any assumptions that
the memory is contiguous, but it should be relatively easy to fix so
that it always relocates to the end of the last (highest) bank of
memory.

> > If I were in this situation, I'd probably run this under Linux.
> Well, we already running production using u-boot.
> And on production devices we have no (fast) network access.
> We boot u-boot from mmc, which flashes images on the same card
> and then boots device. I can't see how faster we can be with Linux,
> which will add several more seconds to boot.

Linx MMC drivers and file system code will probably be way faster
than what we have in U-Boot, and you can inteleave reading from MMC
with writing to NAND - actually you can do it fully in parallel uner
Linux (using for example "buffer" or similar tools).

Until you really measure it you should not make assumptions which way
is faster.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made the integers; all else is the work of Man.       - Kronecker