[PATCH 2/2] arm/cpu/start.c: Avoid copying device-tree when possible

Andrey Smirnov andrew.smirnov at gmail.com
Tue Sep 29 10:52:27 PDT 2015

>> +                     }
>> +
> 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.

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.
With only 256K of total memory availible I just don't have enough RAM
to do this precautionary step of copying ~30K or .dtb. Do you see a
place for a feature like that in upstream code? Something like a
Kconfig option, similar to CONFIG_PBL_FORCE_PIGGYDATA_COPY, that can
be selected on per-board basis and would enable the shortcut?

> 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 |

More information about the barebox mailing list