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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
