Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Wolfgang Denk]

Dear Steven Stallion,

In message CAGGHmKH3W6SQSwG3qKJHQmRaxS7ZRVJmbLw_anvgNA61=pc...@mail.gmail.com 
you wrote:

  bootm has a well-known an documented API: it takes up to three
  arguments: kernel address, ramdisk address, and device tree address.
  Nothing else.
 
 Is there a reason that this should only be used by Linux? The changes
 I have submitted follow the same behavior as NetBSD. VxWorks and QNX
 also have their own quirks that don't follow the same path/usage as
 Linux.

Agreed.  But this should be documented, then.

 The usage seems to indicate this is a valid approach:
 
 Usage:
 bootm [addr [arg ...]]
 
 If this is such a contentious change, I'm happy to drop it. I was
 following the NetBSD approach since it was the most similar. It would
 be a shame to let it go - it's useful.

Please do not misunderstand me - all I'm asking is to document the
exact behaviour.

Personally, I consider the interface a bad design, especially the
different handling (or ignorance) of the bootargs setting depending
on the number of arguments.  But I agree that this has already crept
in.  It's a pity yo want to use exactly this interface, but it's you
who has to use (and suffer from) it, so I won;t really block it.  I've
raised my concerns, that's all.

  Some ports (such as OMAP) will stop once it encounters the first non-ASCII
  character. In general, the parsing for the configuration is fairly strict
  and is only a small risk if a user configures the system incorrectly.
 
  Hm.  This is just a subterfuge for there is no security at all, and
  you are invoking undefined behaviour ...
 
 This would only happen if a user did not configure the loader appropriately.

...which is just a typo away.

  There is also something subtle in not specifying confaddr (or bootargs for
  that matter). Many ports support loading configuration from a FAT file
  system. U-Boot would be no different.
 
  I don't see what this has to do with it?
 
 Plan 9 was traditionally loaded from FAT on PC architectures. Much of
 that support still exists today. Typically, a small FAT partition
 exists, which houses the kernel and the configuration (plan9.ini).
 With U-Boot, to emulate this behavior a fatload would be issued to
 copy the file to the proper location. This allows users to modify
 their configuration and reboot without having to drop into the U-Boot
 shell.

You can still do this with U-Boot.  I see no problems here.

 If do_plan9_bootm writes a NUL byte if no bootargs are defined, this
 would break the fatload method.

Oops?  I cannot parse this.

  You have no way to check for valid data, and you have no way to know
  the correct address, because it is neither fixed nor known to both
  the producer and the consumer?  I'm sorry, but this is crap.
 
 It's known to both the producer and consumer, but can change during
 development. Having it compiled in also means that you do not have
 quick access to the value to use for a fatload, though this is a minor
 annoyance.

I disagree.  It appears that when you load a kernel image, there is no
way to find out what the required confaddr would be.  You have to know
it.  If you have several images with different settings, you always
have to know exactly what is what.  That's not exactly a robust (nor
intelligent) setup.

  I'm sorry, but it appears this design is completely borked, so how
  should I answer this?  If you have no way to know the correct
  adddress, and the consumer has no way to verify the data it recives,
  it's all just trial and error.  Not exactly a robust design, that is.
 
 It's a known address for known kernels but needs to have the
 flexibility to change without a recompile. Personal feelings aside,
 this is how the kernel handles configuration at boot - I can only do
 so much.

I don't know about Plan 9, but is there no way to pass this
information to the boot loader?  For example, if you were using a
device tree, you could ncode it there, so UBoot could pick it up.
Alternatively, you could use FIT images and include an extra blob with
information (and if it's just the confaddr environment setting) for
use in U-Boot, etc. ...

 I very much want these changes (or an acceptable version of them) to
 go upstream. Most users tend to just hack up U-Boot for the boards
 they use and maintain private forks, but I would like to see better
 support in both directions. I'm happy to keep a fork, but these
 changes do not seem onerous, especially given that other operating
 systems that are already supported follow this exact behavior.

I do not intend to block this - I'm just pointing out issues I'm
anticipating.

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: w...@denx.de
It may be that our role on this planet is not to worship God but  to
create him.   - 

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Wolfgang Denk]

Dear Steven Stallion,

In message 1370562103-92148-1-git-send-email-sstall...@gmail.com you wrote:
 This patch introduces support for command line arguments to Plan 9.
 Plan 9 generally dedicates a small region of kernel memory (known
 as CONFADDR) for runtime configuration.  A new environment variable
 named confaddr was introduced to indicate this location when copying
 arguments.
 
 Signed-off-by: Steven Stallion sstall...@gmail.com
 ---
  common/cmd_bootm.c |   19 +++
  1 files changed, 19 insertions(+), 0 deletions(-)
 
 diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
 index 05130b6..5c62271 100644
 --- a/common/cmd_bootm.c
 +++ b/common/cmd_bootm.c
 @@ -1533,6 +1533,7 @@ static int do_bootm_plan9(int flag, int argc, char * 
 const argv[],
  bootm_headers_t *images)
  {
   void (*entry_point)(void);
 + char *s;
  
   if ((flag != 0)  (flag != BOOTM_STATE_OS_GO))
   return 1;
 @@ -1544,6 +1545,24 @@ static int do_bootm_plan9(int flag, int argc, char * 
 const argv[],
   }
  #endif
  
 + if ((s = getenv(confaddr)) != NULL) {
 + char *confaddr = (char *)simple_strtoul(s, NULL, 16);
 +
 + if (argc  2) {
 + int i;
 +
 + s = confaddr;
 + for (i = 2; i  argc; i++) {
 + if (i  2)
 + *s++ = '\n';
 + strcpy(s, argv[i]);
 + s += strlen(argv[i]);
 + }
 + } else if ((s = getenv(bootargs)) != NULL) {
 + strcpy(confaddr, s);
 + }
 + }
 +

This is basically the same code (with only irrelevant differences) as
used by do_bootm_netbsd().  Can you please

1) factor out this common code,  and
2) documnt the behaviour
?

By the way: this patch still triggers two do not use assignment in if
condition checkpoatch errors.  Please fix these, too.

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: w...@denx.de
Advice is seldom welcome; and those who want it the most always like
it the least. -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Steven Stallion]

On Sun, Jun 9, 2013 at 12:52 AM, Wolfgang Denk w...@denx.de wrote:
 This is basically the same code (with only irrelevant differences) as
 used by do_bootm_netbsd().  Can you please

 1) factor out this common code,  and
 2) documnt the behaviour
 ?

Will do.

 By the way: this patch still triggers two do not use assignment in if
 condition checkpoatch errors.  Please fix these, too.

Will do. I'll submit a v2 patch later this evening.

Thanks for being patient :-)

Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Steven Stallion]

On Thu, Jun 6, 2013 at 4:41 PM, Steven Stallion sstall...@gmail.com wrote:
 This patch introduces support for command line arguments to Plan 9.
 Plan 9 generally dedicates a small region of kernel memory (known
 as CONFADDR) for runtime configuration.  A new environment variable
 named confaddr was introduced to indicate this location when copying
 arguments.

Apologies for the double post - it looks like the message had been
sitting in an mqueue waiting to resend.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Steven Stallion]

This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for runtime configuration.  A new environment variable
named confaddr was introduced to indicate this location when copying
arguments.

Signed-off-by: Steven Stallion sstall...@gmail.com
---
 common/cmd_bootm.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 05130b6..5c62271 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1533,6 +1533,7 @@ static int do_bootm_plan9(int flag, int argc, char * 
const argv[],
   bootm_headers_t *images)
 {
void (*entry_point)(void);
+   char *s;
 
if ((flag != 0)  (flag != BOOTM_STATE_OS_GO))
return 1;
@@ -1544,6 +1545,24 @@ static int do_bootm_plan9(int flag, int argc, char * 
const argv[],
}
 #endif
 
+   if ((s = getenv(confaddr)) != NULL) {
+   char *confaddr = (char *)simple_strtoul(s, NULL, 16);
+
+   if (argc  2) {
+   int i;
+
+   s = confaddr;
+   for (i = 2; i  argc; i++) {
+   if (i  2)
+   *s++ = '\n';
+   strcpy(s, argv[i]);
+   s += strlen(argv[i]);
+   }
+   } else if ((s = getenv(bootargs)) != NULL) {
+   strcpy(confaddr, s);
+   }
+   }
+
entry_point = (void (*)(void))images-ep;
 
printf(## Transferring control to Plan 9 (at address %08lx) ...\n,
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Wolfgang Denk]

Dear Steven Stallion,

In message 1370563140-31368-1-git-send-email-sstall...@gmail.com you wrote:
 This patch introduces support for command line arguments to Plan 9.
 Plan 9 generally dedicates a small region of kernel memory (known
 as CONFADDR) for runtime configuration.  A new environment variable
 named confaddr was introduced to indicate this location when copying
 arguments.

Please make this code configurable, so that people who never intend to
use Plan 9 do not suffer from the increased code size.

Then please run your patch through ckeckpatch - as is, this reports
two errors:

ERROR: do not use assignment in if condition

Finally:

 + if ((s = getenv(confaddr)) != NULL) {
 + char *confaddr = (char *)simple_strtoul(s, NULL, 16);
 +
 + if (argc  2) {
 + int i;
 +
 + s = confaddr;
 + for (i = 2; i  argc; i++) {
 + if (i  2)
 + *s++ = '\n';
 + strcpy(s, argv[i]);
 + s += strlen(argv[i]);
 + }
 + } else if ((s = getenv(bootargs)) != NULL) {
 + strcpy(confaddr, s);
 + }
 + }

This design looks pretty much inconsistent and non-intuitive to me.

There is absolutely no length checking in this code.  Is the size of
the available area truely unlimited?  I doubt that...

Why do you make this (completely undocumented!!!) distinction between
bootm being used with one or more arguments?  Why can you not
simply _always_ use bootargs ?

What if the user did not set the confaddr environment variable?
Then the memory reagion there is left uninitialized?  Does this not
cause undefined behaviour when booting Plan 9?

And how does Plan 9 learn where to find this date? I cannot see how
you pass this address on to Plan 9?


Even worse - this code is actually pretty dangerous: confaddr is
neither a reserved name, nor is it in any way exotic enough to be sure
nobody else would use this in his environment.  But if somebody does,
he will suddenly find that some (for him random) data is copied unex-
pectedly to that memory range.  This may cause nasty crashes or other
undefined behaviour which is very difficult to debug.

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: w...@denx.de
Bus error -- please leave by the rear door.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Wolfgang Denk]

Dear Steven,

please always keep the mailing list on Cc: - this is especially
important for patch reviews, where such messages need to be picked up
for patchwork, too.

In message CAGGHmKHmLAd_85SgHyC=ceumhu8u4enqyj3wt3rqyvdzatw...@mail.gmail.com 
you wrote:

  Please make this code configurable, so that people who never intend to
  use Plan 9 do not suffer from the increased code size.
 
 This is already done, if you look at the do_bootm_plan9 function, you'll
 see it is guarded by CONFIG_BOOTM_PLAN9. These changes only affect users
 that are booting Plan 9.

I see.  Hm... I wonder which version of U-Boot your patch is against?
The line numbers in your patch are off by at least 126 lines, and
common/cmd_bootm.c has not been touched for many months ?

  ERROR: do not use assignment in if condition
 
 I noticed the errors, however the style and format of my changes are the
 same as those in other functions in cmd_bootm; do_bootm_netbsd probably
 being the closest example. I did not watch to introduce style drift.

But we should not add more bad style code either.  Feel free to send a
cleanup patch for the existing code parts.  In any case, do not add
more such stuff.


 It's as unlimited as you have memory :-) That said, adjacent pages to
 CONFADDR are zeroed out at boot, so there is no possibility of overflow
 once you branch to the kernel.

Adjacent pages being zeroed - that means that you _are_ actually
limited to one page size?

  Why do you make this (completely undocumented!!!) distinction between
  bootm being used with one or more arguments?  Why can you not
  simply _always_ use bootargs ?
 
 This is to support passing arguments via bootm. This behavior is consistent
 with NetBSD.

...which I consider a really weird desiign that IMO should not be
followed without need.

If you decide to do so nevertheless, then please

1) document the behaviour
2) factor out the common code instead of copying it

  What if the user did not set the confaddr environment variable?
  Then the memory reagion there is left uninitialized?  Does this not
  cause undefined behaviour when booting Plan 9?
 
 There are checks which account for uninitialized memory at boot. It's ugly,
 but it's how the OS deals with configuration. I don't like it either.

How does it detect if there are valid arguments (versus random crap)
in the memory range starting at confaddr?  I can see no checksum or
similar?

 And how does Plan 9 learn where to find this date? I cannot see how
  you pass this address on to Plan 9?
 
 Like most things in Plan 9, it is a compiled offset (defined in mem.h).
 CONFADDR is fixed, so as long as the configuration is dumped to the right
 location (which can change between kernels), it will work.

But then makes no sense to use a confaddr environment variable for
this - the user has no real choice of setting this variable: either it
matches the fixed CONFADDR value, in which case it works, or it is
different, in which case it will silently fail.  This is bad.
I think you should use a CONFIG_SYS_CONFADDR constant instead.

 Even worse - this code is actually pretty dangerous: confaddr is
  neither a reserved name, nor is it in any way exotic enough to be sure
  nobody else would use this in his environment.  But if somebody does,
  he will suddenly find that some (for him random) data is copied unex-
  pectedly to that memory range.  This may cause nasty crashes or other
  undefined behaviour which is very difficult to debug.
 
 True, but it's no different than loadaddr. This only affects Plan 9 users,
 and this behavior will be documented for the kernels which support U-Boot.
 I don't think there is too much danger here, though documentation will be
 important.

It is not documented in U-Boot.  But actually I think this is void -
using an envrionment variable here makes no sense in the first place.

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: w...@denx.de
To be is to program.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Steven Stallion]

On Fri, Jun 7, 2013 at 1:16 AM, Wolfgang Denk w...@denx.de wrote:

 In message CAGGHmKHmLAd_85SgHyC=
 ceumhu8u4enqyj3wt3rqyvdzatw...@mail.gmail.com you wrote:
 
   Please make this code configurable, so that people who never intend to
   use Plan 9 do not suffer from the increased code size.
 
  This is already done, if you look at the do_bootm_plan9 function, you'll
  see it is guarded by CONFIG_BOOTM_PLAN9. These changes only affect users
  that are booting Plan 9.

 I see.  Hm... I wonder which version of U-Boot your patch is against?
 The line numbers in your patch are off by at least 126 lines, and
 common/cmd_bootm.c has not been touched for many months ?


That's odd. I just double checked and my repository seems to be in sync.
I'll do some poking around to make sure I didn't miss something.

  ERROR: do not use assignment in if condition
 
  I noticed the errors, however the style and format of my changes are the
  same as those in other functions in cmd_bootm; do_bootm_netbsd probably
  being the closest example. I did not watch to introduce style drift.

 But we should not add more bad style code either.  Feel free to send a
 cleanup patch for the existing code parts.  In any case, do not add
 more such stuff.


Will do.

 It's as unlimited as you have memory :-) That said, adjacent pages to
  CONFADDR are zeroed out at boot, so there is no possibility of overflow
  once you branch to the kernel.

 Adjacent pages being zeroed - that means that you _are_ actually
 limited to one page size?

   Why do you make this (completely undocumented!!!) distinction between
   bootm being used with one or more arguments?  Why can you not
   simply _always_ use bootargs ?
 
  This is to support passing arguments via bootm. This behavior is
 consistent
  with NetBSD.

 ...which I consider a really weird desiign that IMO should not be
 followed without need.

 If you decide to do so nevertheless, then please

 1) document the behaviour
 2) factor out the common code instead of copying it


Hmm. Are you arguing against supporting command line arguments to bootm, or
that bootm should copy these arguments to bootargs prior to boot? This has
actually been very useful to test changes without having to update my
bootargs environment variable.

Where is the best place to document the behavior, README? The code looks as
though it's common, but unfortunately it's not. plan9.ini(8) requires that
arguments be terminated with a newline, the NetBSD loader uses spaces.

  What if the user did not set the confaddr environment variable?
   Then the memory reagion there is left uninitialized?  Does this not
   cause undefined behaviour when booting Plan 9?
 
  There are checks which account for uninitialized memory at boot. It's
 ugly,
  but it's how the OS deals with configuration. I don't like it either.

 How does it detect if there are valid arguments (versus random crap)
 in the memory range starting at confaddr?  I can see no checksum or
 similar?


Some ports (such as OMAP) will stop once it encounters the first non-ASCII
character. In general, the parsing for the configuration is fairly strict
and is only a small risk if a user configures the system incorrectly.

There is also something subtle in not specifying confaddr (or bootargs for
that matter). Many ports support loading configuration from a FAT file
system. U-Boot would be no different.

I realize this probably seems very foreign. Plan 9 is somewhat unique in
that it relies on a variety of loaders. Some are more intelligent than
others, but in the end, configuration has to be dropped in a known location
for the kernel to parse. There is no second-stage loader, so passing a
pointer has limited utility since the code to parse the config happens
after the MMU has been initialized.

 And how does Plan 9 learn where to find this date? I cannot see how
   you pass this address on to Plan 9?
 
  Like most things in Plan 9, it is a compiled offset (defined in mem.h).
  CONFADDR is fixed, so as long as the configuration is dumped to the right
  location (which can change between kernels), it will work.

 But then makes no sense to use a confaddr environment variable for
 this - the user has no real choice of setting this variable: either it
 matches the fixed CONFADDR value, in which case it works, or it is
 different, in which case it will silently fail.  This is bad.
 I think you should use a CONFIG_SYS_CONFADDR constant instead.


Ah, this is another subtlety. CONFADDR can change depending on the kernel
you are booting. Some ports use as much as 64K to store configuration.
Having to recompile U-Boot and reflash based on a kernel change would add a
lot of complication and frustration. Having confaddr also makes it somewhat
simpler to write a generic boot command which will do a fatload rather than
use bootargs.

 Even worse - this code is actually pretty dangerous: confaddr is
   neither a reserved name, nor is it in any way exotic enough to be sure
   nobody else would 

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Wolfgang Denk]

Dear Steven,

In message cagghmkh2nsdoqjbrucb5xjsjcuoyfco6cz8msjtxdshh6p6...@mail.gmail.com 
you wrote:

 Hmm. Are you arguing against supporting command line arguments to bootm, or
 that bootm should copy these arguments to bootargs prior to boot? This has
 actually been very useful to test changes without having to update my
 bootargs environment variable.

bootm has a well-known an documented API: it takes up to three
arguments: kernel address, ramdisk address, and device tree address.
Nothing else.

If you want to implement a different interface, this should at least
be documented - but then I doubt if this should be named bootm.  If
I use it with 3 arguments, I expect the well-known behaviour, on all
systems.

 Where is the best place to document the behavior, README? The code looks as
 though it's common, but unfortunately it's not. plan9.ini(8) requires that
 arguments be terminated with a newline, the NetBSD loader uses spaces.

A readme in doc/ is OK, too.

  How does it detect if there are valid arguments (versus random crap)
  in the memory range starting at confaddr?  I can see no checksum or
  similar?
 
 Some ports (such as OMAP) will stop once it encounters the first non-ASCII
 character. In general, the parsing for the configuration is fairly strict
 and is only a small risk if a user configures the system incorrectly.

Hm.  This is just a subterfuge for there is no security at all, and
you are invoking undefined behaviour ...

 There is also something subtle in not specifying confaddr (or bootargs for
 that matter). Many ports support loading configuration from a FAT file
 system. U-Boot would be no different.

I don't see what this has to do with it?

  But then makes no sense to use a confaddr environment variable for
  this - the user has no real choice of setting this variable: either it
  matches the fixed CONFADDR value, in which case it works, or it is
  different, in which case it will silently fail.  This is bad.
  I think you should use a CONFIG_SYS_CONFADDR constant instead.
 
 Ah, this is another subtlety. CONFADDR can change depending on the kernel
 you are booting. Some ports use as much as 64K to store configuration.
 Having to recompile U-Boot and reflash based on a kernel change would add a
 lot of complication and frustration. Having confaddr also makes it somewhat
 simpler to write a generic boot command which will do a fatload rather than
 use bootargs.

You have no way to check for valid data, and you have no way to know
the correct address, because it is neither fixed nor known to both
the producer and the consumer?  I'm sorry, but this is crap.

 Is there a better method to allow confaddr to change without forcing a
 re-compile, or duplication if a user decides to do a fatload rather than
 define bootargs?

I'm sorry, but it appears this design is completely borked, so how
should I answer this?  If you have no way to know the correct
adddress, and the consumer has no way to verify the data it recives,
it's all just trial and error.  Not exactly a robust design, that is.

 --485b395e78db9b448d04de92b574
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 div dir=3DltrOn Fri, Jun 7, 2013 at 1:16 AM, Wolfgang Denk span dir=3D=
 ltrlt;a href=3Dmailto:w...@denx.de; 
 target=3D_blankw...@denx.de/agt=
 ;/span wrote:brdiv class=3Dgmail_extradiv class=3Dgmail_quoteb=
 lockquote class=3Dgmail_quote style=3Dmargin:0 0 0 .8ex;border-left:1px =
 #ccc solid;padding-left:1ex

Can you PLEASE stop sending HTML?  Thanks.

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: w...@denx.de
All men should freely use those seven words which have the  power  to
make any marriage run smoothly: You know dear, you may be right.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Steven Stallion]

On Fri, Jun 7, 2013 at 2:57 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Steven,

 In message 
 cagghmkh2nsdoqjbrucb5xjsjcuoyfco6cz8msjtxdshh6p6...@mail.gmail.com you 
 wrote:

 Hmm. Are you arguing against supporting command line arguments to bootm, or
 that bootm should copy these arguments to bootargs prior to boot? This has
 actually been very useful to test changes without having to update my
 bootargs environment variable.

 bootm has a well-known an documented API: it takes up to three
 arguments: kernel address, ramdisk address, and device tree address.
 Nothing else.

Is there a reason that this should only be used by Linux? The changes
I have submitted follow the same behavior as NetBSD. VxWorks and QNX
also have their own quirks that don't follow the same path/usage as
Linux.

 If you want to implement a different interface, this should at least
 be documented - but then I doubt if this should be named bootm.  If
 I use it with 3 arguments, I expect the well-known behaviour, on all
 systems.

The usage seems to indicate this is a valid approach:

Usage:
bootm [addr [arg ...]]

If this is such a contentious change, I'm happy to drop it. I was
following the NetBSD approach since it was the most similar. It would
be a shame to let it go - it's useful.

 Some ports (such as OMAP) will stop once it encounters the first non-ASCII
 character. In general, the parsing for the configuration is fairly strict
 and is only a small risk if a user configures the system incorrectly.

 Hm.  This is just a subterfuge for there is no security at all, and
 you are invoking undefined behaviour ...

This would only happen if a user did not configure the loader appropriately.

 There is also something subtle in not specifying confaddr (or bootargs for
 that matter). Many ports support loading configuration from a FAT file
 system. U-Boot would be no different.

 I don't see what this has to do with it?

Plan 9 was traditionally loaded from FAT on PC architectures. Much of
that support still exists today. Typically, a small FAT partition
exists, which houses the kernel and the configuration (plan9.ini).
With U-Boot, to emulate this behavior a fatload would be issued to
copy the file to the proper location. This allows users to modify
their configuration and reboot without having to drop into the U-Boot
shell.

If do_plan9_bootm writes a NUL byte if no bootargs are defined, this
would break the fatload method.

 Ah, this is another subtlety. CONFADDR can change depending on the kernel
 you are booting. Some ports use as much as 64K to store configuration.
 Having to recompile U-Boot and reflash based on a kernel change would add a
 lot of complication and frustration. Having confaddr also makes it somewhat
 simpler to write a generic boot command which will do a fatload rather than
 use bootargs.

 You have no way to check for valid data, and you have no way to know
 the correct address, because it is neither fixed nor known to both
 the producer and the consumer?  I'm sorry, but this is crap.

It's known to both the producer and consumer, but can change during
development. Having it compiled in also means that you do not have
quick access to the value to use for a fatload, though this is a minor
annoyance.

 Is there a better method to allow confaddr to change without forcing a
 re-compile, or duplication if a user decides to do a fatload rather than
 define bootargs?

 I'm sorry, but it appears this design is completely borked, so how
 should I answer this?  If you have no way to know the correct
 adddress, and the consumer has no way to verify the data it recives,
 it's all just trial and error.  Not exactly a robust design, that is.

It's a known address for known kernels but needs to have the
flexibility to change without a recompile. Personal feelings aside,
this is how the kernel handles configuration at boot - I can only do
so much.

I very much want these changes (or an acceptable version of them) to
go upstream. Most users tend to just hack up U-Boot for the boards
they use and maintain private forks, but I would like to see better
support in both directions. I'm happy to keep a fork, but these
changes do not seem onerous, especially given that other operating
systems that are already supported follow this exact behavior.

Cheers,

Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Steven Stallion]

This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for runtime configuration.  A new environment variable
named confaddr was introduced to indicate this location when copying
arguments.

Signed-off-by: Steven Stallion sstall...@gmail.com
---
 common/cmd_bootm.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 05130b6..5c62271 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1533,6 +1533,7 @@ static int do_bootm_plan9(int flag, int argc, char * 
const argv[],
   bootm_headers_t *images)
 {
void (*entry_point)(void);
+   char *s;
 
if ((flag != 0)  (flag != BOOTM_STATE_OS_GO))
return 1;
@@ -1544,6 +1545,24 @@ static int do_bootm_plan9(int flag, int argc, char * 
const argv[],
}
 #endif
 
+   if ((s = getenv(confaddr)) != NULL) {
+   char *confaddr = (char *)simple_strtoul(s, NULL, 16);
+
+   if (argc  2) {
+   int i;
+
+   s = confaddr;
+   for (i = 2; i  argc; i++) {
+   if (i  2)
+   *s++ = '\n';
+   strcpy(s, argv[i]);
+   s += strlen(argv[i]);
+   }
+   } else if ((s = getenv(bootargs)) != NULL) {
+   strcpy(confaddr, s);
+   }
+   }
+
entry_point = (void (*)(void))images-ep;
 
printf(## Transferring control to Plan 9 (at address %08lx) ...\n,
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot