From owner-svn-src-head@FreeBSD.ORG Sat Jun 20 16:49:50 2015 Return-Path: Delivered-To: svn-src-head@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 802516AD for ; Sat, 20 Jun 2015 16:49:50 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) by mx1.freebsd.org (Postfix) with SMTP id 5DEFAF00 for ; Sat, 20 Jun 2015 16:49:49 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 20 Jun 2015 16:50:06 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t5KGnlx8020234; Sat, 20 Jun 2015 10:49:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1434818987.1415.120.camel@freebsd.org> Subject: Re: svn commit: r284614 - head/sys/boot/uboot/lib From: Ian Lepore To: Maxim Sobolev Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sat, 20 Jun 2015 10:49:47 -0600 In-Reply-To: References: <201506192224.t5JMOxpC097306@svn.freebsd.org> <1434755385.1415.114.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 16:49:50 -0000 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