Daniel Alomar wrote:
> > Boa simply ignores the MimeTypes directive. And it even don't read
the
> > default /etc/mime.types file.
> Did you have a boa.conf? This is my boa.conf where I add the
> css support:
Yes.
> AddType text/plain txt
[ ... ]
The AddType directive works, but the Mime
Hello!
I have a uClinux-dist-20051014 working here. Now I would like to
upgrade to the newest greatest. So I downloaded uClinux-dist-20070130,
which don't build anymore. Now I would like to do a binary search
through available releases to find the release which "broke the build".
Unfortunately,
Jivin Phil Wilshire wrote:
> > Which architecture are you using ? Which tools ?
I use lpc2292 (arm7tdmi) with arm-elf-tools-20040427 on a suse-10.1 box.
> > It would probably take less time to fix the problems with the latest
> > build than to find what you are looking for.
The first problems s
Erwin Authried wrote:
> > > > Which architecture are you using ? Which tools ?
> >
> > I use lpc2292 (arm7tdmi) with arm-elf-tools-20040427 on a suse-10.1
box.
> >
> > The first problems seem to be related to the build environment.
While
> > uClinux-dist-20051014 used CROSS_COMPILE=arm-elf- (whi
Hello!
I'm trying to upgrade from uClinux-dist-20051014 to
uClinux-dist-20070130.
For this, I had to change the toolchain to
http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-200
61213.tar.gz
To get a clean build, I had to make some changes (I have the patch
attached, can someb
Erwin Authried wrote:
[ ... kernel Oops ... ]
> > Any ideas what might be wrong here
> you should take a look into System.map for the values of pc and the
> addresses in the backtrace.
Thanks for the answer, Erwin. It turns out that the crash happens in
sched.c:__wake_up_common() which is inlin
Greg Ungerer wrote:
> Wolf, Josef wrote:
> > I'm trying to upgrade from uClinux-dist-20051014 to
> > uClinux-dist-20070130. For this, I had to change the toolchain to
> >
> >
http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-200
61213.tar.gz
>
[ Sorry for the late response, but this [censored] Outlook has no
threading
support :-( ]
> > This board is not supported yet by the official uclinux
distribution,
> > but I tried to keep board specific changes separate.
> Nice price :-)
Yes. Unfortunately, I still can't get it stable. :-(
An
Hello!
I have a problem with HW/SW floating-point mismatches when I try to
compile uClinux-dist-20051014 with arm-linux-tools-20061213. The
problem
appears when compilation of the user directory (starting with boa)
starts
[ ... ]
ucfront-gcc arm-linux-gcc -Os -g
-fomit-f
Thanks for your answer, Greg!
> > To solve this, I put CFLAGS += -msoft-float in
> > vendors/config/armnommu/config.arch. Then the error changes into:
>
> This final link line will need a "-msoft-float" as well.
> Otherwise it will try to link against the wrong libgcc.a
>
Ough... I would not h
> >>> To solve this, I put CFLAGS += -msoft-float in
> >>> vendors/config/armnommu/config.arch. Then the error changes into:
> >> This final link line will need a "-msoft-float" as well.
> >> Otherwise it will try to link against the wrong libgcc.a
> > Ough... I would not have been asked if it wou
Hello!
When I build uClinux-dist-20051014 with arm-linux-tools-20061213, I get:
# df
Filesystem 1k-blocks Used Available Use% Mounted on
Unhandled fault: external abort on linefetch (F4) at 0x0001
fault-common.c(97): start_code=0x817c0040, start_stack=0x8177ff80)
Bus
Hello!
I'm using uClinux-dist-20051014 with an lp2292 (arm7tdmi). I tried to
compile the gdbserver that is included in uClinux-dist-20051014. But
its
configure script bails out with "Target not supported by gdbserver."
Then I checked config.status, and it says
# This directory was configured
Hello,
> gdbserver should be configured with --host only (it is to be hosted on
> target) gdb and gdbserver are actually tied to eachother, as well as
> toolchain and userland build on target. It therefore makes sense to
> build them as a userland app.
Ah, that explains why it is not bundled wi
Hello Per,
> 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.
Same here...
> Yes, the Makefile should be feed with values from t
I wrote:
> With this, the compile succeeds, I can connect to the server,
> but I get a Oops when I issue a "step" command.
>
> It seems to be a problem with get_user_pages (called from the
> ptrace() call).
> I have checked with
> http://www.ucdot.org/article.pl?sid=03/01/07/0214244&mode=thr
I wrote:
> > With this, the compile succeeds, I can connect to the server,
> > but I get a Oops when I issue a "step" command.
> >
> > It seems to be a problem with get_user_pages (called from the
> > ptrace() call).
> > I have checked with
> > http://www.ucdot.org/article.pl?sid=03/01/07/02
> > I have tracked down this a little bit further. it turns out that
> > read_inferior_memory() is called with memaddr==0, which is simply
> > wrong if there's no MMU available.
>
> It looks like the access to address 0 happens when gdb tries to
> examine the stack frames. Please note the "Send
Hello!
I was searching for a detailed overview about what exactly is allowed
when vfork is used. I could find only some rough overview, but neither
uclinux.org nor ucdot.org seem to have a detailed description. Even
google was of no help. So I've decided to create such an overview by
thinking a
David McCullough wrote:
> Some quick bits.
Thanks for the answer, David.
> > Strictly speaking, in contrast to what the man page says, execve()
is
> > the only member of the exec family that is safe, since everything
else
> > is (probably) part of libc and is prone to modify some data.
>
> Not
David Howells
> > My assumption is that execl*() need to allocate memory in order to
> > construct the argv, so the're probably a big risk. execvp/execv
> > _might_ be safe _if_ they use local storage for their work. But
> > you never can be sure unless you know exactly the internals of your
> >
Hello!
I'm trying to move from dhcpcd-new to busybox's udhcpc. The first
difference I noticed is that udhcpc won't work unless "ifconfig eth0 up"
is issued before udhcpc is invoked. dhcpcd-new don't need the ifonfig
command.
Is this the way it should be? Are there any problems (e.g race
condit
Thanks for the answer, Erwin!
Erwin Authried wrote:
> > I'm trying to move from dhcpcd-new to busybox's udhcpc. The first
> > difference I noticed is that udhcpc won't work unless
> > "ifconfig eth0 up" is issued before udhcpc is invoked. dhcpcd-new
> > don't need the ifonfig command.
> >
> >
Hello..
> gdbserver should be configured with --host only (it is to be hosted on
> target) gdb and gdbserver are actually tied to eachother, as well as
> toolchain and userland build on target. It therefore makes sense to
> build them as a userland app.
>
> Attached is a makefile in order to get
Hello,
How do I reboot from the uClinux shell prompt? I tried the /bin/reboot
command from busybox, but with this I get:
# reboot
#
The system is going down NOW !!
Sending SIGTERM to all processes.
Jan 1 00:14:12 dhcpcd[41]: terminating on signal 15
munmap of non-mmaped memory by
Erwin Authried wrote:
> there's no architecture specific code for hardware reset for your cpu.
> You have to do that in include/asm/arch/system.h.
Thanks for the fast answer, Erwin.
So now I need to find out how this is done on the lpc2292. Any hints?
___
Hello,
I use uClinuc-dist-20051014 with linux-2.4.32 on a lpc2492 (this is an
arm7tdmi from NXP). Most of the time, everything works as expected.
But sometimes, the boot hangs when init/main.c tries to open
/dev/console
(this is a serial console on the internal UART of the lpc2492). When I
enter
Phil Wilshire wrote:
> This is a guess but...
>
> when the system hangs after a "restore flags" it is normally
> due to some unserviced interrupt condition.
> The UART is trying to send you an interrupt but you are not
> servicing it correctly therefor the interrupt is immediately
> reasserted.
Phil Wilshire wrote:
> minicom -o
> will stop the AT commands being issued.
Thanks for the tip, Phil. But I am more concerned about the actual
bug.
> I would fix the linux driver to stop the race.
Since there's no hope that NXP will fix the problem, this is the only
way to go.
The primary que
Greg Ungerer wrote:
> I would be surprised if this was a general problem given how
> much this driver is used. So I would be more inclined to say
> it is specific to the NXP processor you are using.
I am not exctly sure about this. The procedure to trigger this hang
is very specific:
- The con
Hello,
I use uClinux-dist-20051014 for quite a while now and it worked great
so far.
Now I decided to activate md5sum utility in busybox. With this, I get
problems with pthreads. For some reason, only the first four
invocations of pthread_create() are successful. The fifth invocation
simply ha
Myself wrote:
> Now I decided to activate md5sum utility in busybox. With this, I get
> problems with pthreads. For some reason, only the first four
> invocations of pthread_create() are successful. The fifth invocation
> simply hangs. There's no error code returned, the system call simply
> d
Jamie Lokier wrote:
> > OK, I've tracked it down now. Seems to be a stack overflow in
busybox.
> > Adding
> >
> > LDFLAGS += -Wl,-elf2flt="-r -s 65536"
> >
> > to user/busybox/Makefile solves the problem.
>
> Be careful: the "-s" option just changes the _initial_ thread's stack.
>
> The stac
rwarner wrote:
> Have you seen this paper on why an mmu might not be wanted in
> a embedded system?
>
> http://www.linuxdevices.com/articles/AT2598317046.html
> also in .pdf @
> http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf
>
>
> I've also thought that the memory page swapping t
34 matches
Mail list logo
