On May 15, 2012, at 9:38 AM, Rafal Jaworowski wrote: >> >> Should I overwrite the FDT in the kernel with the >> edited FDT? That doesn't feel quite right, but it's >> essentially what the FDT code here was trying to >> do before. > > A given DTB (loaded dynamically or statically embedded in the kernel) has > some small amount of free space inside it so it is possible to perform > in-place modifications, adding properties / nodes until you run our of this > space (libfdt code will handle cases when exceeding this and would fail > gracefully). The fixup mechanism currently implemented does minor > modifications of the device tree in this fashion.
I've fixed the code in sys/boot/fdt/ to do all access through copyout/copyin. I'm waiting for a "make universe" to make sure I didn't break something inadvertently, and will probably commit it tomorrow. Right now, this just copies the DTB to a malloc-ed area, modifies the copy and then writes it back to the same place (either in the kernel or in a separately-loaded blob). It seems to work correctly even when copyout/copyin are doing address translations. > ... if you'd like to modify the blob in a major way you need to relocate it > into a new location with more padding …. create a DTB metadatum (as if the > DTB was loaded dynamically from standalone blob file) with sufficient space, > …. and pass this new copy (as part of regular loader(8) metadata) to the > kernel for processing. The building blocks are there (DTB loaded as metadata) > and should work. Yes, I see how that would work. Is there a real use for this? I could take a look at it once I'm finished with the current ubldr work I'm doing. Tim _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
