Subject: RE: Booting problems on SA1100/1110 boards

From: Jeff Sutherland <[email-masked]>
Date: Thu, 13 Jul 2000 09:55:38 -0400

> Dear experts,
> 
> We're using ARM Linux kernels with Nico patched (2.4.0-test1) on 
> several StrongARM 1100/1110 boards.
> We encountered some problems during porting the kernel on 
> the boards. It would be much appreciated if anyone can locate
> the problems.

It would be helpful if you could supply information about what your
"boards" are, such as Intel development platforms like the Brutus or
Assabet.  Your symptoms indicate possible problems with your memory
subsystem or SDRAM that's not being initialized properly.

//Jeff

> * When we tried to boot the kernel with some modifications of
>    basic configurations (memory map and so on), we could not
>    see any booting messages on the serial console. We could
>    sometimes see the messages, but the cases are very rare.
> 
> * When we commented out the following lines in the proc-sa110.S,
>   the kernel booted well. (the cache and TLC flushes) 
> 
> __sa1100_setup: @ Allow read-buffer operations from userland
>                 mcr     p15, 0, r0, c9, c0, 5
> 
> __sa110_setup:  mov     r0, #F_BIT | I_BIT | SVC_MODE
>                 msr     cpsr_c, r0
>                 mov     r0, #0
> ====>       mcr     p15, 0, r0, c7, c7              @ flush 
> I,D caches on v4
>                 mcr     p15, 0, r0, c7, c10, 4          @ 
> drain write buffer on v4
> ====>       mcr     p15, 0, r0, c8, c7              @ flush 
> I,D TLBs on v4
>                 mcr     p15, 0, r4, c2, c0              @ 
> load page table pointer
>                 mov     r0, #0x1f                       @ 
> Domains 0, 1 = client
>                 mcr     p15, 0, r0, c3, c0              @ 
> load domain access register
>                 mrc     p15, 0, r0, c1, c0              @ get 
> control register v4
> 
> We could not explain the situation since the codes do not seem
> to cause problems.
> Is there any one who can explain the situation?
> 
> Thanks in advance.
> 
> Sungsoo Lim.

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Sung-Soo Lim <[email-masked]>
Date: Thu, 13 Jul 2000 23:51:45 +0900

The boards are:

1. an SA1100-based board which is very similar to, but not
  same as the Intel brutus board.

2. an SA1110-based board which was newly designed.

3. an SA1110-based board which was made by Intrinsyc, co.

These boards showed the same phenomenon.

We ported the Angel debug monitor successfully on the boards.
Since the Angel requires the correct setting of memory configurations,
we thought that the configurations would not be the problem.

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 13 Jul 2000 11:08:40 -0400 (EDT)

> we thought that the configurations would not be the problem.

A misconfigured DRAM can work somewhat for a while until you burst to it,
which happens when the cache is cleaned.  Tipically misconfigured DRAM
systems tend to crash there.

Nicolas

---

From: Sung-Soo Lim <[email-masked]>
Date: Fri, 14 Jul 2000 00:16:22 +0900

OK.
We'll carefully check the DRAM configurations.

Thank you very much.

---

From: Sung-Soo Lim <[email-masked]>
Date: Fri, 14 Jul 2000 00:39:19 +0900

One strange thing on the phenomenon is that when we used
2.2.x series of kernels, such situation did not occur.
Are there any differences on the sensitivity to the
DRAM configurations among the kernel versions?

Thanks.

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 13 Jul 2000 17:10:49 -0400 (EDT)

> 2.2.x series of kernels, such situation did not occur.

Hmmm...  That's strange. 

I have no idea.

Nicolas