Hi, Albrahm:
Thanks a lot!
Best wishes,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Tiger,
On 30 December 2013 17:42, tiger...@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
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
Hello Tiger,
On Wed, Jan 8, 2014 at 6:22 AM, tiger...@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
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
Am 23.04.2012 20:30, schrieb Wolfgang Denk:
Dear Matthias,
In message4f959612.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
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 =
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)
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 seems to me
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 haven't reviewed
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
Hi Wolfgang,
On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger vap...@gentoo.org 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
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 every program
Dear Simon,
In message capnjgz1av723lzf1vnmoarix6dnxfho-962y8wqij5-g462...@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
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
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
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 fully
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
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
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), and fd 0
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
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
Hi Andreas,
On Thu, Dec 1, 2011 at 8:35 AM, Andreas Bießmann
andreas.de...@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
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
25 matches
Mail list logo
