On Tue, Nov 04, 2014 at 10:20:46PM +0100, Wolfgang Denk wrote:
Dear Tom,
In message 20141104205800.GM15133@bill-the-cat you wrote:
Well, we probably should not use this FDT centric decoding function directly on arguments passed from the U-Boot command line.
No, look again at what we're doing. We're not calling a U-Boot function to do U-Boot things. We're calling a U-Boot function to set a DT property. U-Boot needs to obey DT conventions here.
Well, we are running an U-Boot command. And U-Boot documentation says that we use hex inpout base (with the only unlucky exception of the sleep command). So this _command_ should also assume hex input.
... when we can make assumptions about the input, yes.
I can see an argument that we could try and make the heuristics smarter to add '0x' to obvious hex strings, but that'll just cause crazier errors when 0x1000 is passed in and seen as 1000 decimal.
Right. So before calling the fdt code, the U-Boot command should normalize the number.
Hm.... is there a way to determine in advance where we are passing a number as argument [see "common/cmd_fdt.c" lines 260ff] ?
The problem is that 'fdt set ... <decimal>' is valid and 'fdt set ... <0xhex>' is valid (as it 'fdt set ... string'). What I'm saying is that we should think of it as 'fdt set <input to DT>' and within <input to DT> we assume DT conventions, not U-Boot conventions.