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