public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ian Campbell <ijc@hellion.org.uk>
To: u-boot@lists.denx.de
Subject: [U-Boot] Inconsistency between $filesize and commands which accept numeric params.
Date: Thu, 30 Oct 2014 13:57:15 +0000	[thread overview]
Message-ID: <1414677435.2064.34.camel@hellion.org.uk> (raw)

It seems there is some inconsistency wrt number base between commands
which set $filesize in the env and the commands which might consume
them.

e.g.
        
        sun7i# load scsi 0 $fdt_addr_r dtbs/$fdtfile
        21639 bytes read in 191 ms (110.4 KiB/s)
        sun7i# printenv filesize
        filesize=5487
        
So filesize is in hex, but without an 0x prefix. But:
        
        sun7i# fdt addr $fdt_addr_r 0x10000 
        sun7i# fdt set /chosen foo <$filesize>
        sun7i# fdt print /chosen foo          
        foo = <0x0000156f>
        
IOW the parameter to fdt set has been interpreted as a decimal.

If $filesize happens to contains digits [a-f] then:

        sun7i# load scsi 0 $fdt_addr_r dtbs/sun6i-a31-app4-evb1.dtb
        16563 bytes read in 478 ms (33.2 KiB/s)
        sun7i# printenv filesize
        filesize=40b3
        sun7i# fdt set /chosen foo <$filesize>                     
        Sorry, I could not convert "b3>"
        
Obviously I can hack around this with:
        sun7i# fdt set /chosen foo <0x$filesize>

But that seems a bit of an odd thing to have to do (not to mention
potentially fragile).

There seem to be other commands, e.g. mmc write which interpret their
parameters as hex by default, although in that case it does also DTRT
with an 0x prefix.

So I'm not sure if the bug is that setenv_hex doesn't include the 0x, or
that fdt set interprets things as decimal by default instead of hex. Or
maybe there is no bug at all?

Just changing the setenv_hex to include the 0x seemed at first glance
like a good idea, but I'm not really sure.

Thanks,
Ian.

PS my usecase is to implement the fdt based multiboot protocol which Xen
uses in order to load boot-modules, see e.g.
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner#Boot_script
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
(we use something like this on all u-boot based platforms, Allwinner is
just an example).

Ian.

             reply	other threads:[~2014-10-30 13:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30 13:57 Ian Campbell [this message]
2014-10-30 15:21 ` [U-Boot] Inconsistency between $filesize and commands which accept numeric params Wolfgang Denk
2014-10-30 15:32   ` Ian Campbell
2014-11-04 15:44     ` Tom Rini
2014-11-04 15:48       ` Ian Campbell
2014-11-04 20:53         ` Wolfgang Denk
2014-11-04 20:58           ` Tom Rini
2014-11-04 21:20             ` Wolfgang Denk
2014-11-04 22:02               ` Tom Rini
2014-11-04 22:11                 ` Wolfgang Denk
2014-11-04 22:54                   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1414677435.2064.34.camel@hellion.org.uk \
    --to=ijc@hellion.org.uk \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox