sandbox: Add architecture header files

We won't actually load an image with this architecture, but we still need to define it.

Signed-off-by Simon Glass <[email protected]>

---
 common/image.c  |    5 +++--
 include/image.h |    3 +++
 2 files changed, 6 insertions(+), 2 deletions(-)

common/image.c +0 -0

index d38ce4a..8283561 100644

Quoted 17 lines · Simon Glass

We won't actually load an image with this architecture, but we still need to define it.

Signed-off-by Simon Glass <[email protected]>

---
?common/image.c ?| ? ?5 +++--
?include/image.h | ? ?3 +++
?2 files changed, 6 insertions(+), 2 deletions(-)

common/image.c +0 -0

index d38ce4a..8283561 100644
@@ -1581,7 +1581,7 @@ int boot_get_fdt (int flag, int argc, char * const
 argv[], bootm_headers_t *imag goto error;
 ? ? ? ? ? ? ? }
 

common/image.c int boot_get_fdt (int flag, int argc, char * const · line 1584

Quoted 1 line

common/image.c +0 -1

- ? ? ? ? ? ? printf (" ? Booting using the fdt blob at 0x%x\n",

(int)fdt_blob);

common/image.c int boot_get_fdt (int flag, int argc, char * const · line 1584

Quoted 1 line

common/image.c +1 -0

+ ? ? ? ? ? ? printf(" ? Booting using the fdt blob at 0x%p\n", fdt_blob);

Well this is a fix and the patch description doesn't match it.

Can you split it or something?

Cheers

Temporary fix for 64-bit building.

arch/sandbox/config.mk

Quoted 4 lines · On Saturday, September 17, 2011 12:48:43 Simon Glass wrote:

arch/sandbox/config.mk new file +1 -0

 
+LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds

the top level Makefile should take care of this for you so you can just delete this line

Quoted 3 lines

arch/sandbox/cpu/sandbox/cpu.c new file +0 -0

arch/sandbox/cpu/sandbox/cpu.c line 29

Quoted 4 lines

arch/sandbox/cpu/sandbox/cpu.c new file +4 -0

+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ ? ? return -1;
+}

do_reset() is not supposed to return

-mike

Quoted 2 lines

do_reset() is not supposed to return

I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)

I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.

Dear Simon Glass,

Quoted 3 lines · In message <CAPnjgZ1FfRPbU9gtxp9qVM24Ln2R-bWU1OjmrL3E+hijjLwiNQ@mail.gmail.com>…

Quoted 2 lines

do_reset() is not supposed to return

Quoted 6 lines

I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)

I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.

No, I don't want to change the current definition of reset().

And "not able to do the job" is something different than "unimplemented".

Why cannot we do a real reset here? Re-exec'in the running binary or performing a longjmp() to the start might be ideas how to implement this.

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: wd at denx.de "The value of marriage is not that adults produce children, but ?that children produce adults." ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Peter De Vries

Quoted 11 lines · Wolfgang Denk

Quoted 8 lines · Simon Glass

Quoted 1 line

do_reset() is not supposed to return

I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)

I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.

No, I don't want to change the current definition of reset().

OK.

Quoted 6 lines

And "not able to do the job" is something different than "unimplemented".

Why cannot we do a real reset here? Re-exec'in the running binary or performing a longjmp() to the start might be ideas how to implement this.

While this could be done I believe that it might be possible / desirable to exit out of the main loop, rather than longjmp or re-exec. I have not implemented it because I have not got to that bit yet and don't want to put time into a solution I will throw away.

I'm happy to just put:

while (1) ;

in the reset code if you like?

Quoted 27 lines · On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:

Quoted 11 lines · Wolfgang Denk

Quoted 8 lines · Simon Glass

Quoted 1 line

do_reset() is not supposed to return

I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)

I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.

No, I don't want to change the current definition of reset().

OK.

Quoted 6 lines

And "not able to do the job" is something different than "unimplemented".

Why cannot we do a real reset here? Re-exec'in the running binary or performing a longjmp() to the start might be ideas how to implement this.

While this could be done I believe that it might be possible / desirable to exit out of the main loop, rather than longjmp or re-exec. I have not implemented it because I have not got to that bit yet and don't want to put time into a solution I will throw away.

Quoted 5 lines

I'm happy to just put:

while (1) ;

in the reset code if you like?

i would expect "reset" in the sandbox to "exit(1)". ?how else would you exit ? -mike

Hi Mike,

Quoted 32 lines · Mike Frysinger

Quoted 31 lines · On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:

Quoted 11 lines · Wolfgang Denk

Quoted 8 lines · Simon Glass

