mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Trent Piepho <tpiepho@kymetacorp.com>
Cc: barebox <barebox@lists.infradead.org>
Subject: Re: Barebox on small memory systems
Date: Tue, 12 Apr 2016 20:35:55 -0700	[thread overview]
Message-ID: <CAHQ1cqH78JnvYEcRVWJX_s6aSDn_1L+nurtu0L5bofPyHkNLQQ@mail.gmail.com> (raw)
In-Reply-To: <1460506588.9103.26.camel@rtred1test09.kymeta.local>

> 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

  reply	other threads:[~2016-04-13  3:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13  0:15 Trent Piepho
2016-04-13  3:35 ` Andrey Smirnov [this message]
2016-04-26 20:34   ` Trent Piepho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHQ1cqH78JnvYEcRVWJX_s6aSDn_1L+nurtu0L5bofPyHkNLQQ@mail.gmail.com \
    --to=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=tpiepho@kymetacorp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox