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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