Quoted 1 line

do_reset() is not supposed to return

I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)

I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.

No, I don't want to change the current definition of reset().

OK.

Quoted 6 lines

And "not able to do the job" is something different than "unimplemented".

Why cannot we do a real reset here? Re-exec'in the running binary or performing a longjmp() to the start might be ideas how to implement this.

While this could be done I believe that it might be possible / desirable to exit out of the main loop, rather than longjmp or re-exec. I have not implemented it because I have not got to that bit yet and don't want to put time into a solution I will throw away.

I'm happy to just put:

while (1) ;

Quoted 5 lines

Quoted 1 line

in the reset code if you like?

i would expect "reset" in the sandbox to "exit(1)". ?how else would you exit ? -mike

Right, I will do that then for now.

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 41 lines · Simon Glass

Hi Mike,

Quoted 37 lines · Mike Frysinger

Quoted 27 lines · On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:

Quoted 11 lines · Wolfgang Denk

Quoted 8 lines · Simon Glass

Quoted 1 line

do_reset() is not supposed to return

I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)

I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.

No, I don't want to change the current definition of reset().

OK.

Quoted 6 lines

And "not able to do the job" is something different than "unimplemented".

Why cannot we do a real reset here? Re-exec'in the running binary or performing a longjmp() to the start might be ideas how to implement this.

While this could be done I believe that it might be possible / desirable to exit out of the main loop, rather than longjmp or re-exec. I have not implemented it because I have not got to that bit yet and don't want to put time into a solution I will throw away.

Quoted 5 lines

I'm happy to just put:

while (1) ;

in the reset code if you like?

i would expect "reset" in the sandbox to "exit(1)". ?how else would you exit ? -mike

Quoted 1 line

Right, I will do that then for now.

Perhaps even nicer would be to define exit codes for the couple of cases where we expect to "leave" U-Boot. ?So reset, and jump to linux kernel, and perhaps power off. ?So a script calling the sandbox u-boot can check the reason and possibly rerun it in the reset case.

Thanks,
? ?Anton

Quoted 7 lines

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

i would expect "reset" in the sandbox to "exit(1)". how else would you exit ?

Quoted 2 lines · Mike Frysinger

i would expect "reset" in the sandbox to "exit(1)". how else would you exit ?

"reset" should then use "exit(EXIT_SUCCESS)" as thisis a normal termination of the program, not an error condition.

These files are taken from the ARM board implementation and then reduced to remove unneeded cr!uft.

arch/sandbox/lib/Makefile new file +1 -0

 
+LIBGCC	= $(obj)libgcc.o
 

+static int display_dram_config(void)

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

Quoted 3 lines · On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's board.c:
? ? ? ?board_init_f calls board_init_r
? ? ? ?board_init_r does while (1) main_loop()

-mike

On Sat, Sep 17, 2011 at 5:05 PM, Mike Frysinger <[email protected]> wrote:

Quoted 1 line

NAK; i dont see how sandbox is special. just do what i do in Blackfin's

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

Dear Simon Glass,

Quoted 2 lines · In message <CAPnjgZ1DfWHum=WuzRh75eU7raf_QbCWorc6YpkhhuBzOP1B0Q@mail.gmail.com>…

On Sat, Sep 17, 2011 at 5:05 PM, Mike Frysinger <[email protected]> wrote:

...

Quoted 1 line

Quoted 1 line

NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's

...

Quoted 4 lines

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

I think the argument that the sandbox should be implemented and behave like the real implementations is a very important one. ?Please let's stick to that.

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: wd at denx.de A mouse is an elephant built by the Japanese.

Quoted 9 lines · Mike Frysinger

Quoted 3 lines · On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

NAK; i dont see how sandbox is special. just do what i do in Blackfin's board.c:
board_init_f calls board_init_r
board_init_r does while (1) main_loop()

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

Quoted 11 lines · On Friday, September 23, 2011 11:55:11 Simon Glass wrote:

Quoted 9 lines · Mike Frysinger

Quoted 3 lines · On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's board.c:
? ? ? ?board_init_f calls board_init_r
? ? ? ?board_init_r does while (1) main_loop()

Quoted 4 lines

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

i dont understand what you mean. ?the main loop allows you to process commands forever and thus test as many commands as you want.

if you're testing something before the main_loop, then i think it is correct that you'd "boot" from scratch, get to the main_loop (and thus pass your test), and then call "reset" to exit. ?if you want to test something else before main_loop, start all over from scratch.
-mike

Hi Mike,

Quoted 17 lines · Mike Frysinger

