Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] 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? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message Pine.LNX. [EMAIL PROTECTED] 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. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] 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. So just run the needed commands before you run bootm as part of your boot command sequence. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] One difference between a man and a machine is that a machine is quiet when well oiled. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] 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. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). Best regards, gvb P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] 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. So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:44 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] 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. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). Best regards, gvb P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... I think this was lost long ago. If we went with simple it would have just done the register setup and transfer and thats it. leaving it to other commands to do decompression of images, etc. Also we already have a number env vars that impact how bootm works. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. Why not? Wouldn't it be just another environment variable, like the load address for the kernel? -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). I agree 100%. P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... Ther is two of us. I'm your ally when it comes to ripping out unnecessary and complicted stuff out of bootm :-) Just send patches... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Children are natural mimics who act like their parents despite every effort to teach them good manners. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) And exactly this has to be considered a bug in the current bootm implementation. Throwing out this design error would make more sense to me than adding another quirk. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] To the systems programmer, users and applications serve only to provide a test load. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:55 PM, Scott Wood wrote: Kumar Gala wrote: On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 3:55 PM, Scott Wood wrote: Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. Do we really need to do it that way, though? -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote: In message F388F9D5-B685-4DD8- [EMAIL PROTECTED] you wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) And exactly this has to be considered a bug in the current bootm implementation. Throwing out this design error would make more sense to me than adding another quirk. Ok. What do we think 'bootm' at its lowest level should do? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. Who places it there? We were talking about the bootm arguments, which are different things, I think? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] That Microsoft, the Trabant of the operating system world, may be glancing over the Berlin Wall at the Audis and BMWs and Mercedes. In their own universe Trabants and Ladas were mainstream too... -- Evan Leibovitch - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
