Re: [uClinux-dev] regression for m68k/coldfire

[Greg Ungerer]

Hi Laurent,

On 04/02/17 19:49, Laurent Vivier wrote:

Le 04/02/2017 à 03:03, Greg Ungerer a écrit :

Hi Laurent,

On 04/02/17 01:22, Laurent Vivier wrote:

Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :

[snip]

Btw: Laurent, are you m68k with mmu support are going to be included
upstream? I always carry an old binary for any m68k with mmu testing.


I'm working to have the FPU included for now, that will allow to have
the linux-user qemu enabled for 680x0 upstream.

I have a 68040 MMU implementation that I will send after this step.
I didn't have a look to the ColdFire MMU (is there one?), but as 68040
is not the same as the 68030 one, I don't expect it works with coldfire.


There is a ColdFire MMU in some v4 ColdFire parts, for example
the 547x, 548x, 5441x and 5445x families. It is not compatible with
the older 68020/86030/68040 MMU. It is supported in mainline Linux -
at least for the 547x and 548x parts.

It would be really nice to have support for ColdFire MMU in QEMU :-)


I can work on this. Do you have a Coldfire distro I can install?


This is the one I use:

  http://www.uclinux.org/pub/uClinux/dist/

(toolchains for it at http://www.uclinux.org/pub/uClinux/m68k-elf-tools/)

Or if you don't want to compile it there is a ready to
run binary for the m5475evb at:

  http://www.uclinux.org/ports/coldfire/binary.html

Regards
Greg


___
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

Re: [uClinux-dev] regression for m68k/coldfire

[Greg Ungerer]

Hi Laurent,

On 04/02/17 01:22, Laurent Vivier wrote:

Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :

[snip]

Btw: Laurent, are you m68k with mmu support are going to be included
upstream? I always carry an old binary for any m68k with mmu testing.


I'm working to have the FPU included for now, that will allow to have
the linux-user qemu enabled for 680x0 upstream.

I have a 68040 MMU implementation that I will send after this step.
I didn't have a look to the ColdFire MMU (is there one?), but as 68040
is not the same as the 68030 one, I don't expect it works with coldfire.


There is a ColdFire MMU in some v4 ColdFire parts, for example
the 547x, 548x, 5441x and 5445x families. It is not compatible with
the older 68020/86030/68040 MMU. It is supported in mainline Linux -
at least for the 547x and 548x parts.

It would be really nice to have support for ColdFire MMU in QEMU :-)

Regards
Greg
___
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

Re: [uClinux-dev] regression for m68k/coldfire

[Greg Ungerer]

Hi Waldemar,

On 03/02/17 06:15, Waldemar Brodkorb wrote:
> your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
> booting in qemu-system-m68k:
> 
> qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel 
> qemu-m68k-mcf5208-initramfspiggyback-kernel
[snip]
> [3.46] ColdFire internal UART serial driver
> [3.47] mcfuart.0: ttyS0 at MMIO 0xfc06 (irq = 90,
> base_baud = 208) is a ColdFire UART
> [3.50] console [ttyS0] enabled
> [3.50] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91,
> base_baud = 208) is a ColdFire UART
> [3.51] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92,
> base_baud = 208) is a ColdFire UART
> qemu: hardware error: mcf_fec_read: Bad address 0x200
> 
> CPU #0:
> D0 = 0200   A0 = 4780fdec   F0 =  (   0)
> D1 = 4780ff94   A1 = 401703de   F1 =  (   0)
> D2 = 46dbb000   A2 = 4780f800   F2 =  (   0)
> D3 = 4019d612   A3 = fc030200   F3 =  (   0)
> D4 =    A4 = 4019d608   F4 =  (   0)
> D5 = 40043f7a   A5 = 400222a0   F5 =  (   0)
> D6 = 400df204   A6 = 4783de78   F6 =  (   0)
> D7 = 401701c0   A7 = 4783de28   F7 =  (   0)
> PC = 400e5ff2   SR = 2009 -N--C FPRESULT =0
> Aborted
> wbx@vopenadk:~/m68k/openadk$ 
> wbx@vopenadk:~/m68k/openadk$ qemu-system-m68k --version
> QEMU emulator version 2.8.0
> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
> developers
> 
> Any ideas how to fix it?

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 0x200 - so not 5272).
I sent this patch to the qemu dev list a couple of weeks
back which fixes qemu:

 http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg01781.html

I do not believe it has been picked up by QEMU mainline yet
(I will probably have to resend and push a little to get that done).

Regards
Greg



___
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

Re: [uClinux-dev] [PATCH v2] allow to build arm flat binaries

[Greg Ungerer]

Hi Waldemar,

On 27/08/16 21:25, Waldemar Brodkorb 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 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 binaries. Tested with busybox on Kinetis K70.
>>>>>>>>
>>>>>>>> Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
>>>>>>>
>>>>>>> Thanks. Applied to the github elf2flt repository (with Thomas'
>>>>>>> Tested-by).
>>>>>>
>>>>>> The adding of the ARM.eidx section in this patch breaks binaries
>>>>>> that have a global offset table (GOT). I propose the attached fix
>>>>>> that puts it within the data section proper - and not effectively
>>>>>> at the start of the data section.
>>>>>>
>>>>>> The original patch would have no impact on fully relocated
>>>>>> binaries, generally only those compiled with -fpic or similar.
>>>>>
>>>>> I tested your patch with Buildroot on a STM32F29 device, but it
>>>>> fails on boot while executing one of the startup scripts:
>>>>>
>>>>> [0.65] STM32 USART driver initialized
>>>>> [0.65] 40011000.serial: ttyS0 at MMIO 0x40011000 (irq = 17, 
>>>>> base_baud = 5625000) is a stm32-usart
>>>>> [0.89] console [ttyS0] enabled
>>>>> [0.91] Freeing unused kernel memory: 12K (9000a000 - 9000d000) In
>>>>> [1.26]
>>>>> [1.26] Unhandled exception: IPSR = 0003 LR = fff1
>>>>> [1.26] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
>>>>> [1.26] Hardware name: STM32 (Device Tree Support)
>>>>> [1.26] task: 9055 ti: 9055a000 task.ti: 9055a000
>>>>> [1.26] PC is at 0x2100
>>>>> [1.26] LR is at 0xfffd
>>>>> [1.26] pc : [<2100>]lr : []psr: 4035
>>>>> [1.26] sp : 9055bff8  ip : 9055bfe0  fp : 90555008
>>>>> [1.26] r10:   r9 : 0003  r8 : 0024
>>>>> [1.26] r7 : 0072  r6 : 906ccad8  r5 :   r4 : 0072
>>>>> [1.26] r3 :   r2 : 0003  r1 : 906ccafc  r0 : 
>>>>> [1.26] xPSR: 4035
>>>>> [1.26] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
>>>>> [1.26] Hardware name: STM32 (Device Tree Support)
>>>>> [1.26] [<0800bd41>] (unwind_backtrace) from [<0800b0df>] 
>>>>> (show_stack+0xb/0xc)
>>>>> [1.26] [<0800b0df>] (show_stack) from [<0800b68f>] 
>>>>> (__invalid_entry+0x4b/0x4c)
>>>>>
>>>>> Without the patch the system boots up fine.
>>>>
>>>> Ok, thanks for the feedback.
>>>>
>>>> Can you try this patch instead then?
>>>> It keeps the ARM.edix table at the same relative position, but moves
>>>> the _etext symbol to be after the ARM.eidx table. The ARM.eidx section
>>>> is marked as read-only in the linked ELF file.
>>>
>>> This works for me.
>>> What application is breaking without it?
>>
>> Not a specific application. The problem I was trying to solve
>> was for code compiled PIC. And specifically the case where the
>> text and data sections where loading at non-contiguous RAM
>> addresses. 
>>
>> In the end problem is not so much this (this change only ended
>> up added a ":text" to to the flatmem redirection of the segment
>> contents). The problem actually seems to be related to code
>> generation for symbols with hidden visibility - for the PIC
>> case they where being loaded via PC relative instructions and
>> not using register indirect via the designated base register.
>>
>> Anyway, for now I don't think this patch is necessary, so you
>> can ignore it.
> 
> Okay. Do you think disabling DOPIC in uClibc-ng is related to the
> problem? Did you have DOPIC on or off for ypur ARM noMMU tests?
> 
> I have to disable it.

Yes, I have to disable it too. Having DOPIC on will compile the
lib code with -fPIC - and that is where I see some problems.
Not sure of the root of those problems yet, but you get access
being attempted outside of the text and data when they are loaded
in separate memory regions.

Regards
Greg


___
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

Re: [uClinux-dev] [PATCH v2] allow to build arm flat binaries

[Greg Ungerer]

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 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 binaries. Tested with busybox on Kinetis K70.
>>>>>>
>>>>>> Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
>>>>>
>>>>> Thanks. Applied to the github elf2flt repository (with Thomas'
>>>>> Tested-by).
>>>>
>>>> The adding of the ARM.eidx section in this patch breaks binaries
>>>> that have a global offset table (GOT). I propose the attached fix
>>>> that puts it within the data section proper - and not effectively
>>>> at the start of the data section.
>>>>
>>>> The original patch would have no impact on fully relocated
>>>> binaries, generally only those compiled with -fpic or similar.
>>>
>>> I tested your patch with Buildroot on a STM32F29 device, but it
>>> fails on boot while executing one of the startup scripts:
>>>
>>> [0.65] STM32 USART driver initialized
>>> [0.65] 40011000.serial: ttyS0 at MMIO 0x40011000 (irq = 17, 
>>> base_baud = 5625000) is a stm32-usart
>>> [0.89] console [ttyS0] enabled
>>> [0.91] Freeing unused kernel memory: 12K (9000a000 - 9000d000) In
>>> [1.26]
>>> [1.26] Unhandled exception: IPSR = 0003 LR = fff1
>>> [1.26] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
>>> [1.26] Hardware name: STM32 (Device Tree Support)
>>> [1.26] task: 9055 ti: 9055a000 task.ti: 9055a000
>>> [1.26] PC is at 0x2100
>>> [1.26] LR is at 0xfffd
>>> [1.26] pc : [<2100>]lr : []psr: 4035
>>> [1.26] sp : 9055bff8  ip : 9055bfe0  fp : 90555008
>>> [1.26] r10:   r9 : 0003  r8 : 0024
>>> [1.26] r7 : 0072  r6 : 906ccad8  r5 :   r4 : 0072
>>> [1.26] r3 :   r2 : 0003  r1 : 906ccafc  r0 : 
>>> [1.26] xPSR: 4035
>>> [1.26] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
>>> [1.26] Hardware name: STM32 (Device Tree Support)
>>> [1.26] [<0800bd41>] (unwind_backtrace) from [<0800b0df>] 
>>> (show_stack+0xb/0xc)
>>> [1.26] [<0800b0df>] (show_stack) from [<0800b68f>] 
>>> (__invalid_entry+0x4b/0x4c)
>>>
>>> Without the patch the system boots up fine.
>>
>> Ok, thanks for the feedback.
>>
>> Can you try this patch instead then?
>> It keeps the ARM.edix table at the same relative position, but moves
>> the _etext symbol to be after the ARM.eidx table. The ARM.eidx section
>> is marked as read-only in the linked ELF file.
> 
> This works for me.
> What application is breaking without it?

Not a specific application. The problem I was trying to solve
was for code compiled PIC. And specifically the case where the
text and data sections where loading at non-contiguous RAM
addresses. 

In the end problem is not so much this (this change only ended
up added a ":text" to to the flatmem redirection of the segment
contents). The problem actually seems to be related to code
generation for symbols with hidden visibility - for the PIC
case they where being loaded via PC relative instructions and
not using register indirect via the designated base register.

Anyway, for now I don't think this patch is necessary, so you
can ignore it.

Regards
Greg


___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

On 25/08/16 07:30, Waldemar Brodkorb wrote:
> 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 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, here is the output with patched
>>>> kernel:
>>>> ~ # /hello
>>>> [  162.46] BINFMT_FLAT: Loading file: /hello
>>>> [  162.46] Mapping is 9052, Entry point is 45, data_start is 8984
>>>> [  162.46] Load /hello: TEXT=90520040-90528984 DATA=905289a0-9052e1b0 
>>>> BSS=9052e1b0-9053240c
>>>> [  162.46] BINFMT_FLAT: reference 0x87 to shared library 237, 
>>>> killing hello!
>>>> SEGV
>>>>
>>>> /hello
>>>> [   11.23] BINFMT_FLAT: reference 0x87 to shared library 237, 
>>>> killing hello!
>>>> SEGV
>>>>
>>>> Hmm, on the stm32 with latest buildroot, I now get this errors.
>>>>
>>>> But I just use UCLIBC_FORMAT_FLAT. The kernel defconfig used has
>>>> CONFIG_BINFMT_SHARED_FLAT enabled.
>>>
>>> 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
>>> ./output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc
>>> -Wl,-elf2flt=-v -o hello hello.c -lpthread :
>>> ..
>>> reloc[403] = 0xe140
>>>  RELOC[404]: offset=0x5724 symbol=frame_dummy+0x0 section=.text
>>> size=0 fixup=0xac (reloc=0xe144)
>>> reloc[404] = 0xe144
>>>  RELOC[405]: offset=0x5728 symbol=pthread_initialize+0x0
>>> section=.text size=0 fixup=0x87ec (reloc=0xe148)
>>> reloc[405] = 0xe148
>>>  RELOC[406]: offset=0x572c symbol=__do_global_dtors_aux+0x0
>>> section=.text size=0 fixup=0x80 (reloc=0xe14c)
>>> reloc[406] = 0xe14c
>>> ..
>>>
>>> So pthread_initialize() is the problem?
>>
>> I have an idea what is broken here now.
>>
>> I am able to run this same test on qemu/versatile and get the
>> same result as you above with "hello" pthread test.
>>
>> I think elf2flt is not properly handling R_ARM_TARGET1 relocation
>> types. And this causes a bad relocation calculation at runtime.
>>
>> Can you try the attached patch?
>>
>> This fixes it for me, and I can run "hello" and get expected result.
> 
> Thanks. This works for me, too.
> 
> Great that we have a solution for it!
> Please push it :=)

Pushed up to the git tree on github.
(https://github.com/uclinux-dev/elf2flt)

Regards
Greg



___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

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 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 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 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.
>>>>>
>>>>> Thanks for the patch, will try it.
>>>>>
>>>>>>> I am not sure any Qemu Cortex-M3/4 system emulation is
>>>>>>> available.
>>>>>>
>>>>>> Do you know of any qemu target machines that work out-of-the-box
>>>>>> with a stock linux kernel with MMU disabled?
>>>>>
>>>>> No.
>>>>>
>>>>>> I used to use the gdb/ARMulator many years ago, but the kernel
>>>>>> target machine (Atmel/at91eb01) is long gone in modern kernel
>>>>>> version.
>>>>>
>>>>> I tried three different qemu forks, but they all only provide
>>>>> system level emulation for bare-metal apps. Skyeye crashes for me
>>>>> and recent GDB doesn't contain the old Armulator stuff.
>>>>>
>>>>> I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
>>>>> without MMU, but get no output.
>>>>
>>>> Looking into the other ARM flat problem, I figured we need to get
>>>> this problem solved as well.
>>>>
>>>> Turns out it is not too hard to get a Versatile target built
>>>> and running on qemu in no-MMU mode. The only real change required
>>>> is the attached patch - which fixes the IO device addressing problem.
>>>>
>>>> With this patch and starting with the versatile_defconfig you
>>>> only need a couple of config changes and it will run on the
>>>> versatile target in qemu. You need to disable CONFIG_MMU
>>>> and set the DRAM sizing (base at 0, size 128MB).
>>>>
>>>> This patch is against a linux-4.4 kernel, and it looks like the
>>>> versatile target has gone device tree from 4.5 and newer - so
>>>> this patch won't apply or work on them as is.
>>>
>>> Can you show us the commandline you use? What -cpu do you use?
>>
>> To run qemu I use:
>>
>>   qemu-system-arm -M versatilepb -nographic -kernel images/zImage -append 
>> "console=ttyAMA0,115200"
>>
>> The running system reports:
>>
>>   CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00091176
>>   CPU: VIVT data cache, VIVT instruction cache
>>   Machine: ARM-Versatile PB
>>
>> So its an ARM926 - but I didn't specify any CPU to qemu, I just
>> let it default to whatever is the versatilepb qemu default.
>>
>> Attached is the linux kernel config I used to generate kernel.
>>
>> Note that I have had to make a couple of changes to elf2flt to get
>> apps working. I'll send some emails about those soon. But that 
>> doesn't affect getting the kernel running on qemu.
> 
> I can't get it working.
> Can you explain what toolchain do you use?

My own manually compiled toolchain.


> gcc version? binutils version? soft-float toolchain?

  gcc-5.4.0
  binutils-2.26

Toolchain targeted at arm-uclinuxeabi using hard-float
(as in --with-float=hard gcc configuration)


> Are you using arm or thumb instructions?

ARM only.


> Can you show me gcc -v of your cross-compiler?

Using built-in specs.
COLLECT_GCC=arm-uclinuxeabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arm-uclinuxeabi/5.4.0/lto-wrapper
Target: arm-uclinuxeabi
Configured with: ../configure --target=arm-uclinuxeabi --with-float=hard 
--enable-multilib --with-system-zlib --disable-libsanitizer 
--enable-languages=c,c++ --prefix=/usr/local
Thread model: single
gcc version 5.4.0 (GCC) 

Kernel is a pristine linux-4.4 with only the hardware IO patch
listed earlier in the thread applied.

In the end I didn't need to modify elf2flt to get a working system
using an arm-uclinuxeabi toolchain.

Regards
Greg



___
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

Re: [uClinux-dev] [PATCH v2] allow to build arm flat binaries

[Greg Ungerer]

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,
>>>
>>> On 14/03/16 15:01, Waldemar Brodkorb wrote:
>>>> 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>
>>>
>>> Thanks. Applied to the github elf2flt repository (with Thomas'
>>> Tested-by).
>>
>> The adding of the ARM.eidx section in this patch breaks binaries
>> that have a global offset table (GOT). I propose the attached fix
>> that puts it within the data section proper - and not effectively
>> at the start of the data section.
>>
>> The original patch would have no impact on fully relocated
>> binaries, generally only those compiled with -fpic or similar.
> 
> I tested your patch with Buildroot on a STM32F29 device, but it
> fails on boot while executing one of the startup scripts:
> 
> [0.65] STM32 USART driver initialized
> [0.65] 40011000.serial: ttyS0 at MMIO 0x40011000 (irq = 17, base_baud 
> = 5625000) is a stm32-usart
> [0.89] console [ttyS0] enabled
> [0.91] Freeing unused kernel memory: 12K (9000a000 - 9000d000) In
> [1.26]
> [1.26] Unhandled exception: IPSR = 0003 LR = fff1
> [1.26] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
> [1.26] Hardware name: STM32 (Device Tree Support)
> [1.26] task: 9055 ti: 9055a000 task.ti: 9055a000
> [1.26] PC is at 0x2100
> [1.26] LR is at 0xfffd
> [1.26] pc : [<2100>]lr : []psr: 4035
> [1.26] sp : 9055bff8  ip : 9055bfe0  fp : 90555008
> [1.26] r10:   r9 : 0003  r8 : 0024
> [1.26] r7 : 0072  r6 : 906ccad8  r5 :   r4 : 0072
> [1.26] r3 :   r2 : 0003  r1 : 906ccafc  r0 : 
> [1.26] xPSR: 4035
> [1.26] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
> [1.26] Hardware name: STM32 (Device Tree Support)
> [1.26] [<0800bd41>] (unwind_backtrace) from [<0800b0df>] 
> (show_stack+0xb/0xc)
> [1.26] [<0800b0df>] (show_stack) from [<0800b68f>] 
> (__invalid_entry+0x4b/0x4c)
> 
> Without the patch the system boots up fine.

Ok, thanks for the feedback.

Can you try this patch instead then?
It keeps the ARM.edix table at the same relative position, but moves
the _etext symbol to be after the ARM.eidx table. The ARM.eidx section
is marked as read-only in the linked ELF file.

Regards
Greg


>From e50c50accd2505877df19569d3671d06b786aed2 Mon Sep 17 00:00:00 2001
From: Greg Ungerer <g...@linux-m68k.org>
Date: Thu, 18 Aug 2016 16:39:56 +1000
Subject: [PATCH] elf2flt: move ARM.eidx sections to end of data

Currently .ARM.eidx section is put in between the text and data sections
of the output binary. But a flat binary really only understands text and
data sections, and they are written contiguously to the bariny file.
The flat header data start is expected to be the end of the text section.

The problem is that the start of the data section may contain a GOT.
binfmt_flat header flags the presence of a GOT, and binfmt_flat will
simply try to carry out relocations on the start of the data section
assuming it is a GOT. But it won't be now if the ARM.eidx section is there.

The ARM.eidx section is marked as a read-only ELF section, so lets move it
into the text section proper. This moves the _etext symbol to be after the
ARM.edix section - and keeps the GOT at the start of the data section

Signed-off-by: Greg Ungerer <g...@uclinux.org>
---
 elf2flt.ld.in | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/elf2flt.ld.in b/elf2flt.ld.in
index ec1fe6f..2520ed1 100644
--- a/elf2flt.ld.in
+++ b/elf2flt.ld.in
@@ -45,16 +45,18 @@ W_RODAT		*(.gnu.linkonce.r*)
 		PROVIDE(@SYMBOL_PREFIX@__ctbp = .);
 		*(.call_table_data)
 		*(.call_table_text)
+
+		. = ALIGN(0x20) ;
 	} > flatmem :text
 
 	/* .ARM.exidx name sections containing index entries for section unwinding */
 	/* .ARM.exidx is sorted, so has to go in its own output section.  */
-	@SYMBOL_PREFIX@__exidx_start = .;
+	__exidx_start = .;
 	.ARM.exidx :
 	{
 		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
-	} > flatmem
-	@SYMBOL_PREFIX@__exidx_end = .;
+	} > flatmem :text
+	__exidx_end = .;
 
 	. = ALIGN(0x20) ;
 	@SYMBOL_PREFIX@_etext = . ;
-- 
1.9.1

___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

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 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, here is the output with patched
kernel:
~ # /hello
[  162.46] BINFMT_FLAT: Loading file: /hello
[  162.46] Mapping is 9052, Entry point is 45, data_start is 8984
[  162.46] Load /hello: TEXT=90520040-90528984 DATA=905289a0-9052e1b0 
BSS=9052e1b0-9053240c
[  162.46] BINFMT_FLAT: reference 0x87 to shared library 237, killing 
hello!
SEGV

 /hello
[   11.23] BINFMT_FLAT: reference 0x87 to shared library 237, killing 
hello!
SEGV

Hmm, on the stm32 with latest buildroot, I now get this errors.

But I just use UCLIBC_FORMAT_FLAT. The kernel defconfig used has
CONFIG_BINFMT_SHARED_FLAT enabled.


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
./output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc
-Wl,-elf2flt=-v -o hello hello.c -lpthread :
..
reloc[403] = 0xe140
  RELOC[404]: offset=0x5724 symbol=frame_dummy+0x0 section=.text
size=0 fixup=0xac (reloc=0xe144)
reloc[404] = 0xe144
  RELOC[405]: offset=0x5728 symbol=pthread_initialize+0x0
section=.text size=0 fixup=0x87ec (reloc=0xe148)
reloc[405] = 0xe148
  RELOC[406]: offset=0x572c symbol=__do_global_dtors_aux+0x0
section=.text size=0 fixup=0x80 (reloc=0xe14c)
reloc[406] = 0xe14c
..

So pthread_initialize() is the problem?


I have an idea what is broken here now.

I am able to run this same test on qemu/versatile and get the
same result as you above with "hello" pthread test.

I think elf2flt is not properly handling R_ARM_TARGET1 relocation
types. And this causes a bad relocation calculation at runtime.

Can you try the attached patch?

This fixes it for me, and I can run "hello" and get expected result.

Regards
Greg


>From dedce8765d203c1c162a57e6259375e0b457173f Mon Sep 17 00:00:00 2001
From: Greg Ungerer <g...@linux-m68k.org>
Date: Fri, 19 Aug 2016 23:49:51 +1000
Subject: [PATCH] elf2flt: fix relocation support for R_ARM_TARGET types

R_ARM_TARGET1 (and I think R_ARM_TARGET2) relocation types should be
treated in the same way as R_ARM_ABS32. Fix them to write out the addend
to the flat binary in network byte order.

Signed-off-by: Greg Ungerer <g...@uclinux.org>
---
 elf2flt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/elf2flt.c b/elf2flt.c
index 5ae7dd9..3f31569 100644
--- a/elf2flt.c
+++ b/elf2flt.c
@@ -1505,7 +1505,9 @@ DIS29_RELOCATION:
 	(((*p)->howto->type != R_ARM_PC24) &&
 	((*p)->howto->type != R_ARM_PLT32)))
 	tmp.c[i3] = (hl >> 24) & 0xff;
-if ((*p)->howto->type == R_ARM_ABS32)
+if (((*p)->howto->type == R_ARM_ABS32) ||
+((*p)->howto->type == R_ARM_TARGET1) ||
+((*p)->howto->type == R_ARM_TARGET2))
 	*(uint32_t *)r_mem = htonl(hl);
 else
 	*(uint32_t *)r_mem = tmp.l;
-- 
1.9.1

___
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

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

Hi Waldemar,

On 19/08/16 08:53, Waldemar Brodkorb wrote:
> 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 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 this Bug!
>>> It works for 4.6.5 for me.
>>
>> That fix is in Linus' tree now, as of 4.8-rc2.
>> So it will be in linux-4.8 when released.
>>
>>
>>> In Buildroot are some build failures like:
>>> http://autobuild.buildroot.net/results/1ec/1ec691746b5196e9fd6779c22ef2ca4600349fb4/
>>>
>>> Which seems to be a limitation of mcf520x. When I disable msep-data
>>> pcre can be compiled.
>>
>> Not sure, perhaps it is exceeding the maximum entries of the GOT.
>>
>>
>>> Is it possible to have a mixup of sep-data and one memory region
>>> binaries on the same system?
>>
>> Oh yeah, that is no problem. The binfmt_flat loader does
>> the right things no matter which type was used to compile
>> the application.
> 
> I discussed our Buildroot issues with Thomas.
> Is there any benefit using -msep-data if Application XIP isn't used?
> 
> The toolchain used for Buildroot autobuilder defaults to -msep-data
> and breaks compilation of software packages as pcre, fftw, ffmpeg
> and more. We can just remove -msep-data for these packages, but this
> makes no sense, if the application can not be used in a XIP only
> firmware. 
> So is there any benefit in having -msep-data when non-XIP is used?

No, not really. The code (text) section of an -msep-data binary
will be slightly larger (few %) due to it being PIC. Oddly enough
though non -msep-data binaries are usually slightly larger due to
the much larger number of relocations needed to be stored.

As you have found the limitations on code size and relocations
hit you with -msep-data - and you will not have those will fully
absolute binaries.

Dropping -msep-data is probably the best choice here. Keeping in
mind that it is currently broken without the m68k/signal.c kernel
patch.

Regards
Greg



___
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

Re: [uClinux-dev] [PATCH v2] allow to build arm flat binaries

[Greg Ungerer]

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 binaries. Tested with busybox on Kinetis K70.
>>
>> Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
> 
> Thanks. Applied to the github elf2flt repository (with Thomas'
> Tested-by).

The adding of the ARM.eidx section in this patch breaks binaries
that have a global offset table (GOT). I propose the attached fix
that puts it within the data section proper - and not effectively
at the start of the data section.

The original patch would have no impact on fully relocated
binaries, generally only those compiled with -fpic or similar.

Regards
Greg


