From owner-freebsd-arm@freebsd.org Mon Dec 18 16:49:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18328E9A1EF for ; Mon, 18 Dec 2017 16:49:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5923C3E4E; Mon, 18 Dec 2017 16:49:25 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 670948e9; Mon, 18 Dec 2017 17:49:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=0v88XkanwUgLBod68oMy9BvhtoA=; b=q9Ja2qu1duEuKT57mpvsWp8sOTQa jbeTwWW07cOqIQVP+B6pRUWatD6efezromOK83ECKV9ghxsnZP84te57EDiqV1xm zGcVrkRudUNxsAFhoqvN6sS3Z7nq/cyQCBaoo3UYHG9t2MZjn5gCB2FtxrBAXogx lJwVgw7KpkYDQf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=mDMK88SUXOHGob1IhSZcdEQEYICZdfKCnhMjV1zlklqMW6okdpw+uNpW xkvEkVPZ4f3mLpkbEEjC6xlDv/tmGIwPS20FQKnEtWctRy2vPibpO73uUtigAexr zvRf3hwxW0/VkX0ApGhvbzYsyq4S8NWoOL777RU/u7xmGvZmf8M= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 97f32969 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 18 Dec 2017 17:49:23 +0100 (CET) Date: Mon, 18 Dec 2017 17:49:18 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: Daniel Braniss , freebsd-arm@freebsd.org Subject: Re: ubldr question Message-Id: <20171218174918.c6aa89984174ce41d500b5b7@bidouilliste.com> In-Reply-To: <1513611489.95072.45.camel@freebsd.org> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> <1513611489.95072.45.camel@freebsd.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:49:27 -0000 On Mon, 18 Dec 2017 08:38:09 -0700 Ian Lepore wrote: > On Mon, 2017-12-18 at 10:48 +0100, Emmanuel Vadot wrote: > > On Sun, 17 Dec 2017 10:02:05 -0700 > > Ian Lepore wrote: > >=20 > > >=20 > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > > >=20 > > > > Hi, > > > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > > > override the > > > > default .dtb file set by uboot, but now it seems these files are > > > > either not read, or the > > > > command has changed. > > > >=20 > > > > So, apart from stoping the loader, and typing ?env set fdtfile > > > > xxx.dtb? > > > > is there another way? > > > >=20 > > > > cheers, > > > > danny > > > >=20 > > > You should be able to "saveenv" after making your change. > > >=20 > > > The uEnv.txt that used to be supported was to make it possible to > > > programatically change the boot behavior from freebsd userland. =A0Th= at > > > feature got lost when the uboot ports were all rewritten to use a > > > default environment (boot scripts and all) for freebsd that is > > > basically identical to what linux uses. =A0It's a lot less work for t= he > > > port maintainers, but we lost some functionality along the way. > > >=20 > > > -- Ian > > =A0We currently use the default for the boards for the env, the default > > value for most of the board is to put the env in the mmc (in the space > > reserved for u-boot) and not in the fat. There is some discussion to > > move the env in the fat by default for allwinner boards as u-boot is > > getting too big now. > > =A0One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot > > port is currently lacking of a proper way to customize the defconfigs > > (I'm currently working on this part) and I don't want to have too many > > patches (one for each board/soc). > > =A0As of functionality, I'm not sure we lost something, one can still > > create a u-boot script (u-boot.scr) and do everything he needs for a > > custom boot. (Also setenv/saveenv works as Ian said). > >=20 >=20 > The uEnv.txt file never had anything to do with=A0ENV_IS_IN_FAT or > anything else related uboot's builtin features for saving/loading the > environment. =A0It was something we added as part of freebsd boot > support, to provide a way for userland software to control the boot > process without knowing anything about how uboot stores its env (which > can be completely inaccessible to running freebsd apps in some cases). Yes sorry, I always (don't know why, maybe the name ...) mix up thoses two. > It was there specifically to support pingpong update schemes where > updates are applied to an inactive slice/partition/device, then some > persistant data is written that switches which slice/part/dev is used > for the next boot. =A0On some systems, especially if loader(8) is in use, > that can be controlled through the MBR or GPT. =A0On other systems, those > things may not be an option, and uEnv.txt was the always-available > mechanism. >=20 > So yeah, we definitely lost something. =A0It wasn't well-documented, and > from the lack of complaints up until now, I guess it wasn't something > that was widely used. =A0But it's just one of several important (IMO) > features of the old uboot ports that we lost. =A0The other major loss was > some standard env script vars that made it easy for a user to hook into > the boot process and customize it using just a 'setenv' command. > =A0"Write your own boot.scr" is nowhere near an adequate replacement for > the lost functionality of being able to set a variable or two in plain > text. >=20 > -- Ian I agree that we lost something then, I'll see what I can do. As you said it was done for pingpong support, which release image do not provide, I try to provide something that work for 99% of the users (which either download a snapshot/release or build their own with crochet or similar tool. I expect users that want something better/different as what we provide in the image to be able to come up with a solution that fix their needs. As a general rule for u-boot : we have almost catched upstream and all the modification should go there (but we can cherry-pick commits for our ports). Also I'm currently looking at what to do for loading ubldr.bin, the u-boot guys told me to use scripts (u-boot.scr) but they will be deprecated in the near future and u-boot will only use EFI or syslinux.conf, I'll start a thread soon on uboot@freebsd with my finding and the pro/con of using each solution. Cheers, --=20 Emmanuel Vadot