Jerry Van Baren wrote: > My concern from the u-boot side is that u-boot has to know exactly > *where* to put the expanded blob because it has to pass it to linux and > keep it out of linux' way so it doesn't get "stepped on." Linux has an > advantage in that it "owns" all of memory and can allocate and > deallocate whatever and wherever and it won't step on itself (hopefully).
Linux is pretty careful not to step on the device tree; it marks the area as reserved, and moves it if it really has to. The only scenario I think would be problematic is if the kernel is started somewhere other than zero, and has to relocate itself, and the relocation clobbers the device tree. That's easily avoided by making sure the device tree is at a higher address than the kernel -- and is really not much different than the old bd_t mechanism, which didn't use a user provided address AFAIK. > I'm assuming your boot wedge has the advantage of being able to use > linux's malloc() and thus don't have to worry about coordinating with > linux on memory allocation. No, it uses its own malloc. > With the current u-boot fdt command, you can resize the blob, and this > can be done in a script with all the (somewhat limited) capabilities of > the u-boot shell (an adaptation of hush). OK, I'm just going by the behavior of the default boot commands on (at least some of) our boards, which just give you an error if the blob isn't already enlarged. Maybe I should just poke Kim et al. about fixing our default environment -- though I'm guessing it'd still have to know from the script how much to enlarge the blob. > In the u-boot world, we fixate on memory maps and putting things in > specific places. I've noticed. :-) -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
