From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Mon, 04 Aug 2008 16:19:29 -0400 Subject: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot In-Reply-To: References: <20080804185652.0D4FA24848@gemini.denx.de> Message-ID: <48976451.2030405@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Kumar Gala wrote: > On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: > >> In message >> you wrote: >>> Added the 'fdtcmd' environment variable as a way to provide 'fdt' >>> commands >>> that the user can supply to manipulate the device tree after >>> ft_board_setup() >>> and before the tree is handled to the kernel. >> Where exactly is the needed, i. e. which spoecific situation do you >> have in mind where this function cannot be implemented as part of >> either a "preboot" or a standard "bootcmd" command sequence? > > The situation is if we are fixing up or adding properties or nodes via > the ft_board_setup() how do I go about modifying that before the > device tree is handed to the kernel. > > An example would be if we start adding the i2c node via code in u-boot > and after we have done that we want to add a frequency property at > runtime w/o changing the u-boot code. > > - k My original way long ago initial cut didn't do the board and /chosen fixups as part of the bootm execution. My original intent was that we would run "fdt chosen" and "fdt bd" and whatever else was necessary before running "bootm", including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if "fdt chosen" and/or "fdt bd" is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of "fdt chosen" and "fdt bd" in bootm ("nofdtfixup"?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when "fdt chosen" and "fdt bd" (add "fdt cpu"?) is run and allow our users to wedge additional fdt stuff in the boot sequence. gvb