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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux