Hi, Albrahm:
Thanks a lot!
Best wishes,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hello Tiger,
On Wed, Jan 8, 2014 at 6:22 AM, 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
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
Hi Tiger,
On 30 December 2013 17:42, 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
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
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 compil
Am 23.04.2012 20:30, schrieb Wolfgang Denk:
Dear Matthias,
In message<4f959612.7040...@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 D
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 ru
Dear Mike Frysinger,
In message <201204231657.18531.vap...@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), a
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 tha
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 seei
Dear Mike Frysinger,
In message <201204231503.08835.vap...@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
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
> > > p
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
Dear Simon,
In message
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 b
Dear Matthias,
In message <4f959612.7040...@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 ever
Hi Wolfgang,
On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger wrote:
> On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
>> =>md 0x100
>> 0100:Segmentation fault
>
> yes, this is because the code to make this work was reverted because of ppc
> oddity. i haven't reviewed that y
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.
Bec
Dear Matthias Weisser,
In message <4f959235.1070...@arcor.de> you wrote:
>
> > On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
> >>=>md 0x100
> >>0100:Segmentation fault
> >
> > yes, this is because the code to make this work was reverted because of ppc
> > oddity. i h
Am 23.04.2012 17:41, schrieb Mike Frysinger:
> On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
>> =>md 0x100
>> 0100: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 see
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
> =>md 0x100
> 0100: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)
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 = 0x
DRAM bank = 0x
-> start= 0x
-> size = 0x080
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
>
Hi Andreas,
On Thu, Dec 1, 2011 at 8:35 AM, Andreas Bießmann
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 d
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-l
25 matches
Mail list logo
