Dear Ian,
In message 1415116135.11486.51.camel@hellion.org.uk you wrote:
/*
- Parse the user's input, partially heuristic. Valid formats:
- <0x00112233 4 05> - an array of cells. Numbers follow standard
C conventions.- [00 11 22 .. nn] - byte stream
- "string" - If the the value doesn't start with "<" or "[", it is
treated as a string. Note that the quotes arestripped by the parser before we get the string.which is inconsistent with the "U-Boot uses hex input base by default" mantra.
Because this is FDT centric and not U-Boot centric, yes?
I guess?
Well, we probably should not use this FDT centric decoding function directly on arguments passed from the U-Boot command line.
Since <decimal numbers> is a valid thing to do in an entry here. I think the right answer is the more hacky sounding one of when you script using 'fdt set' you need to be mindful of the constraints on input that are imposed upon us by FDT. <hex> is invalid but <0xhex> is what is expected.
The 0x prefix hack/trick is what I'm actually doing, but the maintainer of our test system wanted some assurances that u-boot wasn't going to change under our feet if someone fixed a bug.
I think this is a hack that is bound to break. Today you use $filesize, tomorrow you may find you need to perform some operations on this (say, rounding up in some way), and you may end up with a variable that already contains a "0x" prefix, and your code will fail beause 0x0x... gets misinterpreted.
Sounds like you are saying this is all working as designed, and there is no bug, but I'll let Wolfgang and you thrash that out ;-).
Tom: this is a bug ;-)
Best regards,
Wolfgang Denk