Quoted 11 lines · On Friday, September 23, 2011 11:55:11 Simon Glass wrote:

Quoted 9 lines · Mike Frysinger

Quoted 3 lines · On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's board.c:
? ? ? ?board_init_f calls board_init_r
? ? ? ?board_init_r does while (1) main_loop()

Quoted 4 lines

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

Quoted 9 lines

i dont understand what you mean. ?the main loop allows you to process commands forever and thus test as many commands as you want.

if you're testing something before the main_loop, then i think it is correct that you'd "boot" from scratch, get to the main_loop (and thus pass your test), and then call "reset" to exit. ?if you want to test something else before main_loop, start all over from scratch.
-mike

In short: at this stage I really don't mind what this particular patch looks like - it will become clear later.

Long version: I think there might be a basic confusion here as to how this test idea is supposed to work. I think I mentioned at some point that the question of the test controller will be resolved later.

The test controller is the thing that kicks off tests. Many of these tests will be for a complete run of U-Boot from start to bootm/reset/whatever.

If the test controller is separate from U-boot and runs U-Boot once for each test then yes: reset and bootm can exit, the main loop never needs to quit, etc.

If the test controller is linked with U-Boot, and is basically just a high-level control function for the rest of the code, then we want reset and bootm to exit back to this test controller code.

I haven't written any tests yes so it isn't yet clear what the trade-offs are, but I suspect that linking at least part of the test controller with U-Boot is going to be attractive so that it can spread its tentacles and see what is going on during the test run.

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 45 lines · Simon Glass

Hi Mike,

Quoted 17 lines · Mike Frysinger

Quoted 11 lines · On Friday, September 23, 2011 11:55:11 Simon Glass wrote:

Quoted 9 lines · Mike Frysinger

Quoted 3 lines · On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's board.c:
? ? ? ?board_init_f calls board_init_r
? ? ? ?board_init_r does while (1) main_loop()

Quoted 4 lines

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

Quoted 9 lines

i dont understand what you mean. ?the main loop allows you to process commands forever and thus test as many commands as you want.

if you're testing something before the main_loop, then i think it is correct that you'd "boot" from scratch, get to the main_loop (and thus pass your test), and then call "reset" to exit. ?if you want to test something else before main_loop, start all over from scratch.
-mike

In short: at this stage I really don't mind what this particular patch looks like - it will become clear later.

Long version: I think there might be a basic confusion here as to how this test idea is supposed to work. I think I mentioned at some point that the question of the test controller will be resolved later.

The test controller is the thing that kicks off tests. Many of these tests will be for a complete run of U-Boot from start to bootm/reset/whatever.

If the test controller is separate from U-boot and runs U-Boot once for each test then yes: reset and bootm can exit, the main loop never needs to quit, etc.

Quoted 8 lines

If the test controller is linked with U-Boot, and is basically just a high-level control function for the rest of the code, then we want reset and bootm to exit back to this test controller code.

I haven't written any tests yes so it isn't yet clear what the trade-offs are, but I suspect that linking at least part of the test controller with U-Boot is going to be attractive so that it can spread its tentacles and see what is going on during the test run.

I would actually vote for the exact opposite. ?The test controller should be able to get this information from the mocks of the devices that are used and the input and output it provides and consumes from stdio.

I think it would be better to factor this into two problems. ?Plus, I'm always a fan of smaller single purpose tools that are composed at the process boundary.

Thanks,
? ?Anton

Quoted 7 lines

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Hi Anton,

Quoted 55 lines · Anton Staaf

Quoted 45 lines · Simon Glass

Hi Mike,

Quoted 17 lines · Mike Frysinger

Quoted 11 lines · On Friday, September 23, 2011 11:55:11 Simon Glass wrote:

Quoted 9 lines · Mike Frysinger

Quoted 3 lines · On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:

Since the sandbox architecture doesn't do relocation, we prefer to call board_init_r() explicitly when board_init_f() returns. Similarly we prefer to call main_loop() when board_init_r returns.

NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's board.c:
? ? ? ?board_init_f calls board_init_r
? ? ? ?board_init_r does while (1) main_loop()

Quoted 4 lines

I have done as you say for now, but this isn't great. It means that the only way back to the top level (say to run another test) is to use setjmp/longjmp. But I will deal with this issue when it actually comes up.

Quoted 9 lines

i dont understand what you mean. ?the main loop allows you to process commands forever and thus test as many commands as you want.

if you're testing something before the main_loop, then i think it is correct that you'd "boot" from scratch, get to the main_loop (and thus pass your test), and then call "reset" to exit. ?if you want to test something else before main_loop, start all over from scratch.
-mike

