svn commit: r284614 - head/sys/boot/uboot/lib

[Maxim Sobolev]

No, what I am saying is that it sets "fdtaddr=4096" for the value of 0x1000
and that drives btloader nuts. Dumb, yeah! On the positive note got
redpitaya fully working (except lack of the I2C support and actual fpga
support being unknown). But at least I can try to dual-boot it now.

-Max

On Fri, 2015-06-19 at 16:56 -0700, Maxim Sobolev wrote:
> Ian, that's cool and dandy, but I still suggest we put some sanity
checking
> and have certain workarounds in the loader (whenever it does not add
> ambiguity or blows up a code too much of course), so that new folks in
town
> trying to port to new platforms like myself won't spend hours and hours
> hunting known issues and bugs. And hitting those infinite loops is very
> frustrating with no errors or anything. On top of that, in some cases you
> may be stuck with vendor-provided u-boot with no way to patch and
> re-compile. BTW, there is another stupid bug existing in the u-boot
loader,
> which basically sets fdtaddr in decimal not in hex. On my particular board
> this makes ubldr to blow up with CPU exception, unfortunately no
workaround
> is possible since there is no 0x for hex values and majority of cases when
> this variable is set is in hex.
>
> -Maxim

Yeah, I wasn't complaining about the change, I just wanted to let you
know you're not the first one down this path.  Now that you've fixed the
lockup, you'll run into other odd behavior with env vars.

I'm not sure I understand the second problem you mention.  When numbers
are represented as ascii text in the u-boot env, they're always
interpretted as hex constants whether they have a leading 0x or not.
This seems to be a u-boot convention.  Are you saying ubldr is failing
to convert them back to binary correctly if they lack the 0x?

-- Ian