From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joakim Tjernlund Date: Thu, 6 Dec 2007 23:43:48 +0100 Subject: [U-Boot-Users] Can U-boot Autodetect arch/ppcversusarch/powerpc from info in the uImage? In-Reply-To: <057f01c83611$e37308d0$5267a8c0@Jocke> References: Your message of "Tue, 04 Dec 2007 00:33:15 +0100."<057d01c83604$e0bb9ce0$5267a8c0@Jocke><20071204002352.71F48242E9@gemini.denx.de> <057f01c83611$e37308d0$5267a8c0@Jocke> Message-ID: <00aa01c83859$77863cb0$02ac10ac@Jocke> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > -----Original Message----- > From: u-boot-users-bounces at lists.sourceforge.net > [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf > Of Joakim Tjernlund > Sent: den 4 december 2007 02:06 > To: wd at denx.de > Cc: u-boot-users at lists.sourceforge.net; 'Darcy Watkins' > Subject: Re: [U-Boot-Users] Can U-boot Autodetect > arch/ppcversusarch/powerpc from info in the uImage? > > > -----Original Message----- > > From: wd at denx.de [mailto:wd at denx.de] > > Sent: den 4 december 2007 01:24 > > To: Joakim Tjernlund > > Cc: 'Darcy Watkins'; u-boot-users at lists.sourceforge.net > > Subject: Re: [U-Boot-Users] Can U-boot Autodetect arch/ppc > > versusarch/powerpc from info in the uImage? > > > > Dear Jocke, > > > > in message <057d01c83604$e0bb9ce0$5267a8c0@Jocke> you wrote: > > > > > > Wolfgang, have you read the "Passing the OF tree to bootm > > from board code?" > > > thread? Would you mind explain why it was removed and why > > you don't think > > > it should be in u-boot? > > > > Is there a thread to it? I can just find a single posting from you, > > without any replies... > > Yes, there were a few replies. > > > > > But as for your question: > > > > I cannot remember that, or when, or why exactly this feature was > > removed; I cannot even remember that it ever exited. > > Was a long time ago, I too can't recall details. > > > > > But in genral I think it is a very bad idea to compile > the device > > tree into the U-Boot image, because that means you can > never replace > > / change / update it. Also I fail to understand why you > would want to > > do that. To me it seems much more sensible to have > separate U-Boot > > and device tree images, which can be replaced > independent of each > > other. If you want, you can still store these in adjacent > locations > > in flash. You can even attach these (you probably want to > insert some > > padding to align on flash sector boundaries) images to > for a single > > file which can be downloaded and flashed in a single operation. > > I create a template tree that is compiled into u-boot. Then runtime > code adjusts/amends the tree as needed for that particular board. > We do have many diffrent boards that more or less look the same to > u-boot and kernel. For all these boards I do only one > u-boot/kernel that > runs on all boards. Reason for that is too ease SW updates and save > space. This might not be the best methond of doing things but thats > how it has been the last 7 years so it is not something that > is easy to > change now. > > Even if the above method isn't something you want in u-boot I still > think there should be a way to pass the dev. tree to the bootm command > without using the environment/command arguments. For instance if > one has several trees, board code should be able decide which > tree to use. > Command args should still overide this builtin tree. > > Jocke > > > > As far as I understand your request, this offers all the > same options > > you can get with a compiled in device tree blob, but with > the added > > benefit of allowing many more things at the same time, too. > > > > Maybe I'm missing something? Yes, here are some things to consider. The extension I made can just as easily be a function that returns a dev. tree. - One can have a dev. tree update procedure similar to rendundant env. The funktion then selects which dev. tree is valid and passes that back. - The function can construct a dev. tree from builtin rules/code. - One can even make it tftp a tree at boot and pass that back. Great in a development env. especially if you are debugging the dev. tree. and the kicker is that you can still override this tree at runtime by passing a dev. tree argument to bootm. All this will be possible by the simple patch I posted earlier, included below. [PATCH] Make it possible to use a builtin OF tree. Signed-off-by: Joakim Tjernlund --- common/cmd_bootm.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index d816349..8405de7 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -507,6 +507,9 @@ fixup_silent_linux () #endif /* CONFIG_SILENT_CONSOLE */ #ifdef CONFIG_PPC +#ifndef DEFAULT_OF_TREE + #define DEFAULT_OF_TREE NULL +#endif static void __attribute__((noinline)) do_bootm_linux (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[], @@ -527,7 +530,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int flag, void (*kernel)(bd_t *, ulong, ulong, ulong, ulong); image_header_t *hdr = &header; #if defined(CONFIG_OF_FLAT_TREE) || defined(CONFIG_OF_LIBFDT) - char *of_flat_tree = NULL; + char *of_flat_tree = DEFAULT_OF_TREE; ulong of_data = 0; #endif -- 1.5.3.6 > > > > Best regards, > > > > Wolfgang Denk