From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 03 Apr 2007 06:34:01 -0400 Subject: [U-Boot-Users] (Try 2) Please pull branch fdt-cmd from u-boot-fdt.git In-Reply-To: <1175593151.12080.17.camel@gentoo-jocke.transmode.se> References: <20070331174341.GA26946@dellserver.lan> <1175593151.12080.17.camel@gentoo-jocke.transmode.se> Message-ID: <46122D99.3080408@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Joakim Tjernlund wrote: > On Sat, 2007-03-31 at 13:43 -0400, Jerry Van Baren wrote: >> Dear Wolfgang, >> >> Please pull from the "fdt-cmd" branch at >> git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd >> currently broken, someday fixed: >> git://denx.de/git/u-boot-fdt.git fdt-cmd >> >> I've resplit the patches and emailed them to the u-boot list. >> >> This change is only the starting point. :-) I've only done the >> mpc8360/mpc8360emds board. Some fairly small changes need to be done >> to the other mpc8xxx family CPU and board subdirectories to allow them >> to use the libfdt/fdt command. To see what needs adapting, see: >> cpu/mpc83xx/cpu.c | 102 +++++- >> board/mpc8360emds/pci.c | 20 + >> >> Note that I've created a new CONFIG_OF_LIBFDT that is intended to >> ultimately supplant CONFIG_OF_FLAT_TREE. Use one or the other: new way >> CONFIG_OF_LIBFDT or old way CONFIG_OF_FLAT_TREE. Obviously, the only >> way to get the new fdt command is to use CONFIG_OF_LIBFDT. > > This is probably a little off but I am thinking about were to > put my dtb on the flash and it occured to me that it could fit into the > environment sector as the environment doesn't use the whole sector. > But one can't just write it into that sector without take measures to > preserve the environment. > Is this a bad idea? > > Jocke That is an excellent idea and should be one of our goals: to better coordinate the dft and env variables. As the penultimate goal, I believe we could move the env variables _into_ the dft and replace the get/set env routines with dft get/set routines. I'm still thinking about this... env variables are used very early in power up (before RAM is initialized), but I haven't seen any reason that it /can't/ be done. The downside of dfts is that the code is bigger. My preliminary size delta with the code as it stands is about +4.5K. I don't know how much we would save if we removed the env handling routines, but I'm sure nowhere near that (0.5K would be my guess). For size sensitive u-boot images, we could use it read-only which would probably cut it down to 1-2K, but then we would not be able to replace the env handling. gvb