Barebox on small memory systems

Barebox on small memory systems

[Trent Piepho]

I'm considering porting barebox to Altera's Arria10 SoC.  A key
difference from the existing Cyclone V support is that the SoC SDRAM
controller is part of the FPGA scanchain.  Which means that in order to
use SDRAM, the bootloader must load a file much larger than the maximum
bootloader size into the FPGA.

With Cyclone V the code needed to use SDRAM is a few kB, fits inside the
60 kB maximum bootloader size, and runs as part of the barebox PBL.  It
seems almost all other ARM SoC's also have SDRAM init code that is small
enough to fit inside barebox.  With Arria 10 the maximum bootloader size
is increased to 204 kB but the code/data needed to use SDRAM is several
MB.  So barebox will need to load it out of flash itself.

In order to get an image file out of flash and programmed into the FPGA,
it's useful to have a number of barebox drivers, like the MCI system,
partition table parsing, FAT filesystem, etc.  Basically getting the
full barebox (with a minimal set of drivers, e.g. no shell) running
without having SDRAM access.

So can one run barebox in 256 Kb?

A minimal config of a non-PBL non-relocatable barebox with the necessary
features is only about 54 Kb.  So that certainly fits.  But that doesn't
include stack, heap, bss, etc.  Can a stripped down barebox actually run
in 256 Kb and mount a FAT filesystem to get a next stage bootloader?
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox on small memory systems

[Andrey Smirnov]

> In order to get an image file out of flash and programmed into the FPGA,
> it's useful to have a number of barebox drivers, like the MCI system,
> partition table parsing, FAT filesystem, etc.  Basically getting the
> full barebox (with a minimal set of drivers, e.g. no shell) running
> without having SDRAM access.
>
> So can one run barebox in 256 Kb?

I was able to do it, although in a different, but IMHO comparable
configuration. My use-case was running bare minimum Barebox _with_ the
shell and UART driver, sans everything else out of IRAM (256kB) on
i.MX6Q (the users wanted to be able to tweak DDR controller's
configuration at runtime via BB console interface). If memory serves
me well after system booted I had about 50kB or RAM to spare(although
I don't know what the peak usage was during boot process)

>
> A minimal config of a non-PBL non-relocatable barebox with the necessary
> features is only about 54 Kb.  So that certainly fits.  But that doesn't
> include stack, heap, bss, etc.  Can a stripped down barebox actually run
> in 256 Kb and mount a FAT filesystem to get a next stage bootloader?

The image I was building was indeed a non-PBL non-relocatable variant,
however I had to do three further modifications:

- Disable MMU, becuase just the page table alone in my case would take
about 1MB or space
- Create a stripped down .dts that didn't include Kernel's .dts and
contained only bare minimum
- Apply the following patch to avoid copying device tree blob and
process it in-place instead

From 3f9b5b2631de9fa5a270012c09e18a145946e728 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov <andrew.smirnov@gmail.com>
Date: Sun, 8 Nov 2015 16:39:42 -0800
Subject: [PATCH] arm/cpu/start.c: Avoid copying device-tree when possible

In case of non-relocatable image device-tree blob should already be
preloaded into memory as a part of Barebox binary upload, so there is
no need to 'memcpy' it again

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 arch/arm/cpu/start.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/start.c b/arch/arm/cpu/start.c
index e037d91..7489014 100644
--- a/arch/arm/cpu/start.c
+++ b/arch/arm/cpu/start.c
@@ -179,8 +179,17 @@ __noreturn void barebox_non_pbl_start(unsigned
long membase,
  const char *name;

  if (blob_is_fdt(boarddata)) {
- totalsize = get_unaligned_be32(boarddata + 4);
- name = "DTB";
+ if (!IS_ENABLED(CONFIG_RELOCATABLE)
+    && !IS_ENABLED(CONFIG_PBL_IMAGE)) {
+ /*
+  If Barebox is not relocatable
+  there's no need to move data around
+ */
+ barebox_boarddata = boarddata;
+ } else {
+ totalsize = get_unaligned_be32(boarddata + 4);
+ name = "DTB";
+ }
  } else if (blob_is_compressed_fdt(boarddata)) {
  struct barebox_arm_boarddata_compressed_dtb *bd = boarddata;
  totalsize = bd->datalen + sizeof(*bd);
-- 
2.5.5

Hope this helps.

Andrey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox on small memory systems

[Trent Piepho]

On Tue, 2016-04-12 at 20:35 -0700, Andrey Smirnov wrote:
> > In order to get an image file out of flash and programmed into the FPGA,
> > it's useful to have a number of barebox drivers, like the MCI system,
> > partition table parsing, FAT filesystem, etc.  Basically getting the
> > full barebox (with a minimal set of drivers, e.g. no shell) running
> > without having SDRAM access.
> >
> > So can one run barebox in 256 Kb?
> 
> I was able to do it, although in a different, but IMHO comparable
> configuration. My use-case was running bare minimum Barebox _with_ the
> shell and UART driver, sans everything else out of IRAM (256kB) on
> i.MX6Q (the users wanted to be able to tweak DDR controller's
> configuration at runtime via BB console interface). If memory serves
> me well after system booted I had about 50kB or RAM to spare(although
> I don't know what the peak usage was during boot process)

I've done some trials now by booting a small barebox configured for
256kB from a real barebox.  I could get a shell-less non-relocatable
non-pbl barebox to work, with mci, fat, partition, uart, i2c, eeprom
drivers.  But with the simple shell I run out of heap space (116Kb of
heap) as the shell runs init scripts.

Found a few issues when trying to optimize barebox:

PBL without relocation doesn't work because the PBL and main barebox try
to link at the same TEXT_BASE value.

One can't specify a TEXT_BASE when using relocation.  barebox always
links at 0, even if you know it will usually be loaded at a certain
address.

socfpga relocates the PBL twice.  The board entry function does it and
then the code in start.c does it again.

> > A minimal config of a non-PBL non-relocatable barebox with the necessary
> > features is only about 54 Kb.  So that certainly fits.  But that doesn't
> > include stack, heap, bss, etc.  Can a stripped down barebox actually run
> > in 256 Kb and mount a FAT filesystem to get a next stage bootloader?
> 
> The image I was building was indeed a non-PBL non-relocatable variant,
> however I had to do three further modifications:
> 
> - Disable MMU, becuase just the page table alone in my case would take
> about 1MB or space

Thanks for the hint, I needed to do this too.  Even mapping just 1MB
takes a significant amount of space.  Also the MMU code appears to crash
if one tells it to map less than 1MB.

> In case of non-relocatable image device-tree blob should already be
> preloaded into memory as a part of Barebox binary upload, so there is
> no need to 'memcpy' it again

Why does the dtb ever need to be copied?  It looks to me like a
relocatable barebox will copy from _text to __bss_start to the
relocation address.  The compiled in dtb data will be that range.  So in
the relocation case, what's the point of the copying it a second time?

Seems like the only reason to copy it would be if it was an external dtb
image provided to barebox by another bootloader.  Is there anything that
can do this besides a PBL?
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox