Hi Mike,
I doubt that it's good to use the libraries from the binutils build dir,
they should be used from the path where they are finally installed.
Regards,
Erwin
Am Mittwoch, den 20.02.2008, 18:03 -0500 schrieb Mike Frysinger:
> I'm lazy and having to set 4 configure options when I could just
Hi,
I'm trying to debug a simple helloworld program with gdbserver on m5282evb
running the latest patch of uClinux-dist (20080131).
I compile gdbserver and separately compile gdb for
target=m68k-uclinux-uclibc.
In the target, I run:
gdbserver :1 hello
which starts OK.
But in the host, I have
On 2/20/08, souhail sou <[EMAIL PROTECTED]> wrote:
>
> thank you for your response,
>
>
> i do like you said,
> then the out put show me something strange:
>
> [EMAIL PROTECTED]:/uClinux-dist/linux-2.6.x# skyeye -e linux
> arch: arm
> cpu info: armv3, arm7tdmi, 41007700, fff8ff00, 0
> mach info: na
Jivin Erwin Authried lays it down ...
> Hi Mike,
> I doubt that it's good to use the libraries from the binutils build dir,
> they should be used from the path where they are finally installed.
In Mikes defense, that is how it has been done in the past as we are
building elf2flt against the tool
Jivin Mike Frysinger lays it down ...
> On Wednesday 20 February 2008, David McCullough wrote:
> > Jivin Mike Frysinger lays it down ...
> >
> > > On Tuesday 30 October 2007, Julian Brown wrote:
> > > > This patch allows flthdr's compression options to work in a wider
> > > > variety of environmen
Hello,
Is there any testsuite available for testing uClinux functionality?
Thanks,
Seeni.
_
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/_
skyeye-testsuite-2.3.tar.bz2
- Message d'origine
De : Seeniraj Gurusamy Naickar <[EMAIL PROTECTED]>
À : uclinux-dev@uclinux.org
Envoyé le : Jeudi, 21 Février 2008, 11h26mn 55s
Objet : [uClinux-dev] Test suite to test uClinux
.hmmessage P
{
margin:0px;padding:0px;}
body.hmmessage
{
FONT-
Hi Seeni
The Linux Test Project has been applied to the Blackfin System
http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel
It is not a trivial job to port this to another platform but
if you have the time it is well worth doing.
Regards
Phil Wilshire
souhail sou wrote:
I succed to resolve it thanks
but another error
exec file "linux"'s format is elf32-littlearm.
load section .init: addr = 0x01008000 size = 0xf000.
load section .text: addr = 0x01017000 size = 0x000ade94.
not load section .pci_fixup: addr = 0x010c5000 size = 0x .
not load section
On Thursday 21 February 2008, Erwin Authried wrote:
> I doubt that it's good to use the libraries from the binutils build dir,
> they should be used from the path where they are finally installed.
that decision is in the hands of the guy compiling elf2flt. also, since
you're statically compiling
I understand that with uCLinux the heap for all processes is allocated
dynamically from a single pool for all processes.
Where is the cache memory for the file systems (such as JFFS2) allocated ?
Does the activities of the file systems cause heap space blocking and/or
fragmentation that migh
В сообщении от Monday 18 February 2008 21:13:18 Matt Waddel написал(а):
> Do you have the CPUCLOCK set to 18000 in the bdi2000
> mcf5329.cfg file?
>
> CPUCLOCK18000 ;the CPU clock rate after processing the init list
I tried all CPUCLOCK values but it didn't have any effect.
I was ab
Well, this version seems to be ok. What file you are burning? When i
tested it with monte jade i used the redboot.rom from intel for ixdpg425
(it is the new name for monte jade)
I think now it is not the problem of flashing. Try the file from the web
site from intel.
(I also used the low baudrate,
Hello
I am using M5235EVB and uClinux 20070130 with kernel 2.6.x. I have several
problems with mcf_qspi compilation:
1) mcf_qspi.c includes devfs_fs_kernel.h which was used in kernel 2.4 but is
not present in 2.6
2) There are some undefined symbols, like QSPIDEBUG, QSPIBSZ, MCFSIM_ICR4 and
so o
Hello all,
I have the M5208EVBe board booting the uClinux distro provided by Intec.
I tried to build the mcf_5208 driver several weeks ago. The driver did
not compile as is under 2.6.x. There were several defines missing. Worse
yet I seem to remember that a couple of the QSPI device registers
UDP recvfrom is not working for us with the 2.6.23 kernel. Is there a
patch for this?
- UDP sendto works
- UDP recvfrom worked in the 2.6.19 dist
Here is what we used to test this:
- PC to uclinux --
1. on uclinux (192.168.1.77):
nc -l -u -p 4794
2. from PC on network:
echo "hell
Actually this is an un-patch. I'm running that latest sources (via
uClinux-dist-20070130-20080212.patch) and found some very odd behavior
with my web UI that uses 'haserl' and busybox's shell (ash). The symptom
suggested a buffer overflow, which led me to discover there are uClinux
patches against
On Thursday 21 February 2008, [EMAIL PROTECTED] wrote:
> Actually this is an un-patch. I'm running that latest sources (via
> uClinux-dist-20070130-20080212.patch) and found some very odd behavior
> with my web UI that uses 'haserl' and busybox's shell (ash). The symptom
> suggested a buffer overfl
Jivin [EMAIL PROTECTED] lays it down ...
> Actually this is an un-patch. I'm running that latest sources (via
> uClinux-dist-20070130-20080212.patch) and found some very odd behavior
> with my web UI that uses 'haserl' and busybox's shell (ash). The symptom
> suggested a buffer overflow, which led
DMcLeod wrote:
UDP recvfrom is not working for us with the 2.6.23 kernel. Is there a
patch for this?
What hardware platform?
What ethernet driver?
- UDP sendto works
- UDP recvfrom worked in the 2.6.19 dist
Here is what we used to test this:
- PC to uclinux --
1. on uclinux
Hi Michael,
Michael Schnell wrote:
I understand that with uCLinux the heap for all processes is allocated
dynamically from a single pool for all processes.
Where is the cache memory for the file systems (such as JFFS2) allocated ?
The same memory pool.
Everything is allocated from the same
Quoth Sean McGranaghan:
> I could not get the mcf_qspi driver to leave the chip select asserted
> after the 16th word in the transfer. (I tried all manner of
> configurations using the QCRn[CONT] bit (bit 15 in the Command
> Register) and QWR[CSIV] bit (bit 12 of the Wrap Register). The short
> of
Hi,
I'm using the i2c-dev.c driver, but am having a problem with i2c* not
showing up in either /dev or /proc/bus. Apparently I'm not the only
one who has encountered this:
https://lists.linux-foundation.org/pipermail/bugme-new/2003-October/009143.html
It seems like that driver is compiling into
What I'm asking is to undo a uClinux patch to the original busybox sources.
We are in accord.
On Thu, Feb 21, 2008 at 6:07 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thursday 21 February 2008, [EMAIL PROTECTED] wrote:
> > Actually this is an un-patch. I'm running that latest sources (via
I understand the need to eliminate duplicate definitions, but libbb.h
already includes . That's sufficient for getting BUFSIZ, yes? I guess
I could request that busybox remove the ifndef BUFSIZ declaration, but that
still leaves me wondering who is seeing the duplicate declaration warnings
that tri
Quoth David van Geest:
> I'm using the i2c-dev.c driver, but am having a problem with i2c* not
> showing up in either /dev or /proc/bus. Apparently I'm not the only
> one who has encountered this:
> https://lists.linux-foundation.org/pipermail/bugme-new/2003-
> October/009143.html
>
> It seems li
On Thursday 21 February 2008, [EMAIL PROTECTED] wrote:
> I understand the need to eliminate duplicate definitions, but libbb.h
> already includes . That's sufficient for getting BUFSIZ, yes? I
> guess I could request that busybox remove the ifndef BUFSIZ declaration,
> but that still leaves me wond
Jivin Mike Frysinger lays it down ...
> On Thursday 21 February 2008, [EMAIL PROTECTED] wrote:
> > I understand the need to eliminate duplicate definitions, but libbb.h
> > already includes . That's sufficient for getting BUFSIZ, yes? I
> > guess I could request that busybox remove the ifndef BUFSI
Jivin [EMAIL PROTECTED] lays it down ...
> I understand the need to eliminate duplicate definitions, but libbb.h
> already includes . That's sufficient for getting BUFSIZ, yes? I guess
> I could request that busybox remove the ifndef BUFSIZ declaration, but that
> still leaves me wondering who is
When moving the xmalloc changes from the Blackfin elf2flt to the upstream
elf2flt repo, I accidentally dropped the libiberty.h include. Not a fatal
error, but having proper prototypes is always a good thing.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
elf2flt.c |1 +
1 files change
30 matches
Mail list logo
