Hallo,

Could you post the information dump from `arm-elf-objdump -x vmlinux_266`?
It looks like the .elf file is -possibly- being loaded at 0x10000000?
What do the elf headers say?

mt

Hi again

"old" embedix linux/src/arch/arm/boot/Makefile:

Quote:

ifeq ($(CONFIG_ARCH_LH79520),y)
ZTEXTADDR = 0x40100000
ZBSSADDR = 0x20300000
ZRELADDR = 0x200c8000
INITRD_PHYS = 0x20400000
INITRD_VIRT = 0xC0400000
PARAMS_PHYS = 0x200c0000
endif

In new the 2.6.6 kernel one (linux/src/arch/arm/boot/Makefile) i am using "integrator" config (first time try):

Quote:

zreladdr-$(CONFIG_ARCH_INTEGRATOR) := 0x200C8000
params_phys-$(CONFIG_ARCH_INTEGRATOR) := 0x200C0000
initrd_phys-$(CONFIG_ARCH_INTEGRATOR) := 0x20400000

linux/src/arch/arm/Makefile:

"old" embedix one:

Quote:

ifeq ($(CONFIG_ARCH_LH79520),y)
# C0008000 is the default, so not needed -- DDD
MACHINE = lh79520
ifeq ($(CONFIG_LPD_79520_10),y)
TEXTADDR = 0xc00c8000
endif
endif

new 2.6.6 one:

Quote:

textaddr-y := 0xC00C8000

I rebuilt the stuff with following result:

(the vmlinux is the one from: crosstool-0.28-rc28/build/arm-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/linux-2.6.6/arch/arm/boot/compressed/vmlinux)

Quote:

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/arm-softfloat-linux-gnu-objdump -fp vmlinux

vmlinux: file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00000000

Program Header:
LOAD off 0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**15
filesz 0x000b88f0 memsz 0x000c0d28 flags rwx
private flags = 200: [APCS-32] [FPA float format] [software FP]

... whoops load address = 0????

There gets another "vmlinux" image created in "linux/src" root dir:

Quote:

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/arm-softfloat-linux-gnu-objdump -fp vmlinux

vmlinux: file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0xc00c8000

Program Header:
LOAD off 0x00008000 vaddr 0xc00c8000 paddr 0xc00c8000 align 2**15
filesz 0x00185900 memsz 0x00198634 flags rwx
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]

This looks right but failed to load via TFTP too (copied over to tftpboot dir as vmlinux_266)

Quote:

losh> load elf /tftp/198.120.75.6:/vmlinux_266
loading from /tftp/198.120.75.6:/vmlinux_266:
Reverything went wrong, fsr: e59f0005 far: c00c8000
r00: c00c8000 r01: 20042925 r02: 000001fe r03: 00000000
r04: 00000200 r05: 200428e8 r06: 00000000 r07: 00020000
r08: c00c8000 r09: 2003de48 r10: 00000005 r11: 2003dd3c
r12: c00c8001 sp: 2003dd30 lr: 20013234 pc: 200108d4
spsr:00000053 cpsr:000000d7
bt: sp: 2003dc84 (stack: 2003cdd0 - 2003e2d0)
0: fp:2003dcac + 40 20000388() called from: 20003f44
1: fp:2003dcc4 + 20 20003f04() called from: 20001150
2: fp:2003dce4 + 28 20001098() called from: 200002bc
3: fp:2003dd3c + 84 200108b0() called from: 20013230
4: fp:2003dd60 + 32 200130fc() called from: 20002ad8
5: fp:2003dd84 + 32 20002a58() called from: 20007ab0
6: fp:2003deb4 + 300 20007620() called from: 20004f80
7: fp:2003e03c + 388 20004f30() called from: 20006d08
8: fp:2003e094 + 84 20006bbc() called from: 20006da0
9: fp:2003e2b4 + 540 20006d34() called from: 20003afc
10: fp:2003e2cc + 20 20003ad4() called from: 20003ad0
(fp:2003e2cc->2003dc4c, sp:2003e2d0)

Whats the problem here?

Regards

Hello again,

i've read some interesting information about alternative boot loaders like "BLOB" from

http://projects.buici.com/arm/

I have no JTAG for download yet so i tried to use the logicloader to download the prebuild ELF image from website but failed:

Quote:

losh> load elf /tftp/198.120.75.6:/wblob
loading from /tftp/198.120.75.6:/wblob:
Reverything went wrong, fsr: e59f0005 far: 60000000
r00: 60000000 r01: 20042925 r02: 000001fe r03: 0000005a
r04: 00000200 r05: 200428e8 r06: 00000000 r07: 00003e60
r08: 60000000 r09: 2003de48 r10: 00000005 r11: 2003dd3c
r12: 60000001 sp: 2003dd30 lr: 20013234 pc: 200108d4
spsr:00000053 cpsr:000000d7
bt: sp: 2003dc84 (stack: 2003cdd0 - 2003e2d0)
0: fp:2003dcac + 40 20000388() called from: 20003f44
1: fp:2003dcc4 + 20 20003f04() called from: 20001150
2: fp:2003dce4 + 28 20001098() called from: 200002bc
3: fp:2003dd3c + 84 200108b0() called from: 20013230
4: fp:2003dd60 + 32 200130fc() called from: 20002ad8
5: fp:2003dd84 + 32 20002a58() called from: 20007ab0
6: fp:2003deb4 + 300 20007620() called from: 20004f80
7: fp:2003e03c + 388 20004f30() called from: 20006d08
8: fp:2003e094 + 84 20006bbc() called from: 20006da0
9: fp:2003e2b4 + 540 20006d34() called from: 20003afc
10: fp:2003e2cc + 20 20003ad4() called from: 20003ad0
(fp:2003e2cc->2003dc84, sp:2003e2d0)

Seems i missed that:

Quote:

. The elf binary, wblob, includes the elf header which makes it a good candidate for loading via wiggler, BDI2000, or LogicLoader when they fix their code.

When does this get fixed?
It seems to have some coincedence with the linux kernel images download crashes i described in previous posts.

I dont know what causes the crash, would it sound feasible to make the ELF download via TFTP stuff more robust and possible print out some more "debugging" information so one gets to know what/why this happens?

Regards

Hi, sorry I didn't answer sooner, I wrote a reply and then forgot to hit 'submit'. I think your linux image should be linked to run at 0xc..., which it is, but it should have elf headers telling it to load at 0x2..., which it doesn't. Lolo runs in physical memory addressing (SDRAM at 0x20000000), and virtual mapping (SDRAM at 0xc0000000) doesn't come into effect until linux is started. You should be able to use objcopy to adjust the load address in the vmlinux image program header.

Hi again

thanks to your suggestion the _download_ works now:

Quote:

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/arm-softfloat-linux-gnu-objdump -fp vmlinux

vmlinux: file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0xc00c8000

Program Header:
LOAD off 0x00008000 vaddr 0xc00c8000 paddr 0xc00c8000 align 2**15
filesz 0x0016cf70 memsz 0x0017df54 flags rwx
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]

changing the load/start addr:

Quote:

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/arm-softfloat-linux-gnu-objcopy --change-addresses -0xA0000000 vmlinux vmlinux.new

verifying:

Quote:

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/arm-softfloat-linux-gnu-objdump -fp vmlinux.new

vmlinux.new: file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x200c8000

Program Header:
LOAD off 0x00008000 vaddr 0x200c8000 paddr 0x200c8000 align 2**15
filesz 0x0016cf70 memsz 0x0017df54 flags rwx
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]

Looks ok, copy to tftpboot image (vmlinux_266)
Using Lolo:

Quote:

losh> load elf /tftp/198.120.75.6:/vmlinux_266
loading from /tftp/198.120.75.6:/vmlinux_266:
R............
elf file type : 0x0002
machine type: 0028 version: 1
prog start addr : 0x200c8000
num prog headers: 1
num sect headers: 14
offset : 0x00008000 disk length: 0x0016cf70 mem len: 0x0017df54
phyaddr: 0x200c8000 vaddr : 0x200c8000 dl addr: 0x200c8000
ignoring rest of file... 364935 bytes. done
running md5sum on the _loaded_ portion of the file:
82986dc688d009e3ebde540d2e35a40c - addr: 200c8000 len: 0016cf70