>> v1 -> v2:
>>   - segfault problem fixed, r_mem pointer should be initialized
>>   - v1 was successfully tested by Thomas Petazzoni with buildroot
>> generated image for STM32F429
>>
>> ---
>>   elf2flt.c |   11 ++-
>>   elf2flt.ld.in |   17 ++---
>>   2 files changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/elf2flt.c b/elf2flt.c
>> index fcd797c..7d0e639 100644
>> --- a/elf2flt.c
>> +++ b/elf2flt.c
>> @@ -56,6 +56,8 @@ const char *elf2flt_progname;
>>
>>   #if defined(TARGET_h8300)
>>   #include   /* TARGET_* ELF support for the BFD library   
>>  */
>> +#elif defined(TARGET_arm)
>> +#include 
>>   #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(TARGET_nios) 
>> || defined(TARGET_nios2)
>>   #include "cygwin-elf.h"/* Cygwin uses a local copy */
>>   #elif defined(TARGET_xtensa)
>> @@ -451,7 +453,7 @@ dump_symbols(symbols, number_of_symbols);
>>   qsort (relpp, relcount, sizeof *relpp, compare_relocs);
>>   #endif
>>   for (p = relpp; (relcount && (*p != NULL)); p++, relcount--) {
>> -unsigned char *r_mem;
>> +unsigned char *r_mem = NULL;
>>   int relocation_needed = 0;
>>
>>   #ifdef TARGET_microblaze
>> @@ -646,16 +648,23 @@ dump_symbols(symbols, number_of_symbols);
>>   default:
>>   goto good_32bit_resolved_reloc;
>>   #elif defined(TARGET_arm)
>> +case R_ARM_TARGET1:
>> +case R_ARM_TARGET2:
>>   case R_ARM_ABS32:
>>   relocation_needed = 1;
>>   break;
>>   case R_ARM_REL32:
>> +case R_ARM_JUMP24:
>> +case R_ARM_CALL:
>>   case R_ARM_THM_PC11:
>>   case R_ARM_THM_PC22:
>> +case R_ARM_THM_JUMP24:
>>   case R_ARM_PC24:
>>   case R_ARM_PLT32:
>>   case R_ARM_GOTPC:
>>   case R_ARM_GOT32:
>> +case R_ARM_PREL31:
>> +case R_ARM_NONE:
>>   relocation_needed = 0;
>>   break;
>>   default:
>> diff --git a/elf2flt.ld.in b/elf2flt.ld.in
>> index bfda0ef..ec1fe6f 100644
>> --- a/elf2flt.ld.in
>> +++ b/elf2flt.ld.in
>> @@ -35,6 +35,8 @@ W_RODAT*(.rodata1)
>>   W_RODAT*(.rodata.*)
>>   W_RODAT*(.gnu.linkonce.r*)
>>
>> +/* .ARM.extab name sections containing exception unwinding 
>> information */
>> +*(.ARM.extab* .gnu.linkonce.armextab.*)
>>   /* This is special code area at the end of the normal
>>  text section.  It contains a small lookup table at
>>  the start followed by the code pointed to by entries
>> @@ -43,11 +45,20 @@ W_RODAT*(.gnu.linkonce.r*)
>>   PROVIDE(@SYMBOL_PREFIX@__ctbp = .);
>>   *(.call_table_data)
>>   *(.call_table_text)
>> -
>> -. = ALIGN(0x20) ;
>> -@SYMBOL_PREFIX@_etext = . ;
>>   } > flatmem :text
>>
>> +/* .ARM.exidx name sections containing index entries for section 
>> unwinding */
>> +/* .ARM.exidx is sorted, so has to go in its own output section.  */
>> +@SYMBOL_PREFIX@__exidx_start = .;
>> +.ARM.exidx :
>> +{
>> +*(.ARM.exidx* .gnu.linkonce.armexidx.*)
>> +} > flatmem
>> +@SYMBOL_PREFIX@__exidx_end = .;
>> +
>> +. = ALIGN(0x20) ;
>> +@SYMBOL_PREFIX@_etext = . ;
>> +
>>   .data : {
>>   . = ALIGN(0x4) ;
>>   @SYMBOL_PREFI

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

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,
>> >
>> >>>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 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.
>> >
>> >Thanks for the patch, will try it.
>> >
>> >>>I am not sure any Qemu Cortex-M3/4 system emulation is
>> >>>available.
>> >>
>> >>Do you know of any qemu target machines that work out-of-the-box
>> >>with a stock linux kernel with MMU disabled?
>> >
>> >No.
>> >
>> >>I used to use the gdb/ARMulator many years ago, but the kernel
>> >>target machine (Atmel/at91eb01) is long gone in modern kernel
>> >>version.
>> >
>> >I tried three different qemu forks, but they all only provide
>> >system level emulation for bare-metal apps. Skyeye crashes for me
>> >and recent GDB doesn't contain the old Armulator stuff.
>> >
>> >I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
>> >without MMU, but get no output.
>> 
>> Looking into the other ARM flat problem, I figured we need to get
>> this problem solved as well.
>> 
>> Turns out it is not too hard to get a Versatile target built
>> and running on qemu in no-MMU mode. The only real change required
>> is the attached patch - which fixes the IO device addressing problem.
>> 
>> With this patch and starting with the versatile_defconfig you
>> only need a couple of config changes and it will run on the
>> versatile target in qemu. You need to disable CONFIG_MMU
>> and set the DRAM sizing (base at 0, size 128MB).
>> 
>> This patch is against a linux-4.4 kernel, and it looks like the
>> versatile target has gone device tree from 4.5 and newer - so
>> this patch won't apply or work on them as is.
> 
> Can you show us the commandline you use? What -cpu do you use?

To run qemu I use:

  qemu-system-arm -M versatilepb -nographic -kernel images/zImage -append 
"console=ttyAMA0,115200"

The running system reports:

  CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00091176
  CPU: VIVT data cache, VIVT instruction cache
  Machine: ARM-Versatile PB

So its an ARM926 - but I didn't specify any CPU to qemu, I just
let it default to whatever is the versatilepb qemu default.

Attached is the linux kernel config I used to generate kernel.

Note that I have had to make a couple of changes to elf2flt to get
apps working. I'll send some emails about those soon. But that 
doesn't affect getting the kernel running on qemu.

Regards
Greg


#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.4.0-uc0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_PHYS_OFFSET=0x
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_GENERIC_CLOCKEVENTS=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

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 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 this Bug!
It works for 4.6.5 for me.


That fix is in Linus' tree now, as of 4.8-rc2.
So it will be in linux-4.8 when released.



In Buildroot are some build failures like:
http://autobuild.buildroot.net/results/1ec/1ec691746b5196e9fd6779c22ef2ca4600349fb4/

Which seems to be a limitation of mcf520x. When I disable msep-data
pcre can be compiled.


Not sure, perhaps it is exceeding the maximum entries of the GOT.



Is it possible to have a mixup of sep-data and one memory region
binaries on the same system?


Oh yeah, that is no problem. The binfmt_flat loader does
the right things no matter which type was used to compile
the application.

Regards
Greg



___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

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 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 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.


Thanks for the patch, will try it.


I am not sure any Qemu Cortex-M3/4 system emulation is
available.


Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?


No.


I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.


I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.

I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.


Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.

Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.

With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).

This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.

Regards
Greg


>From b7c1666813424d329868335c8faf8886b0f85b6c Mon Sep 17 00:00:00 2001
From: Greg Ungerer <g...@linux-m68k.org>
Date: Thu, 11 Aug 2016 21:33:11 +1000
Subject: [PATCH] arm: fix versatile platform to work in no-MMU mode

If CONFIG_MMU is disabled then do not carry out the virtual memory address
translation for IO devices.

With this fix in place we can run the ARM Versatile board (including its
qemu emulation) as a no-MMU Linux system.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/arm/mach-versatile/include/mach/hardware.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-versatile/include/mach/hardware.h b/arch/arm/mach-versatile/include/mach/hardware.h
index 3e5d425..36c6cd2 100644
--- a/arch/arm/mach-versatile/include/mach/hardware.h
+++ b/arch/arm/mach-versatile/include/mach/hardware.h
@@ -30,8 +30,12 @@
 #define VERSATILE_PCI_VIRT_BASE		(void __iomem *)0xe800ul
 #define VERSATILE_PCI_CFG_VIRT_BASE	(void __iomem *)0xe900ul
 
+#ifdef CONFIG_MMU
 /* macro to get at MMIO space when running virtually */
 #define IO_ADDRESS(x)		(((x) & 0x0fff) + (((x) >> 4) & 0x0f00) + 0xf000)
+#else
+#define IO_ADDRESS(x)		(x)
+#endif
 
 #define __io_address(n)		((void __iomem __force *)IO_ADDRESS(n))
 
-- 
1.9.1

___
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

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

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.

Regards
Greg



On 08/06/16 21:38, 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
> 
> 
>> Waldemar Brodkorb wbx at openadk.org
>> Fri May 27 15:35:58 EDT 2016
>>
>> Previous message: [uClinux-dev] qemu coldfire SIGILL with pthread app
>> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>
>> 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:
>>> >>>>> 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.
>>> >>>>> Tested with buildroot and qemu_m68k_mcf5208_defconfig. It uses gcc
>>> >>>>> 4.9.3 and binutils 2.25.1. The kernel is 4.5.3 including the signal
>>> >>>>> handler patch. uClibc-ng 1.0.14 is used.
>>> >>>>>
>>> >>>>> Any idea?
>>> >>>>
>>> >>>> Do you get the SIGILL when running without strace?
>>> >>>
>>> >>> Yes.
>>> >>>
>>> >>>> How often does it work, and not work?
>>> >>>
>>> >>> ~ # ill=0; for i in $(seq 1 50); do /test; if [ $? -ne 0 ]; then 
>>> >>> ill=$(($ill+1)) ;fi; sleep 2; done
>>> >>> ~ # echo $ill
>>> >>> 30
>>> >>>
>>> >>> It is not always the same.
>>> >>
>>> >> Ok. I expect I would see it pretty easily though if I
>>> >> run hello 100 times for example.
>>> >>
>>> >>
>>> >>>> I have a setup with a gcc-5.3/binutils-2.25.1 toolchain building
>>> >>>> linux-4.6 and using uClibc-ng-1.0.14 and using your hello.c test
>>> >>>> app and I don't see any SIGILLs. Ran it quite a few times but
>>> >>>> didn't see any.
>>> >>>
>>> >>> Hmm. I now changed to gcc 5.3.0 and see the same problem.
>>> >>> Need to try linux-4.6. What version of Qemu are you using?
>>> >>> I recently updated to 2.6.0.
>>> >>
>>> >> I was using an older 2.3.50. But I just pulled down 2.6 and
>>> >> tried again. I still don't see any SIGILLs.
>>> >>
>>> >> Looking at your strace dump and mine it puzzles me that the initial
>>> >> startup is a little different. On my dump the first output
>>> >> write() is the 3rd system call. On your traces it is much later.
>>> >>
>>> >> Can you send me your hello (and hello.gdb) binaries?
>>> >
>>> > They are here:
>>> > http://debug.openadk.org/coldfire/
>>>
>>> Thanks. I can reproduce it with that binary easily.
>>>
>>>
>>> > Are you using linuxthreads.old or linuxthreads.new?
>>> > I use old, and new will be removed in the next uClibc-ng release.
>>>
>>> I am using the old linux threads. I have attached my uClibc-ng
>>> config so you can see what I am using.
>>>
>>> I can see that your hello binary is a good bit smaller than mine.
>>> The code generated looks quite different too. Do you compile apps
>>> and libs with -msep-data?
>>
>> That is the exact reason. I used FLAT without -msep-data.
>> When I use -msep-data I get no SIGILL.
>>
>> Any idea why simple FLAT breaks the binaries?
> 
> No, not sure why. I would have thought it should work.
> 
> Regards
> Greg
> 

___
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

Re: [uClinux-dev] (no subject)

[Greg Ungerer]

Hi Joshua,

On 30/06/16 21:52, Joshua Stokes wrote:
> My question is about compiling uclinux-rootfs, specifically the 1st step in 
> the README file which reads:
> 
> You will need a cross-compiler package for your target. Many binary
>  tools packages exists specifically for compiling uClinux. Install
>  that in the standard way first. For example, if you are targeting m68k
>  or ColdFire systems then you can use the m68k-elf-tools binary
>  packages of www.uclinux.org.

Specifically on the question of cross compilers, there is some
binary toolchains on the uclinux sourceforge site:

https://sourceforge.net/projects/uclinux/files/Tools/

Regards
Greg


> I am basically trying to compile a uclinux distribution that is installed on 
> STBs, specifically the Fetch TV uclinux. The firmware version is 2.01278 and 
> the required files are located at http://www.fetchtv.com.au/opensource
> 
> Can someone please shed some light on this situation
> 
> Thanks
> 
>>From Joshua P Stokes
> ___
> 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
> 

___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

Hi Waldemar,

On 09/06/16 06:49, Waldemar Brodkorb wrote:

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?


Sorry, no, not yet.

Regards
Greg
___
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

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

Hi Waldemar,

On 09/06/16 06:48, Waldemar Brodkorb wrote:
> 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 is bad :(
>  
>>> Any idea why simple FLAT breaks the binaries?
>>
>> No, not sure why. I would have thought it should work.
> 
> Can you reproduce it?

Yes. In fact I see problems problems with running any
apps when compiled without -msep-data. Though I get to a
shell on boot, it dies within a few seconds.


> How should we handle this? Exclude simple FLAT in buildroot
> for coldfire and default to sep-data?

I think yes. I always build and test with -msep-data.

Regards
Greg


___
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

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

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



Waldemar Brodkorb wbx at openadk.org
Fri May 27 15:35:58 EDT 2016

Previous message: [uClinux-dev] qemu coldfire SIGILL with pthread app
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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:
>>>>> 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.
>>>>> Tested with buildroot and qemu_m68k_mcf5208_defconfig. It uses gcc
>>>>> 4.9.3 and binutils 2.25.1. The kernel is 4.5.3 including the signal
>>>>> handler patch. uClibc-ng 1.0.14 is used.
>>>>>
>>>>> Any idea?
>>>>
>>>> Do you get the SIGILL when running without strace?
>>>
>>> Yes.
>>>
>>>> How often does it work, and not work?
>>>
>>> ~ # ill=0; for i in $(seq 1 50); do /test; if [ $? -ne 0 ]; then 
ill=$(($ill+1)) ;fi; sleep 2; done
>>> ~ # echo $ill
>>> 30
>>>
>>> It is not always the same.
>>
>> Ok. I expect I would see it pretty easily though if I
>> run hello 100 times for example.
>>
>>
>>>> I have a setup with a gcc-5.3/binutils-2.25.1 toolchain building
>>>> linux-4.6 and using uClibc-ng-1.0.14 and using your hello.c test
>>>> app and I don't see any SIGILLs. Ran it quite a few times but
>>>> didn't see any.
>>>
>>> Hmm. I now changed to gcc 5.3.0 and see the same problem.
>>> Need to try linux-4.6. What version of Qemu are you using?
>>> I recently updated to 2.6.0.
>>
>> I was using an older 2.3.50. But I just pulled down 2.6 and
>> tried again. I still don't see any SIGILLs.
>>
>> Looking at your strace dump and mine it puzzles me that the initial
>> startup is a little different. On my dump the first output
>> write() is the 3rd system call. On your traces it is much later.
>>
>> Can you send me your hello (and hello.gdb) binaries?
>
> They are here:
> http://debug.openadk.org/coldfire/

Thanks. I can reproduce it with that binary easily.


> Are you using linuxthreads.old or linuxthreads.new?
> I use old, and new will be removed in the next uClibc-ng release.

I am using the old linux threads. I have attached my uClibc-ng
config so you can see what I am using.

I can see that your hello binary is a good bit smaller than mine.
The code generated looks quite different too. Do you compile apps
and libs with -msep-data?


That is the exact reason. I used FLAT without -msep-data.
When I use -msep-data I get no SIGILL.

Any idea why simple FLAT breaks the binaries?


No, not sure why. I would have thought it should work.

Regards
Greg

___
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

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

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:
>>>>> 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.
>>>>> Tested with buildroot and qemu_m68k_mcf5208_defconfig. It uses gcc
>>>>> 4.9.3 and binutils 2.25.1. The kernel is 4.5.3 including the signal
>>>>> handler patch. uClibc-ng 1.0.14 is used.
>>>>>
>>>>> Any idea?
>>>>
>>>> Do you get the SIGILL when running without strace?
>>>
>>> Yes.
>>>
>>>> How often does it work, and not work?
>>>
>>> ~ # ill=0; for i in $(seq 1 50); do /test; if [ $? -ne 0 ]; then 
>>> ill=$(($ill+1)) ;fi; sleep 2; done
>>> ~ # echo $ill
>>> 30
>>>
>>> It is not always the same.
>>
>> Ok. I expect I would see it pretty easily though if I
>> run hello 100 times for example.
>>
>>
>>>> I have a setup with a gcc-5.3/binutils-2.25.1 toolchain building
>>>> linux-4.6 and using uClibc-ng-1.0.14 and using your hello.c test
>>>> app and I don't see any SIGILLs. Ran it quite a few times but
>>>> didn't see any.
>>>
>>> Hmm. I now changed to gcc 5.3.0 and see the same problem.
>>> Need to try linux-4.6. What version of Qemu are you using?
>>> I recently updated to 2.6.0.
>>
>> I was using an older 2.3.50. But I just pulled down 2.6 and
>> tried again. I still don't see any SIGILLs.
>>
>> Looking at your strace dump and mine it puzzles me that the initial
>> startup is a little different. On my dump the first output
>> write() is the 3rd system call. On your traces it is much later.
>>
>> Can you send me your hello (and hello.gdb) binaries?
> 
> They are here:
> http://debug.openadk.org/coldfire/

Thanks. I can reproduce it with that binary easily.


> Are you using linuxthreads.old or linuxthreads.new?
> I use old, and new will be removed in the next uClibc-ng release.

I am using the old linux threads. I have attached my uClibc-ng
config so you can see what I am using.

I can see that your hello binary is a good bit smaller than mine.
The code generated looks quite different too. Do you compile apps
and libs with -msep-data?

Regards
Greg


#
# Automatically generated file; DO NOT EDIT.
# uClibc-ng 1.0.14 C Library Configuration
#
# TARGET_alpha is not set
# TARGET_arc is not set
# TARGET_arm is not set
# TARGET_avr32 is not set
# TARGET_bfin is not set
# TARGET_c6x is not set
# TARGET_cris is not set
# TARGET_frv is not set
# TARGET_h8300 is not set
# TARGET_hppa is not set
# TARGET_i386 is not set
# TARGET_ia64 is not set
# TARGET_lm32 is not set
TARGET_m68k=y
# TARGET_metag is not set
# TARGET_microblaze is not set
# TARGET_mips is not set
# TARGET_nios2 is not set
# TARGET_or1k is not set
# TARGET_powerpc is not set
# TARGET_sh is not set
# TARGET_sparc is not set
# TARGET_x86_64 is not set
# TARGET_xtensa is not set

#
# Target Architecture Features and Options
#
TARGET_ARCH="m68k"
FORCE_OPTIONS_FOR_ARCH=y
TARGET_SUBARCH=""
# UCLIBC_FORMAT_FLAT is not set
UCLIBC_FORMAT_FLAT_SEP_DATA=y
# UCLIBC_FORMAT_SHARED_FLAT is not set
ARCH_HAS_DEPRECATED_SYSCALLS=y
ARCH_BIG_ENDIAN=y

#
# Using Big Endian
#
# ARCH_HAS_MMU is not set
UCLIBC_HAS_FLOATS=y
# UCLIBC_HAS_FPU is not set
UCLIBC_HAS_SOFT_FLOAT=y
DO_C99_MATH=y
# DO_XSI_MATH is not set
# UCLIBC_HAS_FENV is not set
UCLIBC_HAS_LONG_DOUBLE_MATH=y
KERNEL_HEADERS="$(STAGEDIR)/include"
UCLIBC_UCLINUX_BROKEN_MUNMAP=y
HAVE_DOT_CONFIG=y

#
# General Library Settings
#
# DOPIC is not set
ARCH_HAS_NO_SHARED=y
ARCH_HAS_NO_LDSO=y
UCLIBC_CTOR_DTOR=y
# HAS_NO_THREADS is not set
LINUXTHREADS_OLD=y
# LINUXTHREADS_NEW is not set
UCLIBC_HAS_THREADS=y
# PTHREADS_DEBUG_SUPPORT is not set
UCLIBC_HAS_SYSLOG=y
UCLIBC_HAS_LFS=y
# MALLOC is not set
MALLOC_SIMPLE=y
# MALLOC_GLIBC_COMPAT is not set
# UCLIBC_HAS_OBSTACK is not set
UCLIBC_DYNAMIC_ATEXIT=y
COMPAT_ATEXIT=y
UCLIBC_HAS_UTMPX=y
UCLIBC_HAS_UTMP=y
UCLIBC_SUSV2_LEGACY=y
UCLIBC_SUSV3_LEGACY=y
# UCLIBC_SUSV3_LEGACY_MACROS is not set
UCLIBC_SUSV4_LEGACY=y
# UCLIBC_STRICT_HEADERS is not set
# UCLIBC_HAS_STUBS is not set
UCLIBC_HAS_SHADOW=y
# UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set
UCLIBC_HAS___PROGNAME=y
UCLIBC_HAS_PTY=y
ASSUME_DEVPTS=y
UNIX98PTY_ONLY=y
UCLIBC_HAS_GETPT=y
UCLIBC_HAS_LIBUTIL=y
UCLIBC_HAS_TM_EXTENSIONS=y
UCLIBC_HAS_TZ_CACHING=y
UCLIBC_HAS_TZ_FILE=y
UCLIBC_HAS_TZ_FILE_READ_MANY=y
UCLIB

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

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 coldfire emulation:
>>> http://debug.openadk.org/arm-pthreads/hello.c
>>>
>>> Sometimes it works, sometimes I get SIGILL.
>>> Tested with buildroot and qemu_m68k_mcf5208_defconfig. It uses gcc
>>> 4.9.3 and binutils 2.25.1. The kernel is 4.5.3 including the signal
>>> handler patch. uClibc-ng 1.0.14 is used.
>>>
>>> Any idea?
>>
>> Do you get the SIGILL when running without strace?
> 
> Yes.
> 
>> How often does it work, and not work?
> 
> ~ # ill=0; for i in $(seq 1 50); do /test; if [ $? -ne 0 ]; then 
> ill=$(($ill+1)) ;fi; sleep 2; done
> ~ # echo $ill
> 30
> 
> It is not always the same.

Ok. I expect I would see it pretty easily though if I
run hello 100 times for example.


>> I have a setup with a gcc-5.3/binutils-2.25.1 toolchain building
>> linux-4.6 and using uClibc-ng-1.0.14 and using your hello.c test
>> app and I don't see any SIGILLs. Ran it quite a few times but
>> didn't see any.
> 
> Hmm. I now changed to gcc 5.3.0 and see the same problem.
> Need to try linux-4.6. What version of Qemu are you using?
> I recently updated to 2.6.0.

I was using an older 2.3.50. But I just pulled down 2.6 and
tried again. I still don't see any SIGILLs.

Looking at your strace dump and mine it puzzles me that the initial
startup is a little different. On my dump the first output
write() is the 3rd system call. On your traces it is much later.

Can you send me your hello (and hello.gdb) binaries?

Regards
Greg


___
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

Re: [uClinux-dev] qemu coldfire SIGILL with pthread app

[Greg Ungerer]

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 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
ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
getpid()= 115
rt_sigaction(SIGRTMIN, {0x46c6184e, [], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x46c617ba, [RTMIN], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x46c613be, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x46c76000
write(1, "x: 0, y: 0\n", 11x: 0, y: 0)= 11
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x46aec000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x46aee000
pipe([3, 4])= 0
clone(child_stack=0x46aedfe0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 116
write(4, "F\3069\340\0\0\0\5F\307\7\fF\307\t\\F\307^\230F\306L\224F\307^\210", 
28) = 28
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
write(4, "F\307\5 \0\0\0\0\0\0\0\0F\306\1\214F\307^\304\200\0\0\0\0\0\0\0", 28) 
= 28
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([], 8strace: Process 116 attached 
[pid   116] rt_sigprocmask(SIG_SETMASK, ~[TRAP RT_1], NULL, 8) = 0
[pid   116] read(3, 
"F\3069\340\0\0\0\5F\307\7\fF\307\t\\F\307^\230F\306L\224F\307^\210", 28) = 28
[pid   116] poll([{fd=3, events=POLLIN}], 1, 2000) = 1 ([{fd=3, 
revents=POLLIN}])
[pid   116] getppid()   = 115
[pid   116] read(3, "F\307\5 
\0\0\0\0\0\0\0\0F\306\1\214F\307^\304\200\0\0\0\0\0\0\0", 28) = 28
[pid   116] mmap2(NULL, 20480, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x47f6
[pid   116] clone(child_stack=0x47f63ea0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|SIGRT_1) = 117
[pid   116] kill(115, SIGRTMIN 
[pid   115] <... rt_sigsuspend resumed> ) = ? ERESTARTNOHAND (To be restarted 
if no handler)
[pid   115] --- SIGRTMIN {si_signo=SIGRTMIN, si_code=SI_USER, si_pid=116, 
si_uid=0} ---
[pid   115] sigreturn({mask=[RTMIN]})   = -1 EINTR (Interrupted system call)
[pid   115] write(1, "y increment finished\n", 21y increment finished) = 21
[pid   115] rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
[pid   115] rt_sigsuspend([], 8strace: Process 117 attached 
[pid   117] getpid()= 117
[pid   117] rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
[pid   117] write(1, "x increment finished\n", 21x increment finished) = 21
[pid   117] kill(115, SIGRTMIN 
[pid   115] <... rt_sigsuspend resumed> ) = ? ERESTARTNOHAND (To be restarted 
if no handler)
[pid   115] --- SIGRTMIN {si_signo=SIGRTMIN, si_code=SI_USER, si_pid=117, 
si_uid=0} ---
[pid   115] sigreturn({mask=[RTMIN]})   = -1 EINTR (Interrupted system call)
[pid   115] --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, 
si_addr=0x46c6b220} ---
[pid   115] +++ killed by SIGILL +++
[pid   117] +++ killed by SIGILL +++
+++ killed by SIGILL +++
ILL

And here when it works:
~ # strace -f /test
ioctl(0, TCGETS, {B115200 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
getpid()= 111
rt_sigaction(SIGRTMIN, {0x46c6184e, [], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x46c617ba, [RTMIN], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x46c613be, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x46c76000
write(1, "x: 0, y: 0\n", 11x: 0, y: 0)= 11
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x47f68000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_SHARED|MAP_ANONYMOUS|MAP_UNINITIALIZED, 0, 0) = 0x47f6a000
pipe([3, 4])= 0
clone(child_stack=0x47f69fe0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 112
write(4, "F\3069\340\0\0\0\5F\307\7\fF\307\t\\F\307^\230F\306L\224F\307^\210", 
28) = 28
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
write(4, "F\307\5 \0\0\0\0\0\0\0\0F\306\1\214F\307^\304\200\0\0\0\0\0\0\0", 28) 
= 28
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([], 8strace: Process 112 attached 
[pid   112] rt_sigprocmask(SIG_SETMASK, ~[TRAP RT_1], NULL, 8) = 0
[pid   112] read(3, 
"F\3069\340\0\0\0\5F\307\7\fF\307\t\\F\307^\230F\306L\224F\307^\210", 28) = 28
[pid   112] poll([{fd=3, events=POLLIN}], 1, 2000) = 1 ([{fd=3, 
revents=POLLIN}])
[pid   112] getppid()   = 111
[pid   112] read(3, "F\307\5 

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

Hi Waldemar,

On 11/05/16 04:57, Waldemar Brodkorb wrote:

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
./output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc
-Wl,-elf2flt=-v -o hello hello.c -lpthread :
..
reloc[403] = 0xe140
   RELOC[404]: offset=0x5724 symbol=frame_dummy+0x0 section=.text
size=0 fixup=0xac (reloc=0xe144)
reloc[404] = 0xe144
   RELOC[405]: offset=0x5728 symbol=pthread_initialize+0x0
section=.text size=0 fixup=0x87ec (reloc=0xe148)
reloc[405] = 0xe148
   RELOC[406]: offset=0x572c symbol=__do_global_dtors_aux+0x0
section=.text size=0 fixup=0x80 (reloc=0xe14c)
reloc[406] = 0xe14c
..

So pthread_initialize() is the problem?


Sure does look that way. I am not sure why looking at the above
details though.

Can you run again with the "Kernel-Traced-Load" flag set on the
hello program (so run the flthdr -k on it first). I want to see
what the actual memory regions allocated where and how far out
of those bounds the relocation ended up.


Here it is:
~ # /hello
[   57.91] BINFMT_FLAT: Loading file: /hello
[   57.91] Mapping is 9058, Entry point is 45, data_start is 8984
[   57.91] Load /hello: TEXT=90580040-90588984 DATA=905889a0-9058e1b0 
BSS=9058e1b0-9059240c
[   57.91] BINFMT_FLAT: reloc[405] outside program 0xed87 (0 - 
0x123b0/0x8944), killing hello!
SEGV


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.



The same hello world application works on Qemu m68k somehow. It starts and
get SIGILL, but at least not a relocation problem.


If you want to post more details on that I can have a look
at that too.

Regards
Greg
___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

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 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, here is the output with patched
>> kernel:
>> ~ # /hello 
>> [  162.46] BINFMT_FLAT: Loading file: /hello
>> [  162.46] Mapping is 9052, Entry point is 45, data_start is 8984
>> [  162.46] Load /hello: TEXT=90520040-90528984 DATA=905289a0-9052e1b0 
>> BSS=9052e1b0-9053240c
>> [  162.46] BINFMT_FLAT: reference 0x87 to shared library 237, 
>> killing hello!
>> SEGV
>>
>>  /hello 
>> [   11.23] BINFMT_FLAT: reference 0x87 to shared library 237, 
>> killing hello!
>> SEGV
>>
>> Hmm, on the stm32 with latest buildroot, I now get this errors.
>>
>> But I just use UCLIBC_FORMAT_FLAT. The kernel defconfig used has
>> CONFIG_BINFMT_SHARED_FLAT enabled.
> 
> 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
> ./output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc
> -Wl,-elf2flt=-v -o hello hello.c -lpthread :
> ..
> reloc[403] = 0xe140
>   RELOC[404]: offset=0x5724 symbol=frame_dummy+0x0 section=.text
> size=0 fixup=0xac (reloc=0xe144)
> reloc[404] = 0xe144
>   RELOC[405]: offset=0x5728 symbol=pthread_initialize+0x0
> section=.text size=0 fixup=0x87ec (reloc=0xe148)
> reloc[405] = 0xe148
>   RELOC[406]: offset=0x572c symbol=__do_global_dtors_aux+0x0
> section=.text size=0 fixup=0x80 (reloc=0xe14c)
> reloc[406] = 0xe14c
> ..
> 
> So pthread_initialize() is the problem?

Sure does look that way. I am not sure why looking at the above
details though.

Can you run again with the "Kernel-Traced-Load" flag set on the
hello program (so run the flthdr -k on it first). I want to see
what the actual memory regions allocated where and how far out
of those bounds the relocation ended up.

Regards
Greg


___
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

Re: [uClinux-dev] toolchain for c++ on coldfire

[Greg Ungerer]

Hi Angelo,

On 29/04/16 17:28, angelo wrote:

i have the 5.3.0 c and c++ toolchain up and running.
Last issue i had was compiling errors building a separate
applications in c++, related to usleep undefined.

To have usleep included in the recent uClibc library, you need

UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y



Many thanks for this great script.

Could compile full uClinux-dist but with a recent kernel 4.5 (> 3.5).

Still a last issue,
if i compile a c++ app with this 5.3.0 toolchain, and upload it to a
mcf5307 system, (kernel built with older toolchain and system
with older uClibc) i get a strange
"ILL" console message after execution, and program exits.

am i doing something wrong ?


If you compile the c++ app within the uclinux-dist do you get the same 
result?


Can you post the c++ app?
Or at least a simple test case that shows the problem?

Regards
Greg




On 29/04/2016 07:22, 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.

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?

It is required because it fails to compile without it :-)
I don't know why it fails, I didn't dig any further into it.


Do you mind to add some notes/comments to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833

I don't see I can add any value there. I googled and found
Larry's bug report and fix at this link. The above patch is
exactly Larry's solution from that thread.



There is another workaround in your script:
  find ${GCCLIB} -name libgcc.a -print | while read t
 do
 ${TARGET}-ar dv "$t" _ctors.o
 done

What kind of pain this is causing?

I don't know. It was in that script before I started using it.
It hasn't caused any problems with it there so I have never
removed it.



Both works fine for me and the second workaround
is simpler than my old way via a extra gcc spec file
and a gcc-wrapper script.

So when you are compiling a modern gcc for m68k-uclinux you
don't hit the problem compiling linux-atomic.c?

Regards
Greg


___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent byuclinux-...@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev




___
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


___
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

Re: [uClinux-dev] toolchain for c++ on coldfire

[Greg Ungerer]

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.
>>>
>>> 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?

It is required because it fails to compile without it :-)
I don't know why it fails, I didn't dig any further into it.

> Do you mind to add some notes/comments to 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833

I don't see I can add any value there. I googled and found
Larry's bug report and fix at this link. The above patch is
exactly Larry's solution from that thread.


> There is another workaround in your script:
>  find ${GCCLIB} -name libgcc.a -print | while read t
> do
> ${TARGET}-ar dv "$t" _ctors.o
> done
> 
> What kind of pain this is causing?

I don't know. It was in that script before I started using it.
It hasn't caused any problems with it there so I have never
removed it.


> Both works fine for me and the second workaround
> is simpler than my old way via a extra gcc spec file
> and a gcc-wrapper script.

So when you are compiling a modern gcc for m68k-uclinux you
don't hit the problem compiling linux-atomic.c?

Regards
Greg


___
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

Re: [uClinux-dev] toolchain for c++ on coldfire

[Greg Ungerer]

Hi Angelo,

On 21/04/16 17:08, angelo wrote:
> Hi Greg,
> 
> i am currently stuck at STAGE5, with this error:
> 
> checking size of double... 8
> checking size of long double... 12
> checking for inttypes.h... no
> checking for stdint.h... no
> checking for stdlib.h... no
> checking for ftw.h... no
> checking for unistd.h... no
> checking for sys/stat.h... no
> checking for sys/types.h... no
> checking for string.h... no
> checking for strings.h... no
> checking for memory.h... no
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... no
> checking whether decimal floating point is supported... no
> configure: WARNING: decimal float is not supported for this target, ignored
> checking whether fixed-point is supported... no
> checking whether to use setjmp/longjmp exceptions... unknown
> configure: error: unable to detect exception model
> Makefile:12550: set di istruzioni per l'obiettivo "configure-target-libgcc" 
> non riuscito
> make[1]: *** [configure-target-libgcc] Errore 1
> make[1]: uscita dalla directory 
> "/home/angelo/archivio/aziende/sysam/uClinux-toolchains/m68k-uclinux-gcc"
> Makefile:876: set di istruzioni per l'obiettivo "all" non riuscito
> make: *** [all] Errore 2

Do you mean during STAGE6?
That is where I would expect these configure checks.

Any way, most of those headers should be found (so "... yes").
It looks like the header install step didn't work as expected.
Can you check for files under /usr/local/m68k-uclinux/include.

Regards
Greg


> Any idea on what it could be ?
> 
> Thanks
> 
> Regards,
> Angelo
> 
> 
> On 20/04/2016 08:01, angelo wrote:
>> Many thanks,
>>
>> i see that the patch seems related to this
>>
>> https://gcc.gnu.org/ml/gcc/2016-04/msg00118.html
>>
>> It is the workaround i see also somewhere, so good to have it.
>>
>> Regards,
>> Angelo
>>
>>
>>
>> On 20/04/2016 02:24, 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.
>>>
>>> Regards
>>> Greg
>>>
>>>
>>>
>>>> On 19/04/2016 15:52, Greg Ungerer wrote:
>>>>> Hi Angelo,
>>>>>
>>>>> On 19/04/16 17:40, angelo wrote:
>>>>>> Sry, i forgot html format enabled, so i resend.
>>>>>>
>>>>>> Dear Greg and all,
>>>>>>
>>>>>> i am building from some time some c++ apps for mcf5307.
>>>>>> At the time being, with the toolchain m68k-uclinux-20101118 i get
>>>>>> some errors, like usleep not declared, even including ,
>>>>>> as
>>>>>> 88:15: error: ‘usleep’ was not declared in this scope
>>>>>>
>>>>>> Actually, the only toolchain i can use successfully for c++
>>>>>> apps on mcf5307 is an old
>>>>>>
>>>>>> Sourcery_CodeBench_Lite_for_ColdFire_uClinux
>>>>>>
>>>>>> But we know they are no more available / open. Do you know any other
>>>>>> alternative ? Or a guide i can use to prepare a c,c++ toolchain
>>>>>> for uClinux (then i can make it available) ?
>>>>> Attached is a build script I use to build m68k-uclinux toolchains.
>>>>>
>>>>> Most recently I have built and am testing a gcc-5.3 based toolchain.
>>>>> The elf2flt package referenced in this script was just a snapshot
>>>>> of the github uclinux/elf2flt tree on that date.
>>>>>
>>>>> I don't know if it will work any better for you with c++ apps,
>>>>> but it is worth a try.
>>>>>
>>>>> Note that gcc-5.3 will produce broken non-MMU m68k linux
>>>>> for kernel versions older then 4.5 (due to code generation
>>>>> issues with the signal handling code). So keep that in mind
>>>>> if you are compiling kernels with it.
>>>>>
>>>>> Regards
>>>>> Greg
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> uClinux-dev mailing list
>>>>> uClinux-dev@uclinux.org
>>>>> http://mailman.uclinux.org/mailman/

Re: [uClinux-dev] toolchain for c++ on coldfire

[Greg Ungerer]

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.

Regards
Greg



> On 19/04/2016 15:52, Greg Ungerer wrote:
>> Hi Angelo,
>>
>> On 19/04/16 17:40, angelo wrote:
>>> Sry, i forgot html format enabled, so i resend.
>>>
>>> Dear Greg and all,
>>>
>>> i am building from some time some c++ apps for mcf5307.
>>> At the time being, with the toolchain m68k-uclinux-20101118 i get
>>> some errors, like usleep not declared, even including ,
>>> as
>>> 88:15: error: ‘usleep’ was not declared in this scope
>>>
>>> Actually, the only toolchain i can use successfully for c++
>>> apps on mcf5307 is an old
>>>
>>> Sourcery_CodeBench_Lite_for_ColdFire_uClinux
>>>
>>> But we know they are no more available / open. Do you know any other
>>> alternative ? Or a guide i can use to prepare a c,c++ toolchain
>>> for uClinux (then i can make it available) ?
>>
>> Attached is a build script I use to build m68k-uclinux toolchains.
>>
>> Most recently I have built and am testing a gcc-5.3 based toolchain.
>> The elf2flt package referenced in this script was just a snapshot
>> of the github uclinux/elf2flt tree on that date.
>>
>> I don't know if it will work any better for you with c++ apps,
>> but it is worth a try.
>>
>> Note that gcc-5.3 will produce broken non-MMU m68k linux
>> for kernel versions older then 4.5 (due to code generation
>> issues with the signal handling code). So keep that in mind
>> if you are compiling kernels with it.
>>
>> Regards
>> Greg
>>
>>
>>
>> ___
>> 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
> 
> 
> 
> ___
> 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
> 

--- gcc-5.3.0/libgcc/config.host.org	2016-01-13 13:03:24.815783571 +1000
+++ gcc-5.3.0/libgcc/config.host	2016-01-13 13:04:05.191784224 +1000
@@ -794,7 +794,7 @@
 m68k*-*-openbsd*)
 	;;
 m68k-*-uclinux*)	# Motorola m68k/ColdFire running uClinux with uClibc
-	tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
+	tmake_file="$tmake_file m68k/t-floatlib"
 	md_unwind_header=m68k/linux-unwind.h
 	;;
 m68k-*-linux*)			# Motorola m68k's running GNU/Linux
___
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

Re: [uClinux-dev] toolchain for c++ on coldfire

[Greg Ungerer]

Hi Angelo,

On 19/04/16 17:40, angelo wrote:

Sry, i forgot html format enabled, so i resend.

Dear Greg and all,

i am building from some time some c++ apps for mcf5307.
At the time being, with the toolchain m68k-uclinux-20101118 i get
some errors, like usleep not declared, even including ,
as
88:15: error: ‘usleep’ was not declared in this scope

Actually, the only toolchain i can use successfully for c++
apps on mcf5307 is an old

Sourcery_CodeBench_Lite_for_ColdFire_uClinux

But we know they are no more available / open. Do you know any other
alternative ? Or a guide i can use to prepare a c,c++ toolchain
for uClinux (then i can make it available) ?


Attached is a build script I use to build m68k-uclinux toolchains.

Most recently I have built and am testing a gcc-5.3 based toolchain.
The elf2flt package referenced in this script was just a snapshot
of the github uclinux/elf2flt tree on that date.

I don't know if it will work any better for you with c++ apps,
but it is worth a try.

Note that gcc-5.3 will produce broken non-MMU m68k linux
for kernel versions older then 4.5 (due to code generation
issues with the signal handling code). So keep that in mind
if you are compiling kernels with it.

Regards
Greg



build-uclinux-tools.sh
Description: application/shellscript
___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

Hi Waldemar,

On 17/04/16 01:38, Waldemar Brodkorb wrote:
> Greg Ungerer wrote,
>> On 07/04/16 19:35, Waldemar Brodkorb wrote:
>>> Greg Ungerer wrote,
>>>>> You can find readelf, objdump -x, objdump -D and the source of
>>>>> hello.c here:
>>>>> http://debug.openadk.org/arm-pthreads/
>>>>
>>>> If you compile supplying "-v" in the elf2flt flags then it
>>>> will produce a verbose output that contains all the relocation
>>>> information. That will be helpful here. (Post it here too if
>>>> you want).
>>>
>>> Attached is the log for this exec:
>>> ~ # ./hello 
>>> BINFMT_FLAT: reloc outside program 0x9989 (0 - 0x12588/0x8af0),
>>> killing hello!
>>> SEGV
>>>
>>> Unfortunately I had to disable both ARM specific fprintf debug
>>> outputs, as they generate a segfault in elf2flt again.
>>> Are they required and helpful? Or should I send a patch to remove them?
>>
>> I am not sure which ones you are referring to?
>  
> I have attached a patch showing the problematic lines.

Ok, I see. My first thought is that they may in fact be
showing a problem right here. Can you possibly debug a little
here and determine which of the printf args are causing the
segfault?


>>>>> Stracing the process does not work:
>>>>> ~ # ./strace ./hello
>>>>> BINFMT_FLAT: Loading file: ./hello
>>>>> ./strace: Can't attach to 45: No such process
>>>>> ~ # Mapping is 7056, Entry point is 45, data_start is 8b4c
>>>>> Load ./hello: TEXT=70560040-70568b4c DATA=70568b50-7056e388
>>>>> BSS=7056e388-705725e4
>>>>> BINFMT_FLAT: reloc outside program 0xb589 (0 - 0x125a4/0x8b0c),
>>>>> killing hello!
>>>>
>>>> strace won't help you here. The program isn't running yet, the
>>>> relocation failure is at exec time.
>>>
>>> Okay, after using gdbserver from Emcraft I understood it will be
>>> something before I can use gdb/strace.
>>>  
>>>>> Any help is appreciated,
>>>>
>>>> The verbose elf2flt output may give some clues. You may need to
>>>> instrument the kernel's fs/binfmt_flat.c code to match up reloc
>>>> numbers though if nothing is obviously wrong in the verbose
>>>> reloc information.
>>>
>>> This will be harder for me at the moment, as compiling my own
>>> kernel for this device is not working ATM. But if required I will
>>> get it working.
>>
>> I couldn't see the problem in amongst that verbose output.
>> I would really want to see what reloc number the kernel loader
>> is barfing on to make sense of it.
> 
> 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 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.


> console. And I could ask Thomas to test something on his device.
> I think my STM is slightly different to his device, I also need
> to change some USB ID in OpenOCD to flash. May be there is also some
> difference in the IRQ number handling the serial device.

I don't expect that the specific target really has an impact here.
It feels more like a general ARM elf2lft problem.


>> I don't have a working ARM nommu target build at the moment,
>> so I don't have any way to try this myself. I will try and
>> put something together so I can run it under qemu to debug it
>> further.
> 
> You could try latest buildroot to generate an image for
> STM32 F4 discovery, sth like this:
> http://www2.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html

I have used the smaller ST parts (not with Linux), but not this one.


> I am not sure any Qemu Cortex-M3/4 system emulation is
> available. 

Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?

I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.

Regards
Greg



diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index f723cd3..17544c1 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -310,7 +310,7 @@ out_free:
 //
 

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

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:
>>> http://debug.openadk.org/arm-pthreads/
>>
>> If you compile supplying "-v" in the elf2flt flags then it
>> will produce a verbose output that contains all the relocation
>> information. That will be helpful here. (Post it here too if
>> you want).
> 
> Attached is the log for this exec:
> ~ # ./hello 
> BINFMT_FLAT: reloc outside program 0x9989 (0 - 0x12588/0x8af0),
> killing hello!
> SEGV
> 
> Unfortunately I had to disable both ARM specific fprintf debug
> outputs, as they generate a segfault in elf2flt again.
> Are they required and helpful? Or should I send a patch to remove them?

I am not sure which ones you are referring to?


>>> Stracing the process does not work:
>>> ~ # ./strace ./hello
>>> BINFMT_FLAT: Loading file: ./hello
>>> ./strace: Can't attach to 45: No such process
>>> ~ # Mapping is 7056, Entry point is 45, data_start is 8b4c
>>> Load ./hello: TEXT=70560040-70568b4c DATA=70568b50-7056e388
>>> BSS=7056e388-705725e4
>>> BINFMT_FLAT: reloc outside program 0xb589 (0 - 0x125a4/0x8b0c),
>>> killing hello!
>>
>> strace won't help you here. The program isn't running yet, the
>> relocation failure is at exec time.
> 
> Okay, after using gdbserver from Emcraft I understood it will be
> something before I can use gdb/strace.
>  
>>> Any help is appreciated,
>>
>> The verbose elf2flt output may give some clues. You may need to
>> instrument the kernel's fs/binfmt_flat.c code to match up reloc
>> numbers though if nothing is obviously wrong in the verbose
>> reloc information.
> 
> This will be harder for me at the moment, as compiling my own
> kernel for this device is not working ATM. But if required I will
> get it working.

I couldn't see the problem in amongst that verbose output.
I would really want to see what reloc number the kernel loader
is barfing on to make sense of it.

I don't have a working ARM nommu target build at the moment,
so I don't have any way to try this myself. I will try and
put something together so I can run it under qemu to debug it
further.

Regards
Greg


> ___
> 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
> 

___
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

[uClinux-dev] [git pull] m68knommu/coldfire fixes

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-linus branch.
Only a single change that removes a local arch specific gpio bus sysfs
device that now clashes with the generic gpio bus sysfs device interface.

Regards
Greg



The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:

  Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) 

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-linus

for you to fetch changes up to 2763ee644809820fb1b741f1e7dd779038092324:

  m68k/gpio: remove arch specific sysfs bus device (2016-04-11 12:03:18 +1000)


Greg Ungerer (1):
  m68k/gpio: remove arch specific sysfs bus device

 arch/m68k/coldfire/gpio.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)
___
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

Re: [uClinux-dev] BINFMT_FLAT: reloc outside program

[Greg Ungerer]

Hi Waldemar,

On 05/04/16 20:49, Waldemar Brodkorb wrote:

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 used in the binary. Non-threading
applications are working fine. (Linuxthreads.old used)
The problem was reported by Thomas Petazzoni from Buildroot project.

On the build system I used this example code:
http://timmurphy.org/2010/05/04/pthreads-in-c-a-minimal-working-example/

$ /usr/bin/arm-openadk-uclinux-uclibceabi-gcc -o hello hello.c -lpthread
$ /usr/bin/arm-openadk-uclinux-uclibceabi-flthdr -k hello
$ /usr/bin/arm-openadk-uclinux-uclibceabi-flthdr -p hello
hello
 Magic:bFLT
 Rev:  4
 Build Date:   Tue Apr  5 12:28:25 2016
 Entry:0x45
 Data Start:   0x8b4c
 Data End: 0xe384
 BSS End:  0x125e0
 Stack Size:   0x1000
 Reloc Start:  0xe384
 Reloc Count:  0x197
 Flags:0x11 ( Load-to-Ram Kernel-Traced-Load )

On the target system:
~ # ./hello
BINFMT_FLAT: Loading file: ./hello
Mapping is 7002, Entry point is 45, data_start is 8b4c
Load ./hello: TEXT=70020040-70028b4c DATA=70028b50-7002e388
BSS=7002e388-700325e4
BINFMT_FLAT: reloc outside program 0xb589 (0 - 0x125a4/0x8b0c),
killing hello!
SEGV

You can find readelf, objdump -x, objdump -D and the source of
hello.c here:
http://debug.openadk.org/arm-pthreads/


If you compile supplying "-v" in the elf2flt flags then it
will produce a verbose output that contains all the relocation
information. That will be helpful here. (Post it here too if
you want).



Stracing the process does not work:
~ # ./strace ./hello
BINFMT_FLAT: Loading file: ./hello
./strace: Can't attach to 45: No such process
~ # Mapping is 7056, Entry point is 45, data_start is 8b4c
Load ./hello: TEXT=70560040-70568b4c DATA=70568b50-7056e388
BSS=7056e388-705725e4
BINFMT_FLAT: reloc outside program 0xb589 (0 - 0x125a4/0x8b0c),
killing hello!


strace won't help you here. The program isn't running yet, the
relocation failure is at exec time.



gdbserver (gdb 7.11) does not compile for me as it uses fork():
build-gnulib-gdbserver/import/libgnu.a
build-libiberty-gdbserver/libiberty.a -lthread_db
linux-low.o: In function `linux_create_inferior':
linux-low.c:(.text+0x25d2): undefined reference to `fork'
linux-ptrace.o: In function `linux_child_function':
linux-ptrace.c:(.text+0x24): undefined reference to `fork'
linux-ptrace.o: In function `linux_check_ptrace_features':
linux-ptrace.c:(.text+0x10a): undefined reference to `fork'
thread-db.o: In function `thread_db_init':
thread-db.c:(.text+0x520): undefined reference to `td_thr_tlsbase'
collect2: error: ld returned 1 exit status


That won't help you here either (at least for this specific
problem). It is the exec step this program that is failing.



I searched the internet and found that it might be stack size
related. But even compiling example code and C library with
-Wl,-elf2flt=-s16384 didn't help.


Ok, that is always a good thing to try first.



Any help is appreciated,


The verbose elf2flt output may give some clues. You may need to
instrument the kernel's fs/binfmt_flat.c code to match up reloc
numbers though if nothing is obviously wrong in the verbose
reloc information.

Regards
Greg


___
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

[uClinux-dev] [git pull] m68knommu/coldfire fixes for 4.6

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.
The main change is the removal of the bit-rotten 68360 support.
Also a fix to always make the ethernet FEC platform info available.

Regards
Greg



The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb:

  Linux 4.5-rc7 (2016-03-06 14:48:03 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next

for you to fetch changes up to a3595962d82495f51a80feb19dcdb135556a9527:

  m68knommu: remove obsolete 68360 support (2016-03-07 10:07:17 +1000)


Greg Ungerer (2):
  m68knommu: fix FEC platform device registration when driver is modular
  m68knommu: remove obsolete 68360 support

 arch/m68k/68360/Makefile |  12 -
 arch/m68k/68360/commproc.c   | 309 
 arch/m68k/68360/config.c | 169 -
 arch/m68k/68360/entry.S  | 164 -
 arch/m68k/68360/head-ram.S   | 402 -
 arch/m68k/68360/head-rom.S   | 413 --
 arch/m68k/68360/ints.c   | 138 
 arch/m68k/Kconfig.cpu|   7 -
 arch/m68k/Kconfig.debug  |   2 +-
 arch/m68k/Kconfig.machine|   6 -
 arch/m68k/Makefile   |   3 -
 arch/m68k/coldfire/device.c  |   4 +-
 arch/m68k/include/asm/commproc.h | 664 ---
 arch/m68k/include/asm/m68360.h   |  13 -
 arch/m68k/include/asm/m68360_enet.h  | 177 --
 arch/m68k/include/asm/m68360_pram.h  | 431 ---
 arch/m68k/include/asm/m68360_quicc.h | 362 ---
 arch/m68k/include/asm/m68360_regs.h  | 408 -
 arch/m68k/kernel/early_printk.c  |   8 +-
 arch/m68k/kernel/setup_no.c  |   7 -
 20 files changed, 7 insertions(+), 3692 deletions(-)
 delete mode 100644 arch/m68k/68360/Makefile
 delete mode 100644 arch/m68k/68360/commproc.c
 delete mode 100644 arch/m68k/68360/config.c
 delete mode 100644 arch/m68k/68360/entry.S
 delete mode 100644 arch/m68k/68360/head-ram.S
 delete mode 100644 arch/m68k/68360/head-rom.S
 delete mode 100644 arch/m68k/68360/ints.c
 delete mode 100644 arch/m68k/include/asm/commproc.h
 delete mode 100644 arch/m68k/include/asm/m68360.h
 delete mode 100644 arch/m68k/include/asm/m68360_enet.h
 delete mode 100644 arch/m68k/include/asm/m68360_pram.h
 delete mode 100644 arch/m68k/include/asm/m68360_quicc.h
 delete mode 100644 arch/m68k/include/asm/m68360_regs.h
___
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

Re: [uClinux-dev] [PATCH v2] allow to build arm flat binaries

[Greg Ungerer]

Hi Waldemar,

On 14/03/16 15:01, Waldemar Brodkorb wrote:

Add patchset from ptxdist which is required to produce working
ARM flat binaries. Tested with busybox on Kinetis K70.

Signed-off-by: Waldemar Brodkorb 


Thanks. Applied to the github elf2flt repository (with Thomas'
Tested-by).

Regards
Greg




v1 -> v2:
  - segfault problem fixed, r_mem pointer should be initialized
  - v1 was successfully tested by Thomas Petazzoni with buildroot
generated image for STM32F429

---
  elf2flt.c |   11 ++-
  elf2flt.ld.in |   17 ++---
  2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/elf2flt.c b/elf2flt.c
index fcd797c..7d0e639 100644
--- a/elf2flt.c
+++ b/elf2flt.c
@@ -56,6 +56,8 @@ const char *elf2flt_progname;

  #if defined(TARGET_h8300)
  #include   /* TARGET_* ELF support for the BFD library  
  */
+#elif defined(TARGET_arm)
+#include 
  #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(TARGET_nios) || 
defined(TARGET_nios2)
  #include "cygwin-elf.h" /* Cygwin uses a local copy */
  #elif defined(TARGET_xtensa)
@@ -451,7 +453,7 @@ dump_symbols(symbols, number_of_symbols);
qsort (relpp, relcount, sizeof *relpp, compare_relocs);
  #endif
for (p = relpp; (relcount && (*p != NULL)); p++, relcount--) {
-   unsigned char *r_mem;
+   unsigned char *r_mem = NULL;
int relocation_needed = 0;

  #ifdef TARGET_microblaze
@@ -646,16 +648,23 @@ dump_symbols(symbols, number_of_symbols);
default:
goto good_32bit_resolved_reloc;
  #elif defined(TARGET_arm)
+   case R_ARM_TARGET1:
+   case R_ARM_TARGET2:
case R_ARM_ABS32:
relocation_needed = 1;
break;
case R_ARM_REL32:
+   case R_ARM_JUMP24:
+   case R_ARM_CALL:
case R_ARM_THM_PC11:
case R_ARM_THM_PC22:
+   case R_ARM_THM_JUMP24:
case R_ARM_PC24:
case R_ARM_PLT32:
case R_ARM_GOTPC:
case R_ARM_GOT32:
+   case R_ARM_PREL31:
+   case R_ARM_NONE:
relocation_needed = 0;
break;
default:
diff --git a/elf2flt.ld.in b/elf2flt.ld.in
index bfda0ef..ec1fe6f 100644
--- a/elf2flt.ld.in
+++ b/elf2flt.ld.in
@@ -35,6 +35,8 @@ W_RODAT   *(.rodata1)
  W_RODAT   *(.rodata.*)
  W_RODAT   *(.gnu.linkonce.r*)

+   /* .ARM.extab name sections containing exception unwinding 
information */
+   *(.ARM.extab* .gnu.linkonce.armextab.*)
/* This is special code area at the end of the normal
   text section.  It contains a small lookup table at
   the start followed by the code pointed to by entries
@@ -43,11 +45,20 @@ W_RODAT *(.gnu.linkonce.r*)
PROVIDE(@SYMBOL_PREFIX@__ctbp = .);
*(.call_table_data)
*(.call_table_text)
-
-   . = ALIGN(0x20) ;
-   @SYMBOL_PREFIX@_etext = . ;
} > flatmem :text

+   /* .ARM.exidx name sections containing index entries for section 
unwinding */
+   /* .ARM.exidx is sorted, so has to go in its own output section.  */
+   @SYMBOL_PREFIX@__exidx_start = .;
+   .ARM.exidx :
+   {
+   *(.ARM.exidx* .gnu.linkonce.armexidx.*)
+   } > flatmem
+   @SYMBOL_PREFIX@__exidx_end = .;
+
+   . = ALIGN(0x20) ;
+   @SYMBOL_PREFIX@_etext = . ;
+
.data : {
. = ALIGN(0x4) ;
@SYMBOL_PREFIX@_sdata = . ;


___
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

Re: [uClinux-dev] out-of-date libgmp / building for M5208

[Greg Ungerer]

On 13/02/16 11:55, Andrew Cagney wrote:
> FYI,
> 
> I've attached a simpler Kconfig and makefile.  However,
> 
> On 15 December 2015 at 00:32, Greg Ungerer <g...@uclinux.org> wrote:
>> Hi Andrew,
>>
>> On 15/12/15 02:11, Andrew Cagney wrote:
>>> On 13 December 2015 at 20:35, Greg Ungerer <g...@uclinux.org> wrote:
>>>> On 12/12/15 03:03, Andrew Cagney wrote:
>>>>> I came up with the attached.  The existing libgmp configuration in
>>>>> lib/Kconfig would need removing.
>>>>
>>>> Just a heads up... But some other targets in the tree that
>>>> currently have libgmp enabled no longer compile with this
>>>> in place.
>>>>
>>>> For example building an ARM target fails at:
>>>>
>>>> ...
>>>> Executing: /bin/sh -c 'ucfront-gcc' 'arm-linux-gnueabi-20150104-gcc' 
>>>> '-std=gnu99' '-DHAVE_CONFIG_H' '-I.' '-D__GMP_WITHIN_GMP' '-O1' '-pipe' 
>>>> '-fno-common' '-fno-builtin' '-Wall' '-Dlinux' '-D__linux__' '-Dunix' 
>>>> '-DEMBED' '-c' 'tal-reent.c' '-fPIC' '-o' 'tal-reent.o'
>>>> Executing: touch tal-reent.lo
>>>> make[5]: *** No rule to make target `mpn/add_n.lo', needed by `libgmp.la'. 
>>>>  Stop.
>>>> make[5]: Leaving directory 
>>>> `/home/gerg/uclinux-dist.foo/lib/libgmp/build/gmp-6.1.0'
>>>> make[4]: *** [all-recursive] Error 1
>>>
>>> What happens if you point the URL at 5.x series, for instance:
>>> https://gmplib.org/download/gmp/gmp-5.1.3.tar.xz
>>
>> Same result. Fails to build with same error.
> 
> 
> I've had no luck with this.  Hmm, perhaps my build works because I'm
> using the C file:
> 
> gmp-6.1.0/mpn/add_n.c -> ../mpn/generic/add_n.c
> 
> but arm would be trying to build the assembler instead.

So you didn't try to build for any other architecture?

Regards
Greg


>>> This thread:
>>>http://stackoverflow.com/a/16726435/1357163
>>> lead me to this patch:
>>>https://gmplib.org/repo/gmp-5.1/rev/2347fd4901ad
>>> which I don't seem to be able to find in 6.x's ChangeLog.
>>
>> The problem doesn't appear to be ARM specific. I tried a compile
>> of an x86_64 target and it failed in a similar way:
>>
>>  make[5]: *** No rule to make target `mpn/invert_limb_table.lo', needed by 
>> `libgmp.la'.  Stop.
>>
>> Regards
>> Greg
>>
>>
>>> (and of course, just my luck that --disable-assembly was only added in 6.x)
>>>
>>>
>>> ___
>>> 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

___
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

Re: [uClinux-dev] [PATCH 6/6] Add xtensa support

[Greg Ungerer]

Hi Waldemar,

On 31/12/15 09:55, Waldemar Brodkorb wrote:
> This is forward ported version of patch from 2006' elf2flt by
> Oskar Schirmer .
> 
> Signed-off-by: Max Filippov 
> Signed-off-by: Waldemar Brodkorb 

Applied to elf2flt git tree, thanks.

Regards
Greg


> ---
>  elf2flt.c |   69 
> +
>  elf2flt.ld.in |7 --
>  2 files changed, 74 insertions(+), 2 deletions(-)
> 

___
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

[uClinux-dev] [git pull] m68knommu/coldfire fixes for 4.5

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.
Only a single change, limiting the return values for coldfire gpio
get function.

Regards
Greg



The following changes since commit 168309855a7d1e16db751e9c647119fe2d2dc878:

  Linux 4.4-rc8 (2016-01-03 15:15:37 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next

for you to fetch changes up to 4693c2493a9b2d0c5d407496ea107676a690f1c0:

  m68k: coldfire/gpio: Be sure to clamp return value (2016-01-04 
13:25:12 +1000)



Linus Walleij (1):
  m68k: coldfire/gpio: Be sure to clamp return value

 arch/m68k/coldfire/gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
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

Re: [uClinux-dev] [PATCH 2/6] recent binutils for h8/300 no longer use prefix

[Greg Ungerer]

On 31/12/15 09:55, Waldemar Brodkorb wrote:

Remove SYMBOL_PREFIX for h8/300.

Signed-off-by: Waldemar Brodkorb 
Signed-off-by: Yoshinori Sato 


Applied to elf2flt git tree, thanks.

Regards
Greg



---
  configure.ac |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index adf5883..5ca70d5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -181,7 +181,7 @@ fi

  SYMBOL_PREFIX=
  case $target in
-   h8300|bfin*)
+   bfin*)
SYMBOL_PREFIX=_
;;
  esac


___
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

Re: [uClinux-dev] [PATCH 3/6] h8300 address space is 24bit.

[Greg Ungerer]

Hi Yoshinori,

On 06/01/16 02:54, Yoshinori Sato wrote:
> On Mon, 04 Jan 2016 16:30:24 +0900,
> Greg Ungerer wrote:
>> On 31/12/15 09:55, Waldemar Brodkorb wrote:
>>> 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 8a8b97c..0401e20 100644
>>> --- a/flthdr.c
>>> +++ b/flthdr.c
>>> @@ -167,8 +167,16 @@ process_file(const char *ifile, const char *ofile)
>>> r = ntohl(relocs[i]);
>>> raddr = flat_get_relocate_addr(r);
>>> printf("%u\t0x%08lx (0x%08"PRIx32")\t", i, 
>>> r, raddr);
>>> +#if defined(TARGET_h8300)
>>> +   raddr &= ~0x0001;
>>> +#endif
>>> fseek_stream(, sizeof(old_hdr) + raddr, 
>>> SEEK_SET);
>>> fread_stream(, sizeof(addr), 1, );
>>> +#if defined(TARGET_h8300)
>>> +   addr = ntohl(addr);
>>> +   if (r & 1)
>>> +   addr &= 0x00ff;
>>> +#endif
>>> printf("%"PRIx32"\n", addr);
>>> }
>>>  
>>
>> The current flthdr.c code is essentially arch clean at the
>> moment (no other #ifdef arch special cases). Is this change
>> really necessary?
> 
> Yes. Want fix it.
> Current code generate broken relocation information.
> So can't load.

I don't follow. What code generates broken relocation information?

The above modified code is only printing out the relocation
information. If whatever code generated it is wrong then
why not fix that?

I can see an argument for better checking - so that bad
relocs don't cause the seeking and printing out of wrong
information. That would be an improvement, and it wouldn't
be architecture dependent.

Regards
Greg


> I sent fix of latest master.
> 
>> Regards
>> Greg
>>
>>
> 

___
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

Re: [uClinux-dev] [PATCH 1/6] dlopen is used by newer binutils, so check for it

[Greg Ungerer]

Hi Waldemar,

On 05/01/16 05:00, Waldemar Brodkorb wrote:
> Greg Ungerer wrote,
>> 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 +
>>>  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 redirect some functions to the system symbols, but 
>>> other local symbols
>>>  dnl come from libiberty/libbfd.
>>>  dnl int getopt(int, char * const [], const char *) __asm("_" "getopt" 
>>> "$UNIX2003");
>>>  AC_CHECK_LIB(c, malloc, LIBS="-lc $LIBS")
>>> +AC_CHECK_LIB(dl, dlopen)
>>
>> Could you successfully compile with just this?
> 
> Yes. May be it depends on the autoconf/automake used?
> Or it depends on binutils version?
> I am using binutils 2.25.1. Checked with --enable-plugins on and
> off for m68k.

I am using binutils-2.25.1 also. I used my system autoconf
(which was version 2.69).


>> I have to use:
>>
>>   AC_CHECK_LIB(dl, dlopen, LIBS="$LIBS -ldl")
>>
>> to get the correct lib ordering at link time. Otherwise the
>> linking of elf2flt fails for me (testing with m68k).
> 
> Should I send an update? So it does fix a case where it fails for
> you?

Yes. I had to have the -ldl at the end of the link line
of elf2flt for it to successfully link.

If you could generate a new patch that would be good.


> I remember buildroot having problems, when LTO and so
> --enable-plugins in binutils is used, they just add -ldl:
> http://lists.busybox.net/pipermail/buildroot/2015-September/139966.html

The original check did force -ldl to be added to the libs list
at build time. But it was too early in the args list, it had
to be after the bfd libs to work for me.

Regards
Greg



___
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

Re: [uClinux-dev] nspr

[Greg Ungerer]

Hi Andrew,

On 12/12/15 03:50, Andrew Cagney wrote:
> The patch "nspr.diff" adds a standalone and up-to-date NSPR library.
> It is always built statically.  For the patches:
> 
> nspr-00--done--nspr-configure-in--m68k-is-not-m68020-60.patch I
> believe it's been accepted
> nspr-02--hold--ifdef-have-dlfcn-h.patch: it's been submitted and
> hopefully accepted
> nspr-03--todo--barf-fork-call.patch: hack: I don't think s/fork/vfork/
> would work here, and since I don't need it to work I took the easy way
> out
> 
> I should point out that while Mozilla thinks NSPR and NSS should go
> hand-in-hand (per the current lib/nss directory which tries to build
> both) I found things became much easier when I split those two and
> built them separately (NSPR uses autoconf, abet incorrectly; NSS uses
> GNU make; NSS+NSPR uses GNU make to invoke autoconf ).   The patch
> "wip-nss.diff" (do not apply) hints at how I'm getting lib/nss to use
> the previously built NSPR

So ignoring wip-nss.diff do you think nspr.diff is in good
enough shape to apply to uClinux-dist?  Or does it need more
work and/or testing?

Regards
Greg


> ___
> 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
> 

___
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

Re: [uClinux-dev] [PATCH 3/6] h8300 address space is 24bit.

[Greg Ungerer]

Hi Waldemar,

On 31/12/15 09:55, Waldemar Brodkorb wrote:
> From: Yoshinori Sato 
> 
> Signed-off-by: Yoshinori Sato 
> Signed-off-by: Waldemar Brodkorb 
> ---
>  flthdr.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/flthdr.c b/flthdr.c
> index 8a8b97c..0401e20 100644
> --- a/flthdr.c
> +++ b/flthdr.c
> @@ -167,8 +167,16 @@ process_file(const char *ifile, const char *ofile)
>   r = ntohl(relocs[i]);
>   raddr = flat_get_relocate_addr(r);
>   printf("%u\t0x%08lx (0x%08"PRIx32")\t", i, 
> r, raddr);
> +#if defined(TARGET_h8300)
> + raddr &= ~0x0001;
> +#endif
>   fseek_stream(, sizeof(old_hdr) + raddr, 
> SEEK_SET);
>   fread_stream(, sizeof(addr), 1, );
> +#if defined(TARGET_h8300)
> + addr = ntohl(addr);
> + if (r & 1)
> + addr &= 0x00ff;
> +#endif
>   printf("%"PRIx32"\n", addr);
>   }
>  

The current flthdr.c code is essentially arch clean at the
moment (no other #ifdef arch special cases). Is this change
really necessary?

Regards
Greg


___
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

Re: [uClinux-dev] out-of-date libgmp / building for M5208

[Greg Ungerer]

Hi Andrew,

On 15/12/15 02:11, Andrew Cagney wrote:
> On 13 December 2015 at 20:35, Greg Ungerer <g...@uclinux.org> wrote:
>> On 12/12/15 03:03, Andrew Cagney wrote:
>>> I came up with the attached.  The existing libgmp configuration in
>>> lib/Kconfig would need removing.
>>
>> Just a heads up... But some other targets in the tree that
>> currently have libgmp enabled no longer compile with this
>> in place.
>>
>> For example building an ARM target fails at:
>>
>> ...
>> Executing: /bin/sh -c 'ucfront-gcc' 'arm-linux-gnueabi-20150104-gcc' 
>> '-std=gnu99' '-DHAVE_CONFIG_H' '-I.' '-D__GMP_WITHIN_GMP' '-O1' '-pipe' 
>> '-fno-common' '-fno-builtin' '-Wall' '-Dlinux' '-D__linux__' '-Dunix' 
>> '-DEMBED' '-c' 'tal-reent.c' '-fPIC' '-o' 'tal-reent.o'
>> Executing: touch tal-reent.lo
>> make[5]: *** No rule to make target `mpn/add_n.lo', needed by `libgmp.la'.  
>> Stop.
>> make[5]: Leaving directory 
>> `/home/gerg/uclinux-dist.foo/lib/libgmp/build/gmp-6.1.0'
>> make[4]: *** [all-recursive] Error 1
> 
> What happens if you point the URL at 5.x series, for instance:
> https://gmplib.org/download/gmp/gmp-5.1.3.tar.xz

Same result. Fails to build with same error.


> This thread:
>http://stackoverflow.com/a/16726435/1357163
> lead me to this patch:
>https://gmplib.org/repo/gmp-5.1/rev/2347fd4901ad
> which I don't seem to be able to find in 6.x's ChangeLog.

The problem doesn't appear to be ARM specific. I tried a compile
of an x86_64 target and it failed in a similar way:

 make[5]: *** No rule to make target `mpn/invert_limb_table.lo', needed by 
`libgmp.la'.  Stop.

Regards
Greg


> (and of course, just my luck that --disable-assembly was only added in 6.x)
> 
> 
>> Regards
>> Greg
>>
>>
>>
>>> On 9 December 2015 at 17:35, David McCullough <ucde...@gmail.com> wrote:
>>>>
>>>> Andrew Cagney wrote the following:
>>>>> On 8 December 2015 at 07:03, Greg Ungerer <g...@uclinux.org> wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> On 08/12/15 04:23, Andrew Cagney wrote:
>>>>>>>
>>>>>>> The libgmp bundled with uClinux, by default, doesn't build for the
>>>>>>> M5208 - the m68k assembler uses instructions dropped from early
>>>>>>> Coldfires.
>>>>>>> The hack I'm using locally is to configure with --host=none (I got
>>>>>>> this trick second hand from somewhere).
>>>>>>>
>>>>>>> Anyway I noticed that libgmp is, er, a little out-of-date.  The latest
>>>>>>> version has --disable-assembly which looks to be a cleaner way to
>>>>>>> handle the assembler problem.
>>>>>>> (How to decide when to configure with that option is an open question,
>>>>>>> a Kconfig option).
>>>>>>>
>>>>>>> As anyone looked at updating this; or to turn the question round, is
>>>>>>> there anything needed in the existing version that would prevent this?
>>>>>>
>>>>>>
>>>>>> Nothing stopping updating as far as I know.
>>>>>>
>>>>>> Can I suggest that if you do decide to update it that you convert
>>>>>> it to automake building.
>>>>>
>>>>> Yes, that's the plan.  I've noticed that the framework's improved
>>>>> significantly over the years and I've been able to drop some of my
>>>>> local hacks.
>>>>>
>>>>>> The trend over the last couple of years
>>>>>> is that if we are updating a package then convert it. There
>>>>>> are quite a few examples to follow in the lib directory. Just
>>>>>> look for directories that contain a "makefile" and optionally a
>>>>>> patches directory and not much else.
>>>>>
>>>>> Any pointers for how to handle --disable-assembly configure option?
>>>>> For instance, since libreswan requires libgmp, it would have:
>>>>>select LIB_LIBGMP
>>>>> but libreswan doesn't know if --disable-assembly is required, that
>>>>> would be set by a vendor/platform files?
>>>>
>>>> Yep,  make that part of the libgmp setup.  If you switch to automake you
>>>> can add that option to a Kconfig in the libgmp directory,  again,  there
>>>> are quite a few examples in the tree.  some have their own Kconfig files:

Re: [uClinux-dev] out-of-date libgmp / building for M5208

[Greg Ungerer]

Hi Andrew,

On 12/12/15 03:03, Andrew Cagney wrote:
> I came up with the attached.  The existing libgmp configuration in
> lib/Kconfig would need removing.

I would suggest not bothering to make it a menu on its own.
And the config entry for LIB_LIBGMP_DISABLE_ASSEMBLY should
have a "depends on LIB_LIBGMP".

Otherwise it is looking good.

Regards
Greg



> On 9 December 2015 at 17:35, David McCullough <ucde...@gmail.com> wrote:
>>
>> Andrew Cagney wrote the following:
>>> On 8 December 2015 at 07:03, Greg Ungerer <g...@uclinux.org> wrote:
>>>> Hi Andrew,
>>>>
>>>> On 08/12/15 04:23, Andrew Cagney wrote:
>>>>>
>>>>> The libgmp bundled with uClinux, by default, doesn't build for the
>>>>> M5208 - the m68k assembler uses instructions dropped from early
>>>>> Coldfires.
>>>>> The hack I'm using locally is to configure with --host=none (I got
>>>>> this trick second hand from somewhere).
>>>>>
>>>>> Anyway I noticed that libgmp is, er, a little out-of-date.  The latest
>>>>> version has --disable-assembly which looks to be a cleaner way to
>>>>> handle the assembler problem.
>>>>> (How to decide when to configure with that option is an open question,
>>>>> a Kconfig option).
>>>>>
>>>>> As anyone looked at updating this; or to turn the question round, is
>>>>> there anything needed in the existing version that would prevent this?
>>>>
>>>>
>>>> Nothing stopping updating as far as I know.
>>>>
>>>> Can I suggest that if you do decide to update it that you convert
>>>> it to automake building.
>>>
>>> Yes, that's the plan.  I've noticed that the framework's improved
>>> significantly over the years and I've been able to drop some of my
>>> local hacks.
>>>
>>>> The trend over the last couple of years
>>>> is that if we are updating a package then convert it. There
>>>> are quite a few examples to follow in the lib directory. Just
>>>> look for directories that contain a "makefile" and optionally a
>>>> patches directory and not much else.
>>>
>>> Any pointers for how to handle --disable-assembly configure option?
>>> For instance, since libreswan requires libgmp, it would have:
>>>select LIB_LIBGMP
>>> but libreswan doesn't know if --disable-assembly is required, that
>>> would be set by a vendor/platform files?
>>
>> Yep,  make that part of the libgmp setup.  If you switch to automake you
>> can add that option to a Kconfig in the libgmp directory,  again,  there
>> are quite a few examples in the tree.  some have their own Kconfig files:
>>
>> grep -l automake lib/*/makefile user/*/makefile
>>
>> ls lib/*/Kconfig user/*/Kconfig
>>
>> to find them all.
>>
>> Cheers,
>> Davidm
>>
>> --
>> David McCullough,  dav...@spottygum.com,   Ph: 0410 560 763
>> ___
>> 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
>>
>>
>> ___
>> 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

___
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

Re: [uClinux-dev] out-of-date libgmp / building for M5208

[Greg Ungerer]

Hi Andrew,

On 12/12/15 03:03, Andrew Cagney wrote:
> I came up with the attached.  The existing libgmp configuration in
> lib/Kconfig would need removing.

Just a heads up... But some other targets in the tree that
currently have libgmp enabled no longer compile with this
in place.

For example building an ARM target fails at:

...
Executing: /bin/sh -c 'ucfront-gcc' 'arm-linux-gnueabi-20150104-gcc' 
'-std=gnu99' '-DHAVE_CONFIG_H' '-I.' '-D__GMP_WITHIN_GMP' '-O1' '-pipe' 
'-fno-common' '-fno-builtin' '-Wall' '-Dlinux' '-D__linux__' '-Dunix' '-DEMBED' 
'-c' 'tal-reent.c' '-fPIC' '-o' 'tal-reent.o'  
Executing: touch tal-reent.lo 
make[5]: *** No rule to make target `mpn/add_n.lo', needed by `libgmp.la'.  
Stop.
make[5]: Leaving directory 
`/home/gerg/uclinux-dist.foo/lib/libgmp/build/gmp-6.1.0'
make[4]: *** [all-recursive] Error 1

Regards
Greg

 

> On 9 December 2015 at 17:35, David McCullough <ucde...@gmail.com> wrote:
>>
>> Andrew Cagney wrote the following:
>>> On 8 December 2015 at 07:03, Greg Ungerer <g...@uclinux.org> wrote:
>>>> Hi Andrew,
>>>>
>>>> On 08/12/15 04:23, Andrew Cagney wrote:
>>>>>
>>>>> The libgmp bundled with uClinux, by default, doesn't build for the
>>>>> M5208 - the m68k assembler uses instructions dropped from early
>>>>> Coldfires.
>>>>> The hack I'm using locally is to configure with --host=none (I got
>>>>> this trick second hand from somewhere).
>>>>>
>>>>> Anyway I noticed that libgmp is, er, a little out-of-date.  The latest
>>>>> version has --disable-assembly which looks to be a cleaner way to
>>>>> handle the assembler problem.
>>>>> (How to decide when to configure with that option is an open question,
>>>>> a Kconfig option).
>>>>>
>>>>> As anyone looked at updating this; or to turn the question round, is
>>>>> there anything needed in the existing version that would prevent this?
>>>>
>>>>
>>>> Nothing stopping updating as far as I know.
>>>>
>>>> Can I suggest that if you do decide to update it that you convert
>>>> it to automake building.
>>>
>>> Yes, that's the plan.  I've noticed that the framework's improved
>>> significantly over the years and I've been able to drop some of my
>>> local hacks.
>>>
>>>> The trend over the last couple of years
>>>> is that if we are updating a package then convert it. There
>>>> are quite a few examples to follow in the lib directory. Just
>>>> look for directories that contain a "makefile" and optionally a
>>>> patches directory and not much else.
>>>
>>> Any pointers for how to handle --disable-assembly configure option?
>>> For instance, since libreswan requires libgmp, it would have:
>>>select LIB_LIBGMP
>>> but libreswan doesn't know if --disable-assembly is required, that
>>> would be set by a vendor/platform files?
>>
>> Yep,  make that part of the libgmp setup.  If you switch to automake you
>> can add that option to a Kconfig in the libgmp directory,  again,  there
>> are quite a few examples in the tree.  some have their own Kconfig files:
>>
>> grep -l automake lib/*/makefile user/*/makefile
>>
>> ls lib/*/Kconfig user/*/Kconfig
>>
>> to find them all.
>>
>> Cheers,
>> Davidm
>>
>> --
>> David McCullough,  dav...@spottygum.com,   Ph: 0410 560 763
>> ___
>> 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
>>
>>
>> ___
>> 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

___
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

Re: [uClinux-dev] support .lz (lzip) compression

[Greg Ungerer]

Hi Andrew,

On 11/12/15 06:07, Andrew Cagney wrote:
> Surprise!  libgmp uses yet another compression format ...
> 
> My work-in-progress libgmp makefile tests it, trust me :-)

Thanks, that looks good. I'll apply that to the working tree.

Regards
Greg


___
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

Re: [uClinux-dev] out-of-date libgmp / building for M5208

[Greg Ungerer]

Hi Andrew,

On 14/12/15 12:18, Andrew Cagney wrote:
> On 13 December 2015 at 19:43, Greg Ungerer <g...@uclinux.org> wrote:
>> Hi Andrew,
>>
>> On 12/12/15 03:03, Andrew Cagney wrote:
>>> I came up with the attached.  The existing libgmp configuration in
>>> lib/Kconfig would need removing.
>>
>> I would suggest not bothering to make it a menu on its own.
>> And the config entry for LIB_LIBGMP_DISABLE_ASSEMBLY should
>> have a "depends on LIB_LIBGMP".
> 
> I tried that.  Consider:
> 
> - target board is M5208EVB which isn't supported by libgmp's assembly files
> 
> - libreswan requires libgmp so it's Kconfig includes a line to enable
> building libgmp
> 
> So the developer uses menuconfig, selects "libreswan", and builds.
> 
> Unfortunately it fails because the disable-assembly option needs to be
> set manually.
> 
> Having it as a separate flag and not requiring LIB_LIBGMP made it
> possible to save it in the vendor config file regardless of LIB_LIBGMP
> status.

But what user would set the disable assembler option correctly
when they don't even think they need libgmp?  I don't think it
logically follows that it should be an always selectable option.


> idea's welcome.

In your example above it is not the M5208EVB that is the selection
criteria. It is probably the fact that a ColdFire architecture CPU
is the target.

Maybe make time setting would work better in this case. Have a look
in the lib/libssl/makefile for an example that has to solve a
similar problem.

Regards
Greg


___
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

Re: [uClinux-dev] out-of-date libgmp / building for M5208

[Greg Ungerer]

Hi Andrew,

On 08/12/15 04:23, Andrew Cagney wrote:

The libgmp bundled with uClinux, by default, doesn't build for the
M5208 - the m68k assembler uses instructions dropped from early
Coldfires.
The hack I'm using locally is to configure with --host=none (I got
this trick second hand from somewhere).

Anyway I noticed that libgmp is, er, a little out-of-date.  The latest
version has --disable-assembly which looks to be a cleaner way to
handle the assembler problem.
(How to decide when to configure with that option is an open question,
a Kconfig option).

As anyone looked at updating this; or to turn the question round, is
there anything needed in the existing version that would prevent this?


Nothing stopping updating as far as I know.

Can I suggest that if you do decide to update it that you convert
it to automake building. The trend over the last couple of years
is that if we are updating a package then convert it. There
are quite a few examples to follow in the lib directory. Just
look for directories that contain a "makefile" and optionally a
patches directory and not much else.

Regards
Greg

___
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

Re: [uClinux-dev] cvs repository?

[Greg Ungerer]

On 05/12/15 06:55, Michael wrote:

Yes.

You are welcome to email patches for Greg to integrate to this mailing
list.


Yes, please. Patches to this list is a great place to start.

Michael: can we remove the cvs link from the main www page?
It is long dead and not coming back, so we can stop some
confusion by at least removing it.

Regards
Greg




On 2015-12-04 (W49) 10:51 AM, Lennart Sorensen wrote:

On Fri, Dec 04, 2015 at 10:37:15AM -0500, Michael wrote:

Andrew the CVS died the death about 5 years ago.  Mike Frysinger and
others from ADI had already converted it to a GIT repo .. but no one
provided
a copy of the new repo(s) back for uClinux.org to host for them.

So is the sourceforge link (which seems to lead to a place with a release
from August 2015) the most "official" at the moment?



___
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


___
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

Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808)

[Greg Ungerer]

Hi Ted,

On 03/12/15 19:24, Ted Victorio wrote:

Your patch works! The m5329.c compiled.
But I got 2 additional undefined errors ref to nand_ecc.c, so I
corrected by adding MTD_NAND_ECC to linux config:
 # Disk-On-Chip Device Drivers
 #
 CONFIG_MTD_NAND_ECC=y
 CONFIG_MTD_NAND_M5329=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_IDS=y

And I added these two lines to
uClinux-dist/vendors/Freescale/M5329EVB/Makefile (as I did to make
uClinux-dist-20080808 work)
 mtd0,c,90,0 mtd1,c,90,2 mtd2,c,90,4 \
 mtdblock0,b,31,0 mtdblock1,b,31,1 mtdblock2,b,31,2 \

The image.bin was succesfully built. However, the problem now is the
image.bin booting has stopped at 0x-0x0016e000 : "ROMfs"
(see captured display below)

I noticed differences between 2015 and 2008:
(1) Is m53xx compatible to m532x?  [2015] uClinux/COLDFIRE(m53xx)  vs
[2008] uClinux/COLDFIRE(m532x)


Yes, that is the intention. 53xx is meant to cater for similar
parts such as the 5329 and 537x families.



(2) Why different sizes for RAM probe?  [2015] uclinux[mtd]: probe
address=0x4029bc20 size=0x16e000  vs  [2008] uclinux[mtd]: RAM probe
address=0x401c83b8 size=0x3f7000


How big is your images/romfs.img file?
This size should match that (rounded to 4k I think).
Perhaps the default user space tool set is quite different,
thus producing a quite different size romfs (root filesystem).



(3) Why does 2015 not display NAND found like in 2008?  [2008] NAND
device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V
8-bit)


My first guess is that this probing is where the kernel is stuck.
So without the nand enabled do you get a complete all the way up boot
of 20150808?



(3) MTD partition creation? [2015] Creating 1 MTD partitions on "ram":
0x-0x0016e000 : "ROMfs"  vs  [2008] Creating 1 MTD
partitions on "NAND 16MiB 3,3V 8-bit": 0x-0x0100 : "M5329
flash partition 1"

Any clues to solve this?


I would suggest adding some more printk trace in the m5239.c nand
driver to see where it is possibly getting stuck.

Regards
Greg



---
dBUG> go 0x4002
Linux version 4.0.0-uc0 (root@RHEL6) (gcc version 4.5.1 (GCC) ) #9 Wed
Dec 2 20:51:10 PST 2015

uClinux/COLDFIRE(m53xx)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4080
Kernel command line: console=ttyS0,19200 rootfstype=romfs
PID hash table entries: 2048 (order: 0, 8192 bytes)
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Memory: 28416K/32768K available (1945K kernel code, 118K rwdata, 328K
rodata, 72K init, 79K bss, 4352K reserved, 0K cma-reserved)
Virtual kernel memory layout:
 vector  : 0x4000 - 0x4400   (   1 KiB)
 kmap: 0x - 0x   (4095 MiB)
 vmalloc : 0x - 0x   (4095 MiB)
 lowmem  : 0x4000 - 0x4200   (  32 MiB)
   .init : 0x40276000 - 0x40288000   (  72 KiB)
   .text : 0x4002 - 0x40206490   (1946 KiB)
   .data : 0x40206490 - 0x40275e00   ( 447 KiB)
   .bss  : 0x40288000 - 0x4029bc20   (  80 KiB)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS:256
Console: colour dummy device 80x25
Calibrating delay loop... 159.12 BogoMIPS (lpj=795648)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
NET: Registered protocol family 16
Switched to clocksource tmr
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 0, 8192 bytes)
TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 512 (order: 0, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
NET: Registered protocol family 1
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
io scheduler noop registered (default)
Initing M532x Framebuffer
Console: switching to colour frame buffer device 100x37
fb0: M532x FB frame buffer device @0x41a0
ColdFire internal UART serial driver
mcfuart.0: ttyS0 at MMIO 0xfc06 (irq = 90, base_baud = 500) is a
ColdFire UART
console [ttyS0] enabled
mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 500) is a
ColdFire UART
mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 500) is a
ColdFire UART
brd: module loaded
loop: module loaded
nbd: registered device at major 43
uclinux[mtd]: probe address=0x4029bc20 size=0x16e000
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on "ram":
0x-0x0016e000 : "ROMfs"
-------


On Wednesday, December 2, 2015 4:06 PM,

Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808)

[Greg Ungerer]

Hi Ted,

On 02/12/15 06:56, Ted Victorio wrote:

I am unable to compile for the M5329 NAND using the configuration below.

Distro:uClinux-dist-20150808
Tool:   m68k-uclinux-tools-20101118
Platform:   Freescale MCF5329EVB

# Linux/m68k 4.0.0-uc0 Kernel Configuration

[snip]


Errors:
drivers/mtd/nand/m5329.c: In function 5329_init:
drivers/mtd/nand/m5329.c:85:2: error: lvalue required as left operand of
assignment
drivers/mtd/nand/m5329.c:90:4: error: lvalue required as left operand of
assignment
drivers/mtd/nand/m5329.c:92:4: error: lvalue required as left operand of
assignment
drivers/mtd/nand/m5329.c:131:2: error: implicit declaration of function
add_mtd_partitions

Do I need additional options? Or something else?


The definitions for register addresses were sanitized for Coldfire
hardware a few kernel revisions back. They are now all register
addresses (or offsets) - not access macros as some were.

You will need the patch below to fix this driver (compile tested
only). The include of mtdcore is a little ugly, but it should get
you going for now.

Regards
Greg



--- linux/drivers/mtd/nand/m5329.c.org  2015-12-03 00:19:18.324085936 +1000
+++ linux/drivers/mtd/nand/m5329.c  2015-12-03 00:27:49.644082361 +1000
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "../mtdcore.h"

 /*
  * MTD structure for M5329EVB board
@@ -82,14 +83,14 @@
struct nand_chip *this;

/* Setup NAND flash chip select signals */
-   MCF_FBCS2_CSAR = NAND_FLASH_ADDRESS;
-   MCF_FBCS2_CSCR = (MCF_FBCS_CSCR_PS_8
-   | MCF_FBCS_CSCR_BEM
-   | MCF_FBCS_CSCR_AA
-   | MCF_FBCS_CSCR_SBM
-   | MCF_FBCS_CSCR_WS(7));
-   MCF_FBCS2_CSMR = (MCF_FBCS_CSMR_BAM_16M
-   | MCF_FBCS_CSMR_V);
+   writel(NAND_FLASH_ADDRESS, MCF_FBCS2_CSAR);
+   writel(MCF_FBCS_CSCR_PS_8
+   | MCF_FBCS_CSCR_BEM
+   | MCF_FBCS_CSCR_AA
+   | MCF_FBCS_CSCR_SBM
+   | MCF_FBCS_CSCR_WS(7),
+   MCF_FBCS2_CSCR);
+   writel(MCF_FBCS_CSMR_BAM_16M | MCF_FBCS_CSMR_V, MCF_FBCS2_CSMR);

/* Allocate memory for MTD device structure and private data */
m5329_mtd = kmalloc (sizeof(struct mtd_info)+sizeof (struct nand_chip),


___
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

Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808)

[Greg Ungerer]

Hi Cristobal,

On 03/12/15 01:13, Cristobal Chaves wrote:
> First of all you have to compile the drivers if you wanna add the drivers, 
> then you have to modify the kconfig file adding the names of the divers files 
> *.o and *.c. Once you have added the files to the configure file you can 
> patch the kernel and finally add the drivers configuring the kernel 
> graphically or manually. Just follow the steps of bellow:

This really makes no sense. And it seems unnecessary given the
original poster was clearly already compiling the driver in
the kernel tree. The m5329.c driver source in that tree is
broken - the compile error messages give that.

You don't add *.c or *.o names into a Kconfig. They would only
ever go into a Makefile.

Regards
Greg

 

> 1) Compile drivers
> 2) Add names of files *.o and *.c to the respective KCONFIG
> 3) Patch Kernel using Diff tool
> 4) Compile Kernel
> 5) Add drivers to the configuration of custom kernel
> 6) Compile Kernel 
> 7) Done, you have your custom kernel with new drivers added.  
> 
> BR,
> 
> Cristobal  
> 
>> To: uclinux-dev@uclinux.org
>> From: g...@uclinux.org
>> Date: Thu, 3 Dec 2015 00:33:30 +1000
>> Subject: Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB 
>> (uClinux-dist-20150808)
>>
>> Hi Ted,
>>
>> On 02/12/15 06:56, Ted Victorio wrote:
>> > I am unable to compile for the M5329 NAND using the configuration below.
>> >
>> > Distro: uClinux-dist-20150808
>> > Tool: m68k-uclinux-tools-20101118
>> > Platform: Freescale MCF5329EVB
>> >
>> > # Linux/m68k 4.0.0-uc0 Kernel Configuration
>> [snip]
>> >
>> > Errors:
>> > drivers/mtd/nand/m5329.c: In function 5329_init:
>> > drivers/mtd/nand/m5329.c:85:2: error: lvalue required as left operand of
>> > assignment
>> > drivers/mtd/nand/m5329.c:90:4: error: lvalue required as left operand of
>> > assignment
>> > drivers/mtd/nand/m5329.c:92:4: error: lvalue required as left operand of
>> > assignment
>> > drivers/mtd/nand/m5329.c:131:2: error: implicit declaration of function
>> > add_mtd_partitions
>> >
>> > Do I need additional options? Or something else?
>>
>> The definitions for register addresses were sanitized for Coldfire
>> hardware a few kernel revisions back. They are now all register
>> addresses (or offsets) - not access macros as some were.
>>
>> You will need the patch below to fix this driver (compile tested
>> only). The include of mtdcore is a little ugly, but it should get
>> you going for now.
>>
>> Regards
>> Greg
>>
>>
>>
>> --- linux/drivers/mtd/nand/m5329.c.org 2015-12-03 00:19:18.324085936 +1000
>> +++ linux/drivers/mtd/nand/m5329.c 2015-12-03 00:27:49.644082361 +1000
>> @@ -27,6 +27,7 @@
>> #include 
>> #include 
>> #include 
>> +#include "../mtdcore.h"
>>
>> /*
>> * MTD structure for M5329EVB board
>> @@ -82,14 +83,14 @@
>> struct nand_chip *this;
>>
>> /* Setup NAND flash chip select signals */
>> - MCF_FBCS2_CSAR = NAND_FLASH_ADDRESS;
>> - MCF_FBCS2_CSCR = (MCF_FBCS_CSCR_PS_8
>> - | MCF_FBCS_CSCR_BEM
>> - | MCF_FBCS_CSCR_AA
>> - | MCF_FBCS_CSCR_SBM
>> - | MCF_FBCS_CSCR_WS(7));
>> - MCF_FBCS2_CSMR = (MCF_FBCS_CSMR_BAM_16M
>> - | MCF_FBCS_CSMR_V);
>> + writel(NAND_FLASH_ADDRESS, MCF_FBCS2_CSAR);
>> + writel(MCF_FBCS_CSCR_PS_8
>> + | MCF_FBCS_CSCR_BEM
>> + | MCF_FBCS_CSCR_AA
>> + | MCF_FBCS_CSCR_SBM
>> + | MCF_FBCS_CSCR_WS(7),
>> + MCF_FBCS2_CSCR);
>> + writel(MCF_FBCS_CSMR_BAM_16M | MCF_FBCS_CSMR_V, MCF_FBCS2_CSMR);
>>
>> /* Allocate memory for MTD device structure and private data */
>> m5329_mtd = kmalloc (sizeof(struct mtd_info)+sizeof (struct nand_chip),
>>
>>
>> ___
>> 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
> 
> 
> ___
> 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
> 

___
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

Re: [uClinux-dev] FetchTV and UCLinux

[Greg Ungerer]

On 03/11/15 01:22, Wicks, George wrote:
> Joshua:
> 
> Your best bet is to take a look at the source - go to the FetchTV page:
> 
> http://www.fetchtv.com.au/opensource
> 
> The page states:
> 
> The FetchTV set top box comprises software code developed by third parties, 
> including software code subject to the GNU General Public License "GPL" and 
> GNU Lesser General Public License "LGPL". The terms of the GPL and LGPL, as 
> well as any additional or/and modified open source packages used by 
> Yuxing/Hybroad to build the FetchTV set top box software, are listed below:
> 
> 
> Firmware Version 2.0.1278 or later:
> stblinux-2.6.18-7.1.tar.bz2
> LGPL.tar.gz
> uclinux-rootfs-2.6.18-7.1.tar.bz2
> xfsprogs-3.0.2.tar.gz
> 
> Hope this helps...

For whatever it is worth the uclinux-rootfs-2.6.18-7.1.tar.bz2
is a highly modified repackaging of a uclinux-dist source package
(http://www.uclinux.org/pub/uClinux/dist/). No idea what version
that it forked of from though.

Regards
Greg




> -Original Message-
> From: uclinux-dev-boun...@uclinux.org 
> [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Joshua Stokes
> Sent: Monday, November 02, 2015 1:12 AM
> To: uclinux-dev@uclinux.org
> Subject: [uClinux-dev] FetchTV and UCLinux
> 
> Hi UCLinux
> 
> Apparently FetchTV uses your software and I was wondering how the open 
> resources (software code), can be used, as I'm fascinated in the advanced 
> coding that happens behind the scenes with operating systems. I would really 
> like to learn how FetchTV uses IPTV and Internet protocols.
> 
> Could you please help me in learning more about this?
> 
> Thanks
> 
>>From Joshua P Stokes
> ___
> 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
> 
> NOTICE OF CONFIDENTIALITY:
> This message may contain information that is considered confidential and 
> which may be prohibited from disclosure under applicable law or by 
> contractual agreement. The information is intended solely for the use of the 
> individual or entity named above. If you are not the intended recipient, you 
> are hereby notified that any disclosure, copying, distribution or use of the 
> information contained in or attached to this message is strictly prohibited. 
> If you have received this email transmission in error, please notify the 
> sender by replying to this email and then delete it from your system.
> ___
> 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
> 

___
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

Re: [uClinux-dev] m68k compile issue with 4.0.5

[Greg Ungerer]

Hi Waldemar,

On 17/06/15 15:42, Waldemar Brodkorb wrote:
 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?

Yes, on real M5208EVB hardware. That is what I ran it on.
I didn't run it under QEMU.


 I still need at least two patches.
 
 http://cgit.openadk.org/cgi/cgit/openadk.git/tree/target/m68k/qemu-m68k/patches/4.0.5/qemu-coldfire.patch
 Without this one I get black screen.

Better to use the fixes to QEMU instead of working around
its problems in the linux kernel sources :-)

This thread has the QEMU fixes:

https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg03224.html

I have posted them a couple of times to the QEMU dev list, but
no-one seems to pick them up.


 http://cgit.openadk.org/cgi/cgit/openadk.git/tree/target/m68k/qemu-m68k/patches/4.0.5/m68k-coldfire-fec.patch
 Without this one I get 
 qemu: hardware error: mcf_fec_read: Bad address 0x1c4
 ...
 Abort

Yes, you still need that. I haven't cleaned that up into a
state that I am totally happy with yet.


 Networking still does not work for me after booting with the two
 patches applied:
 fec fec.0 (unnamed net_device) (uninitialized): MDIO read timeout
 fec: probe of fec.0 failed with error -5
 
 Any idea?

Hmm, no, haven't seen that one. I'll try a run with qemu and see
if I can see what is going on.

Regards
Greg



___
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

Re: [uClinux-dev] m68k compile issue with 4.0.5

[Greg Ungerer]

Hi Waldemar,

On 16/06/15 16:24, 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.

 With 4.0.4 everything is fine. With 4.0.5 I get following compile
 error:
   adk-uclinux-gcc -Wp,-MD,mm/.nommu.o.d  -nostdinc -isystem
 /home/wbx/m68k/toolchain_qemu-m68k_uclibc-ng_m68k_nommu/usr/lib/gcc/m68k-openadk-uclinux-uclibc/4.9.2/include
 -I./arch/m68k/include -Iarch/m68k/include/generated/uapi
 -Iarch/m68k/include/generated  -Iinclude -I./arch/m68k/include/uapi
 -Iarch/m68k/include/generated/uapi -I./include/uapi
 -Iinclude/generated/uapi -include ./include/linux/kconfig.h
 -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
 -fno-strict-aliasing -fno-common
 -Werror-implicit-function-declaration -Wno-format-security
 -std=gnu89 -mcpu=5208 -pipe -DUTS_SYSNAME=\uClinux\ -D__uClinux__
 -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized
 --param=allow-store-data-races=0 -Wframe-larger-than=1024
 -fno-stack-protector -Wno-unused-but-set-variable
 -fomit-frame-pointer -fno-var-tracking-assignments
 -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
 -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
 -Werror=date-time -DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s
 -DKBUILD_BASENAME=KBUILD_STR(nommu)
 -DKBUILD_MODNAME=KBUILD_STR(nommu) -c -o mm/nommu.o mm/nommu.c
 mm/nommu.c: In function 'delete_vma':
 mm/nommu.c:861:3: error: implicit declaration of function 'vma_fput'
 [-Werror=implicit-function-declaration]
vma_fput(vma);
^
 cc1: some warnings being treated as errors

 Any idea what change breaks the compile?
 
 I tried a few m68knommu defconfigs, but can't reproduce it.
 
 Is this a plain v4.0.5? I can't find the offending call to vma_fput().
 git grep vma_fput tells me there's no vma_fput in the kernel sources?

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?

Regards
Greg


 Gr{oetje,eeting}s,
 
 Geert
 
 --
 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
 ge...@linux-m68k.org
 
 In personal conversations with technical people, I call myself a hacker. But
 when I'm talking to journalists I just say programmer or something like 
 that.
 -- Linus Torvalds
 ___
 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
 

___
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

Re: [uClinux-dev] [PATCH] m68knommu: fix fec setup warning for ColdFire 5271 builds

[Greg Ungerer]

On 26/03/15 18:27, Andreas Schwab wrote:

g...@uclinux.org writes:


Fix it my moving the definition of par inside the 5271 conditional code.

s/my/by/


Thanks Andreas, I'll fix that up.

Regards
Greg


___
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

Re: [uClinux-dev] arch/m68k/platform/coldfire/M527x.c : m527x_fec_init

[Greg Ungerer]

Hi Ertheb,

On 24/03/15 04:18, ertheb wrote:
 Hi,
 
 Very tiny change to avoid one warning with MCF5271. :-)

Thanks. I'll create a patch for that too.

Regards
Greg


 static void __init m527x_fec_init(void)
 {
 -u16 par;
 u8 v;
 
 /* Set multi-function pins to ethernet mode for fec0 */
 #if defined(CONFIG_M5271)
 v = readb(MCFGPIO_PAR_FECI2C);
 writeb(v | 0xf0, MCFGPIO_PAR_FECI2C);
 #else
 +u16 par;
 par = readw(MCFGPIO_PAR_FECI2C);
 writew(par | 0xf00, MCFGPIO_PAR_FECI2C);
 v = readb(MCFGPIO_PAR_FEC0HL);
 writeb(v | 0xc0, MCFGPIO_PAR_FEC0HL);
 
 /* Set multi-function pins to ethernet mode for fec1 */
 par = readw(MCFGPIO_PAR_FECI2C);
 writew(par | 0xa0, MCFGPIO_PAR_FECI2C);
 v = readb(MCFGPIO_PAR_FEC1HL);
 writeb(v | 0xc0, MCFGPIO_PAR_FEC1HL);
 #endif
 }
 
 ertheb.
 ___
 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
 

___
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

Re: [uClinux-dev] kernel 3.10 + ColdFire MCF5271

[Greg Ungerer]

Hi Ertheb,

On 18/03/15 03:16, ertheb wrote:
 Hi all,
 
 I use uClinux since 2008 on a board compatible with the Freescale M5271EVB.
 
 I have successfully used kernel 2.4, 2.6, 3.1 and 3.3 with the default
 Freescale M5271EVB configuration.
 
 Recently, i have tried to use uClinux-dist-20140504 with kernel 3.10.
 Compilation is o.k but a crash occurs at the kernel boot (see below).
 
 I have applied the kernel patch 3.10.0 to 3.10.68 (2015-02-06) without
 success.
 
 PC register address is located inside fec_probe function, i think crash
 occurs when kernel try to probe a second FEC module.
 (MCF5271 has only one fec module).
 
 I made this modification and now kernel boot correctly.
 
 uClinux-dist/linux-3.x/arch/m68k/include/asm/m527xsim.h
 
 /*
  *FEC ethernet module.
  */
  #defineMCFFEC_BASE0(MCF_IPSBAR + 0x1000)
  #defineMCFFEC_SIZE00x800
 
 +#ifdef CONFIG_M5275
  #defineMCFFEC_BASE1(MCF_IPSBAR + 0x1800)
  #defineMCFFEC_SIZE10x800
 +#endif

Yes, that is broken. That looks to be the right place to fix it here too.
I'll generate a fix for mainline.

The next uclinux-dist will be based around a linux-3.18 kernel, and
I will fix it in there too.

Thanks
Greg




 Linux version 3.10.0-uc0 (root@debian-st8) (gcc version 4.2.4) #15 Tue
 Feb 10 09:38:33 CET 2015
 
 
 uClinux/COLDFIRE(m527x)
 COLDFIRE port done by Greg Ungerer, g...@snapgear.com
 Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
 Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 2040
 Kernel command line: console=ttyS1,19200
 PID hash table entries: 2048 (order: 0, 8192 bytes)
 Dentry cache hash table entries: 2048 (order: 0, 8192 bytes)
 Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
 Sorting __ex_table...
 Memory: 13448k/13448k available (1408k kernel code, 1464k data, 64k init)
 Virtual kernel memory layout:
 vector  : 0x - 0x0400   (   1 KiB)
 kmap: 0x - 0x   (4095 MiB)
 vmalloc : 0x - 0x   (4095 MiB)
 lowmem  : 0x - 0x0100   (  16 MiB)
   .init : 0x001c - 0x001d   (  64 KiB)
   .text : 0x0002 - 0x0017f8b0   (1407 KiB)
   .data : 0x0017f8b0 - 0x001bffc0   ( 258 KiB)
   .bss  : 0x001d - 0x001dd238   (  53 KiB)
 SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
 NR_IRQS:256
 Calibrating delay loop... 64.71 BogoMIPS (lpj=323584)
 pid_max: default: 32768 minimum: 301
 Mount-cache hash table entries: 1024
 NET: Registered protocol family 16
 bio: create slab bio-0 at 0
 pps_core: LinuxPPS API ver. 1 registered
 pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
 giome...@linux.it
 PTP clock support registered
 Switching to clocksource pit
 NET: Registered protocol family 2
 TCP established hash table entries: 1024 (order: 0, 8192 bytes)
 TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
 TCP: Hash tables configured (established 1024 bind 2048)
 TCP: reno registered
 UDP hash table entries: 512 (order: 0, 8192 bytes)
 UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
 NET: Registered protocol family 1
 ROMFS MTD (C) 2007 Red Hat, Inc.
 io scheduler noop registered (default)
 ColdFire internal UART serial driver
 ttyS0 at MMIO 0x4200 (irq = 77) is a ColdFire UART
 ttyS1 at MMIO 0x4240 (irq = 78) is a ColdFire UART
 console [ttyS1] enabled
 ttyS2 at MMIO 0x4280 (irq = 79) is a ColdFire UART
 brd: module loaded
 uclinux[mtd]: probe address=0x1dd238 size=0xda000
 uclinux[mtd]: set ROMfs to be root filesystem
 Creating 1 MTD partitions on ram:
 0x-0x000da000 : ROMfs
 libphy: fec_enet_mii_bus: probed
 bad frame format: 
 PC: [000fcbe0] 0x0fcbe0
 SR: 2004  SP: 0084be3c  a2: 001d9394
 d0: 00954000d1: d2: 001aee36d3: 00954000
 d4: 001bb77ad5: a0: 400018e4a1: 0084be96
 Process swapper (pid: 1, task=0084c000)
 Frame format=4 eff addr=001aee68 pc=0084bef0
 Stack from 0084be78:
   001aee36 001aee36 001bb73c 0003bb34 001cd5d4
 001aee68
 001aee36 000eebac 001aee2c 000ed938 001aee36 001aee68 0017e20a
 001aee36
 000edd74 001bb73c 001aee36  000ec0a0 000edd00 001bb73c
 000ec3a6
 001aee36 001bb73c 0007 001c 00942420 001badcc 0083eacc
 0086eed0
 000ed744 001badcc  001bb73c 000edd00 000ecf0c 001bb73c
 0007
 001c  001cf908 001bb73c 001c0096 0003bb34 001cd5d4
 000ee036
 Call Trace:
 [0003bb34] 0x03bb34
  [000eebac] 0x0eebac
  [000ed938] 0x0ed938
  [0017e20a] 0x17e20a
  [000edd74] 0x0edd74
 
 [000ec0a0] 0x0ec0a0
  [000edd00] 0x0edd00
  [000ec3a6] 0x0ec3a6
  [000ed744] 0x0ed744
  [000edd00] 0x0edd00
 
 [000ecf0c] 0x0ecf0c
  [001c0096] 0x1c0096
  [0003bb34] 0x03bb34
  [000ee036] 0x0ee036
  [001c9c70] 0x1c9c70
 
 [001c0096] 0x1c0096
  [0003bb34] 0x03bb34
  [000eecfe] 0x0eecfe
  [001c9c7c] 0x1c9c7c
  [001c01a6

Re: [uClinux-dev] [PATCH] m68k: Add missing ioport_unmap()

[Greg Ungerer]

Hi Geert,

On 15/09/14 17:36, Geert Uytterhoeven wrote:
 On Mon, Sep 15, 2014 at 3:07 AM, Greg Ungerer g...@uclinux.org wrote:
 On 14/09/14 19:45, Geert Uytterhoeven wrote:
 drivers/net/ethernet/cirrus/cs89x0.c: In function ‘cs89x0_ioport_probe’:
 drivers/net/ethernet/cirrus/cs89x0.c:1629: error: implicit declaration of 
 function ‘ioport_unmap’

 Add the missing ioport_unmap() implementation, and convert ioport_map()
 from a macro to a static inline function while we're at it (both copied
 from asm-generic).

 The non-mmu version of this, io_no.h, doesn't implement these either.
 Should it?
 
 I think it should. However, you probably can't get there without PCI or ISA
 enabled.
 
 (doing some experiments with M548x/allmodconfig builds)
 
 Currently PCI on M54xx is limited to MMU=y?

Yes, though I am not sure why we have it limited to that case.


 As soon as PCI can be enabled with MMU=n, you can get to:
 
 lib/pci_iomap.c: In function ‘pci_iomap’:
 lib/pci_iomap.c:37: error: implicit declaration of function ‘ioport_map’
 lib/pci_iomap.c:37: warning: return makes pointer from integer without a cast
 
 drivers/gpio/gpio-amd8111.c: In function ‘amd_gpio_init’:
 drivers/gpio/gpio-amd8111.c:215: error: implicit declaration of
 function ‘ioport_map’
 drivers/gpio/gpio-amd8111.c:215: warning: assignment makes pointer
 from integer without a cast
 drivers/gpio/gpio-amd8111.c: In function ‘amd_gpio_exit’:
 drivers/gpio/gpio-amd8111.c:236: error: implicit declaration of
 function ‘ioport_unmap’

Ok, I say yes we need it for non-MMU too. Do you want to come up with
another patch for the non-MMU case, or do you want me to do it?

Regards
Greg




___
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

Re: [uClinux-dev] [PATCH] m68k: Add missing ioport_unmap()

[Greg Ungerer]

Hi Geert,

On 14/09/14 19:45, Geert Uytterhoeven wrote:
 drivers/net/ethernet/cirrus/cs89x0.c: In function ‘cs89x0_ioport_probe’:
 drivers/net/ethernet/cirrus/cs89x0.c:1629: error: implicit declaration of 
 function ‘ioport_unmap’
 
 Add the missing ioport_unmap() implementation, and convert ioport_map()
 from a macro to a static inline function while we're at it (both copied
 from asm-generic).

The non-mmu version of this, io_no.h, doesn't implement these either.
Should it?

Regards
Greg


 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
 ---
  arch/m68k/include/asm/io_mm.h | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
 index ffdf54f44bc6..8955b40a5dc4 100644
 --- a/arch/m68k/include/asm/io_mm.h
 +++ b/arch/m68k/include/asm/io_mm.h
 @@ -510,6 +510,13 @@ static inline void memcpy_toio(volatile void __iomem 
 *dst, const void *src, int
   */
  #define xlate_dev_kmem_ptr(p)p
  
 -#define ioport_map(port, nr) ((void __iomem *)(port))
 +static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 +{
 + return (void __iomem *) port;
 +}
 +
 +static inline void ioport_unmap(void __iomem *p)
 +{
 +}
  
  #endif /* _IO_H */
 

___
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

Re: [uClinux-dev] Make errors while building snapgear-4.0.0.7

[Greg Ungerer]

Hi 

On 01/09/14 22:51, GravyFace wrote:
 I'm using gcc version 4.6.3

Hmmm. In your boot trace your kernel is reporting a gcc-3.4.4 compiler:

 Linux version 2.6.26-uc0 (root@test-ubu01) (gcc version 3.4.4) #13 Tue Aug 
 26 12:14:17 EDT 2014

Regards
Greg



 Oddly, now I can't build with kernel config I have: threw two separate 
 errors, one was a complaint of line X in the dhclient configuration, lastly 
 was a lex error of some nondescript reasoning.  I tried again with make 
 clean, no dice, so clearly fingers of the rotund persuasion are wreaking 
 havoc in the kernel config.  I blew away my snapgear directory, extracting 
 tarball, trying again from scratch now.
 
 
 On Mon, Sep 1, 2014 at 1:05 AM, Greg Ungerer g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 
 Hi,
 
 On 31/08/14 13:49, GravyFace wrote:
  Update: I was able to (I think) sort out the kernel config by using 
 make menuconfig and with the help of search (/), find the parameters 
 suggested, change them, and re-build the image.  Unfortunately it seems as 
 though these kernel config options aren't correct: it just hangs after using 
 base address
 
 Can you post your modified kernel config here?
 
 I took the 4.0.7 source, modified kernel config to enable those
 settings, and that network loads, boots and runs for me on a SG560.
 
 I am using a new compiler version, not sure if that might be an issue.
 (I am using a gcc-4.2.1 toolchain).
 
 Regards
 Greg
 
 
 
  Recovery Bootloader
  (C) Copyright 1999-2006, Secure Computing Inc (www.securecomputing.com 
 http://www.securecomputing.com http://www.securecomputing.com)
  SecureComputing/SG560 Version 3.1.5u1
  'n'etwork, 'f'lash, 's'erial [n] :
  Timeout, initiating network
  Decompressing etherboot
  +Getting DHCP address... .
Ethernet eth0: MAC address 00:d0:cf:0b:b9:34
  IP: 192.168.0.101/255.255.255.0 http://192.168.0.101/255.255.255.0 
 http://192.168.0.101/255.255.255.0, Gateway: 192.168.0.1
  Default server: 192.168.0.254, DNS server IP: 0.0.0.0
 
  RedBoot(tm) bootstrap and debug environment [RAM]
  Red Hat certified release, version 1.94 - built 16:02:10, Nov  4 2005
 
  Platform: CyberGuard SG5XX family of VPN/Firewall/Routers (XScale) BE
  Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
 
  RAM: 0x-0x0100, 0x00060d48-0x00ff3000 available
  == Executing boot script in 1.000 seconds - enter ^C to abort
  RedBoot load -v -s 0x0020 -b 0x0080 image.bin
  Using default protocol (TFTP)
  |
  Raw file loaded 0x0020-0x002c65f8, assumed entry at 0x0020
  RedBoot exec -r 0x0080 -c console=ttyS0,115200 root=/dev/ram0 
 0x0020
  [Using ramdisk at 0x80-0xbcf000]
  Using base address 0x0020 and length 0x000c65fc
 
 
  Power light and the port lights are solid.
 
 
  On Sat, Aug 30, 2014 at 8:20 PM, GravyFace gravyf...@gmail.com 
 mailto:gravyf...@gmail.com mailto:gravyf...@gmail.com 
 mailto:gravyf...@gmail.com wrote:
 
  Hi Greg,
 
  Searched online for where to place those kernel config entries; 
 tried to add them to the symlink'ed config.arch in the root snapgear-4.0.7 
 directory but that made 'make' unhappy.
 
  Where should I be placing those config lines?  There's oodles of 
 files with similar CONFIG_ lines, so not sure where I should be putting it.
 
  Thanks
 
 
  On Fri, Aug 29, 2014 at 2:28 AM, Greg Ungerer g...@uclinux.org 
 mailto:g...@uclinux.org mailto:g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 
 
  Hi,
 
  On 29/08/14 00:09, GravyFace wrote:
   Sure, here you go:
  
   Recovery Bootloader
   (C) Copyright 1999-2006, Secure Computing Inc 
 (www.securecomputing.com http://www.securecomputing.com 
 http://www.securecomputing.com http://www.securecomputing.com)
   SecureComputing/SG560 Version 3.1.5u1
   'n'etwork, 'f'lash, 's'erial [n] :
   Recovery Bootloader
   (C) Copyright 1999-2006, Secure Computing Inc 
 (www.securecomputing.com http://www.securecomputing.com 
 http://www.securecomputing.com http://www.securecomputing.com)
   SecureComputing/SG560 Version 3.1.5u1
   'n'etwork, 'f'lash, 's'erial [n] :
   Timeout, initiating network
   Decompressing etherboot
   +Getting DHCP address... .
 Ethernet eth0: MAC address 
 00:d0:cf:0b:b9:34
   IP: 192.168.0.101/255.255.255.0 
 http://192.168.0.101/255.255.255.0 http://192.168.0.101/255.255.255.0 
 http://192.168.0.101/255.255.255.0, Gateway: 192.168.0.1
   Default server: 192.168.0.254, DNS server IP: 0.0.0.0
  
   RedBoot(tm

Re: [uClinux-dev] Make errors while building snapgear-4.0.0.7

[Greg Ungerer]

 CONFIG_USER_BUSYBOX_FREE=y
 CONFIG_USER_BUSYBOX_KILL=y
 CONFIG_USER_BUSYBOX_PS=y
 CONFIG_USER_BUSYBOX_UPTIME=y
 CONFIG_USER_BUSYBOX_FEATURE_SH_IS_ASH=y
 CONFIG_USER_BUSYBOX_ASH=y
 CONFIG_USER_BUSYBOX_ASH_OPTIMIZE_FOR_SIZE=y
 CONFIG_USER_BUSYBOX_SYSLOGD=y
 CONFIG_USER_BUSYBOX_FEATURE_ROTATE_LOGFILE=y
 CONFIG_USER_BUSYBOX_FEATURE_REMOTE_LOG=y
 CONFIG_USER_BUSYBOX_KLOGD=y
 CONFIG_USER_RAMIMAGE_NONE=y
 CONFIG_POOR_ENTROPY=y
 
 
 
 
 On Mon, Sep 1, 2014 at 8:51 AM, GravyFace gravyf...@gmail.com 
 mailto:gravyf...@gmail.com wrote:
 
 Hi,
 
 I'm using gcc version 4.6.3
 
 Oddly, now I can't build with kernel config I have: threw two 
 separate errors, one was a complaint of line X in the dhclient configuration, 
 lastly was a lex error of some nondescript reasoning.  I tried again with 
 make clean, no dice, so clearly fingers of the rotund persuasion are wreaking 
 havoc in the kernel config.  I blew away my snapgear directory, extracting 
 tarball, trying again from scratch now.
 
 
 On Mon, Sep 1, 2014 at 1:05 AM, Greg Ungerer g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 
 Hi,
 
 On 31/08/14 13:49, GravyFace wrote:
  Update: I was able to (I think) sort out the kernel config by 
 using make menuconfig and with the help of search (/), find the parameters 
 suggested, change them, and re-build the image.  Unfortunately it seems as 
 though these kernel config options aren't correct: it just hangs after using 
 base address
 
 Can you post your modified kernel config here?
 
 I took the 4.0.7 source, modified kernel config to enable those
 settings, and that network loads, boots and runs for me on a 
 SG560.
 
 I am using a new compiler version, not sure if that might be an 
 issue.
 (I am using a gcc-4.2.1 toolchain).
 
 Regards
 Greg
 
 
 
  Recovery Bootloader
  (C) Copyright 1999-2006, Secure Computing Inc 
 (www.securecomputing.com http://www.securecomputing.com 
 http://www.securecomputing.com)
  SecureComputing/SG560 Version 3.1.5u1
  'n'etwork, 'f'lash, 's'erial [n] :
  Timeout, initiating network
  Decompressing etherboot
  +Getting DHCP address... .
Ethernet eth0: MAC address 
 00:d0:cf:0b:b9:34
  IP: 192.168.0.101/255.255.255.0 
 http://192.168.0.101/255.255.255.0 http://192.168.0.101/255.255.255.0, 
 Gateway: 192.168.0.1
  Default server: 192.168.0.254, DNS server IP: 0.0.0.0
 
  RedBoot(tm) bootstrap and debug environment [RAM]
  Red Hat certified release, version 1.94 - built 16:02:10, Nov  
 4 2005
 
  Platform: CyberGuard SG5XX family of VPN/Firewall/Routers 
 (XScale) BE
  Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
 
  RAM: 0x-0x0100, 0x00060d48-0x00ff3000 available
  == Executing boot script in 1.000 seconds - enter ^C to abort
  RedBoot load -v -s 0x0020 -b 0x0080 image.bin
  Using default protocol (TFTP)
  |
  Raw file loaded 0x0020-0x002c65f8, assumed entry at 
 0x0020
  RedBoot exec -r 0x0080 -c console=ttyS0,115200 
 root=/dev/ram0 0x0020
  [Using ramdisk at 0x80-0xbcf000]
  Using base address 0x0020 and length 0x000c65fc
 
 
  Power light and the port lights are solid.
 
 
  On Sat, Aug 30, 2014 at 8:20 PM, GravyFace gravyf...@gmail.com 
 mailto:gravyf...@gmail.com mailto:gravyf...@gmail.com 
 mailto:gravyf...@gmail.com wrote:
 
  Hi Greg,
 
  Searched online for where to place those kernel config 
 entries; tried to add them to the symlink'ed config.arch in the root 
 snapgear-4.0.7 directory but that made 'make' unhappy.
 
  Where should I be placing those config lines?  There's 
 oodles of files with similar CONFIG_ lines, so not sure where I should be 
 putting it.
 
  Thanks
 
 
  On Fri, Aug 29, 2014 at 2:28 AM, Greg Ungerer 
 g...@uclinux.org mailto:g...@uclinux.org mailto:g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 
 
  Hi,
 
  On 29/08/14 00:09, GravyFace wrote:
   Sure, here you go:
  
   Recovery Bootloader
   (C) Copyright 1999-2006, Secure Computing Inc 
 (www.securecomputing.com http://www.securecomputing.com 
 http://www.securecomputing.com http://www.securecomputing.com

Re: [uClinux-dev] Make errors while building snapgear-4.0.0.7

[Greg Ungerer]

Hi,

On 31/08/14 13:49, GravyFace wrote:
 Update: I was able to (I think) sort out the kernel config by using make 
 menuconfig and with the help of search (/), find the parameters suggested, 
 change them, and re-build the image.  Unfortunately it seems as though these 
 kernel config options aren't correct: it just hangs after using base 
 address

Can you post your modified kernel config here?

I took the 4.0.7 source, modified kernel config to enable those
settings, and that network loads, boots and runs for me on a SG560.

I am using a new compiler version, not sure if that might be an issue.
(I am using a gcc-4.2.1 toolchain).

Regards
Greg



 Recovery Bootloader
 (C) Copyright 1999-2006, Secure Computing Inc (www.securecomputing.com 
 http://www.securecomputing.com)
 SecureComputing/SG560 Version 3.1.5u1
 'n'etwork, 'f'lash, 's'erial [n] :
 Timeout, initiating network
 Decompressing etherboot
 +Getting DHCP address... .
   Ethernet eth0: MAC address 00:d0:cf:0b:b9:34
 IP: 192.168.0.101/255.255.255.0 http://192.168.0.101/255.255.255.0, 
 Gateway: 192.168.0.1
 Default server: 192.168.0.254, DNS server IP: 0.0.0.0
 
 RedBoot(tm) bootstrap and debug environment [RAM]
 Red Hat certified release, version 1.94 - built 16:02:10, Nov  4 2005
 
 Platform: CyberGuard SG5XX family of VPN/Firewall/Routers (XScale) BE
 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
 
 RAM: 0x-0x0100, 0x00060d48-0x00ff3000 available
 == Executing boot script in 1.000 seconds - enter ^C to abort
 RedBoot load -v -s 0x0020 -b 0x0080 image.bin
 Using default protocol (TFTP)
 |
 Raw file loaded 0x0020-0x002c65f8, assumed entry at 0x0020
 RedBoot exec -r 0x0080 -c console=ttyS0,115200 root=/dev/ram0 
 0x0020
 [Using ramdisk at 0x80-0xbcf000]
 Using base address 0x0020 and length 0x000c65fc
 
 
 Power light and the port lights are solid.  
 
 
 On Sat, Aug 30, 2014 at 8:20 PM, GravyFace gravyf...@gmail.com 
 mailto:gravyf...@gmail.com wrote:
 
 Hi Greg,
 
 Searched online for where to place those kernel config entries; tried to 
 add them to the symlink'ed config.arch in the root snapgear-4.0.7 directory 
 but that made 'make' unhappy.
 
 Where should I be placing those config lines?  There's oodles of files 
 with similar CONFIG_ lines, so not sure where I should be putting it.
 
 Thanks
 
 
 On Fri, Aug 29, 2014 at 2:28 AM, Greg Ungerer g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 
 
 Hi,
 
 On 29/08/14 00:09, GravyFace wrote:
  Sure, here you go:
 
  Recovery Bootloader
  (C) Copyright 1999-2006, Secure Computing Inc 
 (www.securecomputing.com http://www.securecomputing.com 
 http://www.securecomputing.com)
  SecureComputing/SG560 Version 3.1.5u1
  'n'etwork, 'f'lash, 's'erial [n] :
  Recovery Bootloader
  (C) Copyright 1999-2006, Secure Computing Inc 
 (www.securecomputing.com http://www.securecomputing.com 
 http://www.securecomputing.com)
  SecureComputing/SG560 Version 3.1.5u1
  'n'etwork, 'f'lash, 's'erial [n] :
  Timeout, initiating network
  Decompressing etherboot
  +Getting DHCP address... .
Ethernet eth0: MAC address 
 00:d0:cf:0b:b9:34
  IP: 192.168.0.101/255.255.255.0 
 http://192.168.0.101/255.255.255.0 http://192.168.0.101/255.255.255.0, 
 Gateway: 192.168.0.1
  Default server: 192.168.0.254, DNS server IP: 0.0.0.0
 
  RedBoot(tm) bootstrap and debug environment [RAM]
  Red Hat certified release, version 1.94 - built 16:02:10, Nov  4 
 2005
 
  Platform: CyberGuard SG5XX family of VPN/Firewall/Routers (XScale) 
 BE
  Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
 
  RAM: 0x-0x0100, 0x00060d48-0x00ff3000 available
  == Executing boot script in 1.000 seconds - enter ^C to abort
  RedBoot load -v -s 0x0020 -b 0x0080 image.bin
  Using default protocol (TFTP)
  |
  Raw file loaded 0x0020-0x002c4b8c, assumed entry at 0x0020
  RedBoot exec -r 0x0080 -c console=ttyS0,115200 
 root=/dev/ram0 0x0020
  [Using ramdisk at 0x80-0xbce000]
  Using base address 0x0020 and length 0x000c4b90
  Linux version 2.6.26-uc0 (root@test-ubu01) (gcc version 3.4.4) #13 
 Tue Aug 26 12:14:17 EDT 2014
  CPU: XScale-IXP42x Family [690541f2] revision 2 (ARMv5TE), 
 cr=39ff
  Machine: McAfee/SG560
  Memory policy: ECC disabled, Data cache writeback
  CPU0: D VIVT undefined 5 cache
  CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
  CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
  Built 1 zonelists in Zone order, mobility grouping off.  Total 
 pages: 4064
  Kernel command line

Re: [uClinux-dev] Make errors while building snapgear-4.0.0.7

[Greg Ungerer]

?)
 1f01512 mtdblock1 (driver?)
 1f02   7424 mtdblock2 (driver?)
 1f03   8192 mtdblock3 (driver?)
 1f04128 mtdblock4 (driver?)
 1f05128 mtdblock5 (driver?)
 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

I suspect you need these enabled:

   CONFIG_BLK_DEV_INITRD=y
   CONFIG_BLK_DEV_RAM=y
   CONFIG_BLK_DEV_RAM_COUNT=4
   CONFIG_BLK_DEV_RAM_SIZE=16384

Doesn't look like they are on from the output above.
Otherwise it looks ok.

Regards
Greg



 On Wed, Aug 27, 2014 at 8:02 PM, Greg Ungerer g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 
 On 27/08/14 23:09, GravyFace wrote:
 
 On Tue, Aug 26, 2014 at 8:44 PM, Greg Ungerer g...@uclinux.org 
 mailto:g...@uclinux.org mailto:g...@uclinux.org 
 mailto:g...@uclinux.org wrote:
 I'm assuming this was the last step,
 
 That is the last step. Easiest fix is to just create a /tftpboot
 directory that is world read/write. Doesn't really matter whether
 you actually have tftp server enabled or not.
 
 Yeah, I was able to figure that out and with the help of the SG 
 manual (amazing, those!) found out about the recovery process of holding 
 down ERASE and booting.  With Wireshark, I was able to see it pick up an IP 
 from tftpd's DHCP service and successfully download my image.bin.
 
 
 Maybe, maybe not. What are the front LEDs doing?
 If the heartbeat (HB) is flashing then it was probably successful.
 
 A serial port console is not enabled by default, so you won't get
 anything on the serial port without doing extra steps.
 
 Now that I have that out of my system, my next step is to 
 install tftpd and (I'm assuming) do a TFTP based install?  Don't see that 
 part on the snapgear.org http://snapgear.org http://snapgear.org 
 http://snapgear.org documentation on archive.org http://archive.org 
 http://archive.org http://archive.org, but maybe I'm missing something.
 
 
 SnapGear has been shutdown so I don't know they have on the web 
 anymore.
 But the tftp network load is pretty simple. To see what is going 
 on hook
 up the serial port at 115200,8,n,1. Then hold in the ERASE button 
 and
 plug in the power. It will come up with a simple boot loader 
 prompt.
 After a few seconds it will timeout and try a network load - 
 doing a
 dhcp address lookup and then trying a tftp load of a system image
 (that is the image.bin file that your compile generated).
 
 
 Well, getting a kernel panic; don't think it can find the flash 
 device...
 
 XScale DSP coprocessor detected.
 VFS: Cannot open root device ram0 or unknown-block(0,0)
 Please append a correct root= boot option; here are the available 
 partitions:
 1f00128 mtdblock0 (driver?)
 1f01512 mtdblock1 (driver?)
 1f02   7424 mtdblock2 (driver?)
 1f03   8192 mtdblock3 (driver?)
 1f04128 mtdblock4 (driver?)
 1f05128 mtdblock5 (driver?)
 Kernel panic - not syncing: VFS: Unable to mount root fs on 
 unknown-block(0,0)
 
 
 Can you send the complete boot log?
 
 
 There was a patch that I never applied as I wasn't sure what the 
 architecture was for these, but seeing this in the boot message (CPU: 
 XScale-IXP42x Family [690541f2] revision 2 (ARMv5TE), cr=39ff), it 
 jogged my memory of this, from the archive.org http://archive.org 
 http://archive.org's snapgear documentation page:
 
 
 Also available is a patch package that can be used to build the 
 Intel IXP4xx Access Library code as part of the SnapGear distribution. This 
 patch set contains support for the Intel CSR-1.4 with DSR-2.6.2 combination, 
 and the Intel CSR-2.4 library (on both 2.4 and 2.6 linux kernels).
 
 There's also this, but it appears as those RedBoot has already been 
 configured:
 
 https://gitorious.org/linux-__nios2/uclinux-dist/source/__5316285bb1b0a07bd2a2a562ec9397__af22dc465d:vendors/__SecureComputing/SG560/README
  
 https://gitorious.org/linux-nios2/uclinux-dist/source/5316285bb1b0a07bd2a2a562ec9397af22dc465d:vendors/SecureComputing/SG560/README
 
 
 Before Linux had in kernel drivers for the IXP4xx eth driver you
 had to use Intel's drivers for them. That SecureComputing/SG560
 config would have been configured with them in mind. I don't recall
 what kernel the Snapgear 4.0 source was based on, but you may be
 able to configure and use the kernels own ixp4xx eth drivers.
 
 You can ignore what that README says about redboot. It doesn't really
 apply to the SG560. (The network boot loading is done using a redboot,
 but it is a stripped down simple one - that just does the network
 loading. It doesn't deal with flash).
 
 Regards
 Greg
 
 
 I would

Re: [uClinux-dev] Make errors while building snapgear-4.0.0.7

[Greg Ungerer]

On 27/08/14 23:09, GravyFace wrote:

On Tue, Aug 26, 2014 at 8:44 PM, Greg Ungerer g...@uclinux.org 
mailto:g...@uclinux.org wrote:
I'm assuming this was the last step,

That is the last step. Easiest fix is to just create a /tftpboot
directory that is world read/write. Doesn't really matter whether
you actually have tftp server enabled or not.

Yeah, I was able to figure that out and with the help of the SG manual (amazing, those!) 
found out about the recovery process of holding down ERASE and booting.  With 
Wireshark, I was able to see it pick up an IP from tftpd's DHCP service and successfully 
download my image.bin.


Maybe, maybe not. What are the front LEDs doing?
If the heartbeat (HB) is flashing then it was probably successful.

A serial port console is not enabled by default, so you won't get
anything on the serial port without doing extra steps.

Now that I have that out of my system, my next step is to install tftpd and (I'm assuming) do a 
TFTP based install?  Don't see that part on the snapgear.org http://snapgear.org 
http://snapgear.org documentation on archive.org http://archive.org 
http://archive.org, but maybe I'm missing something.

SnapGear has been shutdown so I don't know they have on the web anymore.
But the tftp network load is pretty simple. To see what is going on hook
up the serial port at 115200,8,n,1. Then hold in the ERASE button and
plug in the power. It will come up with a simple boot loader prompt.
After a few seconds it will timeout and try a network load - doing a
dhcp address lookup and then trying a tftp load of a system image
(that is the image.bin file that your compile generated).


Well, getting a kernel panic; don't think it can find the flash device...

XScale DSP coprocessor detected.
VFS: Cannot open root device ram0 or unknown-block(0,0)
Please append a correct root= boot option; here are the available partitions:
1f00128 mtdblock0 (driver?)
1f01512 mtdblock1 (driver?)
1f02   7424 mtdblock2 (driver?)
1f03   8192 mtdblock3 (driver?)
1f04128 mtdblock4 (driver?)
1f05128 mtdblock5 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)


Can you send the complete boot log?



There was a patch that I never applied as I wasn't sure what the architecture was for these, 
but seeing this in the boot message (CPU: XScale-IXP42x Family [690541f2] revision 2 
(ARMv5TE), cr=39ff), it jogged my memory of this, from the archive.org 
http://archive.org's snapgear documentation page:

Also available is a patch package that can be used to build the Intel IXP4xx Access 
Library code as part of the SnapGear distribution. This patch set contains support for 
the Intel CSR-1.4 with DSR-2.6.2 combination, and the Intel CSR-2.4 library (on both 2.4 
and 2.6 linux kernels).

There's also this, but it appears as those RedBoot has already been configured:
https://gitorious.org/linux-nios2/uclinux-dist/source/5316285bb1b0a07bd2a2a562ec9397af22dc465d:vendors/SecureComputing/SG560/README


Before Linux had in kernel drivers for the IXP4xx eth driver you
had to use Intel's drivers for them. That SecureComputing/SG560
config would have been configured with them in mind. I don't recall
what kernel the Snapgear 4.0 source was based on, but you may be
able to configure and use the kernels own ixp4xx eth drivers.

You can ignore what that README says about redboot. It doesn't really
apply to the SG560. (The network boot loading is done using a redboot,
but it is a stripped down simple one - that just does the network
loading. It doesn't deal with flash).

Regards
Greg



I would suggest hard setting a command line in your kernel config so that
you have console=ttyS0,115200 set.

I think I saw an old post on how to do that; if I get past the kernel panic, 
this will be the first thing I do.

Regards
Greg



On Mon, Aug 25, 2014 at 9:40 AM, GravyFace gravyf...@gmail.com 
mailto:gravyf...@gmail.com mailto:gravyf...@gmail.com 
mailto:gravyf...@gmail.com wrote:

 Thanks, I'll give that a go now.


 On Mon, Aug 25, 2014 at 2:24 AM, Greg Ungerer g...@uclinux.org 
mailto:g...@uclinux.org mailto:g...@uclinux.org mailto:g...@uclinux.org 
wrote:

 Hi,


 On 24/08/14 03:26, gravyface wrote:

 Hi all,

 First time attempting to compile really anything in Linux (why 
not try this? g), and hitting a wall with a seemingly pam-auth related error.

 Build Environment:

 - Ubuntu Server 12.04.5 LTS with apt versions of binutils, build-essentials, gcc, 
gdb, curses (libncurses5-dev libncursesw5-dev).  I downloaded the arm-linux-tools-20061213.tar.gz 
https://web.archive.org/web/20100715203220/http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-20061213.tar.gz
 
https

Re: [uClinux-dev] qemu/m68k

[Greg Ungerer]

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://lists.busybox.net/pipermail/buildroot/2012-April/052585.html


No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.


Okay, it seems a problem with my uClibc version or configuration.
Still investigating. But using the sash from uClinux works fine
with my own kernel.


Ok, at least that gives you a working base to go from.



qemu: hardware error: mcf_fec_read: Bad address 0x1c4


Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.


Did you found anything?


Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.

I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.

Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.



BTW: Are Cisco devices not official supported by uClinux?
I recently had the luck to find an old Cisco 1000 Series router
with a M68360 Motorola CPU. I like to use it probably for some
runtime testing, if I can boot Linux on it.


I don't think anything is official in uClinux really :-)

There is some old and probably very crufty support for the 68360
in mainline. Not sure what platforms it was used on.

Regards
Greg



From 66b3d160150bee108c40e032214a2d93d782aff1 Mon Sep 17 00:00:00 2001
From: Greg Ungerer g...@uclinux.org
Date: Mon, 18 Aug 2014 16:47:43 +1000
Subject: [PATCH] net: fec: do not read/write undefined registers on ColdFire
 FEC

The Freescale FEC hardware module is used on many different SoC parts,
across at least 3 different CPU architectures. The FEC implementation on
the ColdFire family parts does not define the following registers:

  FEC_R_FIFO_RSFL
  FEC_R_FIFO_RSEM
  FEC_R_FIFO_RAEM
  FEC_R_FIFO_RAFL
  FEC_RACC
  FEC_MIIGSK_CFGR
  FEC_MIIGSK_ENR

But the driver reads and writes to those undefined locations. Those reads
and writes don't seem to have any side effects on real hardware. At least
none that have been observed so far. But they will trip qemu to trigger a
trap for an undefined access.

Modify the conditionals that currently exist in the driver to be used when
compiling for any ColdFire architecture (not just the M5272).

Signed-off-by: Greg Ungerer g...@uclinux.org
---
 drivers/net/ethernet/freescale/fec_main.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 4f87dff..b9045bb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -832,7 +832,9 @@ fec_restart(struct net_device *ndev)
 	const struct platform_device_id *id_entry =
 platform_get_device_id(fep-pdev);
 	int i;
+#if !defined(CONFIG_COLDFIRE)
 	u32 val;
+#endif
 	u32 temp_mac[2];
 	u32 rcntl = OPT_FRAME_SIZE | 0x04;
 	u32 ecntl = 0x2; /* ETHEREN */
@@ -889,7 +891,7 @@ fec_restart(struct net_device *ndev)
 	/* Set MII speed */
 	writel(fep-phy_speed, fep-hwp + FEC_MII_SPEED);
 
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 	/* set RX checksum */
 	val = readl(fep-hwp + FEC_RACC);
 	if (fep-csum_flags  FLAG_RX_CSUM_ENABLED)
@@ -950,7 +952,7 @@ fec_restart(struct net_device *ndev)
 #endif
 	}
 
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 	/* enable pause frame*/
 	if ((fep-pause_flag  FEC_PAUSE_FLAG_ENABLE) ||
 	((fep-pause_flag  FEC_PAUSE_FLAG_AUTONEG) 
@@ -968,7 +970,7 @@ fec_restart(struct net_device *ndev)
 	} else {
 		rcntl = ~FEC_ENET_FCE;
 	}
-#endif /* !defined(CONFIG_M5272) */
+#endif /* !defined(CONFIG_COLDFIRE) */
 
 	writel(rcntl, fep-hwp + FEC_R_CNTRL);
 
@@ -1689,7 +1691,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
 	if (id_entry-driver_data  FEC_QUIRK_HAS_GBIT) {
 		phy_dev-supported = PHY_GBIT_FEATURES;
 		phy_dev-supported = ~SUPPORTED_1000baseT_Half;
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 		phy_dev-supported |= SUPPORTED_Pause;
 #endif
 	}
@@ -1884,7 +1886,7 @@ static int fec_enet_get_ts_info(struct net_device *ndev,
 	}
 }
 
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 
 static void fec_enet_get_pauseparam(struct net_device *ndev,
 struct ethtool_pauseparam *pause)
@@ -2039,7 +2041,7 @@ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
 		return -EOPNOTSUPP;
 	}
 }
-#endif /* !defined(CONFIG_M5272) */
+#endif /* !defined(CONFIG_COLDFIRE) */
 
 static int fec_enet_nway_reset(struct net_device *dev)
 {
@@ -2058,7 +2060,7

Re: [uClinux-dev] qemu/m68k

[Greg Ungerer]

Hi Waldemar,

On 16/08/14 04:12, Waldemar Brodkorb wrote:

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 Linux systems, so don't be
to critical ;)

I don't know what happened to the CVS there. Not sure if it will
be coming back.

May be yu could remove the dead links? Do you have access to the
webserver? Or you could setup a git repository for it?
I can help with it, if you need admin or technical information about
it.


Apparently the hard disk failed in the cvs.uclinux.org server. It will
be coming back, I don't have an ETA for that though.

There is some talk of putting up a git tree for it. Will keep this list
posted on progress towards that.



Anyway, I can give you a starting point that works for me. I have
used the tools I generated at:

   
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/m68k-uclinux-tools-20101118.sh

for a couple of years now. They generate working systems that
run on real hardware and also under qemu. The source for generating
those tools is there in that same directory:

  http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/

I only use it for building Coldfire targets.

That is building the uclinux-dist:

   http://www.uclinux.org/pub/uClinux/dist/

That is a 3.10 kernel, but you can take any linus kernel and use
that with the same result. The uClibc in there may have some changes
over a stock 0.9.33.

A good place to start debugging these types of user space problems
is with the kernel trace option of flat files. So use the flthdr tool
to enable the kernel trace flag (-k) on the generated flat files,
then build you rootfs with those. Then at least you can see where
you app is in RAM.

Yeah, thanks a lot. Kernel trace helped. I got further booting up
the system. I am not really sure, what my problem was, but now I get
to the first shell (busybox hush). I think my elf2flt setup was
br0ken or -msep-data in CFLAGS fixed it.
My bootlog with a strace output of hush:
http://openadk.org/coldfire.txt

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 behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.




BTW: I compiled uClinux, but the result does not start in Qemu.
I used CONFIG_DEFAULTS_FREESCALE_M5208EVB to configure it.
Is there a reason you use -m5307 for gcc, instead of -m5208?


Historical I would think. The original code was developed before
gcc had a -m5208 option. Probably never been updated.


Without the kernel patch from Thomas you get no output.
Without the Qemu patch from Thomas you get:
qemu-system-m68k -nographic -kernel image.elf
qemu: hardware error: mcf_intc_write: Bad write offset 28

With kernel and qemu patch I get:
Linux version 3.10.0-uc0 (wbx@kop-brodkorbw) (gcc version 4.5.1 (GCC) ) #3 Fri 
Aug 15 19:52:04 CEST 2014
uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
...
qemu: hardware error: mcf_fec_read: Bad address 0x1c4


Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.



Disabling FEC ethernet driver gets me too:
uclinux[mtd]: probe address=0x401e91b8 size=0x0
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on ram:
0x-0x : ROMfs
mtd: partition ROMfs is out of reach -- disabled
TCP: cubic registered
NET: Registered protocol family 17
end_request: I/O error, dev mtdblock0, sector 2
EXT2-fs (mtdblock0): error: unable to read superblock
VFS: Cannot open root device (null) or unknown-block(31,0): error
-5
Please append a correct root= boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)

Which version of Qemu are you using to bootup uClinux?


I am using a 1.2.50 modified with the patches I link to at:

  http://marc.info/?l=uclinux-devm=134881405711207w=2

I sent those to the qemu devel list, I don't know if they ever got merged.

The next problem is due to the way images are put together by
default for ColdFire dev board targets. The romfs appended to the
kernel doesn't load by default on qemu.

The solution I use for this (to not have to modify the build) is to start
up qemu halted for the target:

 qemu-system-m68k -s -S -nographic -machine mcf5208evb -kernel 
images/image.elf


And then connect with a m68k-linux-gdb then do:

  target remote localhost:1234
  load images/image.elf
  file linux-3.x/vmlinux

The resuming the target (c) starts up the image and it will have the
romfs in memory.

You can modify the kernel config

Re: [uClinux-dev] qemu/m68k

[Greg Ungerer]

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 Linux systems, so don't be
to critical ;)

My toolchain (gcc 4.8.3, binutils 2.24) seems to work, because I can
boot a kernel:
Linux version 3.15.8 (wbx@kop-brodkorbw) (gcc version 4.8.3 (GCC) ) #25 Thu Aug 
14 16:09:16 CEST 2014
uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16320
Kernel command line: console=ttyS0,19200 ro rootfstype=tmpfs
...

But when init is called I got:
Starting Linux (built with OpenADK).
Freeing unused kernel memory: 1128K (4021e000 - 40338000)
qemu: fatal: Trying to execute code outside RAM or ROM at 0x0001eedc

qemu-system-m68k --version
QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellard

I am using elf2flt from git://wh0rd.org/elf2flt.git to produce flat
binaries.
$ file bin/busybox
$ bin/busybox: BFLT executable - version 4 gotpic

Does anyone have an advice what is wrong here?

The uClinux website have some links to a cvs repository, which are
no longer reachable. Is there a temporary problem?


I don't know what happened to the CVS there. Not sure if it will
be coming back.



Where does the latest version of elf2flt is available?


Hmmm. Well, that is a good question. I don't know where the
definitive version really is anymore.

Anyway, I can give you a starting point that works for me. I have
used the tools I generated at:

  
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/m68k-uclinux-tools-20101118.sh

for a couple of years now. They generate working systems that
run on real hardware and also under qemu. The source for generating
those tools is there in that same directory:

 http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/

I only use it for building Coldfire targets.

That is building the uclinux-dist:

  http://www.uclinux.org/pub/uClinux/dist/

That is a 3.10 kernel, but you can take any linus kernel and use
that with the same result. The uClibc in there may have some changes
over a stock 0.9.33.

A good place to start debugging these types of user space problems
is with the kernel trace option of flat files. So use the flthdr tool
to enable the kernel trace flag (-k) on the generated flat files,
then build you rootfs with those. Then at least you can see where
you app is in RAM.

Regards
Greg



___
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

Re: [uClinux-dev] M5282 Coldfire I2C

[Greg Ungerer]

Hi Steven,

The ColdFire platform parts look ok to me. I would like to apply them
to the m68knommu git tree. Can I have your signed-off-by for that part?
They don't apply cleanly to the for-next branch, due to clashes with
recent qspi changes, but the fixup is simple.

The drivers/i2c/busses changes will need to go via linux-...@vger.kernel.org

Regards
Greg



On 01/07/14 02:53, Steven King wrote:

On Monday 30 June 2014 8:16:01 am Nic Roets wrote:

The patch I tried (dated 2012) did not include the platform support:

I was just going to suggest that in reply to you earlier message.

This is the current version of the patch for kernel v3.15-rc7; It has all
the clocks and what not needed for more recent kernels.

if this doesnt work I'd be very interested in seeing the details of your
setup.


---
  arch/m68k/include/asm/m5206sim.h |8 +
  arch/m68k/include/asm/m520xsim.h |7 +
  arch/m68k/include/asm/m523xsim.h |   10 +-
  arch/m68k/include/asm/m527xsim.h |8 +
  arch/m68k/include/asm/m528xsim.h |9 +
  arch/m68k/include/asm/m5307sim.h |9 +-
  arch/m68k/include/asm/m53xxsim.h |7 +
  arch/m68k/include/asm/m5407sim.h |8 +
  arch/m68k/include/asm/m54xxsim.h |   10 +
  arch/m68k/include/asm/mcfi2c.h   |   15 +
  arch/m68k/platform/coldfire/device.c |  193 +
  arch/m68k/platform/coldfire/m5206.c  |   12 +
  arch/m68k/platform/coldfire/m520x.c  |   18 +-
  arch/m68k/platform/coldfire/m523x.c  |   18 ++
  arch/m68k/platform/coldfire/m5249.c  |   25 ++
  arch/m68k/platform/coldfire/m525x.c  |6 +-
  arch/m68k/platform/coldfire/m527x.c  |   28 ++
  arch/m68k/platform/coldfire/m528x.c  |   18 ++
  arch/m68k/platform/coldfire/m5307.c  |   14 +
  arch/m68k/platform/coldfire/m53xx.c  |   15 +-
  arch/m68k/platform/coldfire/m5407.c  |   14 +
  arch/m68k/platform/coldfire/m54xx.c  |   17 ++
  drivers/i2c/busses/Kconfig   |   10 +
  drivers/i2c/busses/Makefile  |1 +
  drivers/i2c/busses/i2c-coldfire.c|  496 ++
  25 files changed, 971 insertions(+), 5 deletions(-)

diff --git a/arch/m68k/include/asm/m5206sim.h b/arch/m68k/include/asm/m5206sim.h
index 4cf864f..0ddf3ef 100644
--- a/arch/m68k/include/asm/m5206sim.h
+++ b/arch/m68k/include/asm/m5206sim.h
@@ -110,6 +110,7 @@
  /*
   *Define system peripheral IRQ usage.
   */
+#defineMCF_IRQ_I2C029  /* I2C, Level 5 */
  #define   MCF_IRQ_TIMER   30  /* Timer0, Level 6 */
  #define   MCF_IRQ_PROFILER31  /* Timer1, Level 7 */
  #define   MCF_IRQ_UART0   73  /* UART0 */
@@ -138,6 +139,7 @@
  #define   MCFSIM_SWDICR   MCFSIM_ICR8 /* Watchdog timer ICR */
  #define   MCFSIM_TIMER1ICRMCFSIM_ICR9 /* Timer 1 ICR */
  #define   MCFSIM_TIMER2ICRMCFSIM_ICR10/* Timer 2 ICR */
+#defineMCFSIM_I2CICR   MCFSIM_ICR11/* I2C ICR */
  #define   MCFSIM_UART1ICR MCFSIM_ICR12/* UART 1 ICR */
  #define   MCFSIM_UART2ICR MCFSIM_ICR13/* UART 2 ICR */
  #ifdef CONFIG_M5206e
@@ -145,5 +147,11 @@
  #define   MCFSIM_DMA2ICR  MCFSIM_ICR15/* DMA 2 ICR */
  #endif
  
+/*

+ * I2C Controller
+*/
+#define MCFI2C_BASE0   (MCF_MBAR + 0x1e0)
+#define MCFI2C_SIZE0   0x40
+
  //
  #endif/* m5206sim_h */
diff --git a/arch/m68k/include/asm/m520xsim.h b/arch/m68k/include/asm/m520xsim.h
index db3f8ee..505a614 100644
--- a/arch/m68k/include/asm/m520xsim.h
+++ b/arch/m68k/include/asm/m520xsim.h
@@ -50,6 +50,7 @@
  #define MCFINT_UART026  /* Interrupt number for UART0 */
  #define MCFINT_UART127  /* Interrupt number for UART1 */
  #define MCFINT_UART228  /* Interrupt number for UART2 */
+#define MCFINT_I2C0 30  /* Interrupt number for I2C */
  #define MCFINT_QSPI 31  /* Interrupt number for QSPI */
  #define MCFINT_FECRX0 36  /* Interrupt number for FEC RX */
  #define MCFINT_FECTX0 40  /* Interrupt number for FEC RX */
@@ -67,6 +68,7 @@
  #define   MCF_IRQ_QSPI(MCFINT_VECBASE + MCFINT_QSPI)
  #define MCF_IRQ_PIT1(MCFINT_VECBASE + MCFINT_PIT1)
  
+#define MCF_IRQ_I2C0(MCFINT_VECBASE + MCFINT_I2C0)

  /*
   *  SDRAM configuration registers.
   */
@@ -199,6 +201,11 @@
  #define MCFPM_PPMHR0  0xfc040030
  #define MCFPM_PPMLR0  0xfc040034
  #define MCFPM_LPCR0xfc0a0007
+/*
+ * I2C module.
+*/
+#define MCFI2C_BASE0   0xFC058000
+#define MCFI2C_SIZE0   0x40
  
  //

  #endif  /* m520xsim_h */
diff --git a/arch/m68k/include/asm/m523xsim.h b/arch/m68k/include/asm/m523xsim.h
index 5e06b4e..50f6c3f 100644
--- 

Re: [uClinux-dev] M5282 Coldfire I2C

[Greg Ungerer]

Hi Steven,

On 10/07/14 05:42, Steven King wrote:

On Wednesday 09 July 2014 6:35:03 am Greg Ungerer wrote:

Hi Steven,

The ColdFire platform parts look ok to me. I would like to apply them
to the m68knommu git tree. Can I have your signed-off-by for that part?
They don't apply cleanly to the for-next branch, due to clashes with
recent qspi changes, but the fixup is simple.

The drivers/i2c/busses changes will need to go via
linux-...@vger.kernel.org


Alas, therein lies the rub; the folks over at linux-...@vger.kernel.org felt
that since the coldfire i2c is similar to the imx i2c, the existing imx i2c
driver should be used instead of adding another driver to the tree.  So I've
given up on getting this merged and thats why I didnt post this as a patch
with all the sign-offs and whatnot.


Ok, understand. Do you see any value then in having the platform
specific parts merged still then?

I like that it adds the clocks and other base definitions for i2c.
But it its probably not a good idea to have code conditional on a
define that cannot ever be set in tree.

Regards
Greg



___
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

Re: [uClinux-dev] [PATCH m68knommu] Add the m54xx fec driver

[Greg Ungerer]

On 31/05/14 12:09, Steven King wrote:
 On Monday 24 September 2012 1:05:16 am Philippe De Muyter wrote:
 Hello,

 I have cleaned up and updated to 3.6-rc5 my previous port of the
 freescale-written driver for the fast Ethernet Controller of the M547x
 and M548x ColdFires.  It seems from comments found in Freescale sources
 that this uses a MultiChannel DMA controller marketed as MCD and available
 also in the NPC8220 also from Freescale.  Therefore, I have split the
 submission in three parts :
  A generic MCD dma driver
  The M54xx instantiation of the MCD driver
  The FEC driver for M54xx

 I know there are still lines above 80 characters, but I feel they must be
 left that way.  There are also parts of an unfinished netpoll interface.

 Feel free to test and comment.
 
 So whatever happened with this?  Was there ever any feedback from the other 
 maintainers?
 
 For what it is worth, I was able to take the original patches and rebase them 
 to v3.15-rc6 with just a couple of very minor changes and produce a working 
 ethernet for my 5484 system.

I don't recall seeing too much. Time to try again?

Regards
Greg


___
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

Re: [uClinux-dev] gcc -fstack-limit-symbol patches for ColdFile CPU still waiting to be applied

[Greg Ungerer]

Hi Larry,

Note that you can no longer get to me on g...@snapgear.com.
(McAfee shutdown the Snapgear group a couple of years back, and I am no
longer with them. Unfortunately the email address doesn't bounce :-(
Using g...@uclinux.org is best.


On 01/06/14 07:45, Larry Baker wrote:
 I haven't thought about this in a while, but recent activity on the uClinux 
 developer's list reminded me again to check into this bug.
 
 A couple years ago I posted patches on gcc bugzilla for gcc 4.6, 4.7, and 4.8 
 to implement -fstack-limit-symbol for ColdFire processors, as well as to 
 correct the code generated for all m68k processors [1] [2].  I posted an 
 announcement here as well back on 25 September 2012.  The recent 
 conversations here about ColdFire processors made me think someone might 
 still care about that work.
 
 Merging my patches into the gcc trunk keeps getting deferred.  The last time 
 I had any correspondence with anyone about a time frame, I think the delay 
 was because of the lack of someone working on the m68k code in the compiler.  
 I've never written any compiler code before this, but I do know how to read 
 assembly language to see what the compiler is emitting.  (That's how I 
 determined the existing implementation was not right and not as efficient as 
 it could be.)  I was able to generate and run my code on uClinux with the 
 stack checking option using my patched gcc.

It is a shame this is taking so long to get back into gcc proper.
But thanks for the good work, and posting it here.

Regards
Greg



 Regards,
 
 Larry Baker
 US Geological Survey
 650-329-5608
 ba...@usgs.gov
 
 [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53834
 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
 

___
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

Re: [uClinux-dev] [PATCH 0/9] m68knommu: use ColdFire DMA timer

[Greg Ungerer]

Hi Steven,

On 30/05/14 09:22, Steven King wrote:
 On Tuesday 27 May 2014 5:49:40 pm g...@uclinux.org wrote:
 From: Greg Ungerer g...@uclinux.org

 Most of the modern ColdFire family members contain the DMA timer hardware
 module. Build the support code for it and use it on those that do. We can
 use it as an accurate time source.

 I don't have test platforms based on all of these ColdFire types, it would
 be really helpful if anyone that has any of these can test these changes.
 It build tests fine on all these types, and it works on 520x and 527x
 based platforms.

 These changes are (neccessarily) on top of my recent patch series titled
 clean up timer code on the ColdFire 53xx.

 Signed-off-by: Greg Ungerer g...@uclinux.org
 ---
  arch/m68k/include/asm/m520xsim.h|8 
  arch/m68k/include/asm/m523xsim.h|8 
  arch/m68k/include/asm/m527xsim.h|8 
  arch/m68k/include/asm/m528xsim.h|8 
  arch/m68k/include/asm/m53xxsim.h|   10 +-
  arch/m68k/include/asm/m5441xsim.h   |8 
  arch/m68k/platform/coldfire/Makefile|   10 +-
  arch/m68k/platform/coldfire/dma_timer.c |   24 +---
  8 files changed, 63 insertions(+), 21 deletions(-)

 --
 To unsubscribe from this list: send the line unsubscribe linux-m68k in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 Hi Greg,
 
 I was able to to test this on 528x and 5441x and didnt have problems, so you 
 can add my Acked-by if you want.

Great, thanks for testing. I will add your acked-by.

The most significant change is for the 532x and 537x, but
I don't have either of those to test with.

Regards
Greg




___
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

Re: [uClinux-dev] [PATCH 9/9] m68knommu: use ColdFire DMA timer module on devices that have it

[Greg Ungerer]

Hi Steven,

On 29/05/14 01:59, Steven King wrote:
 On Tuesday 27 May 2014 5:49:49 pm g...@uclinux.org wrote:
 From: Greg Ungerer g...@uclinux.org

 The DMA timer hardware module is present in all of the 520x, 527x, 528x,
 53xx and 5441x families of ColdFire SoC. Use it as clock source on those
 parts to give a more accurate clock.

 Signed-off-by: Greg Ungerer g...@uclinux.org
 ---
  arch/m68k/platform/coldfire/Makefile | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/arch/m68k/platform/coldfire/Makefile
 b/arch/m68k/platform/coldfire/Makefile index 0818f77..cdd0b03 100644
 --- a/arch/m68k/platform/coldfire/Makefile
 +++ b/arch/m68k/platform/coldfire/Makefile
 @@ -17,18 +17,18 @@ asflags-$(CONFIG_FULLDEBUG) :=
 -DDEBUGGER_COMPATIBLE_CACHE=1 obj-$(CONFIG_COLDFIRE) += cache.o clk.o
 device.o dma.o entry.o vectors.o obj-$(CONFIG_M5206) += m5206.o timers.o
 intc.o reset.o
  obj-$(CONFIG_M5206e)+= m5206.o timers.o intc.o reset.o
 -obj-$(CONFIG_M520x) += m520x.o pit.o intc-simr.o reset.o
 +obj-$(CONFIG_M520x) += m520x.o pit.o dma_timer.o intc-simr.o reset.o
  obj-$(CONFIG_M523x) += m523x.o pit.o dma_timer.o intc-2.o reset.o
  obj-$(CONFIG_M5249) += m5249.o timers.o intc.o intc-5249.o reset.o
  obj-$(CONFIG_M525x) += m525x.o timers.o intc.o intc-525x.o reset.o
 -obj-$(CONFIG_M527x) += m527x.o pit.o intc-2.o reset.o
 +obj-$(CONFIG_M527x) += m527x.o pit.o dma_timer.o intc-2.o reset.o
  obj-$(CONFIG_M5272) += m5272.o intc-5272.o timers.o
 -obj-$(CONFIG_M528x) += m528x.o pit.o intc-2.o reset.o
 +obj-$(CONFIG_M528x) += m528x.o pit.o dma_timer.o intc-2.o reset.o
  obj-$(CONFIG_M5307) += m5307.o timers.o intc.o reset.o
 -obj-$(CONFIG_M53xx) += m53xx.o pit.o intc-simr.o reset.o
 +obj-$(CONFIG_M53xx) += m53xx.o pit.o dma_timer.o intc-simr.o reset.o
  obj-$(CONFIG_M5407) += m5407.o timers.o intc.o reset.o
  obj-$(CONFIG_M54xx) += m54xx.o sltimers.o intc-2.o
 -obj-$(CONFIG_M5441x)+= m5441x.o pit.o intc-simr.o reset.o
 +obj-$(CONFIG_M5441x)+= m5441x.o pit.o dma_timer.o intc-simr.o 
 reset.o

  obj-$(CONFIG_NETtel)+= nettel.o
  obj-$(CONFIG_CLEOPATRA) += nettel.o
 
 Hi Greg,
 
 I couldn't get this part to apply.  What tree are you using?

This was against linux-3.15-rc4

Regards
Greg



___
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

Re: [uClinux-dev] (no subject)

[Greg Ungerer]

Hi

On 11/04/14 14:12, deepak sachan wrote:

I have downloaded latest uClinux-dist-20131024.tar.bz2 from
http://www.uclinux.org/pub/uClinux/dist/. does it support BF537??? Becoz
while in menu config it doesn`t have BF537 and other board.


That means there is no pre-canned config for that board.
The kernel may support what is on it, if all the appropriate
blackfin code is in the mainline kernel.



Then I have down loaded it from http://docs.blackfin.uclinux.org/doku.php

I am trying to make blackfin-buildroot
$ cd blackfin-buildroot
  blackfin-buildroot $defconfig bf337-stamp
Error:No kernel deconfig name specified check your
BR2_LINUX_KERNEL_DEFCONFIG setting
.stop…http://ez.analog.com/communications#

blackfin-buildroot $make menuconfig

// Done  some settings//

blackfin-buildroot $make

Error:No kernel deconfig name specified check your
BR2_LINUX_KERNEL_DEFCONFIG setting .stop

  I am not able to build it for the bf537 board.


You would need to ask that on the backfin email lists.

Regards
Greg


___
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

Re: [uClinux-dev] coldfire M5272, linux-2.6.x

[Greg Ungerer]

Hi Daniele,

On 11/04/14 01:47, Daniele Ziglioli wrote:
 well, finally I've compiled the last 20131024 with codesourcery toolchain, 
 but ...
 
 I've then started from the config of the M5272C3 EVB  (that is is the more 
 similar to mine),
 and changed kernel execution form add 0x400.
 The same I've  done before with a linux-2.4 kernel, and that work.
 But when i do go 0x400 nothing happen on the console.
 I've an ICDFZ 64K (PE) and the only thing that I could see , looking the 
 address of the assembler line
 where the cpu is looped in the calibrate_delay function.
 
 attached the config used.

You probably want CONFIG_RAMSIZE to be set to 0x100. It should be all
of RAM, not with the vector region size taken of. Otherwise it looks
pretty normal.


 did you know if the last uclinux (linux-3) version run on the M5272C3 EVB ?

I don't think I have run it on that board. I have run it on a few other
ColdFire boards (like the 5208 for example).

Regards
Greg



 Il 10/04/2014 01:32, Greg Ungerer ha scritto:
 Hi Daniele,

 On 10/04/14 01:28, Daniele Ziglioli wrote:
 I've tried to compile, without success, the last kernel linux-3.x for the 
 EVM5272 freescale board.

 My environment:
 Ubuntu 10.04
 m68k-uclinux-tools-20101118.sh  or 
 freescale-coldfire-2011.09-23-m68k-uclinux.bin
 uClinux-dist-20131024.tar.bz2
 I've tried various  dist and compiler (codesourcery and uclinux) ... 
 without success.

 Could you suggest me a working tested environment to get compiled a recent  
 ( linux-2.6.x ) kernel,
 for that board (or a different similar one) ?
 What failed exactly?
 Can you show the compile logs?

 Regards
 Greg


 
 -- 
 Cordiali saluti,
 *Daniele Ziglioli*
 www.signal-elettronica.it http://www.signal-elettronica.it/

___
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

Re: [uClinux-dev] coldfire M5272, linux-2.6.x

[Greg Ungerer]

Hi Daniele,

On 10/04/14 01:28, Daniele Ziglioli wrote:
 I've tried to compile, without success, the last kernel linux-3.x for the 
 EVM5272 freescale board.
 
 My environment:
 Ubuntu 10.04
 m68k-uclinux-tools-20101118.sh  or 
 freescale-coldfire-2011.09-23-m68k-uclinux.bin
 uClinux-dist-20131024.tar.bz2
 I've tried various  dist and compiler (codesourcery and uclinux) ... without 
 success.
 
 Could you suggest me a working tested environment to get compiled a recent  
 ( linux-2.6.x ) kernel,
 for that board (or a different similar one) ?

What failed exactly?
Can you show the compile logs?

Regards
Greg


___
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

Re: [uClinux-dev] + LAN919C6 + uCLinux Ethernet Controller Recommendation ?

[Greg Ungerer]

Hi Paul,

On 05/12/13 11:51, Paul Romero wrote:

Do you know the history of the SMSC LAN91C96 Ethernet controller
on uCLinux and the 5249 Coldfire processor series ?


I couldn't speak to why Freescale choose it for that board.
But I think I added support for the 5249 board to the
drivers/net/smc9.c code in the 2.4.x uclinux kernels.



I am looking for a chip to replace the SMSC91C111 used on
the M5249C3 board because the GAL chip needed to interface
it with the Coldfire processor is no available. I would like
to find an Ethernet controller that satisfies the following
criteria for use in the Coldfire/uCLinux Version 2.4.27
environment. (i.e. With the 2.4 kernel.)


Do you need it to me 10/100Mbit?



* Ease of hardware integration with the Coldfire processor.

* Has a driver known to work under uCLinux Version 2.4.27--
   or which can easily be ported to that environment.

* Has a driver known to be compatible with the uCLinux TCP Stack--
   which, preferably, has been proven stable.


There are Linux ethernet drivers for most devices out there. But
when it comes to using them on ColdFire hardware the problems
generally come from how they are logically connected to the SoC.



I haven't found any chips that satisfy this criteria in
the uCLinux archives or on the Internet.


If you are happy using the smsc91c111 I would look at coming up
with some new logic to replace the old GAL. Shouldn't be too hard,
and you look to be changing your hardware anyway.

Regards
Greg


___
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

Re: [uClinux-dev] uclinux code git/svn repository code maintainance

[Greg Ungerer]

Hi Vikas,

On 04/12/13 23:56, Vikas MANOCHA wrote:

I am trying to get uclinux code to port it on my SOC. On the home page
of uclinux.org, tarballs are available but no link to any git (not svn
also) repository.


There is currently not git/cvs tree for the uclinux-dist.



Being an open project, I think it should  be present somewhere  missed
by me.

How the code for uclinux is being maintained. Any information would be
of great help.


Patches sent to this list are rolled into the tar ball source releases
as they are produced.

Regards
Greg



___
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

[uClinux-dev] uClinux-dist-20131024

[Greg Ungerer]

Hi All

I have uploaded a new version of the uClinux-dist to the web site, links
from here:

  http://www.uclinux.org/pub/uClinux/dist/

There is a lot of new stuff in this one. Linux-3.10 kernel, new uClibc,
a few new apps and many improvements to the underlying build system. In
particular it handles staging includes and libraries more cleanly, and
uses standard autoconf/configure a lot more.

Note that snapgear no longer exits, so my old email, g...@snapgear.com,
no longer works. Use g...@uclinux.org to get to me.

Regards
Greg

___
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

Re: [uClinux-dev] [PATCH] arch: m68k: include: asm: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not.

[Greg Ungerer]

Hi Geert,

On 29/06/13 18:26, Geert Uytterhoeven wrote:
 On Sat, Jun 29, 2013 at 10:01 AM, Michael Schmitz schmitz...@gmail.com 
 wrote:
 The same .config file, also report the compiling error below:

 drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of
 function ‘iowrite8’ [-Werror=implicit-function-declaration]
 drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of
 function ‘iowrite16’ [-Werror=implicit-function-declaration]
 drivers/i2c/busses/i2c-ocores.c:91:2: error: implicit declaration of
 function ‘iowrite32’ [-Werror=implicit-function-declaration]
 drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of
 function ‘ioread8’ [-Werror=implicit-function-declaration]
 drivers/i2c/busses/i2c-ocores.c:101:2: error: implicit declaration of
 function ‘ioread16’ [-Werror=implicit-function-declaration]
 drivers/i2c/busses/i2c-ocores.c:106:2: error: implicit declaration of
 function ‘ioread32’ [-Werror=implicit-function-declaration]

 Excuse me, I am not quite familiar with the related hardware and m68k,
 I guess under m68k architecture, we need not this drivers, is it correct ?
 
 Until someone synthesizes the OpenCores i2c core together with the
 OpenCores 68000 core (they seem to have one), and tries to run uClinux
 on it...
 
 That would be correct, yes. Perhaps add appropriate dependencies in
 drivers/i2c/Kconfig to allow building I2C drivers
 only on hardware that supports it?
 
 We still want it for compile-coverage.
 
 Now, the issue is that m68knommu doesn't implement ioread8() and
 friends, so I'm adding the uClinux list.

I think this is relatively strait forward to fix. And we end up
making m68knommu targets consistent with the MMU m68k targets in
the process.

Regards
Greg



[PATCH] m68knommu: user generic iomap to support ioread*/iowrite*

There is no reason we cannot use the generic iomap support to give us
the ioread* and iowrite* family of IO access functions. The m68k arch with
MMU enabled does, so this makes us consistent for all m68k now.

Some potentially valid drivers will fail to compile without these,
for example:

drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of
function ‘iowrite8’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of
function ‘iowrite16’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:91:2: error: implicit declaration of
function ‘iowrite32’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of
function ‘ioread8’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:101:2: error: implicit declaration of
function ‘ioread16’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:106:2: error: implicit declaration of
function ‘ioread32’ [-Werror=implicit-function-declaration]

Signed-off-by: Greg Ungerer g...@uclinux.org
---
 arch/m68k/Kconfig | 2 +-
 arch/m68k/include/asm/io_no.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 821170e..c3cda41 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -11,6 +11,7 @@ config M68K
select VIRT_TO_BUS
select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
select GENERIC_CPU_DEVICES
+   select GENERIC_IOMAP
select GENERIC_STRNCPY_FROM_USER if MMU
select GENERIC_STRNLEN_USER if MMU
select FPU if MMU
@@ -72,7 +73,6 @@ source kernel/Kconfig.freezer
 config MMU
bool MMU-based Paged Memory Management Support
default y
-   select GENERIC_IOMAP
help
  Select if you want MMU-based virtualised addressing space
  support by paged memory management. If unsure, say 'Y'.
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 353bf75..e153478 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -4,6 +4,7 @@
 #ifdef __KERNEL__
 
 #include asm/virtconvert.h
+#include asm-generic/iomap.h
 
 /*
  * These are for ISA/PCI shared memory _only_ and should never be used

___
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

Re: [uClinux-dev] Initial Timer on m5329 not running

[Greg Ungerer]

Hi Christian,

On 16/04/13 19:01, Christian Gieseler wrote:
 -Original Message-
 From: Greg Ungerer [mailto:gregunge...@westnet.com.au]
 Sent: Tuesday, April 02, 2013 8:27 AM
 On 26/03/13 16:54, Christian Gieseler wrote:
 diff git a/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c
 b/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c

 --- a/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c

 +++ b/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c

 @@ 120,6 +120,8 @@ static struct clk * const enable_clks[] __initconst
 = {

 __clk_0_25, /* mcfuart.1 */

 __clk_0_26, /* mcfuart.2 */

 + __clk_0_28, /* mcftmr.0 */

 + __clk_0_29, /* mcftmr.1 */

 Is this patch reversed?
 
 What do you mean with reversed? If I have a look at
 http://lxr.linux.no/#linux+v3.8.7/arch/m68k/platform/coldfire/m532x.c

In that file:

__clk_0_25,/* mcfuart.1 */
__clk_0_26,/* mcfuart.2 */
__clk_0_28,/* mcftmr.0 */
__clk_0_29,/* mcftmr.1 */

Yet your patch above is adding those same mcftimer lines.
So I suspect you diffed the files in the wrong order when you generated
the patch (that is you did diff new-file old-file instead of the
other way around).


 they
 are disabled.

I don't follow. Disabled?

Regards
Greg


___
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

Re: [uClinux-dev] [PATCH] enable Timer on coldfire 532x

[Greg Ungerer]

Hi Christian,

On 16/04/13 18:57, Christian Gieseler wrote:
 This patch enables the initial Timer on coldfire 532x systems. 
 Without this, the scheduler will not be triggered and the system hangs,
 after all sequential code is executed. It should also apply on later kernel
 versions.
 Please be patient if the patch is not matching the needed pattern as this is
 my first patch. I am open for advice :-)

This one looks ok to me. I have applied it to the m68knommu git tree.

Regards
Greg


 Regards,
 Christian
 
 Signed-off-by: Christian Gieseler christiangiese...@yahoo.de
 
 --- linux-3.6.11/arch/m68k/platform/coldfire/m532x.c.orig 2013-04-16
 10:38:16.604838828 +0200
 +++ linux-3.6.11/arch/m68k/platform/coldfire/m532x.c  2013-04-16
 10:39:08.354700290 +0200
 @@ -119,7 +119,8 @@ static struct clk * const enable_clks[] 
   __clk_0_24,/* mcfuart.0 */
   __clk_0_25,/* mcfuart.1 */
   __clk_0_26,/* mcfuart.2 */
 -
 + __clk_0_28,/* mcftmr.0 */
 + __clk_0_29,/* mcftmr.1 */
   __clk_0_32,/* mcfpit.0 */
   __clk_0_33,/* mcfpit.1 */
   __clk_0_37,/* mcfeport.0 */
 @@ -135,8 +136,6 @@ static struct clk * const disable_clks[]
   __clk_0_17,/* edma */
   __clk_0_22,/* mcfi2c.0 */
   __clk_0_23,/* mcfqspi.0 */
 - __clk_0_28,/* mcftmr.0 */
 - __clk_0_29,/* mcftmr.1 */
   __clk_0_30,/* mcftmr.2 */
   __clk_0_31,/* mcftmr.3 */
   __clk_0_34,/* mcfpit.2 */
 
 ___
 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
 

___
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

Re: [uClinux-dev] Initial Timer on m5329 not running

[Greg Ungerer]

Hi Christian,

On 26/03/13 16:54, Christian Gieseler wrote:
 Coldfire 5329 seems not be used with latest kernels. The Main Timer is not 
 running, so the scheduler won´t behave like expected.
 
 To change this the following change has to be done in m532x.c arch setup. 
 There is probably more to be fixed.

Please do post any follow up patches you need to make it work.
Bonus points if you create them in readily git appliable format
(as per Documentation/SubmittingPatches).
  

 diff git a/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c 
 b/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c
 
 --- a/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c
 
 +++ b/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c
 
 @@ 120,6 +120,8 @@ static struct clk * const enable_clks[] __initconst = {
 
 __clk_0_25, /* mcfuart.1 */
 
 __clk_0_26, /* mcfuart.2 */
 
 + __clk_0_28, /* mcftmr.0 */
 
 + __clk_0_29, /* mcftmr.1 */

Is this patch reversed?
This is the order they are in the latest kernels.

Regards
Greg



 __clk_0_32, /* mcfpit.0 */
 
 __clk_0_33, /* mcfpit.1 */
 
 __clk_0_37, /* mcfeport.0 */
 
 @@ 135,8 +137,6 @@ static struct clk * const disable_clks[] __initconst = {
 
 __clk_0_17, /* edma */
 
 __clk_0_22, /* mcfi2c.0 */
 
 __clk_0_23, /* mcfqspi.0 */
 
 -  __clk_0_28, /* mcftmr.0 */
 
 -  __clk_0_29, /* mcftmr.1 */
 
 __clk_0_30, /* mcftmr.2 */
 
 __clk_0_31, /* mcftmr.3 */
 
 __clk_0_34, /* mcfpit.2 */
 
  
 
 
 
 ___
 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
 

___
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

Re: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3

[Greg Ungerer]

Hi Ashish,

On 30/03/13 00:58, Ashish Phogat wrote:
 Hi greg,
 I debug fec.c file in linux 2.4.x/drivers/net..Here are 
 my observations:
 
 
 When uclinux boots:
 dhcp daemon is intiated from rc file:
 
 *dhcpcd -p -a eth0 *
 
 which tries to open the ethernet port by calling:
 
 *fec_enet_open* function.
 
 In that function I found that
 
 *fep-link* variable is never initiated to *1*
 
 Based on my PHY  as *AM79C874  *and config options shown below:
 
 #if defined(CONFIG_M5272)
 #define M5272_PHY_STAT_INT
 # if defined(CONFIG_BOARD_UC5272)
 #define PHY_INTMCF_INT_INT6
 #define PHY_START_ADDR1
 #define ICR_PHY_REG(MCF_MBAR + MCFSIM_ICR4)
 #define ICR_PHY_MASK_IPL0x
 #  if defined(CONFIG_UC5272_PHY_INT)
  #define ICR_PHY_MASK0xFF0F
  #define ICR_PHY_SETUP0x00d0
  #define ICR_MASK_IP0x0080
 #  else /* CONFIG_UC5272_PHY_INT */
  #undef  M5272_PHY_STAT_INT
  #define ICR_PHY_MASK0x
  #define ICR_PHY_SETUP0x
  #define ICR_MASK_IP0x
 #  endif /* CONFIG_UC5272_PHY_INT */
 # else /* CONFIG_BOARD_UC5272 */
 #  if defined(CONFIG_FEC_KS8995M)
   #undef  M5272_PHY_STAT_INT
   #define PHY_START_ADDR5
   #define ICR_PHY_MASK0x
   #define ICR_PHY_SETUP0x
   #define ICR_MASK_IP0x
 #  else /*CONFIG_FEC_KS8995M */
 // These are values for ColdFire 5272 SIM
 #define PHY_INTMCF_INT_INT2
   #define PHY_START_ADDR0
   #define ICR_PHY_REG(MCF_MBAR + MCFSIM_ICR1)
   #define ICR_PHY_MASK_IPL0x
   #define ICR_PHY_MASK0x7077
   #define ICR_MASK_IP0x0800
   #define ICR_PHY_SETUP0x0d00
 #  endif /* CONFIG_FEC_KS8995M */
 # endif /* CONFIG_BOARD_UC5272 */
 #endif /* CONFIG_M5272 */

I haven't looked at the M5272C3 for quite some time, so I don't recall
if it had an interrupt from the phy or not. Many boards do, as you can
see from the above.


 fep-link *is blocked by *
 *
 #if !defined( M5272_PHY_STAT_INT)
 
 fep-link = 1; /* Always assume we are connected (no interrupt
   to turn on/off link) */
 
 #endif
 
 It seems my link is never up.
 
 Next Step I rebuild uclinux by initializing fep-link to 1 always 
 irrespective of any configuration.
 
 But this time uclinux keep on starting transimission forever by calling
 
 *fec_enet_start_xmit *function*
 *
 
 So I simply kill my *dhcpcd -p -a eth0 * process
 
 and up my ethernet connection by calling
 
 *ifconfig eth0 192.168.0.5 netmask 255.255.255.0 up*
 
 after that everything works fine.
 
 
 I am able to ping my Linux machine.
 
 I don't know whether some configuration is missed for AM79C874. I am not sure 
 how link is supposed to be up. Whether
 
 I should assume to be up always or I have to wait for some interrupt/event 
 which will make my link up.
 
 If you have anything on your side please let me know.

If you can determine if your board has a phy interrupt that would be good.
Based on that you can fix the code to correctly interrupt from the phy.
If your board doesn't then it should be fixed to 1, as your work around
does now.

Regards
Greg



 Thanks
 
 Ashish Phogat
 
 On Thu, Mar 28, 2013 at 1:15 PM, Ashish Phogat engineerpho...@gmail.com 
 mailto:engineerpho...@gmail.com wrote:
 
 Hi Greg,
 I am sorry I am new to linux...I donot know how to add traces. Could you 
 please help me with that?
 
 Meanwhile I am trying to add few utilities in my uclinux such as 
 mii-tool-fec, traceroute or ethtool.
 
 Lets see how much I am able to debug or get more information.
 
 Thanks for your help.
 
 Thanks
 Ashish Phogat
 
 
 On Thu, Mar 28, 2013 at 8:22 AM, Greg Ungerer gregunge...@westnet.com.au 
 mailto:gregunge...@westnet.com.au wrote:
 
 Hi Ashish,
 
 On 28/03/13 21:57, Ashish Phogat wrote:
  I had a look at all the patches made for M5272C3 in cvs.org 
 http://cvs.org
  http://cvs.org for kernel 2.4.x in last couple of years. It seems 
 all
  patches are included in my distribution 
 (uClinux-dist-20120401.tar.bz2).
  I don't have idea why this error NETDEV WATCHDOG is still coming. I 
 am
  running at 50Mhz clock frequency. Is there any problem with 
 frequency?
 
 No, I don't think that will cause you any problems.
 
 From the interrupt count it doesn't look like you are getting any TX
 interrupts from the FEC. This will cause the NETDEV WATCHDOG to
 eventually timeout and you get the kernel trace you see.
 
 You are getting other interrupts from the FEC - I think you should
 add some trace and see what those are. Maybe they will give some
 clues.
 
 Regards
 Greg
 
 
  On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat
  engineerpho...@gmail.com mailto:engineerpho...@gmail.com 
 mailto:engineerpho...@gmail.com mailto:engineerpho...@gmail.com wrote

Re: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3

[Greg Ungerer]

Hi Ashish,

On 28/03/13 21:57, Ashish Phogat wrote:
 I had a look at all the patches made for M5272C3 in cvs.org
 http://cvs.org for kernel 2.4.x in last couple of years. It seems all
 patches are included in my distribution (uClinux-dist-20120401.tar.bz2).
 I don't have idea why this error NETDEV WATCHDOG is still coming. I am
 running at 50Mhz clock frequency. Is there any problem with frequency?

No, I don't think that will cause you any problems.

From the interrupt count it doesn't look like you are getting any TX
interrupts from the FEC. This will cause the NETDEV WATCHDOG to
eventually timeout and you get the kernel trace you see.

You are getting other interrupts from the FEC - I think you should
add some trace and see what those are. Maybe they will give some
clues.

Regards
Greg


 On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat
 engineerpho...@gmail.com mailto:engineerpho...@gmail.com wrote:
 
 Hi Greg,
 When I did cat proc/interrupts:
 
 / cat /proc/interrupts
  66:  0   fec(MII)
  72:   3393   ColdFire Timer
  73:   1084   ColdFire UART
  74:  0   ColdFire UART
  77:  0   ColdFire USB (EP0)
  78:  0   ColdFire USB (EP1)
  79:  0   ColdFire USB (EP2)
  80:  0   ColdFire USB (EP3)
  81:  0   ColdFire USB (EP4)
  82:  0   ColdFire USB (EP5)
  83:  0   ColdFire USB (EP6)
  84:  0   ColdFire USB (EP7)
  86:  0   fec(RX)
  87:  0   fec(TX)
  88: 13   fec(OTHER)
  89:  0   ColdFire QSPI
 
 Thanks
 Ashish phogat
 
 On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer
 gregungere...@gmail.com mailto:gregungere...@gmail.com wrote:
 
 Hi Ashish,
 
 On 27/03/13 06:12, Ashish Phogat wrote:
  My Kernel is 2.4.34.5 and uClinux-dist is
 uClinux-dist-20120401.tar.bz2.
 
 Ok. I haven't run 2.4 kernels for a long time... but some
 comments
 below.
 
 
   / NETDEV WATCHDOG: eth0: transmit timed out
   eth0: transmit timed out.
   Ring data dump: cur_tx 321100, dirty_tx 321100
 cur_rx: 321000
tx: 16 buffers
 00321100:  0012 
 00321108:  0816 
 00321110:  001a 
 00321118:  0c1e 
 00321120:  0432 
 00321128:  40a6 
 00321130:  002a 
 00321138:  002e 
 00321140:  0032 
 00321148:  0036 
 00321150:  003a 
  
rx: 32 buffers
 00321000: 8000 0440 0032
 00321008: 8000 0c70 00320800
 00321010: 8000 092b 0037f000
 00321018: 8000 ff9a 0037f800
 00321020: 8000 7fa2 0037e000
 00321028: 8000 eda6 0037e800
 00321030: 8000 ffa2 0037d000
 00321038: 8000 ffa6 0037d800
 00321040: 8000 ffb2 0037c000
 00321048: 8000 ffb6 0037c800
 0032
  
   Spurious interrupt 1
 
 Together this looks like an interrupt issue. What do you see
 if you cat /proc/interrupts?
 
 Regards
 Greg
 
 
  
   uclinux simply hangs there. I found that there is a
 large amount
  of people who are getting the same problem in past
 couple of years.
  But I did not get any solution for the problem.
  
   Please let me know whether this problem still exists
 in uclinux
  source code for M5272C3. where I will find the
 solution for that?
  
   My Ethernet Hardware Info:
   fec.c: Probe number 1 with 0x
   eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60
   fec: PHY @ 0x1, ID 0x0022561b -- AM79C874
  
   Thanks and Appreciated for your help.
  
   Thanks
   Ashish Phogat
  
  
   ___
   uClinux-dev mailing list
   uClinux-dev@uclinux.org
 mailto:uClinux-dev@uclinux.org
 mailto:uClinux-dev@uclinux.org
 mailto:uClinux-dev@uclinux.org
   http

Re: [uClinux-dev] RAM based filesystem in uclinux

[Greg Ungerer]

On 26/03/13 02:14, Lennart Sorensen wrote:
 On Sat, Mar 23, 2013 at 08:49:37AM +1000, Greg Ungerer wrote:
 Hi Lennart,

 On 22/03/13 23:41, Lennart Sorensen wrote:
 The fact we can recreate the cpio archive and update the uImage from
 the kernel and cpio archive is great.  No recompile crap to deal with
 the way romfs and such have tended to need.  For us building the kernel
 and the filesystem are totally seperate issues.

 I don't follow you here. How does using a ROMfs mean that building
 the kernel and filesystem are not separate?
 
 Well the way I saw it done when I looked at romfs, was that it was part
 of the kernel image so you had to do the linking with the romfs files
 in place to get the kernel image.
 
 Can you replace the romfs without using the kernel source tree, with
 just a vmlinux (or equivelant) file around?

Yes. On many occasions I have mixed various kernel binary and romfs
images when testing regressions. It's so easy the way we do this on
ColdFire, I just cat them together.

Regards
Greg



___
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

Re: [uClinux-dev] Ehernet FEC problem in Coldfire M5272C3

[Greg Ungerer]

Hi Ashish,

On 26/03/13 08:03, Ashish Phogat wrote:
 I am facing a very old problem with my Ethernet connection on M5272C3 
 coldfire board. As soon as my uclinux boots I got the following logs shown 
 below:

What version of kernel?
What version of uClinux-dist?

Regards
Greg



 Command: cat /etc/motd
 Welcome to
    _  _
  /  __| ||_|
 _   _| |  | | _   _   _  _  _
| | | | |  | || |  _ \| | | |\ \/ /
| |_| | |__| || | | | | |_| |/\
|  ___\|_||_|_| |_|\|\_/\_/
| |
|_|
 
 For further information check:
 http://www.uclinux.org/
 
 Execution Finished, Exiting
 
 Sash command shell (version 1.1.1)
 
 / NETDEV WATCHDOG: eth0: transmit timed out
 eth0: transmit timed out.
 Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000
  tx: 16 buffers
   00321100:  0012 
   00321108:  0816 
   00321110:  001a 
   00321118:  0c1e 
   00321120:  0432 
   00321128:  40a6 
   00321130:  002a 
   00321138:  002e 
   00321140:  0032 
   00321148:  0036 
   00321150:  003a 
  
  rx: 32 buffers
   00321000: 8000 0440 0032
   00321008: 8000 0c70 00320800
   00321010: 8000 092b 0037f000
   00321018: 8000 ff9a 0037f800
   00321020: 8000 7fa2 0037e000
   00321028: 8000 eda6 0037e800
   00321030: 8000 ffa2 0037d000
   00321038: 8000 ffa6 0037d800
   00321040: 8000 ffb2 0037c000
   00321048: 8000 ffb6 0037c800
   0032
  
 Spurious interrupt 1
 
 
 uclinux simply hangs there. I found that there is a large amount of people 
 who are getting the same problem in past couple of years. But I did not get 
 any solution for the problem.
 
 Please let me know whether this problem still exists in uclinux source code 
 for M5272C3. where I will find the solution for that?
 
 My Ethernet Hardware Info:
 fec.c: Probe number 1 with 0x
 eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60
 fec: PHY @ 0x1, ID 0x0022561b -- AM79C874
 
 Thanks and Appreciated for your help.
 
 Thanks
 Ashish Phogat
 
 
 ___
 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
 

___
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

Re: [uClinux-dev] ROMFS: bad initial checksum

[Greg Ungerer]

Hi Christian,

On 04/03/13 21:07, Christian Gieseler wrote:

i just wanted to give some feedback about this, so that other people don´t
run in the same issue.
The initial checksum gets corrupted because of variables from m532x.c are
placed in the area where romfs is placed before it is mounted/copied to the
final position.

The two commands
sys_clk_khz = clock_pll(0, 0);
sys_clk_mhz = sys_clk_khz/1000;

overwrite the romfs contents. Commenting the stuff out solves the romfs
problem. You find these variables only in m532x.c and I don´t see what they
are good for. They also don´t exist for other coldfire platforms.
They are in the sources for quite a while now and we did not have the
problem with earlier kernels. Has something changed in the compiling/linking
process, so that addresses have moved?


Well, not so long ago I changed the linker scripts to make them more
like the general m68k scripts. That we we can use the linux common
linker script definitions (which greatly simplifies maintenance).
Not sure if this may have caused this.

Anyway, if all that early clock and pll code is not needed I would
like to remove it. I have never liked how that is so different to
startup than all the other ColdFire parts. I think this code originally
came from Freescale. I don't have a 532x board, so I have never been
able to change to much of that code and test it.

What sort of board do you have?  Is it the Freescale 5329EVB or your
own design?

Regards
Greg



Hi Christian,

On 24/01/13 00:12, Christian Gieseler wrote:

Or is the checksum
tested on a wrong value because I misconfigured an address.
Does someone have a hint how to solve this or where to look for a

solution?

The bootmessages are attached for reference.


Can you send the entire boot sequence?
I want to see all the load segment addresses that are earlier in the
boot

output.


Ok, this didn't have the information I was looking for after all :-(
Can you send the output of:

  m68k-linux-objdump --headers vmlinux

Not sure what your toolchain prefix is, but substitute in place of
m68k-linux-objdump for whatever the Code Sourcery name is.

m68k-uclinux-objdump --headers vmlinux

vmlinux: file format elf32-m68k

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
0 .text 001c9f70  4002  4002  2000  2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata   00026640  401ea000  401ea000  001cc000  2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 __ksymtab 45d8  40210640  40210640  001f2640  2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 __ksymtab_gpl 2318  40214c18  40214c18  001f6c18  2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 __kcrctab 22ec  40216f30  40216f30  001f8f30  2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 __kcrctab_gpl 118c  4021921c  4021921c  001fb21c  2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 __ksymtab_strings dfea  4021a3a8  4021a3a8  001fc3a8  2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 __param   0330  40228394  40228394  0020a394  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 __modver  193c  402286c4  402286c4  0020a6c4  2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .data 0001de40  4022a000  4022a000  0020c000  2**4
CONTENTS, ALLOC, LOAD, DATA
   10 .init.textd57c  40248000  40248000  0022a000  2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
   11 .init.data4a84  4025557c  4025557c  0023757c  2**2
CONTENTS, ALLOC, LOAD, DATA
   12 .bss  f24c  4025a000  4025a000  0023c000  2**4
ALLOC
   13 .comment  0030      0023c000  2**0
CONTENTS, READONLY


Ok, that looks good too. The romfs start address from you console boot
log:

  uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000

matches up with the end of the bss segment. Which is what I would expect.

I would suggest putting some printk trace around the ROMS checksum error
that dumps out what the memory contents of that first romfs block is.
Compare that with your original and see exactly what has changed. Is it just
a few bytes off, or has the whole thing been corrupted in some way?

Regards
Greg





___
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

Re: [uClinux-dev] ROMFS: bad initial checksum

[Greg Ungerer]

Hi Christian,

On 01/23/2013 06:45 PM, Christian Gieseler wrote:
 I am migrating our coldfire 5329 board to linux 3.6.
 I am stuck now with mounting of romfs having a bad initial checksum of the
 first 512 bytes. The system hangs after this message.
 Even if the functions in fs/romfs/inode.c have moved a bit from 2.6.25 to
 super.c and friends from what I can see the routines to 
 calculate the checksum are basically the same. Genromfs (0.5.1) on the host
 has not changed. Has the new Kernel any configuration option
 that has to be changed to generate a proper romfs.img?

No, nothing has changed in this area. I have run 3.6 kernels on
ColdFire boards using romfs setups the same as every kernel before.


 Or is the checksum
 tested on a wrong value because I misconfigured an address.
 Does someone have a hint how to solve this or where to look for a solution?
 The bootmessages are attached for reference.

Can you send the entire boot sequence?
I want to see all the load segment addresses that are earlier in
the boot output.

How do you load the kernel and romfs into RAM?
Are you positive that the romfs is entirely loaded at the address you
think it should be?

Regards
Greg


 ROMFS MTD (C) 2007 Red Hat, Inc.
 msgmni has been set to 23
 io scheduler noop registered
 io scheduler deadline registered
 io scheduler cfq registered (default)
 ColdFire internal UART serial driver
 ttyS0 at MMIO 0xfc06 (irq = 90) is a ColdFire UART
 console [ttyS0] enabled
 ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
 ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
 uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
 uclinux[mtd]: set ROMfs to be root filesystem
 Creating 1 MTD partitions on RAM:
 0x-0x0019c000 : ROMfs
 el5329 flash device: 100 at 0
 el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
 0x01 Chip ID 0x002101
 Amd/Fujitsu Extended Query Table at 0x0040
   Amd/Fujitsu Extended Query version 1.3.
 number of CFI chips: 1
 Creating 5 MTD partitions on  el5329 flash:
 0x-0x0002 : vectors
 0x0002-0x0006 : parameters
 0x0006-0x0010 : bootloader
 0x0010-0x0070 : image
 0x0070-0x0100 : user_data
 libphy: fec_enet_mii_bus: probed
 TCP: cubic registered
 NET: Registered protocol family 17
 ROMFS: bad initial checksum on dev romfs.
 
 
 
 ___
 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
 

___
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

Re: [uClinux-dev] ROMFS: bad initial checksum

[Greg Ungerer]

Hi Christian,

On 01/23/2013 11:25 PM, Christian Gieseler wrote:
 -Original Message-
 From: Greg Ungerer [mailto:gregunge...@westnet.com.au] 
 Sent: Wednesday, January 23, 2013 1:17 PM
 To: uClinux development list
 Cc: Christian Gieseler
 Subject: Re: [uClinux-dev] ROMFS: bad initial checksum

 Hi Christian,

 On 01/23/2013 06:45 PM, Christian Gieseler wrote:
 I am migrating our coldfire 5329 board to linux 3.6.
 I am stuck now with mounting of romfs having a bad initial checksum of 
 the first 512 bytes. The system hangs after this message.
 Even if the functions in fs/romfs/inode.c have moved a bit from 2.6.25 
 to super.c and friends from what I can see the routines to calculate 
 the checksum are basically the same. Genromfs (0.5.1) on the host has 
 not changed. Has the new Kernel any configuration option that has to 
 be changed to generate a proper romfs.img?

 No, nothing has changed in this area. I have run 3.6 kernels on ColdFire
 boards using romfs setups the same as every kernel before.
 
 Are there critical configuration options that I should check another time?

No, none really. Nothing has changed with regard to config options
you need set either.


 Or is the checksum
 tested on a wrong value because I misconfigured an address.
 Does someone have a hint how to solve this or where to look for a
 solution?
 The bootmessages are attached for reference.

 Can you send the entire boot sequence?
 I want to see all the load segment addresses that are earlier in the boot
 output.

Ok, this didn't have the information I was looking for after all :-(
Can you send the output of:

m68k-linux-objdump --headers vmlinux

Not sure what your toolchain prefix is, but substitute in place of
m68k-linux-objdump for whatever the Code Sourcery name is.


 Linux version 3.6.0-uc0 (christian@cglinux) (gcc version 4.6.1 (Sourcery
 CodeBench Lite 2011.09-23) ) #154 PREEMPT Wed Jan 23 14:04:49 CET 2013
 
 uClinux/COLDFIRE(m532x)
 COLDFIRE port done by Greg Ungerer, g...@snapgear.com
 Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
 Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 2024
 Kernel command line: rootfstype=romfs console=tty1 console=ttyS0,115200
 PID hash table entries: 2048 (order: 0, 8192 bytes)
 Dentry cache hash table entries: 2048 (order: 0, 8192 bytes)
 Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
 Memory available: 11992k/16256k RAM, (1831k kernel code, 508k data)
 NR_IRQS:256
 Calibrating delay loop... 154.62 BogoMIPS (lpj=77312)
 pid_max: default: 32768 minimum: 301
 Mount-cache hash table entries: 1024
 NET: Registered protocol family 16
 bio: create slab bio-0 at 0
 Switching to clocksource tmr
 NET: Registered protocol family 2
 TCP established hash table entries: 1024 (order: 0, 8192 bytes)
 TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
 TCP: Hash tables configured (established 1024 bind 2048)
 TCP: reno registered
 UDP hash table entries: 512 (order: 0, 8192 bytes)
 UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
 NET: Registered protocol family 1
 RPC: Registered named UNIX socket transport module.
 RPC: Registered udp transport module.
 RPC: Registered tcp transport module.
 RPC: Registered tcp NFSv4.1 backchannel transport module.
 ROMFS MTD (C) 2007 Red Hat, Inc.
 msgmni has been set to 23
 io scheduler noop registered
 io scheduler deadline registered
 io scheduler cfq registered (default)
 ColdFire internal UART serial driver
 ttyS0 at MMIO 0xfc06 (irq = 90) is a ColdFire UART
 console [ttyS0] enabled
 ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
 ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
 uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
 uclinux[mtd]: set ROMfs to be root filesystem
 Creating 1 MTD partitions on RAM:
 0x-0x0019c000 : ROMfs
 el5329 flash device: 100 at 0
 el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer 
 ID
 0x01 Chip ID 0x002101
 Amd/Fujitsu Extended Query Table at 0x0040
   Amd/Fujitsu Extended Query version 1.3.
 number of CFI chips: 1
 Creating 5 MTD partitions on  el5329 flash:
 0x-0x0002 : vectors
 0x0002-0x0006 : parameters
 0x0006-0x0010 : bootloader
 0x0010-0x0070 : image
 0x0070-0x0100 : user_data
 libphy: fec_enet_mii_bus: probed
 TCP: cubic registered
 NET: Registered protocol family 17
 ROMFS: bad initial checksum on dev romfs.
 
 
 How do you load the kernel and romfs into RAM?
 I use dbug as bootloader and copy image.bin via tftp and then execute from
 ram:
 
 Power-on Reset
 
 ColdFire MCF532x
 Firmware v4a.1a.1b.0100_1616 (Built on Nov  5 2009 15:47:58)
 Copyright 2005 Freescale Semiconductor, Inc.
 Enter 'help' for help.
 
 dBUG dn
 Downloading Image 'image.bin' from 192.168.10.254
 TFTP transfer completed 
 Read 3228676 bytes (6307 blocks)
 dBUG go 0x4002

Ok, good, that is pretty standard stuff

Re: [uClinux-dev] ROMFS: bad initial checksum

[Greg Ungerer]

Hi Christian,

On 24/01/13 00:00, Christian Gieseler wrote:

No, nothing has changed in this area. I have run 3.6 kernels on ColdFire

boards using romfs setups the same as every kernel before.

Can you tell me one example in the 20121024 release that you have
successfully running so that I can maybe have a look at the config.


Yeah, try the Freescale/M5208EVB. Here is its bootup trace
(this was generated from 20121004 and run today).

Regards
Greg



Linux version 3.6.0-uc0 (gerg@goober) (gcc version 4.5.1 (GCC) ) #1 Thu Jan 24 
09:59:43 EST 2013


uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4080
Kernel command line:
PID hash table entries: 2048 (order: 0, 8192 bytes)
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Memory available: 29832k/32768k RAM, (1372k kernel code, 327k data)
SLUB: Genslabs=15, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS:256
Calibrating delay loop... 109.46 BogoMIPS (lpj=547328)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024
NET: Registered protocol family 16
bio: create slab bio-0 at 0
Switching to clocksource pit
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 8192 bytes)
TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
TCP: Hash tables configured (established 1024 bind 2048)
TCP: reno registered
UDP hash table entries: 512 (order: 0, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
NET: Registered protocol family 1
ROMFS MTD (C) 2007 Red Hat, Inc.
io scheduler noop registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0xfc06 (irq = 90) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
brd: module loaded
uclinux[mtd]: RAM probe address=0x401c918c size=0xde000
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on RAM:
0x-0x000de000 : ROMfs
libphy: fec_enet_mii_bus: probed
TCP: cubic registered
NET: Registered protocol family 17
VFS: Mounted root (romfs filesystem) readonly on device 31:0.
Freeing unused kernel memory: 48k freed (0x401b - 0x401ba000)
Shell invoked to run file: /etc/rc
Command: hostname uClinux
Command: /bin/expand /etc/ramfs.img /dev/ram1
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram1 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: mkdir /var/empty
Command: mkdir /var/dhcpc
Command: ifconfig lo 127.0.0.1
Command: route add -net 127.0.0.0 netmask 255.0.0.0 lo
Command: dhcpcd -p -a eth0 
[22]
Command: cat /etc/motd
eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=fec-1:01, irq=-1)
Welcome to
   _  _
 /  __| ||_|
_   _| |  | | _   _   _  _  _
   | | | | |  | || |  _ \| | | |\ \/ /
   | |_| | |__| || | | | | |_| |/\
   |  ___\|_||_|_| |_|\|\_/\_/
   | |
   |_|

For further information check:
http://www.uclinux.org/

Execution Finished, Exiting

Sash command shell (version 1.1.1)
/

___
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

Re: [uClinux-dev] ROMFS: bad initial checksum

[Greg Ungerer]

Hi Christian,

On 24/01/13 00:12, Christian Gieseler wrote:

Or is the checksum
tested on a wrong value because I misconfigured an address.
Does someone have a hint how to solve this or where to look for a

solution?

The bootmessages are attached for reference.


Can you send the entire boot sequence?
I want to see all the load segment addresses that are earlier in the
boot

output.


Ok, this didn't have the information I was looking for after all :-( Can you
send the output of:

 m68k-linux-objdump --headers vmlinux

Not sure what your toolchain prefix is, but substitute in place of
m68k-linux-objdump for whatever the Code Sourcery name is.

m68k-uclinux-objdump --headers vmlinux

vmlinux: file format elf32-m68k

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
   0 .text 001c9f70  4002  4002  2000  2**2
   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .rodata   00026640  401ea000  401ea000  001cc000  2**4
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   2 __ksymtab 45d8  40210640  40210640  001f2640  2**1
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   3 __ksymtab_gpl 2318  40214c18  40214c18  001f6c18  2**1
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 __kcrctab 22ec  40216f30  40216f30  001f8f30  2**1
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   5 __kcrctab_gpl 118c  4021921c  4021921c  001fb21c  2**1
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   6 __ksymtab_strings dfea  4021a3a8  4021a3a8  001fc3a8  2**0
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   7 __param   0330  40228394  40228394  0020a394  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   8 __modver  193c  402286c4  402286c4  0020a6c4  2**1
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   9 .data 0001de40  4022a000  4022a000  0020c000  2**4
   CONTENTS, ALLOC, LOAD, DATA
  10 .init.textd57c  40248000  40248000  0022a000  2**1
   CONTENTS, ALLOC, LOAD, READONLY, CODE
  11 .init.data4a84  4025557c  4025557c  0023757c  2**2
   CONTENTS, ALLOC, LOAD, DATA
  12 .bss  f24c  4025a000  4025a000  0023c000  2**4
   ALLOC
  13 .comment  0030      0023c000  2**0
   CONTENTS, READONLY


Ok, that looks good too. The romfs start address from you console boot
log:

uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000

matches up with the end of the bss segment. Which is what I would
expect.

I would suggest putting some printk trace around the ROMS checksum
error that dumps out what the memory contents of that first romfs
block is. Compare that with your original and see exactly what has
changed. Is it just a few bytes off, or has the whole thing been
corrupted in some way?

Regards
Greg


___
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

Re: [uClinux-dev] Coldfire uClinux boot with u-boot

[Greg Ungerer]

Hi Steve,

On 01/12/2013 09:38 AM, Steve deRosier wrote:

I'm stuck trying to get Linux to boot from U-Boot on a Coldfire system
and I'd love some ideas of what to try next.

I'm upgrading a uClinux system from a 2.4 kernel to 3.3. Additionally
I'm trying to upgrade the boot-loader from u-boot 1.1.6 to release
2012.07.  The board is based on a MCF5235EVB. I did the Linux upgrade
first, and am successfully getting the existing system boot loader to
boot my upgraded Linux 3.3 images. Now I've moved on to upgrading u-boot.

I was able to get U-Boot to come up successfully and it recognizes my
Linux image and a bootm command starts just fine.  It does the checks,
uncompresses, and goes to boot.  I turned on the debug messages in
U-Boot, so I get the ## Transferring control to Linux (at address
0x2) ... message, it goes and does the jump and then...nothing...

Note that the exact same Linux image boots fine from 1.1.6.  My 1.1.6
can boot both the 2.4 legacy image as well as my new 3.3 image.

Unfortunately I've got minimal visibility into the system (My BDM
interface is being a PITA, I've got assembly-only stepping, using
CodeWarrior!!@#!@$!, in flash only.  Pretty much nothing else is
functioning right at the moment), so I've been relegated to
debug-via-printf, which isn't terribly useful at the interface between
u-boot and linux.


There is a couple of tricks I use to help debug in these difficult
types of scenarios.

First you really want to know if the kernel is even getting started
or not. So I throw in some raw console output into the assembler
kernel startup code (arch/m68k/platform/coldfire/head.S in this case).
For example something like this:

moveb   #'a', %d0
movel   #0x420c, %a0
moveb   %d0, (%a0)

(Completely untested and not checked in any way :-)
Very simple, just enough to get some idea if you are getting here or
not. Note that this assumes u-boot has already setup the serial port
to the baud, etc, that you expect. And don't expect anything much to
work after this, unless you know for sure that the registers used
here (%d0 and %a0 in this case) are not being used. Oh and of course
this isn't waiting for FIFO space or anything like that - this really
is quick and dirty stuff.

If you are getting into the kernel startup code, then take the trace
up to the C code level. Code up a simple console char output routine
(use the serial driver console routines as an example).

A lot of kernel code can run before the console is enabled and output
starts to come out.

Regards
Greg



Through reading code, I see a huge discrepancy between how 1.1.6 and
2012.07 starts the kernel.

1.1.6 uses a line:
theKernel (linux_argc, linux_argv, linux_env, 0);

2012.07:
/*
* Linux Kernel Parameters (passing board info data):
*   sp+00: Ignore, side effect of using jsr to jump to kernel
*   sp+04: ptr to board info data
*   sp+08: initrd_start or 0 if no initrd
*   sp+12: initrd_end - unused if initrd_start is 0
*   sp+16: Start of command line string
*   sp+20: End   of command line string
*/
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);

Clearly different... I'd assume that U-Boot's Linux starting magic is in
sync with the current Linux kernel, but if that's the case, and these
are actually as different as they appear, then the OLD U-Boot should
have a problem starting the NEW kernel also.  For grins, I grafted on
the old sequence code into the new U-Boot, but that (as expected) failed
also.

I looked at the Coldfire startup code and it looks like it corrosponds
to the same comment in U-Boot, and interestingly it seems to discard the
bd_t structure that's passed in first.

So far I think I've figured this out:
* The FDT isn't used on Coldfire targets.
* The Coldfire code discards the bd_t data passed in through u-boot.
* Something funky is going on keeping Linux from booting, and it happens
early enough that I can't see it in printk-land.

If it makes a difference, for some reason we load kernel at 0x2 and
jump to 0x2. This is a legacy of the existing project, I've tried to
change it to 0x0, but that didn't help either. I had suspected it had to
do with where the old bootloader placed itself in RAM, but it shouldn't
be an issue with the new bootloader.

For reference:
RAM: 0x, 32MB
SRAM: 0x2000
MBAR: 0x4000
Flash: 0xFFC0, 4mb (second flash module at 0xFF80, but U-Boot
doesn't know about that one). Image is stored at 0xFFC4 and uses an
initrd romfs immedately after the kernel

Basic setup and design is similar to the 5235EVB.

CONFIG_UBOOT, MTD_UCLINUX and MTD_UCLINUX_EBSS are all Y.
I've been bashing my head against this wall all week, so I'd love it if
anyone's got some ideas.

Thanks,
- Steve

5235IWI bootm 0xffc4
## Current stack ends at 0x01f2ca2c *  kernel: cmdline image address =
0xffc4
## Booting kernel from Legacy Image at ffc4 ...
Image Name:   IWI 007
Image Type:   M68K Linux Kernel Image (gzip 

Re: [uClinux-dev] Coldfire uClinux boot with u-boot

[Greg Ungerer]

Hi Steve,

On 01/16/2013 03:53 PM, Steve deRosier wrote:

Thanks to all that replied.

I'm still not 100% there, but finally got further.  Greg, I should've
just coded up the UART output like you suggested, but I had already
started using a GPIO pin I could easily access and hooked it up to my
oscope.  I did the same as you suggested, and popped it into head.S and
confirmed that u-boot was at least jumpping into the kernel.  Then I
used code similar to:

 *((volatile u8 *)0x401B) = (u8)(0x01);
 mdelay(10);
 *((volatile u8 *)0x401B) = (u8)(0x00);

and used that in the C startup code to trace through.  Eventually I
figured out it was getting stuck on my RTC driver (on my
platform_driver_register() call), commented that out, and it got far
enough to put stuff out the console.  Then it oopsed. This was durring
the second mtd map operation (I've got two flash chips on this thing):


Is the newer u-boot not setting up the SoC chip selects the same?
Might explain why its accessing devices that is giving you trouble.

Regards
Greg




.
.
.
Flash external probe(0xff40,4194304,2): 40 at ff40
bad frame format: 
Modules linked in:
PC: [00133650] cfi_qry_mode_on+0x8fe/0xf3e
SR: 2008  SP: 0183be58  a2: 0027a8f4
d0: 0002d1: ff40d2: d3: 0008
d4: f0f0d5: 0002a0: ff40a1: 0183bf6c
Process swapper (pid: 1, task=0183c000)
Frame format=4 eff addr=0024c92f pc=
Stack from 0183be94:
 0183bf32 0001 0002 0001 0183bf32 0027a8f4 
00131c36
  0027a8f4 0183bf32 0024c92f 004c 0183bf32 0001
0002
 0001 0027a8f4 0027a664 0012b4cc 000f3acc 00131b2e 0013a9d2
0027a8f4
   0183bf32 0024c92f 004c 6800 0027a8f4
01f6523a
 01f3cf70 00131ab0 0027a66c 0012b4cc 001d7a1c 00131b2e 0027a57c
0027
  0002 0001    

Call Trace: [00131c36] cfi_probe_chip+0x3c/0xaee
  [0024c92f] packet_seq_ops+0x59fc9/0x65b86
  [0012b4cc] mtd_device_parse_register+0x0/0xc8
  [000f3acc] memset+0x0/0x7c
  [00131b2e] do_map_probe+0x0/0xb6
  [0013a9d2] mtd_do_chip_probe+0x8e/0x3d8
  [0024c92f] packet_seq_ops+0x59fc9/0x65b86
  [00131ab0] get_mtd_chip_driver+0x0/0x7e
  [0012b4cc] mtd_device_parse_register+0x0/0xc8
  [001d7a1c] printk+0x0/0x18
  [00131b2e] do_map_probe+0x0/0xb6
  [00131bf4] cfi_probe+0x10/0x16
  [00131b52] do_map_probe+0x24/0xb6
  [001d7a1c] printk+0x0/0x18
  [0028f9b4] m5235_mtd_init+0xb8/0x16e
  [0024c92f] packet_seq_ops+0x59fc9/0x65b86
  [0028f8fc] m5235_mtd_init+0x0/0x16e
  [000200c8] do_one_initcall+0x0/0x1d8
  [000201d8] do_one_initcall+0x110/0x1d8
  [000200c8] do_one_initcall+0x0/0x1d8
  [0028666a] kernel_init+0x82/0x106
  [0028f8fc] m5235_mtd_init+0x0/0x16e
  [002865e8] kernel_init+0x0/0x106
  [00020a3a] kernel_thread+0x2a/0x3c

Code: 4cd7 1cfc 4fef 0024 4e75 2041 d1c2 3084 6000 f7f0 2204 2e05 e989
e78c e3af 8a87 2205 e9a9 8a81 6000 f832 2041 d1c3 1085
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!


So, I'm out of the woods so to speak, but not quite there yet.  What I'm
totally flummoxed by is the fact that these drivers (indeed, the whole
kernel and the stuff in userspace) works just fine booted from the old
u-boot, but crap out from the new u-boot.  Clearly I've done something
wrong here, but I'm not sure what or how.  Based on behavior, I'm going
to be taking a very close look at the RAM allocations and stack space.
Though the stack pointer above is within my address space (32M, starting
at 0, so 0x to 0x0200). Mayhaps I'm running over my stack,
hence a bad frame format: ?  Not 100% sure of that particular
message, got to look that up.

Anyway, this is as far as I got today, tomorrow I'm going to be
examining the oops in detail and figure out why/what's going on.

I can't immagine what the difference between the old u-boot and the new
one would be that could cause the kernel to work in former case but
totally crash in the latter. I'm open to suggestions.

Thanks,
- Steve



___
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

Re: [uClinux-dev] m68k nommu: build failure in v3.8-rc2

[Greg Ungerer]

Hi Richard,

On 01/06/2013 10:26 PM, Richard Cochran wrote:

I see the following error, using the .config inline, below.

arch/m68k/mm/init.c: In function 'print_memmap':
arch/m68k/mm/init.c:139:2: error: 'KMAP_START' undeclared (first use in this 
function)
arch/m68k/mm/init.c:139:2: note: each undeclared identifier is reported only 
once for each function it appears in
arch/m68k/mm/init.c:139:2: error: 'KMAP_END' undeclared (first use in this 
function)

Looks to me like KMAP_START is only meant for the MMU case. This error
was possibly caused by one of these two patches.

$ pr v3.7.. -- arch/m68k/mm/init.c
f50bf88 m68k: move to a single instance of free_initmem()
dd1cb3a m68k: merge MMU and non-MMU versions of mm/init.c

What is the right fix for this?


This is the planned fix:

http://marc.info/?l=linux-m68km=135088484810474w=2

Well actually it was meant to go in before the above changes. I
have it queued to go to Linus soon. Just awaiting another fix
for non-mmu 68000 build issues so I can send them all together.

Regards
Greg



---
#
# Automatically generated file; DO NOT EDIT.
# Linux/m68k 3.8.0-rc2 Kernel Configuration
#
CONFIG_M68K=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_CSUM=y
CONFIG_TIME_LOW_RES=y
CONFIG_NO_IOPORT=y
# CONFIG_NO_DMA is not set
CONFIG_ZONE_DMA=y
CONFIG_HZ=100
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_DEFAULT_HOSTNAME=(none)
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y




___
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

Re: [uClinux-dev] Segmentation fault while running some applications!

[Greg Ungerer]

Hi Arshan,

On 12/13/2012 12:11 AM, Arshan Awais wrote:

I have tried to compile the kernel by disabling the MMU, but it gives
following errors during compilation:


No, you don't want to do that. Having the MMU enabled is fine in
this case.

I would guess from your original dump that the code is most
likely executing code in uClibc (I assume that is what you are
using if you are building with the uClinux-dist).

Try this from the command line of your AT91SAM9X platform:

cat /proc/self/maps

I expect you will see something like:

8000-00085000 r-xp  1f:02 1141   /bin/sh
0008d000-00092000 rw-p 0007d000 1f:02 1141   /bin/sh
00092000-0009e000 rwxp 00092000 00:00 0  [heap]
4000-40005000 r-xp  1f:02 1286522/lib/ld-uClibc-0.9.29.so
40005000-40006000 rw-p 40005000 00:00 0
4000c000-4000d000 r--p 4000 1f:02 1286522/lib/ld-uClibc-0.9.29.so
4000d000-4000e000 rw-p 5000 1f:02 1286522/lib/ld-uClibc-0.9.29.so
4000e000-4005b000 r-xp  1f:02 1287024/lib/libuClibc-0.9.29.so
4005b000-40062000 ---p 4005b000 00:00 0
40062000-40063000 r--p 0004c000 1f:02 1287024/lib/libuClibc-0.9.29.so
40063000-40064000 rw-p 0004d000 1f:02 1287024/lib/libuClibc-0.9.29.so
40064000-40067000 rw-p 40064000 00:00 0
bedce000-bedd rwxp beffe000 00:00 0  [stack]


Compare what you find with your dump addresses.

Regards
Greg



In file included from arch/arm/mm/proc-arm926.S:36:
arch/arm/mm/proc-macros.S:81:2: error: #error PTE shared bit mismatch
arch/arm/mm/proc-macros.S:84:2: error: #error PTE bufferable bit mismatch
arch/arm/mm/proc-macros.S:87:2: error: #error PTE cacheable bit mismatch

I am a bit confused about disabling the MMU because AT91SAM9X has MMU
support...can u make me clear about that?

On Wed, Dec 12, 2012 at 2:01 PM, Arshan Awais arshanc...@gmail.com wrote:

Thanks for reply Greg!

No, the MMU is enabled in the kernel configuration.

On Tue, Dec 11, 2012 at 6:51 AM, Greg Ungerer
gregunge...@westnet.com.au wrote:

Hi Arshan,


On 12/04/2012 03:32 PM, Arshan Awais wrote:


hi,
i m having an issue when i run iptables on AT91SAM9X in uClinux. I get
following messages when i run iptables command:

# iptables -v
pgd = c0474000
[198c] *pgd=203f0031, *pte=, *ppte=

Pid: 372, comm: iptables
CPU: 0 Not tainted (2.6.30.4-uc0 #195)
PC is at 0x401446c4



You need to figure out where this address is.

Are you truly running with MMU disabled?
You will pretty easily be able to tell from your kernel .config.

Regards
Greg



LR is at 0x9ad0
pc : [401446c4] lr : [9ad0] psr: 6010
sp : bef16d50 ip : 401446c0 fp : 
r10: 40025000 r9 :  r8 : 
r7 : 0002 r6 : bef16eb4 r5 : bef16f8f r4 : 198c
r3 : 198c r2 :  r1 : 198c r0 : 198c
Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 0005317f Table: 20474000 DAC: 0015
[c00282c4] (show_regs+0x0/0x50) from [c002cd64]
(__do_user_fault+0x5c/0xa4)
r5:198c r4:c1c5b9c0
[c002cd08] (__do_user_fault+0x0/0xa4) from [c002d020]
(do_page_fault+0x1f8/0x230)
r7:c182a214 r6:c1c5b9c0 r5:00o_Dat0026d40]
(ret_from_exception+0x0/0x10)
Exception sto 0xc12f5ff8)
5fa0: 198c 198c  198c
5fc0: 198c bef16f8f bef16eb4 0002   40025000

5fe0: 401446c0 bef16d50 9ad0 401446c4 6010 
Segmentation fault

Kindly help me solving the issue...
___
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







___
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

Re: [uClinux-dev] Segmentation fault while running some applications!

[Greg Ungerer]

Hi Arshan,

On 12/04/2012 03:32 PM, Arshan Awais wrote:

hi,
i m having an issue when i run iptables on AT91SAM9X in uClinux. I get
following messages when i run iptables command:

# iptables -v
pgd = c0474000
[198c] *pgd=203f0031, *pte=, *ppte=

Pid: 372, comm: iptables
CPU: 0 Not tainted (2.6.30.4-uc0 #195)
PC is at 0x401446c4


You need to figure out where this address is.

Are you truly running with MMU disabled?
You will pretty easily be able to tell from your kernel .config.

Regards
Greg



LR is at 0x9ad0
pc : [401446c4] lr : [9ad0] psr: 6010
sp : bef16d50 ip : 401446c0 fp : 
r10: 40025000 r9 :  r8 : 
r7 : 0002 r6 : bef16eb4 r5 : bef16f8f r4 : 198c
r3 : 198c r2 :  r1 : 198c r0 : 198c
Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 0005317f Table: 20474000 DAC: 0015
[c00282c4] (show_regs+0x0/0x50) from [c002cd64] (__do_user_fault+0x5c/0xa4)
r5:198c r4:c1c5b9c0
[c002cd08] (__do_user_fault+0x0/0xa4) from [c002d020]
(do_page_fault+0x1f8/0x230)
r7:c182a214 r6:c1c5b9c0 r5:00o_Dat0026d40] (ret_from_exception+0x0/0x10)
Exception sto 0xc12f5ff8)
5fa0: 198c 198c  198c
5fc0: 198c bef16f8f bef16eb4 0002   40025000 
5fe0: 401446c0 bef16d50 9ad0 401446c4 6010 
Segmentation fault

Kindly help me solving the issue...
___
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



___
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

Re: [uClinux-dev] [PATCH] m68k: move to a single instance of free_initmem()

[Greg Ungerer]

Hi Geert,

On 11/11/12 20:43, Geert Uytterhoeven wrote:

On Tue, Oct 23, 2012 at 5:40 AM,  g...@snapgear.com wrote:

[snip]

  void free_initmem(void)
  {
-#ifdef CONFIG_RAMKERNEL
+#ifndef CONFIG_MMU_SUN3
 unsigned long addr;

-   /*
-* The following code should be cool even if these sections
-* are not page aligned.
-*/
-   addr = PAGE_ALIGN((unsigned long) __init_begin);
-   /* next to check that the page we free is not a partial page */
-   for (; addr + PAGE_SIZE  ((unsigned long) __init_end); addr += 
PAGE_SIZE) {
+   addr = (unsigned long) __init_begin;
+   for (; addr  ((unsigned long) __init_end); addr += PAGE_SIZE) {
 ClearPageReserved(virt_to_page(addr));
 init_page_count(virt_to_page(addr));
 free_page(addr);
 totalram_pages++;
 }
 pr_notice(Freeing unused kernel memory: %luk freed (0x%x - 0x%x)\n,
-   (addr - PAGE_ALIGN((unsigned long) __init_begin))  10,
-   (int)(PAGE_ALIGN((unsigned long) __init_begin)),
-   (int)(addr - PAGE_SIZE));
-#endif
+   (addr - (unsigned long) __init_begin)  10,
+   (unsigned int) __init_begin, (unsigned int) __init_end);


Which is now BTW almost identical to free_initrd_mem(), so the common
parts can be extracted in a helper function.


Indeed it can. Well spotted :-)

Patch coming up.

Regards
Greg



Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
___
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