In short: at this stage I really don't mind what this particular patch looks like - it will become clear later.

Long version: I think there might be a basic confusion here as to how this test idea is supposed to work. I think I mentioned at some point that the question of the test controller will be resolved later.

The test controller is the thing that kicks off tests. Many of these tests will be for a complete run of U-Boot from start to bootm/reset/whatever.

If the test controller is separate from U-boot and runs U-Boot once for each test then yes: reset and bootm can exit, the main loop never needs to quit, etc.

Quoted 8 lines

If the test controller is linked with U-Boot, and is basically just a high-level control function for the rest of the code, then we want reset and bootm to exit back to this test controller code.

I haven't written any tests yes so it isn't yet clear what the trade-offs are, but I suspect that linking at least part of the test controller with U-Boot is going to be attractive so that it can spread its tentacles and see what is going on during the test run.

Quoted 6 lines

I would actually vote for the exact opposite. ?The test controller should be able to get this information from the mocks of the devices that are used and the input and output it provides and consumes from stdio.

I think it would be better to factor this into two problems. ?Plus, I'm always a fan of smaller single purpose tools that are composed at the process boundary.

Yes it seems that we need some sort of config input and results output 'file' which device mocks can consume and produce. For the runtime I am thinking of some device state which is specific to testing. For example, a SPI flash driver might be able to emulate failure to erase a block. This feature would be enabled by config, and perhaps the results output would include the pages read/written, etc.

But I do want to keep this simple...

Regards,
Simon

Quoted 12 lines

Thanks,
? ?Anton

Quoted 7 lines

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 7 lines · On Saturday, September 17, 2011 12:48:48 Simon Glass wrote:

common/cmd_bootm.c +1 -0

 
+#if BITS_PER_LONG == 32

? ? ? int ? (*appl)(int, char * const []);
+#endif

common/cmd_bootm.c static int bootm_start_standalone(ulong iflag, int argc, char * const argv[]) · line 472

Quoted 5 lines

+#if BITS_PER_LONG == 32
? ? ? appl = (int (*)(int, char * const []))ntohl(images.ep); ? ? ? (*appl)(argc-1, &argv[1]);

common/cmd_bootm.c +1 -1

-
+#endif

why do you need this ? ?if it's because you're converting from a 32bit int to a pointer, then you could address this by putting an (unsigned long) cast between the pointer and the ntohl() call.

-mike

arch/sandbox/config.mk line 20

Quoted 5 lines · On Saturday, September 17, 2011 12:48:52 Simon Glass wrote:

arch/sandbox/config.mk +1 -1

 
-PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
+PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -I/usr/include

since this gets used by all u-boot files, shouldnt the /usr/include path get added only for specific files/dirs ? ?the ones that glue the u-boot world to the host C library ?

board/sandbox/common/Makefile

Quoted 9 lines

board/sandbox/common/Makefile new file +5 -0

 
+clean:
+ ? ? rm -f $(SOBJS) $(OBJS)
+
+distclean: ? clean
+ ? ? rm -f $(LIB) core *.bak $(obj).depend

these dont get used, so punt them

board/sandbox/common/os.c

Quoted 2 lines

board/sandbox/common/os.c new file +0 -0

isnt this an "arch" issue and not "board" ?

include/os.h

Quoted 2 lines

include/os.h new file +0 -0

seems like this glue should be in the sandbox arch subdir -mike

+#define CONFIG_SYS_PROMPT "=>" /* Command Prompt */

+#define CONFIG_LMB

include/configs/sandbox.h

Quoted 2 lines · On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:

include/configs/sandbox.h new file +0 -0

missing #ifdef multiple include protection

include/configs/sandbox.h

Quoted 2 lines

include/configs/sandbox.h new file +2 -0

+#define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_SYS_SDRAM_BASE ? ? ? ?0

Quoted 1 line

+#define CONFIG_DRAM_SIZE ? ? (128 << 20)

do you need any of this ?

Quoted 2 lines

+#define ? ? ?CONFIG_SYS_PROMPT ? ? ? ? ? ? ? "=>" ? ?/* Command Prompt */

this file has a bunch of "#define<tab>" where it should be "#define<space>"

Quoted 2 lines

+#define CONFIG_LMB

i dont think you need this either ?

-mike

Quoted 4 lines · Mike Frysinger

Quoted 1 line · On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:

+#define CONFIG_DRAM_SIZE (128 << 20)

do you need any of this ?

I want to have simulated DRAM, so yes. But I will make it start always at 0 which removes one item.

Quoted 6 lines · On Friday, September 23, 2011 12:00:15 Simon Glass wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line · On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:

