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

From: Tom Walsh (tom@mytoys.com)
Date: Tue Jan 18 2000 - 23:12:26 EST


"Vladimir A. Gurevich" wrote:

> Hello Tom,
>
> Tom Walsh wrote:
>
> > I have started the attempt to bring uClinux up on my platform and have a
> > question about line #43 of the
> > ../linux/arch/m68knommu/platforms/68EZ328/ucsimm-head.S file. The instruction
> > there is a 'movew #0x10B, FFFFF902' and the comment is that it is setting the
> > baud rate to 9600, but this value doesn't set it to that rate.
> > A value of '0x0038' (as advertised in the manual) does give 9600 baud.
>
> Several comments:
>
> 1) Besides all UART-related registers (0xFFFFF9xx) there is one more that
> has a visible effect on the actual baud rate. I am talking about PRESC
> bit in PLLCR register. It should be cleared in order for the values in
> the table 11-3 (pages 11-7, 11-8 in MC68EZ328 UM) to produce correct
> values. By default, this bit is not cleared, but I checked that
> all *head.S files (*/crt0_r[ao]m.S in 2.0.38.1pre1 clear it).
>
> 2) According to the Table 11-3 0x0038 will give you 115200 baud and I am
> pretty sure this is correct, since I use it my ports and had no problems.
> You might want to look at ads-head.S and alma_ans-head.S
>
> 3) According to the same table the right value for 9600 baud is 0x0226. And
> actually, this table is encoded in drivers/char/68328serial.c in
> hw_baud_table[].
>
> 4) The value that you are mentioning, 0x10b was taken from the old xcopilot
> code. It might still be correct for 9600 baud. The way the prescaler works
> is a little obscure, but you might want to try to do the calculations.
> I would not suggest using it.
>
> Happy hacking,
> Vladimir
>

Vladimir,

    It seems to be a bit strange, while I was bringing up the board and getting my
flashloader built I had the '*.b' file programmmed to dump 0x0038 into 0xfffff902 to
get 9600 baud, oh well, there has been much going on here in the last 5 days, I
could be mistaken.

    The problem with the ucsimm-head.S file did not turn out to be the baudrate. I
tried to get the board to send the diagnostic 'ABCDEF', but it wouldn't. I did
finally get the board to send these once I edited the 'ucsimm.ld' file's memory map
to match something like my own, I am using an 8 meg flash store and I couldn't get
the flash to use the MEMORY map of the ucsimm. I still am working my way through
that file, why is the 1 meg flash memory mapped to 0x10c00000? Why isn't it mapped
to 0x10000000 even? This is causing me problems in mapping my memory <sigh>.

    I got my board to emit the 'ABCDEF' and the ucsimm copyright, then it buss
faults: the address lines stop "wiggling", so I am going after the ld file mapping,
tomorrow. If I have to do a lot of printk stuff to track down the problem, it will
have to be done on the PII-350 workstation, as the laptop is only a P1-300.

    You use the /linux/arch/m68knommu/platforms/68EZ328/ads_flash.ld for the Mot
eval board? Maybe I'd be better off using the kernel that you have (actually the ld
file + sources) as I wish to have the entire o/s running in DRAM and leave the Flash
for a database store / update.

    Sorry OM, it is late and has been "a long day at the button"...

Regards,

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