[ECOS] SA11x0 platform port problems

[ECOS] SA11x0 platform port problems

[Nathan J Ickes]

I'm doing platform ports for two custom boards, one based on the
SA1110 and one on the SA1100. Both are similar to the Assabet board,
with the notable exception that they use SRAM (1MB) instead of
Assabet's SDRAM. I'm having the same problem with RedBoot on both
boards: on boot, both boards print the following:

+
RedBoo

and then apparently die. Coincidentally (or not), that's a total of
eight characters (two for the '\n', and not counting '+', which isn't
part of the printf() call), exactly the length of the hardware
transmit FIFO in the SA11x0. This makes me suspect I have an interrupt
problem, except that RedBoot runs fine on my Assabet board, and I
don't see what's different. It wouldn't surprise me if there was
another hardcoded reference to the DRAM bank somewhere in there, but I
haven't found anything. Anybody else seen this sort of problem?

Where does that '+' character come from? I notice that the Assabet
board also prints a character before the "\nRedBoot..." string, but on
that board, the character is non-ASCII. Is this a garbage character
that's due to the way the serial port is initialized, or is it
intentional?

Also, I noticed that the ARM vectors.S appears to miscalculate the
reset vector: the first eight instructions of the _platform_setup1
macro are skipped. The easy solution is of course to add eight nop
instructions to the start of the macro, and I notice that the Brutus
platform port does exactly this. The nops are missing from the Assabet
port, though, and this makes the board very flaky about booting up. Is
this miscalculation a feature (if so, for what purpose?), or a bug?

-- Nathan Ickes

RE: [ECOS] SA11x0 platform port problems

[Gary Thomas]

 
On 26-Feb-2001 Nathan J Ickes wrote:
> I'm doing platform ports for two custom boards, one based on the
> SA1110 and one on the SA1100. Both are similar to the Assabet board,
> with the notable exception that they use SRAM (1MB) instead of
> Assabet's SDRAM. I'm having the same problem with RedBoot on both
> boards: on boot, both boards print the following:
> 
> +
> RedBoo
> 
> and then apparently die. Coincidentally (or not), that's a total of
> eight characters (two for the '\n', and not counting '+', which isn't
> part of the printf() call), exactly the length of the hardware
> transmit FIFO in the SA11x0. This makes me suspect I have an interrupt
> problem, except that RedBoot runs fine on my Assabet board, and I
> don't see what's different. It wouldn't surprise me if there was
> another hardcoded reference to the DRAM bank somewhere in there, but I
> haven't found anything. Anybody else seen this sort of problem?
> 

You might be able to determine more about this by putting a huge spin
loop inside of 'cyg_hal_plf_serial_putc()' (in hal/arm/sa11x0/var/current/hal_diag.c),
just to see if it is a timing issue.

BTW, what tools are you using?  Did you build the RedBoot that you
run on the Assabet?

> Where does that '+' character come from? I notice that the Assabet
> board also prints a character before the "\nRedBoot..." string, but on
> that board, the character is non-ASCII. Is this a garbage character
> that's due to the way the serial port is initialized, or is it
> intentional?
> 

The garbage is not intentional, but probably due to the clock switching
code in the startup.  The '+' character is being printed by the GDB stubs
initialization code, BTW.

> Also, I noticed that the ARM vectors.S appears to miscalculate the
> reset vector: the first eight instructions of the _platform_setup1
> macro are skipped. The easy solution is of course to add eight nop
> instructions to the start of the macro, and I notice that the Brutus
> platform port does exactly this. The nops are missing from the Assabet
> port, though, and this makes the board very flaky about booting up. Is
> this miscalculation a feature (if so, for what purpose?), or a bug?

I hadn't heard about this at all and I'm not convinced it may be a tools
problem.  However, I have recently revamped this setup which removes
these problems (no more funny pointers, at least for ROM applications).
I don't know if/when these changes will hit anon CVS though, so if you
need them right away, I might be able to provide them to you in private
email.

Re: [ECOS] SA11x0 platform port problems

[Jonathan Larmour]

Gary Thomas wrote:
> 
> I hadn't heard about this at all and I'm not convinced it may be a tools
> problem.  However, I have recently revamped this setup which removes
> these problems (no more funny pointers, at least for ROM applications).
> I don't know if/when these changes will hit anon CVS though, so if you
> need them right away, I might be able to provide them to you in private
> email.

Anon CVS should be updated later today probably.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine