Date: Sat, 20 Jun 2015 10:49:47 -0600 From: Ian Lepore <ian@freebsd.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r284614 - head/sys/boot/uboot/lib Message-ID: <1434818987.1415.120.camel@freebsd.org> In-Reply-To: <CAH7qZfuj4ZqEVVWtROZXTsrhy7C2DFw06ijJxUwbLbGEDtRPbQ@mail.gmail.com> References: <201506192224.t5JMOxpC097306@svn.freebsd.org> <1434755385.1415.114.camel@freebsd.org> <CAH7qZfuj4ZqEVVWtROZXTsrhy7C2DFw06ijJxUwbLbGEDtRPbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1434818987.1415.120.camel>