Try to execute it:

Quote:

losh> exec

Nothing happens ... no "uncompressing Linux" whatever message

Does the kernel you're trying to build have support for the 79520?
Unless you've hacked over some stuff from the lineo tree, I wouldn't expect it to get very far. IIRC, there's rudimentary serial port support in the uncompressor (that's where the "Uncompressing linux..." comes from.) It's probably similar to the a400/a404 that Marc Singer has been working on.

Quote:
Unless you've hacked over some stuff from the lineo tree, I wouldn't expect it to get very far.

Thats true. I've looked into lineo/lpd port stuff

patches
kernel config
linux/arch/arm/*
linux/arch/arm/mach-lh79520/*

just to realize its much work to get this board supported with a stock 2.6.x kernel from arm-linux (organisational changes 2.4.x -> 2.6.x apply additional penalties).

I've seen your name in arch* files as maintainer so you seem to be the one who ported the lineo stuff to this board

Do you know of any work in progress to get LH795xx board supported like its already done with LH7A4xx series in stock arm-linux kernel?

Well i guess i have to stick to another approach which comes to my mind.
I've got a working newer toolchain (gcc 3.3.3, glibc 2.3.2) which is built from 2.4.24 stock kernel.
If i extract the lineo patched 2.4.17-rmk2-lineo5 kernel includes to new toolchain build dir and rebuild the whole 3.3.3 toolchain it might be possible to build additional kernel drivers based on new toolchain and add them to kernel which was built using the 2.95.x toolchain.

The application development would be done from same, newer toolchain too.
All the stuff (glibc, libstdc++) would be linked statically, leaving the older userland applications including their dependencies to older glibc (dynamic) in place.
That way the userland application can be implemented and deployed completely separate from the lineo/logicpd BDK stuff.

Does this sound feasible?

Regards

I noticed that there is an entry for lpd79520 at http://www.arm.linux.org....developer/machines/, might be worth checking out <!-- s:o --><!-- s:o -->)

All of the sharp chips use the ARM PrimeCell peripherals, more or less, so I guess in theory it wouldn't be that much work to get it going, since it appears that a lot of these drivers already exist. Theory would be a nice place to work, of course.

mt

Hello again

yes there is an entry but it doesnt necessarily mean stock kernel support.
Let me quote some answer .. figure the rest.

Quote:

To be perfectly honest with you, we [...] haven't done much with Linux on the 79520 other than verify that the work Sharp paid Embedix to do can be built and used.
I know that Embedix doesn't necessarily do things in a "standard" way and you'll have to do some tweaking to get it to do the things you want it to.

Anyway i am happy with my crosstool based toolchain for now.
I got a working 3.3.3 gcc, glibc 2.3.2 and gdb 6.1.1 full cross.
I already replaced some of the rather old userland stuff (latest busybox, tinylogin...) and it works great.

I can locally and remotely debug userland binaries with latest gdb/gdbserver.
I managed to get some very nice low cost JTAG solution to work with LogicPDs LH79520 board and my GDB using OcdLibRemote over raven/wiggler interface to debug loader and linux kernel.

I am now fully concentrating on replacing the boot loader, manage some kernel driver development and developing userland applications.

Maybe in a future project we might think of completely dropping the Embedix stuff...

Regards

load elf /tftp/xx.xx.xx.xx:/vmlinux
R

and then it hangs.

objdump -fp vmlinux

vmlinux: file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x20008000

Program Header:
LOAD off 0x00008000 vaddr 0x20008000 paddr 0x20008000 align 2**15
filesz 0x00152580 memsz 0x0017cfbc flags rwx
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]


I've also tried this with the addresses changed to 0x200C8000. Some results (none).

The kernel was generated with a non-bdk toolchain, but it still shouldn't hang. I'd settle for a message telling me what the problem is. (The "VMLINUX" kernel I downloaded seems to load OK.)

Ken

lolo is running in the space from 0x20000000 - 0x200c0000,
so you're loading linux right over it.