mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH 2/2] arm/cpu/start.c: Avoid copying device-tree when possible
Date: Wed, 30 Sep 2015 09:00:16 +0200	[thread overview]
Message-ID: <20150930070016.GY7858@pengutronix.de> (raw)
In-Reply-To: <CAHQ1cqFEsiq7Qumi54aJv2C_nh7xkR0jkrBnU5Z6jyhWp3zmKQ@mail.gmail.com>

On Tue, Sep 29, 2015 at 10:52:27AM -0700, Andrey Smirnov wrote:
> >> +                     }
> >> +
> >
> > At this place it is unknown where in memory the fdt is. It could well be
> > somewhere in the malloc area space, so we need to move it to a safe
> > place before we setup malloc in the next step.
> 
> I didn't do an exhaustive search in the source but it seemed like all
> of the callers of barebox_arm_entry() were calling it either with NULL
> or some build-in address, so I assumed that this change shouldn't be a
> problem for non-relocatable binaries, but you are right, semantics of
> the functions does not restrict the location of fdt data.

For most if not all boards the fdt is built into the PBL. The PBL can
run on any place. Take for example the Karo i.MX6 board. The load
address is configured as 0x20000000 which in somewhere in the middle of
the SDRAM. This is where the PBL is executed and thus also the place
where the builtin fdt is stored. Now the PBL extracts the barebox binary
to near the end of SDRAM and jumps there. The fdt is now somewhere in
the middle of SDRAM where it will be overwritten by the malloc pool
sooner or later.

> 
> I'd still like to discuss the possibility of introducing a feature
> like that to the codebase. Right now I have a use-case where I use
> Barebox as a DDR memory tuning/testing tool on i.MX6Q where I upload
> the image to IRAM via JTAG and execute Barebox straight out of SRAM.

I understand your usecase and I think it's worth supporting it.

So what are our options? You could run the tuning/testing completely
from the PBL. We now have console support in the PBL, so you can output
the results. You cannot do any interactive things though. We could add
simple getc() support to the PBL, but something like a shell is out of
reach. Do you need interactive input anyway?
Another possibility would be to make device tree support optional for
i.MX6. It is optional for the other i.MXes for historic reasons, so we
could make it optional for i.MX6 aswell. This would give you another
~30K which is now used by the dtb.
I'm a bit afraid that the regular-barebox-in-SRAM usecase will break
quite frequently upstream because the image gets too big or simply
because some other changes have side effects. For this reason I would
really prefer the PBL way if that's possible for you.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

  reply	other threads:[~2015-09-30  7:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-26  6:02 [PATCH 1/2] arm/cpu/start.c: Distil some common code in __start() Andrey Smirnov
2015-09-26  6:02 ` [PATCH 2/2] arm/cpu/start.c: Avoid copying device-tree when possible Andrey Smirnov
2015-09-29  6:58   ` Sascha Hauer
2015-09-29 17:52     ` Andrey Smirnov
2015-09-30  7:00       ` Sascha Hauer [this message]
2015-09-30 17:56         ` Andrey Smirnov
2015-10-01  6:22           ` Sascha Hauer
2015-10-06 17:35             ` Andrey Smirnov

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=20150930070016.GY7858@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    /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