Hi uClinux hackers,
I am trying to build a Linux System for Qemu/m68k to do runtime
testing of a uClibc spin-off called uClibc-ng.
(http://www.uclibc-ng.org)
I am really a newbie regarding MMU-less Linux systems, so don't be
to critical ;)
My toolchain (gcc 4.8.3, binutils 2.24) seems to work,
Hi Greg,
Greg Ungerer wrote,
Hi Waldemar,
On 15/08/14 00:18, Waldemar Brodkorb wrote:
Hi uClinux hackers,
I am trying to build a Linux System for Qemu/m68k to do runtime
testing of a uClibc spin-off called uClibc-ng.
(http://www.uclibc-ng.org)
I am really a newbie regarding MMU-less
Hi Greg,
Do you have a suggestion why I get a segfault after first executed
command? Similar behaviour Thomas Petazzoni have seen, while he was
trying to run buildroot in Qemu/m68k. See here:
http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html
No, I haven't seen that
Hi Greg,
Greg Ungerer wrote,
Hi Waldemar,
On 22/08/14 06:25, Waldemar Brodkorb wrote:
Do you have a suggestion why I get a segfault after first executed
command? Similar behaviour Thomas Petazzoni have seen, while he was
trying to run buildroot in Qemu/m68k. See here:
http
Hi,
Thanks for the help. After adding the FEC Kernel patch, the error
didn't occur anymore. I now have a shell (sash) with simpleinit and
can execute my uClibc tests.
best regards
Waldemar
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
Hi Geert,
Geert Uytterhoeven wrote,
Hi Waldemar,
On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb w...@openadk.org wrote:
I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k.
Any idea what change breaks the compile?
I tried a few m68knommu defconfigs, but can't
Hi Greg,
Greg Ungerer wrote,
I don't have any compile (or runtime) problems with m5208evb_defconfig
on linux-4.0.5 either. That is close to what most people use with qemu.
What .config are you using?
Are you sure the defconfig creates a bootable image?
I still need at least two patches.
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 31/12/15 09:55, Waldemar Brodkorb wrote:
> >Add a check for dlopen to configure.ac
> >
> >Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org>
> >---
> > configure.ac |1 +
> >
Sync part of the patches from http://cgit.uclibc-ng.org/cgi/cgit/elf2flt.git/
required to support H8/300 and Xtensa.
Tested with GDB simulator for H8/300 and Qemu for Xtensa.
Waldemar Brodkorb (3):
dlopen is used by newer binutils, so check for it
recent binutils for h8/300 no longer use
From: Yoshinori Sato <ys...@users.souceforge.jp>
R_H8_DIR24A8 / R_H8_DIR24R8 keep all byte.
Signed-off-by: Yoshinori Sato <ys...@users.sourceforge.jp>
Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org>
---
elf2flt.c |4 ++--
1 file changed, 2 insertions(+), 2 deleti
Remove SYMBOL_PREFIX for h8/300.
Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org>
Signed-off-by: Yoshinori Sato <ys...@users.souceforge.jp>
---
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index adf5883..5c
Add a check for dlopen to configure.ac
Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org>
---
configure.ac |1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index 4e7df5a..adf5883 100644
--- a/configure.ac
+++ b/configure.ac
@@ -192,6 +192,7 @@ dnl re
From: Yoshinori Sato <ys...@users.souceforge.jp>
Add new relocation R_H8_DISP32A16.
hi-byte clear on R_H8_DIR32 R_H8_DIR24A8 R_H8_DIR24R8 R_H8_DIR32A16
R_H8_DISP32A16
Signed-off-by: Yoshinori Sato <ys...@users.sourceforge.jp>
Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org&
From: Yoshinori Sato <ys...@users.souceforge.jp>
Signed-off-by: Yoshinori Sato <ys...@users.sourceforge.jp>
Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org>
---
flthdr.c |8
1 file changed, 8 insertions(+)
diff --git a/flthdr.c b/flthdr.c
index 8a8b9
Hi Greg,
Greg Ungerer wrote,
> Thanks for that. When I get a spare minute I will dig into it
> and see if I can make any sense of that. It is obviously way out
> of the expected range.
Any spare minute to check what is wrong here?
best regards
Waldemar
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> Sorry for the slow response. The uclinux-dev email list seems
> very unreliable at the moment. I never got your last response,
> but I can see it in the archives:
>
> http://mailman.uclinux.org/pipermail/uclinux-dev/2016-May/052747.html
Oh, that
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 26/05/16 22:05, Waldemar Brodkorb wrote:
> > Greg Ungerer wrote,
> >> On 20/05/16 14:20, Waldemar Brodkorb wrote:
> >>> Greg Ungerer wrote,
> >>>> On 16/05/16 19:54, Waldemar Brodkorb wrote:
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 20/05/16 14:20, Waldemar Brodkorb wrote:
> > Greg Ungerer wrote,
> >> On 16/05/16 19:54, Waldemar Brodkorb wrote:
> >>> I compile and test the thread test app from here on
> >>> Qemu coldfi
Add patchset from ptxdist which is required to produce working
ARM flat binaries. Tested with busybox on Kinetis K70.
Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
---
v1 -> v2:
- segfault problem fixed, r_mem pointer should be initialized
- v1 was successfully tested by Thomas
Ted Victorio wrote,
> The syslogd (busybox) compiled successfully; however, executing syslogd gave
> this result:
>
> /> syslogd: exec /proc/self/exe: No such file or directory
>
> Please advise. Thank you very much.
Is /proc mounted on your system?
best regards
Waldemar
Add patchset from ptxdist which is required to produce working
ARM flat binaries. Tested with busybox on Kinetis K70.
Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
---
After this patch is upstream, I want to send an update
patch to buildroot to use your repository. Then I will
take m
Hi uClinux/elf2flt devs,
How can I debug an issue with the following error while
executing:
~ # ./hello
BINFMT_FLAT: reloc outside program 0xb589 (0 - 0x125a4/0x8b0c),
killing hello!
SEGV
The target is an ARM Cortex-M4 device. The error is only happening
when libpthread from uClibc-ng is
Hi Greg,
Greg Ungerer wrote,
> > How could I generate the information for you? Do you have
> > a kernel patch I would need to apply? I can bootup a kernel
> > and execute code, I just can't type anything into the serial
>
> Attached is a kernel patch that modifies binfmt_flat to print
> out the
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 29/04/16 05:10, Waldemar Brodkorb wrote:
> > Hi Greg,
> > Greg Ungerer wrote,
> >
> >> Hi Angelo,
> >>
> >> On 20/04/16 04:14, angelo wrote:
> >>> infinite thanks.
> >&g
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 16/05/16 19:54, Waldemar Brodkorb wrote:
> >I compile and test the thread test app from here on
> >Qemu coldfire emulation:
> >http://debug.openadk.org/arm-pthreads/hello.c
> >
> >Sometimes it w
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> > I disabled CONFIG_BINFMT_SHARED_FLAT in the kernel.
> > And now I get:
> > ~ # /hello
> > [ 90.83] BINFMT_FLAT: reloc[405] outside program 0xed87 (0
> > - 0x123b0/0x8944), killing hello!
> > SEGV
> >
> > Compiling with
> >
Hi,
I compile and test the thread test app from here on
Qemu coldfire emulation:
http://debug.openadk.org/arm-pthreads/hello.c
Sometimes it works, sometimes I get SIGILL.
Here is the strace output when I get SIGILL:
~ # strace -f /test
ioctl(0, TCGETS, {B115200 opost isig icanon echo ...}) = 0
Hi Greg,
Greg Ungerer wrote,
> Attached is a kernel patch that modifies binfmt_flat to print
> out the reloc number along with the reloc error. That way we can
> map that back to the reloc entry number printed out in the verbose
> output from elf2flt at compile time.
The stm32 is now working,
Hi Greg,
Waldemar Brodkorb wrote,
> Hi Greg,
> Greg Ungerer wrote,
>
> > Attached is a kernel patch that modifies binfmt_flat to print
> > out the reloc number along with the reloc error. That way we can
> > map that back to the reloc entry number printed out in
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 07/04/16 19:35, Waldemar Brodkorb wrote:
> > Hi Greg,
> > Greg Ungerer wrote,
> >
> >>> You can find readelf, objdump -x, objdump -D and the source of
> >>> hello.c here:
> >>>
Hi Greg,
Greg Ungerer wrote,
> Hi Angelo,
>
> On 20/04/16 04:14, angelo wrote:
> > infinite thanks.
> >
> > Do you maybe have also the
> > gcc-5.3.0-fix-libgcc-build.patch ?
>
> Yep, attached.
Can you explain why this patch is required and why
the atomic code failes to compile?
Do you mind to
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 23/04/16 08:50, Waldemar Brodkorb wrote:
> >Hi Greg,
> >Greg Ungerer wrote,
> >
> >>>How could I generate the information for you? Do you have
> >>>a kernel patch I would need to apply? I can
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On this specific issue of simple flat binaries not working on m68k.
> This fixes the issue:
>
> http://marc.info/?l=linux-m68k=146976701216533=2
>
> I can run your hello binary now with no problems after this is
> applied.
Thanks for fixing
Hi,
your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
booting in qemu-system-m68k:
qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel
qemu-m68k-mcf5208-initramfspiggyback-kernel
[0.00] Linux version 4.9.6-1 (wbx@vopenadk) (gcc version
5.4.0 (GCC) ) #2 Thu Feb
Hi,
Laurent Vivier wrote,
> Le 03/02/2017 à 01:35, John Paul Adrian Glaubitz a écrit :
> > On 02/03/2017 01:10 AM, Greg Ungerer wrote:
> >> This is a limitation in the FEC support in QEMU.
> >> This works on real ColdFire hardware (which do support the
> >> FEC MIB stats registers from offset
Hi,
ping?
Any help is appreciated,
Waldemar
> Am 19.12.2016 um 20:42 schrieb Waldemar Brodkorb <w...@openadk.org>:
>
> Hi,
>
> I try to run a simple hello world program on a Numato Mimasv2
> FPGA board with J2 bitstream. It is a slightly modified sh2
> architect
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 19/03/16 13:53, Greg Ungerer wrote:
> > Hi Waldemar,
> >
> > On 14/03/16 15:01, Waldemar Brodkorb wrote:
> >> Add patchset from ptxdist which is required to produce working
> >> ARM flat
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 16/08/16 03:21, Waldemar Brodkorb wrote:
> >Hi Greg,
> >Greg Ungerer wrote,
> >>Hi Waldemar,
> >>
> >>On this specific issue of simple flat binaries not working on m68k.
> >>This f
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 06/05/16 05:06, Waldemar Brodkorb wrote:
> >Hi Greg,
> >Waldemar Brodkorb wrote,
> >
> >>Hi Greg,
> >>Greg Ungerer wrote,
> >>
> >>>Attached is a kernel patch that modifies b
Hi,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 19/08/16 08:48, Waldemar Brodkorb wrote:
> > Hi Greg,
> > Greg Ungerer wrote,
> >
> >> Hi Waldemar,
> >>
> >> On 19/03/16 13:53, Greg Ungerer wrote:
> >>> Hi Waldemar,
> >>&
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> Waldemar Brodkorb wbx at openadk.org wrote:
> > Greg Ungerer wrote,
> >> Hi Waldemar,
> >> On 23/04/16 08:50, Waldemar Brodkorb wrote:
> >> >Hi Greg,
> >> >Greg Ungerer wrote,
> >> &
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 25/08/16 07:35, Waldemar Brodkorb wrote:
> > Hi,
> > Greg Ungerer wrote,
> >
> >> Hi Waldemar,
> >>
> >> On 19/08/16 08:48, Waldemar Brodkorb wrote:
> >>> Hi Greg,
> >>> Greg
Hi Greg,
Greg Ungerer wrote,
> Hi Waldemar,
>
> On 25/08/16 07:34, Waldemar Brodkorb wrote:
> > Hi Greg,
> > Greg Ungerer wrote,
> >
> >> Hi Waldemar,
> >>
> >> Waldemar Brodkorb wbx at openadk.org wrote:
> >>> Greg Ungerer wrot
Hi Alex,
A. Brand wrote,
> Hi together,
>
> normally i work bare metal on Cortex-M devices. But with devices such as the
> Cortex-M7 with more than 200MHz, i think of using uclinux for my coming IoT
> applications.
>
> How is the actual status of the Cortex-M7 Support? My first Target will be
6.2.0 so that libgcc isn't compiled as position independent
code.
best regards
Waldemar
>From 123fe2e98cce5c82d81d2a350529a1ea712a4058 Mon Sep 17 00:00:00 2001
From: Waldemar Brodkorb <w...@openadk.org>
Date: Sat, 26 Mar 2016 10:26:56 +0100
Subject: [PATCH] fix sh2 toolchain building
S
45 matches
Mail list logo