+#define CONFIG_DRAM_SIZE ? ? (128 << 20)

do you need any of this ?

Quoted 2 lines

I want to have simulated DRAM, so yes. But I will make it start always at 0 which removes one item.

which is fine, but i guess the notion of "how much ram do i have" is not standardized anywhere. ?you're copying the arm tree as the basis of the sandbox arch, so it's including the DRAM conventions that arm uses. -mike

There are a few variables set but not used - this marks these as unused for the compiler.

Quoted 2 lines · On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:

There are a few variables set but not used - this marks these as unused for the compiler.

summary says "sandbox:" but i dont think this has anything to do with sandbox. you're just using a newer compiler.

common/cmd_mem.c

Quoted 5 lines

common/cmd_mem.c +1 -1

 
- ? ? ulong ? addr, length, i, junk;
+ ? ? ulong ? addr, length, i, junk __attribute__((unused));

this one is tricky as we just want to read the value from the volatile pointer. ?i'm guessing do "*longp++;" just adds a different warning ?

common/cmd_nvedit.c

Quoted 6 lines

common/cmd_nvedit.c +1 -1

 
- ? ? int len;
+ ? ? int len __attribute((unused));

this file though looks like we should just delete "len"

-mike

Quoted 10 lines · Mike Frysinger

Quoted 2 lines · On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:

There are a few variables set but not used - this marks these as unused for the compiler.

summary says "sandbox:" but i dont think this has anything to do with sandbox. you're just using a newer compiler.

Quoted 3 lines

common/cmd_mem.c +0 -0

Quoted 5 lines

common/cmd_mem.c int do_mem_base (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 474

Quoted 2 lines

common/cmd_mem.c +1 -1

-     ulong   addr, length, i, junk;
+     ulong   addr, length, i, junk __attribute__((unused));

this one is tricky as we just want to read the value from the volatile pointer. i'm guessing do "*longp++;" just adds a different warning ?

Isn't that a nop?

Well I can just assign it to a different variable - I will use 'size' in my new patch set.

Quoted 7 lines

common/cmd_nvedit.c int do_env_edit(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 463

Quoted 5 lines

common/cmd_nvedit.c +1 -1

 
-     int len;
+     int len __attribute((unused));

this file though looks like we should just delete "len"

Yes, done. I don't use lint anyway.

Quoted 17 lines · On Friday, September 23, 2011 12:01:46 Simon Glass wrote:

Quoted 15 lines · Mike Frysinger

Quoted 2 lines · On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:

There are a few variables set but not used - this marks these as unused for the compiler.

summary says "sandbox:" but i dont think this has anything to do with sandbox. you're just using a newer compiler.

common/cmd_mem.c

Quoted 5 lines

common/cmd_mem.c +1 -1

 
- ? ? ulong ? addr, length, i, junk;
+ ? ? ulong ? addr, length, i, junk __attribute__((unused));

this one is tricky as we just want to read the value from the volatile pointer. ?i'm guessing do "*longp++;" just adds a different warning ?

Quoted 1 line

Isn't that a nop?

if it's volatile, it shouldn't be

Quoted 3 lines

Well I can just assign it to a different variable - I will use 'size' in my new patch set.

Marek Vasut posted a patch which dropped the assignment and it seems to not add any warnings

Quoted 10 lines

Quoted 8 lines

common/cmd_nvedit.c

Quoted 6 lines

common/cmd_nvedit.c +1 -1

 
- ? ? int len;
+ ? ? int len __attribute((unused));

this file though looks like we should just delete "len"

Yes, done. I don't use lint anyway.

he also posted a fix for this :)
-mike

arch/sandbox/include/asm/posix_types.h new file +15 -0

 
+typedef struct {
+#if defined(__KERNEL__) || defined(__USE_ALL)
+	int	val[2];
+#else /* !defined(__KERNEL__) && !defined(__USE_ALL) */
+	int	__val[2];
+#endif /* !defined(__KERNEL__) && !defined(__USE_ALL) */
+} __kernel_fsid_t;
+
+#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
+
+#undef	__FD_SET
+#define __FD_SET(fd, fdsetp) \
+		(((fd_set *)fdsetp)->fds_bits[fd >> 5] |= (1<<(fd & 31)))
+
+#undef	__FD_CLR

arch/sandbox/include/asm/u-boot-sandbox.h new file +8 -0

 
+/* cpu/.../cpu.c */
+int	cpu_init(void);
+int	cleanup_before_linux(void);
+
+/* cpu/.../arch/cpu.c */
+int	arch_cpu_init(void);
+int	arch_misc_init(void);
+