[U-Boot] Segmented RAM, big userspace.

[U-Boot] Segmented RAM, big userspace.

[Sergey Lapin]

Hi, all!

We have a board, based on s3c2416, with 128MB of RAM
and 1GB of NAND flash.
RAM is organized as 2 memory banks with far placed bases:

TOP

UNUSED 64MB

64MB SDRAM

--- 128MB segment base 1 -----

UNUSED 64MB

64MB SDRAM

-- 128MB segment base 0 ------

BOTTOM

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. And now we have root filesystem
which we need to flash using u-boot, which is a little over this 64MB limit.

Is there some way to use second memory bank from u-boot?
Is it possible to tftp file in parts and flash it on NAND in parts?
(This requires handling of bad blocks too)

We need to flash using u-boot, that's requirement for speedy production.

It is possible to flash filesystems in parts, but for this to work
these are needed to be properly split. This raises a problem of
bad blocks - writing previous piece might end not where you expect it to
end, but a few blocks later. Hand-handling this case is too error-prone.

Thanks a lot,
S.

[U-Boot] Segmented RAM, big userspace.

[Wolfgang Denk]

Dear Sergey Lapin,

In message <20111213160810.GA27440@build.ihdev.net> you wrote:
> 
> We have a board, based on s3c2416, with 128MB of RAM
> and 1GB of NAND flash.
> RAM is organized as 2 memory banks with far placed bases:
> TOP
> UNUSED 64MB
> 64MB SDRAM
> --- 128MB segment base 1 -----
> UNUSED 64MB
> 64MB SDRAM
> -- 128MB segment base 0 ------
> BOTTOM
> 
> 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?

I would expect that U-Boot (with all it's heap and stack and
everything) sits only at the upper end of the upper bank of memory (in
your sgment 1).

>                                   ... . And now we have root filesystem
> which we need to flash using u-boot, which is a little over this 64MB limit.

Split it?

> Is there some way to use second memory bank from u-boot?
> Is it possible to tftp file in parts and flash it on NAND in parts?
> (This requires handling of bad blocks too)
> 
> We need to flash using u-boot, that's requirement for speedy production.

I somewhat doubt that. Booting Linux is probably a matter of 2 or 3
seconds, or less.  You migth save that time again by using Linux' much
better performing network stack, together with interleaving network
traffic and flash writing.

If I were in this situation, I'd probably run this under Linux.

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
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)

[U-Boot] Segmented RAM, big userspace.

[Sergey Lapin]

On Tue, Dec 13, 2011 at 05:24:22PM +0100, Wolfgang Denk wrote:
> Dear Sergey Lapin,
> 
> In message <20111213160810.GA27440@build.ihdev.net> you wrote:
> > 
> > We have a board, based on s3c2416, with 128MB of RAM
> > and 1GB of NAND flash.
> > RAM is organized as 2 memory banks with far placed bases:
> > TOP
> > UNUSED 64MB
> > 64MB SDRAM
> > --- 128MB segment base 1 -----
> > UNUSED 64MB
> > 64MB SDRAM
> > -- 128MB segment base 0 ------
> > BOTTOM
> > 
> > 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.
If we specify memory size to 64MB, u-boot works, but we lose
access to second segment (segment 1). Or at least have not really
comfortable placement.

> 
> I would expect that U-Boot (with all it's heap and stack and
> everything) sits only at the upper end of the upper bank of memory (in
> your sgment 1).
> 
> >                                   ... . And now we have root filesystem
> > which we need to flash using u-boot, which is a little over this 64MB limit.
> 
> Split it?
There comes issue of NAND bad blocks.
> 
> > Is there some way to use second memory bank from u-boot?
> > Is it possible to tftp file in parts and flash it on NAND in parts?
> > (This requires handling of bad blocks too)
> > 
> > We need to flash using u-boot, that's requirement for speedy production.
> 
> I somewhat doubt that. Booting Linux is probably a matter of 2 or 3
> seconds, or less.  You migth save that time again by using Linux' much
> better performing network stack, together with interleaving network
> traffic and flash writing.
> 
> 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.

tftp is needed for development and images actually can be split, but
it is quite hard to flash them properly.

Thanks a lot,
S.

[U-Boot] Segmented RAM, big userspace.

[Wolfgang Denk]

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

[U-Boot] Segmented RAM, big userspace.

[Scott Wood]

On 12/13/2011 10:08 AM, Sergey Lapin wrote:
> It is possible to flash filesystems in parts, but for this to work
> these are needed to be properly split. This raises a problem of
> bad blocks - writing previous piece might end not where you expect it to
> end, but a few blocks later. Hand-handling this case is too error-prone.

Use a separate partition for each chunk.  Each partition should have
extra space for as many bad blocks as you reasonably anticipate in that
partition.  The start address of each partition is fixed, regardless of
the number of bad blocks in previous partitions.

-Scott