[PATCH dtc] Implement the -R option and add a -S option.
Jerry Van Baren
gvb.uboot at gmail.com
Sun Apr 15 12:41:48 EST 2007
David Gibson wrote:
> On Sat, Apr 14, 2007 at 10:13:49PM -0400, Jerry Van Baren wrote:
>> David Gibson wrote:
>>> On Sat, Apr 14, 2007 at 08:58:49AM -0400, Jerry Van Baren wrote:
>>>> On an unrelated related note, I don't believe my -R additions are
>>>> actually putting out additional reserve map slots (easiest to see using
>>>> the asm format output). I'm still trying to understand why not, it
>>>> seemed pretty straight-forward. When I implemented it, I was looking at
>>>> hexdumps of the dtb binary format and looking at the header and thought
>>>> I had it working... using it with my u-boot mods shows no extra reserved
>>>> slots. I'm looking into where I went wrong.
>>> Be careful to check the actual offsets. Bear in mind that objdump may
>>> elide zero words. Also bear in mind that the only way a reader of the
>>> device tree has of counting the number of reserve entries is stepping
>>> through until it hits the terminating (0,0), so the extra entries will
>>> just look like an early termination of the list. In this sense -R
>>> doesn't add "extra slots", but just ensures that there is space after
>>> the reserve map to add more entries.
>> Hi David,
>> It actually is OK, went back and verified it. I needed to modify the
>> asm output to implement the -R extra slots which was confusing me (patch
>> that you didn't like the calloc in ;-).
>> The calloc change was actually window dressing, I was just being
>> paranoid about a binary blob that is bigger than its contents (has extra
>> space). The unused space is unused, so it doen't really matter if it is
>> non-zero. I'll roll a new version.
> Oh, I think zeroing it is correct, I'd just prefer it was done at the
> callsite, rather than within xmalloc(). Strictly speaking you're
> right, what's in the extra area shouldn't matter, but I don't like the
> idea of potentially leaking random memory contents to file, which I
> think could happen without a memset(). Because dtc is unpriveleged it
> shouldn't actually matter, but it's ugly and a bad habit to establish.
Where I got concerned was a conversion of a .dtb input into a .dts or
.asm output (or even a .dtb output). I've run it and verified that the
extra space (which is potentially random garbage) is not copied to the
output - the size in the header is what it is and the data output is
only the actual data (no major surprise there).
Generating a text output format actually strips the extra size/data
because dtc turns it back into a symbolic form and padding is outside of
the symbolic form, if you follow my drift (there isn't a way to
represent extra blob padding in a dts format).
More information about the Linuxppc-dev