[U-Boot] Sandbox question

[U-Boot] Sandbox question

[Andreas Bießmann]

Dear Simon,

I started to play around with new sandbox architecture and encountered a
serious problem.
Due to the '-nostdinc' switch the file arch/sandbox/cpu/os.c requires
additional CPPFLAGS '-I/usr/include'. On my debian box this is not
enough since the bits/*.h are placed in /usr/include/i386-linux-gnu and
therefore I get errors when compiling arch/sandbox/os.c.
Are there any clean solution to get this working?

best regards

Andreas Bie?mann

[U-Boot] Sandbox question

[Simon Glass]

Hi Andreas,

On Thu, Dec 1, 2011 at 8:35 AM, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Dear Simon,
>
> I started to play around with new sandbox architecture and encountered a
> serious problem.
> Due to the '-nostdinc' switch the file arch/sandbox/cpu/os.c requires
> additional CPPFLAGS '-I/usr/include'. On my debian box this is not
> enough since the bits/*.h are placed in /usr/include/i386-linux-gnu and
> therefore I get errors when compiling arch/sandbox/os.c.
> Are there any clean solution to get this working?

Perhaps removing the -nostdinc switch for just that file would work?
The idea with sandbox is that os.c is the interface to the OS, and is
compiled with access to system headers. You might get link failures,
but it might be ok. It would be nice to avoid 'gcc -print-search-dirs'
if we can.

Regards,
Simon

>
> best regards
>
> Andreas Bie?mann
>

[U-Boot] Sandbox question

[Mike Frysinger]

On Thursday 01 December 2011 11:35:14 Andreas Bie?mann wrote:
> I started to play around with new sandbox architecture and encountered a
> serious problem.
> Due to the '-nostdinc' switch the file arch/sandbox/cpu/os.c requires
> additional CPPFLAGS '-I/usr/include'. On my debian box this is not
> enough since the bits/*.h are placed in /usr/include/i386-linux-gnu and
> therefore I get errors when compiling arch/sandbox/os.c.
> Are there any clean solution to get this working?

try this
-mike

diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
index e5e860b..25ca148 100644
--- a/arch/sandbox/cpu/Makefile
+++ b/arch/sandbox/cpu/Makefile
@@ -23,9 +23,6 @@
 # MA 02111-1307 USA
 #
 
-# os.c is build in the system environment, so needs standard includes
-CPPFLAGS_arch/sandbox/cpu/os.o += -I/usr/include
-
 include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(CPU).o
@@ -40,6 +37,8 @@ all:	$(obj).depend $(LIB)
 $(LIB):	$(OBJS)
 	$(call cmd_link_o_target, $(OBJS))
 
+$(obj)os.o: ALL_CFLAGS := $(filter-out -nostdinc,$(ALL_CFLAGS))
+
 #########################################################################
 
 # defines $(obj).depend target
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111201/b5fcbf06/attachment.pgp>

[U-Boot] Sandbox question

[Wolfgang Denk]

Hello,

I have a few sandbox related questions (examples run on v2012.04)

1) Memory map - What is it supposed to look like?

   I get "DRAM:  128 MiB", and

	=>bdi
	boot_params = 0x00000000
	DRAM bank   = 0x00000000
	-> start    = 0x00000000
	-> size     = 0x08000000
	FB base     = 0x00000000

   Yet I get:

   	=>md 0x100
	00000100:Segmentation fault

2) Sandbox does no handle EOF on stadin; this makes it impossible to
   use it in test scripts.  For example, something like this should
   work:

   	$ echo printenv | ./u-boot

   [As woraround I have to use ``echo 'printenv;reset' | ./u-boot'';
   this works, but is not really intuitive nore useful.]

3) For automatic test suites it would make a lot of sense if the
   return code of U-Boot was the return code of the last executed
   command (expecially when termination of U-Boot is the result of
   encountering EOF on stdin).


What do you 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: wd at denx.de
There is is no reason for any individual to have a computer in  their
home.      -- Ken Olsen (President of Digital Equipment Corporation),
              Convention of the World Future Society, in Boston, 1977

[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
>    	=>md 0x100
> 	00000100:Segmentation fault

yes, this is because the code to make this work was reverted because of ppc 
oddity.  i haven't reviewed that yet to see why, but it seems to me that the 
ppc code is not quite right.

> 2) Sandbox does no handle EOF on stadin; this makes it impossible to
>    use it in test scripts.  For example, something like this should
>    work:
> 
>    	$ echo printenv | ./u-boot

currently as designed -- this is how the hardware works after all.  it keeps 
polling stdin forever and there is no concept of "EOF" in a serial port.  the 
reads are also non-blocking, so i'm not sure it's possible to tell when you've 
got EOF vs read too fast.  might be able to contingent on stdin being a TTY 
though.

> 3) For automatic test suites it would make a lot of sense if the
>    return code of U-Boot was the return code of the last executed
>    command (expecially when termination of U-Boot is the result of
>    encountering EOF on stdin).

i'm not sure how hard that is to pass on.  Simon might know since he's been 
grubbing around the shell internals lately.  we could have reset take an 
argument in the sandbox path so it's easy to pass back arbitrary values in the 
middle of a script.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/bbeacd0f/attachment.pgp>

[U-Boot] Sandbox question

[Matthias Weisser]

Am 23.04.2012 17:41, schrieb Mike Frysinger:
> On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
>>    	=>md 0x100
>> 	00000100:Segmentation fault
> 
> yes, this is because the code to make this work was reverted because of ppc 
> oddity.  i haven't reviewed that yet to see why, but it seems to me that the 
> ppc code is not quite right.

I suggested another solution:
http://patchwork.ozlabs.org/patch/123074/

This has the disadvantage, as discussed in the thread, that the address
passed to mmap is not guaranteed to be returned.

This could be caught by an assert. The base address in the patch
(0x20000000) was choosen with respect to the typical process address
layout on x86 and x86_64 linux to avoid any conflict. Even when ASLR
causes this the u-boot binary could still be started using setarch with
ASLR disabled.

-- 
Matthias

[U-Boot] Sandbox question

[Wolfgang Denk]

Dear Matthias Weisser,

In message <4F959235.1070106@arcor.de> you wrote:
>
> > On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
> >>    	=>md 0x100
> >> 	00000100:Segmentation fault
> > 
> > yes, this is because the code to make this work was reverted because of ppc 
> > oddity.  i haven't reviewed that yet to see why, but it seems to me that the 
> > ppc code is not quite right.

The PPC code just accesses physical memory, as is.

> I suggested another solution:
> http://patchwork.ozlabs.org/patch/123074/
> 
> This has the disadvantage, as discussed in the thread, that the address
> passed to mmap is not guaranteed to be returned.

I don't see why this would be needed.


I think you got things backwards.

Please note that I do NOT complain that "md 0x100" or "md 0" segfaults
in general; it is IMO perfectoy OK to do this if there is no memory.
But the "bdinfo" command reported that memory starts at 0, and then
both these commands are supposed to work.

I am not asking for any specific mapping - I just ask for _consistent_
information provided to the user.

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
If ignorance is bliss, why aren't there more happy people?

[U-Boot] Sandbox question

[Matthias Weisser]

Am 23.04.2012 19:39, schrieb Wolfgang Denk:
>> I suggested another solution:
>> http://patchwork.ozlabs.org/patch/123074/
>>
>> This has the disadvantage, as discussed in the thread, that the address
>> passed to mmap is not guaranteed to be returned.
> 
> I don't see why this would be needed.

Because you will have the same address for "physical memory" in all
instances of sandbox u-boot. This could simplify test scripts a bit.
Imagine testing tftp downloads to memory where DRAM bank-> start is
different for every program run. This was a PITA for me while testing
the tap ethernet simulation for sandbox. And that is why I came up with
the patch.

Or is there something like $(ramstart) in u-boot?

-- 
Matthias

[U-Boot] Sandbox question

[Wolfgang Denk]

Dear Matthias,

In message <4F959612.7040903@arcor.de> you wrote:
>
> Because you will have the same address for "physical memory" in all
> instances of sandbox u-boot. This could simplify test scripts a bit.
> Imagine testing tftp downloads to memory where DRAM bank-> start is
> different for every program run. This was a PITA for me while testing
> the tap ethernet simulation for sandbox. And that is why I came up with
> the patch.

Agreed - though I would expect the mapping at least to be consistent
through all runs of the same binary image.

> Or is there something like $(ramstart) in u-boot?

Not yet - but it would be trivial to add.

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
Everyting looks interesting until you do it. Then you find it's  just
another job.                     - Terry Pratchett, _Moving Pictures_

[U-Boot] Sandbox question

[Matthias Weißer]

Am 23.04.2012 20:30, schrieb Wolfgang Denk:
> Dear Matthias,
>
> In message<4F959612.7040903@arcor.de>  you wrote:
>>
>> Because you will have the same address for "physical memory" in all
>> instances of sandbox u-boot. This could simplify test scripts a bit.
>> Imagine testing tftp downloads to memory where DRAM bank->  start is
>> different for every program run. This was a PITA for me while testing
>> the tap ethernet simulation for sandbox. And that is why I came up with
>> the patch.
>
> Agreed - though I would expect the mapping at least to be consistent
> through all runs of the same binary image.

This would be the case as long as the u-boot image is run without ASLR 
which can be achieved by running it using setarch

>> Or is there something like $(ramstart) in u-boot?
>
> Not yet - but it would be trivial to add.

And would fix the issue without any problems introduced by hinted mmap 
or an "address translation layer". But ramstart would be different on 
every run of the binary if ASLR is active.

-- 
Matthias

[U-Boot] Sandbox question

[Simon Glass]

Hi Wolfgang,

On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
>> ? ? ? =>md 0x100
>> ? ? ? 00000100:Segmentation fault
>
> yes, this is because the code to make this work was reverted because of ppc
> oddity. ?i haven't reviewed that yet to see why, but it seems to me that the
> ppc code is not quite right.

The commit which made this work was this one:

355a835 sandbox: Change md command to use map_physmem

and was reverted by:

94c50f1 Revert "sandbox: Change md command to use map_physmem"

The commit message from the revert is

    The original commit broke long standing assumption that md commands work
    on effective addresses.  This normally isn't an issue for most systems
    that map 1:1, however on systems with a 36-bit address map it breaks.

I did try to start a discussion on the list about how to deal with
this. One idea was to add a translation function in the md command
(and potentially then in other code) that converts an effective
address as seen by U-Boot into one that can be used by the
architecture. The down side is that all architectures except sandbox
would have this as a no-op.

I am pretty keen for sandbox memory to start at 0 if possible, since
it makes test code easier to write if we can make that assumption.
Also I don't like the idea of different people writing test code with
different assumptions about the memory map, such that we can't run all
the tests with the same sandbox config.

>
>> 2) Sandbox does no handle EOF on stadin; this makes it impossible to
>> ? ?use it in test scripts. ?For example, something like this should
>> ? ?work:
>>
>> ? ? ? $ echo printenv | ./u-boot
>
> currently as designed -- this is how the hardware works after all. ?it keeps
> polling stdin forever and there is no concept of "EOF" in a serial port. ?the
> reads are also non-blocking, so i'm not sure it's possible to tell when you've
> got EOF vs read too fast. ?might be able to contingent on stdin being a TTY
> though.

Yes I think this captures the current situation. We could perhaps add
some sort of hack to make this work, perhaps with a new CONFIG option
which accepts EOF on input and somehow passes it up the stack, or
keeps the info in sandbox's state. Another option would be to create a
special sandbox input device. In any case, it would be nice to
implement EOF in the console layer for this. Could be related to
serial cleanup also.

>
>> 3) For automatic test suites it would make a lot of sense if the
>> ? ?return code of U-Boot was the return code of the last executed
>> ? ?command (expecially when termination of U-Boot is the result of
>> ? ?encountering EOF on stdin).
>
> i'm not sure how hard that is to pass on. ?Simon might know since he's been
> grubbing around the shell internals lately. ?we could have reset take an
> argument in the sandbox path so it's easy to pass back arbitrary values in the
> middle of a script.

I'm pretty sure I had this working, at least for one shell. It was
part of the motivation for the command cleanup.

It would be worth sorting out these three things. Once we have a bit
of agreement on which way to go, I'm happy to come up with some
patches for any that don't have volunteers.

> -mike

Regards,
Simon

[U-Boot] Sandbox question

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ1aV723LzF1vnMOArix6DNXFHO-962Y8WQij5-G46226g@mail.gmail.com> you wrote:
> 
> I did try to start a discussion on the list about how to deal with
> this. One idea was to add a translation function in the md command
> (and potentially then in other code) that converts an effective
> address as seen by U-Boot into one that can be used by the
> architecture. The down side is that all architectures except sandbox
> would have this as a no-op.

I don't see why such a function would be needed.  Other architectures
don't need it either.  Yes, some architectures use a common, fixed
mapping (like PPC, where physical RAM almost always starts at address
0x0) - but others don't have such a common map- for example on ARM,
there is a wild mix where RAM starts, and basicly every SoC defines
his own mapping.

> I am pretty keen for sandbox memory to start at 0 if possible, since
> it makes test code easier to write if we can make that assumption.

On ARM you don't have this either.

> Also I don't like the idea of different people writing test code with
> different assumptions about the memory map, such that we can't run all
> the tests with the same sandbox config.

Eventually introducing two variables like ramstart and ramend would
solve 90% of the potential issues.

In any case, information returned by commands like bdinfo must be
correct.

> > currently as designed -- this is how the hardware works after all. ?it keeps
> > polling stdin forever and there is no concept of "EOF" in a serial port. ?the
> > reads are also non-blocking, so i'm not sure it's possible to tell when you've
> > got EOF vs read too fast. ?might be able to contingent on stdin being a TTY
> > though.
>
> Yes I think this captures the current situation. We could perhaps add
> some sort of hack to make this work, perhaps with a new CONFIG option

I don't see why we cannot simply read from stdin (or rathr from file
descriptor 0) as usual?   You can use standard methods like select()
or poll() to wait for input, which will also inform you about events
like EOF.

> which accepts EOF on input and somehow passes it up the stack, or
> keeps the info in sandbox's state. Another option would be to create a
> special sandbox input device. In any case, it would be nice to
> implement EOF in the console layer for this. Could be related to
> serial cleanup also.

Good point.

Marek,  can you please add this to the DM planning?



> It would be worth sorting out these three things. Once we have a bit
> of agreement on which way to go, I'm happy to come up with some
> patches for any that don't have volunteers.

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: wd at denx.de
Of course there's no reason for it, it's just our policy.

[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote:
> Simon wrote:
> > I did try to start a discussion on the list about how to deal with
> > this. One idea was to add a translation function in the md command
> > (and potentially then in other code) that converts an effective
> > address as seen by U-Boot into one that can be used by the
> > architecture. The down side is that all architectures except sandbox
> > would have this as a no-op.
> 
> I don't see why such a function would be needed.  Other architectures
> don't need it either.  Yes, some architectures use a common, fixed
> mapping (like PPC, where physical RAM almost always starts at address
> 0x0) - but others don't have such a common map- for example on ARM,
> there is a wild mix where RAM starts, and basicly every SoC defines
> his own mapping.

because, as you said, you want things to be deterministic.  when the sandbox 
starts up, it does mmap() and there's no guarantee that the address you get 
back is always going to be the same.  you cannot compare this to an SoC where 
the memory layout is always exactly the same for u-boot across runs.  thus we 
need the map call to adjust what the user sees (memory always starts at 0) vs 
what sandbox got back from the kernel (almost literally, any address).

> > Also I don't like the idea of different people writing test code with
> > different assumptions about the memory map, such that we can't run all
> > the tests with the same sandbox config.
> 
> Eventually introducing two variables like ramstart and ramend would
> solve 90% of the potential issues.
> 
> In any case, information returned by commands like bdinfo must be
> correct.

it was correct.  and then the change that made it correct was reverted.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/d8ecaafe/attachment.pgp>

[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote:
> Simon wrote:
> > > currently as designed -- this is how the hardware works after all.  it
> > > keeps polling stdin forever and there is no concept of "EOF" in a
> > > serial port.  the reads are also non-blocking, so i'm not sure it's
> > > possible to tell when you've got EOF vs read too fast.  might be able
> > > to contingent on stdin being a TTY though.
> > 
> > Yes I think this captures the current situation. We could perhaps add
> > some sort of hack to make this work, perhaps with a new CONFIG option
> 
> I don't see why we cannot simply read from stdin (or rathr from file
> descriptor 0) as usual?

the "usual" method of reading from stdin involves the tty doing buffering and 
the application only seeing fully flushed lines.  thus it would not operate the 
same as the hardware (where u-boot gets every char as you type) and you 
wouldn't be able to handle things like tab completion.

> You can use standard methods like select() or poll() to wait for input,
> which will also inform you about events like EOF.

because that isn't how u-boot on the hardware works.  u-boot itself calls 
tstc() to see if there's any data and does so in a continuous loop.  when 
there is data, it calls getc().  tstc() should not block, and getc() isn't 
call unless u-boot knows there's data.

it is also problematic (currently) to get access to errno from the C library 
because u-boot itself has a variable called "errno".  so we cannot call the C 
library's read() and check errno to see why it failed.  would be possible to 
solve by having u-boot internally rename the storage from "errno" to something 
else, and then having u-boot's errno.h header define "errno" to the rename 
value.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/cb422b05/attachment.pgp>

[U-Boot] Sandbox question

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201204231503.08835.vapier@gentoo.org> you wrote:
>
> > I don't see why we cannot simply read from stdin (or rathr from file
> > descriptor 0) as usual?
>
> the "usual" method of reading from stdin involves the tty doing buffering and 
> the application only seeing fully flushed lines.  thus it would not operate the 

That's why I wrote "or rather from fd 0".

> same as the hardware (where u-boot gets every char as you type) and you 
> wouldn't be able to handle things like tab completion.

C'me on.  That's a standard issue.  We know how to handle this, right?

> > You can use standard methods like select() or poll() to wait for input,
> > which will also inform you about events like EOF.
>
> because that isn't how u-boot on the hardware works.  u-boot itself calls 
> tstc() to see if there's any data and does so in a continuous loop.  when 
> there is data, it calls getc().  tstc() should not block, and getc() isn't>  
> call unless u-boot knows there's data.

That's why I suggested to use select() or poll() to poll for available
characters, just like the hardware does.  Only we do NOT want to tun
this in a tight loop.  We will most likely want to add a sufficiently
large delay to keep CPU load in reasonable bounds.

> it is also problematic (currently) to get access to errno from the C library 
> because u-boot itself has a variable called "errno".  so we cannot call the C 

Why invent new methods when we can encapsulate this in the input
interface?

We do not even have to pass EOF on to higher layers in U-Boot - we
could exit directly in the tty interface code.

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
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
      - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>

[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > I don't see why we cannot simply read from stdin (or rathr from file
> > > descriptor 0) as usual?
> > 
> > the "usual" method of reading from stdin involves the tty doing buffering
> > and the application only seeing fully flushed lines.  thus it would not
> > operate the
> 
> That's why I wrote "or rather from fd 0".

reading directly from fd 0 makes no difference.  stdin is stdin.  if stdin is 
backed by a tty, you need to behave differently than if it's backed by a pipe.

> > same as the hardware (where u-boot gets every char as you type) and you
> > wouldn't be able to handle things like tab completion.
> 
> C'me on.  That's a standard issue.  We know how to handle this, right?

and it's being handled already in the code because i submitted a patch to do 
so.  my point was that sandbox can't read from stdin "as usual".

> > > You can use standard methods like select() or poll() to wait for input,
> > > which will also inform you about events like EOF.
> > 
> > because that isn't how u-boot on the hardware works.  u-boot itself calls
> > tstc() to see if there's any data and does so in a continuous loop.  when
> > there is data, it calls getc().  tstc() should not block, and getc()
> > isn't call unless u-boot knows there's data.
> 
> That's why I suggested to use select() or poll() to poll for available
> characters, just like the hardware does.  Only we do NOT want to tun
> this in a tight loop.  We will most likely want to add a sufficiently
> large delay to keep CPU load in reasonable bounds.

where exactly do you propose adding this delay ?  tstc() is called in many 
places (not just the main console loop), many of which are done simply to 
handle the unlikely CTRL+C interrupt.  thus we don't want tstc() delaying at 
all or it'll slow down random CPU-bound operations.

also, what you're proposing is changing the behavior of u-boot when it's in 
the sandbox so that it acts less like the hardware.  when you run u-boot on 
the hardware and it's sitting at the prompt, u-boot is running the cpu at 
100%.

> > it is also problematic (currently) to get access to errno from the C
> > library because u-boot itself has a variable called "errno".  so we
> > cannot call the C
> 
> Why invent new methods when we can encapsulate this in the input
> interface?

i'm not inventing new methods.  i'm telling you that the sandbox OS layer 
today cannot access the C library's errno because u-boot's own implementation 
of errno is overriding it.  so any call sandbox makes to the OS (like read() 
or select() or poll()) that results in an error, sandbox has no way of knowing 
the underlying reason.

> We do not even have to pass EOF on to higher layers in U-Boot - we
> could exit directly in the tty interface code.

yes, we can special case the sandbox-specific serial driver and have it call 
the sandbox-specific exit function when EOF is reached.

if it's a pipe, we can do it in the tstc() func by waiting until POLLIN is 
cleared and POLLHUP is set.

if it's a tty, the eof key (CTRL+D by default) will emit an EOT byte (0x04) 
which we will read in getc().  that is, if we want to actually support this.  
after all, doing CTRL+D on a serial port won't cause the board to reset, so 
i'm not sure the sandbox shell should exit either.  plus, this would get in 
the way of code reading arbitrary data.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/e7ce5e8d/attachment.pgp>

[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 16:57:16 Mike Frysinger wrote:
> On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote:
> > Mike Frysinger wrote:
> > > > You can use standard methods like select() or poll() to wait for
> > > > input, which will also inform you about events like EOF.
> > > 
> > > because that isn't how u-boot on the hardware works.  u-boot itself
> > > calls tstc() to see if there's any data and does so in a continuous
> > > loop.  when there is data, it calls getc().  tstc() should not block,
> > > and getc() isn't call unless u-boot knows there's data.
> > 
> > That's why I suggested to use select() or poll() to poll for available
> > characters, just like the hardware does.  Only we do NOT want to tun
> > this in a tight loop.  We will most likely want to add a sufficiently
> > large delay to keep CPU load in reasonable bounds.
> 
> where exactly do you propose adding this delay ?  tstc() is called in many
> places (not just the main console loop), many of which are done simply to
> handle the unlikely CTRL+C interrupt.  thus we don't want tstc() delaying
> at all or it'll slow down random CPU-bound operations.
> 
> also, what you're proposing is changing the behavior of u-boot when it's in
> the sandbox so that it acts less like the hardware.  when you run u-boot on
> the hardware and it's sitting at the prompt, u-boot is running the cpu at
> 100%.

hmm, maybe the hush shell works differently and calls getc() directly rather 
than itself calling tstc().  so in the hardware, it eats the cpu because the 
hardware has no way of sleeping for the data, but in an OS we can wait for 
input.  should be easy to post a patch for this code path.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/bb019221/attachment.pgp>

[U-Boot] Sandbox question

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201204231657.18531.vapier@gentoo.org> you wrote:
>
> > That's why I wrote "or rather from fd 0".
>
> reading directly from fd 0 makes no difference.  stdin is stdin.  if stdin is 

stdin is stdin (a FILE pointer which uses all the automatic buffering
from stdio), and fd 0 is fd 0 (a plain file descriptoor you can use as
you like).

> backed by a tty, you need to behave differently than if it's backed by a pipe.

This does not play any role in this context, or does it?

> > That's why I suggested to use select() or poll() to poll for available
> > characters, just like the hardware does.  Only we do NOT want to tun
> > this in a tight loop.  We will most likely want to add a sufficiently
> > large delay to keep CPU load in reasonable bounds.
>
> where exactly do you propose adding this delay ?  tstc() is called in many
> places (not just the main console loop), many of which are done simply to 
> handle the unlikely CTRL+C interrupt.  thus we don't want tstc() delaying at 
> all or it'll slow down random CPU-bound operations.

It makes _zero_ sense to burn 100% CPU with this code.  Adding a few
10 ... a few 100 us delay tstc() will probably not be noticed.

Did you try that out?

> also, what you're proposing is changing the behavior of u-boot when it's in
> the sandbox so that it acts less like the hardware.  when you run u-boot on
> the hardware and it's sitting at the prompt, u-boot is running the cpu at 
> 100%.

Correct.  But then U-Boot is the only master of the CPU, and nothing
else can be run in parallel.

In the sandbox, U-Boot is an ordinary user space application and as
such is supposed to behave well.  Burning 100% CPU is a polling input
loop is about the most stupid thing we can do.

> > Why invent new methods when we can encapsulate this in the input
> > interface?
>
> i'm not inventing new methods.  i'm telling you that the sandbox OS layer 
> today cannot access the C library's errno because u-boot's own implementation 
> of errno is overriding it.  so any call sandbox makes to the OS (like read() 
> or select() or poll()) that results in an error, sandbox has no way of knowing 
> the underlying reason.

Than this needs to be fixed for sandbox?


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
If a train station is a place where a train stops,
                                           then what's a workstation?

[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 17:17:57 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > also, what you're proposing is changing the behavior of u-boot when it's
> > in the sandbox so that it acts less like the hardware.  when you run
> > u-boot on the hardware and it's sitting at the prompt, u-boot is running
> > the cpu at 100%.
> 
> Correct.  But then U-Boot is the only master of the CPU, and nothing
> else can be run in parallel.
> 
> In the sandbox, U-Boot is an ordinary user space application and as
> such is supposed to behave well.  Burning 100% CPU is a polling input
> loop is about the most stupid thing we can do.

not when you're aiming to act like the hardware whenever possible.  we 
specifically do not want #ifdef CONFIG_SANDBOX outside of sandbox-specific 
drivers if we can avoid it.  that means we are bound by the implicit 
constraints at the driver boundaries.  so if u-boot common code does:
	while (tstc())
		...
then sandbox should be eating the cpu.  however, it seems that the hush shell 
does while (getc()), so that shouldn't be an issue here.

> > > Why invent new methods when we can encapsulate this in the input
> > > interface?
> > 
> > i'm not inventing new methods.  i'm telling you that the sandbox OS layer
> > today cannot access the C library's errno because u-boot's own
> > implementation of errno is overriding it.  so any call sandbox makes to
> > the OS (like read() or select() or poll()) that results in an error,
> > sandbox has no way of knowing the underlying reason.
> 
> Than this needs to be fixed for sandbox?

the only way to fix it is what i suggested: rename "int errno" in lib/errno.c 
to something like "int uboot_errno" and then add to errno.h: "#define errno 
uboot_errno".  this shouldn't make any difference at all to compiled code.  the 
only difference is that people doing symbol debugging would get a different 
symbol name.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/1217b792/attachment.pgp>

[U-Boot] [PATCH 0/8] Secure boot improvements and test on Beaglebone Black

[Simon Glass]

Hi Tom,

On 2 October 2013 08:44, Simon Glass <sjg@chromium.org> wrote:
> This series adds a few improvements to the image signing feature to
> make it easier to use on the Beaglebone Black.
>
> - Add a DEV_TREE_BIN option to make it easier to include the correct FDT
> (with embedded public keys) into the U-Boot image
> - Enable cache for more TI boards (to speed things up)
> - Increase malloc size
> - Enable CONFIG_OF_CONTROL, FIT and secure boot on am33xx/omap
>     (RFC only, not sure we want this, although we could create a separate
>      config for it)
>
> I also have a change to adjust mkimage to automatically make space in the
> FDT when adding hashes and signatures. Included here is the ENOSPC patch,
> but the fit_image.c patch will wait until the dumpimage tool is merged,
> since I am changing the same code.
>
> With this, secure boot was tested successfully on Beaglebone Black.

Do you think any of these patches should be applied?

Regards,
Simon

>
>
> Simon Glass (8):
>   am33xx/omap: Allow cache enable for all Sitara/OMAP
>   hash: Export functions to find and show hash
>   fdt: Add DEV_TREE_BIN option to specify a device tree binary file
>   fdt: Update functions which write to an FDT to return -ENOSPC
>   arm: ti: Increase malloc size to 16MB for armv7 boards
>   RFC: am33xx/omap: Enable CONFIG_OF_CONTROL
>   RFC: am33xx/omap: Enable FIT support
>   RFC: am33xx/omap: Enable secure boot with CONFIG_FIT_SIGNATURE
>
>  Makefile                                       |   8 +-
>  arch/arm/cpu/armv7/omap-common/Makefile        |   4 +
>  arch/arm/cpu/armv7/omap-common/hwinit-common.c |  41 --
>  arch/arm/cpu/armv7/omap-common/omap-cache.c    |  56 +++
>  arch/arm/cpu/armv7/omap3/board.c               |   8 -
>  arch/arm/dts/am33xx.dtsi                       | 649 +++++++++++++++++++++++++
>  arch/arm/dts/dt-bindings/gpio/gpio.h           |  15 +
>  arch/arm/dts/dt-bindings/pinctrl/am33xx.h      |  41 ++
>  arch/arm/dts/dt-bindings/pinctrl/omap.h        |  54 ++
>  board/siemens/common/board.c                   |   9 -
>  board/ti/dts/am335x-bone-common.dtsi           | 262 ++++++++++
>  board/ti/dts/am335x-boneblack.dts              |  17 +
>  board/ti/dts/tps65217.dtsi                     |  56 +++
>  common/hash.c                                  |  13 +-
>  common/image-fit.c                             |   4 +-
>  doc/README.fdt-control                         |  16 +-
>  include/configs/am335x_evm.h                   |   9 +
>  include/configs/ti_armv7_common.h              |   2 +-
>  include/hash.h                                 |  22 +
>  include/rsa.h                                  |   3 +-
>  lib/rsa/rsa-sign.c                             |  28 +-
>  21 files changed, 1236 insertions(+), 81 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/omap-common/omap-cache.c
>  create mode 100644 arch/arm/dts/am33xx.dtsi
>  create mode 100644 arch/arm/dts/dt-bindings/gpio/gpio.h
>  create mode 100644 arch/arm/dts/dt-bindings/pinctrl/am33xx.h
>  create mode 100644 arch/arm/dts/dt-bindings/pinctrl/omap.h
>  create mode 100644 board/ti/dts/am335x-bone-common.dtsi
>  create mode 100644 board/ti/dts/am335x-boneblack.dts
>  create mode 100644 board/ti/dts/tps65217.dtsi
>
> --
> 1.8.4
>

[U-Boot] sandbox question

[TigerLiu at viatech.com.cn]

Hi, Simon:
Sandbox concept is a very good idea to test uboot's non-platform part
code.

I have a question about compiling uboot sandbox branch:
1. It seems sandbox branch could be compiled by gcc compiler on a x86
platform.
   Not need to set cross compiler tool chains.
   And after finished compiling, it could be run on a x86 environment.
   So, my question is:
   Arm cross compiler tool chains could produce different obj file for a
same .C file.
   The obj file for a same .C file by arm cross compiler tool chain is
not different with the obj file produced by a x86 gcc tool.
   (On my x86 platform, defaut gcc is a x86 version)

   So, for more precise test for non-platform code:
    User should compile sandbox branch with an arm cross compiler tool
chain.
    And should run it on an arm linux environment?

Best wishes,

[U-Boot] sandbox question

[TigerLiu at viatech.com.cn]

Hi, Simon:
Sorry for some typo.
I re-wrote this mail:
---------------------------------------
I have a question about compiling uboot sandbox branch:
1. It seems sandbox branch could be compiled by gcc compiler on a x86
platform.
   Not need to set cross compiler tool chains.
   And after finished compiling, it could be run on a x86 environment.
   So, my question is:
   The obj file for a same .C file by arm cross compiler tool chain is
different with the obj file produced by a x86 gcc tool.
   (On my x86 platform, defaut gcc is a x86 version)

   So, for more precise test for non-platform code:
    User should compile sandbox branch with an arm cross compiler tool
chain.
    And should run it on an arm linux environment?

Best wishes,

[U-Boot] sandbox question

[Simon Glass]

Hi Tiger,


On 30 December 2013 17:42, <TigerLiu@viatech.com.cn> wrote:

> Hi, Simon:
> Sorry for some typo.
> I re-wrote this mail:
>

I've been away, sorry for the delay.


> ---------------------------------------
> I have a question about compiling uboot sandbox branch:
> 1. It seems sandbox branch could be compiled by gcc compiler on a x86
> platform.
>    Not need to set cross compiler tool chains.
>    And after finished compiling, it could be run on a x86 environment.
>    So, my question is:
>    The obj file for a same .C file by arm cross compiler tool chain is
> different with the obj file produced by a x86 gcc tool.
>    (On my x86 platform, defaut gcc is a x86 version)
>
>    So, for more precise test for non-platform code:
>     User should compile sandbox branch with an arm cross compiler tool
> chain.
>     And should run it on an arm linux environment?
>

Well you could, but what benefit would that provide? It would not use any
code from arch/arm if that is what you are thinking. Sandbox is its own
'architecture'?

Regards,
Simon


>
> Best wishes,
>

[U-Boot] sandbox question

[TigerLiu at viatech.com.cn]

Hi, Simon:

Thanks for your reply!

>Well you could, but what benefit would that provide? It would not use
any code from arch/arm if that is what you are thinking. Sandbox is its
own >'architecture'?

 

For example:

1.     i want to test fs/ext4 driver.

They are architecture independent code.

I means:

(1) the obj files produced by arm gcc compiler are different with obj
files produced by x86 gcc compiler.

     Maybe arm gcc compiler would introduce some arm architecture
related optimizations for fs/ext4 drivers.

     Maybe x86 gcc compiler would introduce some x86 architecture
related optimizations for fs/ext4 drivers.

     So, if sandbox's fs/ext4 drivers' test passed on an x86
platform,but these architecture related optimizations would cause 

some potential bugs on ARM platform.

 

Is it a problem?

 

Best wishes,

[U-Boot] sandbox question

[Abraham Varricatt]

Hello Tiger,

On Wed, Jan 8, 2014 at 6:22 AM,  <TigerLiu@viatech.com.cn> wrote:
> Hi, Simon:
>
> Thanks for your reply!
>
>>Well you could, but what benefit would that provide? It would not use
> any code from arch/arm if that is what you are thinking. Sandbox is its
> own >'architecture'?

Your question seems a bit odd to me. My understanding of the sandbox
feature, is to let someone play around with u-boot from an
architecture independent perspective. Theoretically, this means that
you should be able to cross-compile the sandbox application as an ARM
executable and run it anywhere ... like on the Raspberry Pi (ARMv7, I
think). Or you could just compile it and run on a standard x86 system.

Obviously, the binary images produced for both architectures will be
different, but the code should work the same. And naturally, running
the application on an x86 system working at 2Ghz will be different
from running it on an ARM system working at 700Mhz. The whole point of
calling the code "architecture independent" is that it will work
across all systems.

>      So, if sandbox's fs/ext4 drivers' test passed on an x86
> platform,but these architecture related optimizations would cause
>
> some potential bugs on ARM platform.
>

If you really do find an odd bug where it does not work as expected
(it can happen), then that's an exceptional case which should be
investigated further. I'm not sure if investigating it in sandbox mode
will help.

-Abraham V.

[U-Boot] sandbox question

[TigerLiu at viatech.com.cn]

Hi, Albrahm:
Thanks a lot!

Best wishes,