uCLinux on connect me

Question

Hi there. Don't know does this really belong under this category, but it is related to ME.

So is there anyone runnin uCLinux on this device? I found a port (armadillo-j) on the net, which is based on Connect ME. Now we have the linux image, but no working bootloader. I'm not very experienced with the GNU toolchain so this might also be my stupidity:P

With Armadillo they ship a hermit bootloader (hermitXK.bin) which should work. I've tried to program it with naftpapp and it is recognized as proper image -> flashing starts, but then it stops saying something about image transfer error. And if I have understood correctly, this bootloader should be used to program the "real" linux image to the device.

Now I have hermit sources, but it seems I can't compile a proper image from it - Flash header seems to be different and it is not recognized as proper image (I'm probably missing something here, linker switch maybe - to tell which kind of a header we would need?)

Second problem is related to elf files. When I try to load an elf to gdb it says "Dwarf error: Bad offset (0x60000000) in compilation unit header (offset 0x0 +6)

We are trying to compile these under linux using arm-elf toolchain 20030314. arm-elf gcc is version 2.95.3.

Thanks in advance if someone can help.

Answer 1

I've been working on an ARM port of kgdb and ran into the same Dwarf error. In your linker script (a .ld file) you need to add the following lines to force all Dwarf addresses to zero:

/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }


- Josh

Answer 2

I have been looking seriously at uCLinux because of the serious bugs in NetOS. Please post comments during your development to tell us all how it goes.

Thanks,
-Erik

P.S. BTW - How much does the armidillo package cost? I haven't studied Japanese in 20 years and so can't read the website.

Answer 3

egawtry,

What are the serious bugs you're talking about? I'm fighting against a serial port dying without any error code in the several primitives I'm calling, so I'm interested!

-- bugfixer

Answer 4

Thanks alot for your help. We were now able to compile the hermit loader, but for the next (newbie) problem. When I try to run the elf in the debugger, i get the following error:

(gdb) source ../../../gdbconnectme.raven
Setting up the environment for debugging gdb.
The target is assumed to be big endian
../../../gdbconnectme.raven:270: Error in sourced command file:
No struct type named bios_comm.

So what are is this bios_comm and bcomm entries for in the gdbconnectme.raven? Should I just comment them out or...? Any pointers to a documentation are welcome!

--Juha

Answer 5

For the serial port problem, try using a mutex on the output so each thread waits for its turn. That fixed it for me. Also stop using the built-in printf() and putchar() functions.

The bugs I was referring to are the Sockets API bugs, specifically the select() bug (it is not reenterant!).