Re: [uCsimm] ucsimm-head.S broken?

From: Tom Walsh (tom@mytoys.com)
Date: Wed Jan 19 2000 - 17:49:39 EST


Vladimir,

    This an interesting problem... I got less effective results with your
2.0.38.1pre1 sources (unpatch with the diff you had on the site) than I did with the
RT-Controls distro! Here are the details, I get the ABCDEF, so we can assume that:

* the rom is configured (mapped) correctly (maybe, more later).
* the DRAM is mapped correctly, and the size is correct as the stack is being used
in the putc calls.
* the MPU no longer bus faults, but runs merrily along wiggling the address / data
lines.

    As to the rom, I placed a printk ("Here I am\r\n") into the beginning of the
linux/init/main.c, but this message did not appear on the serial port. This
assuming that printk() immediately writes? If not, I will code an interface into
putc that will emit a 'Here!' string via the uart. The assumption being made here is
that the printk will run as is without being initialized(?) and that printk does not
buffer data when the interrupts are not used on the serial port.

    I checked the System.map file and the address of start_kernel is in the correct
range, 0x10000be4, so it appears that it would call that routine... I tried to put
a _start() function call into the start_kernel function, trying to make it loop on
sending 'ABCDEF', no good on the first go around, I simply did a 'make'. After
'make dep ; make clean ; make linux.bin' I did get it to loop on the 'ABCDEF', so I
have a debug 'Here!'. Why do I have to do a full recompile, this seems weird, is it
because the source tree is a series of makes and there is intermediate linking of
some kind being done?

    I did rework the sources, I made a new config type named 'CONFIG_EZ328SIMM',
grepped the sources on 'CONFIG_UCSIMM' and made any necessary adjustments to the
sources to reflect my board design. I did this by adding new 'def' or 'defined'
sections so as not to conflict with the uCsimm stuff. I did find the memory.c file
which defines the hardcoded ram limits of allocation / deallocation...

Comments apprecitated!!!

TomW

--
Tom Walsh - Embedded Systems Consultant - tom over_at mytoys(.)com
'www.mytoys.com', 'www.openhardware.net', 'www.cyberiansoftware.com'
"Windows? No thanks, I have work to do..."

This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST