Flat device trees always have integers in their structure stored as
big-endian. From this point of view, property values are
bags-of-bytes and any endianness is up to users of the device tree to
determine.
The libfdt testcases which use properties with integer values,
currently use native endian format for the architecture on which the
testcases are run. This works ok for now, since both the creation and
checking of the example device trees happen in the same endianness.
This will become a problem, however, for tests of dtc which we want to
add in the nearish future. dtc always uses big-endian format for
'cell' format data in properties; as it needs to in order to produce
powerpc-usable device trees when hosted on a little-endian
architecture.
This patch, therefore, changes the libfdt testsuite to use big-endian
format always for integer format data, in order to interoperate sanely
with future dtc testcases. This also means that the example trees
created by the testsuite should now be byte-for-byte identical
regardless of dtc and libfdt's host platform, which is arguably an
advantage.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The libfdt functions are supposed to behave tolerably well when practical,
even if given a corrupted device tree as input. A silly mistake in
fdt_get_property() means we're bounds checking against the size of a pointer
instead of the size of a property header, meaning we can get bogus
behaviour in a corrupted device tree where the structure block ends in
what's supposed to be the middle of a property.
This patch corrects the problem (fdt_get_property() will now return
BADSTRUCTURE in this case), and also adds a testcase to catch the bug.