how odd... going back to debug level 1, and now that don't work
either... hmm...
Per Hallsmark wrote:
and to add more to the mysteri jffs2 debuglevel 0 doesn't work,
debug level 1 *work*, debug level 2 doesn't work...
must be some timing issue, code execution order or
and to add more to the mysteri jffs2 debuglevel 0 doesn't work,
debug level 1 *work*, debug level 2 doesn't work...
must be some timing issue, code execution order or similar...
Per Hallsmark wrote:
Hi again,
As before in some mailings, I've got a combined mmu/nommu ker
Hi again,
As before in some mailings, I've got a combined mmu/nommu kernel for
ixp465 based targets and arm7tdmi'ish based targets.
It's been reached as:
1. download linux 2.6.24.4 and made it run on a ixp465 based hardware,
everything works good.
2. downloaded the 2.6.24 uclinux patch, app
Ok, thanks for clarifying.
It is better to follow the way community is moving so I just change to this.
Greg Ungerer wrote:
David McCullough wrote:
Jivin Gavin Lambert lays it down ...
Quoth Per Hallsmark:
As said, I'd really like to get rid of conversions in runtime if
possible
:
The build system have to make a little endian cramfs.
The target has to do conversions if it is big endian.
As said, I'd really like to get rid of conversions in runtime if possible.
But perhaps I have to get used to this? Or have I missed something here?
Best regards,
Per
Per Hall
Hi all,
Here is what I've done in short:
1. download linux 2.6.24.4 and made it run on a ixp465 based hardware,
big endian here.
2. downloaded the 2.6.24 uclinux patch, applied it on above kernel and
made it run on a arm7tdmi'ish hardware, little endian.
3. When all this is done, I switched ba
Hi uClinux'ers!
In a arm7tdmi'sh SoC, I put together the 2.6.24 uclinux patch ontop of
2.6.24.4 (customer uses same ver
for other targets and wanted to have same kernel ver all over) and it
sounds like slub would be a good thing.
But slub doesn't work. If I use slab it works fine.
Is slab stil
Hi Greg,
Probably this is known already, so just in case...
There is an error in the patch in section:
diff -Naurp linux-2.6.24/net/netfilter/Makefile
linux-2.6.24-uc0/net/netfilter/Makefile
--- linux-2.6.24/net/netfilter/Makefile 2008-01-25 08:58:37.0 +1000
+++ linux-2.6.24-uc0/net/n
David McCullough wrote:
Jivin Per Hallsmark lays it down ...
Hi,
I'm running a arm7tdmi with a snapgear 3.3.0 base.
A lot of the userland stuff works good but some fails like:
From the data below you have compiled busybox in two completely
different ways.
The first is load
Hi,
I'm running a arm7tdmi with a snapgear 3.3.0 base.
A lot of the userland stuff works good but some fails like:
/> which
BINFMT_FLAT: reloc outside program 0x30590300 (0 - 0x9ec94/0x35180),
killing which!
which[14] killed because of sig - 11
STACK DUMP:
(which is here a busybox applet)
I
h wrote:
Jivin Per Hallsmark lays it down ...
Dear nommu gurus!
I'm back down the work-pile and trying porting linux 2.6 on a ARM nommu
processor.
The boot seems going farly well, but as soon as userland start, it goes
to some parallell universe or something.
Unfortunally this plat
Thanks Greg for clarifying.
Going for the extended proc-arm7tdmi.S as before.
Greg Ungerer wrote:
Hi Per,
Per Hallsmark wrote:
Dear nommu gurus!
I'm back down the work-pile and trying porting linux 2.6 on a ARM
nommu processor.
The boot seems going farly well, but as soon as userland
g/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
# Glue Makefile for busybox
#
# Author: Per Hallsmark <[EMAIL PROTECTED]>
#
PKG=busybox-1.5.0
-include $(CONFIG_CONFI
Dear nommu gurus!
I'm back down the work-pile and trying porting linux 2.6 on a ARM nommu
processor.
The boot seems going farly well, but as soon as userland start, it goes
to some parallell universe or something.
Unfortunally this platform hasn't any jtag interface so it's a struggle
to conti
Hello Josef,
In my snapgear tree, about the same as uClinux tree, there are two previous
gdbserver attempts. One is user/gdbserver and the other user/gdb.
Didn't get any of those working so therefore the birth of a third one.
Yes, the Makefile should be feed with values from the uClinux build en
_
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
# Glue Makefile for gdb/gdbserver
#
# Author: Pe
Perhaps they share interrupts?
Is SA_SHIRQ flag set on both eth irq and usb irq?
-Original Message-
From: "xavier.montagne" <[EMAIL PROTECTED]>
To: "uClinux development list"
Date: Wed, 28 Feb 2007 01:39:02 +0100
Subject: Re: [uClinux-dev] SL811 usb host
> Hi Steve,
>
> Actually it fixe
point to consider is uClinux/snapgear specific
patches for the package. Presently, these patches are
applied directly to the package. With an extra
directory level (???), would the uClinux/snapgear
patch be distributed in the parent directory and
applying the patch be incorporated into the "
links if anyone
wants
to tackle it,
This isn't urgent from my perspective, busy rebuilding toolchains at the
moment :)
Joy :-)
Cheers,
Davidm
# Glue Makefile for yassl
#
# Author: Per Hallsmark <[EMAIL PROTECTED]>
#
PKG = cyassl-0.6.2
all: $(PKG)/Makefile
$(MAKE) -C
19 matches
Mail list logo
