I used smc1 because i was unable to get ppcboot running with smc2. our smc1 is at 9600.

with the cache, i've disabled MSR_DR in head_8xx.S which then seems to get to start_here fine. but inserting the same code just before early_init doesn't seem to work... the assembly I'm using is : lis r25, 0xaaaa ori r25, r25, 0xaaaa lis r26, 0x8100 ori r26,r26,0x0000 stw r25, 0(r26)

where r25 is the pattern I want to write into address 0x81000000. I've used r25 and r26 because I can't see them being used anywhere in the code... I'm not sure how do do it otherwise (i.e. restoring the original register values)

any other ideas would be muchly appreciated, My Hong Vuong

...

...

Murray Jensen Murray.Jensen@csiro.au 12/17/02 04:24pm >>>

On Tue, 17 Dec 2002 14:17:50 +1100, My-Hong Vuong My-Hong.Vuong@au.thalesgroup.com writes:

Thanks for the prompt response.

My pleasure.

The board I'm working with does not utilise SDRAM, rather SRAM -

Samsung

K1S321615M, which does not utilise burst access - our ORx has Burst Inhibit turned on - it does not support burst accesses. This

shouldn't

pose a problem then, should it?

No you are correct, you simply won't do burst transfers on the bus which means it can't be the problem.

We have CPU6 turned off as we're using an MPC860T Rev.D.4.

OK

Switching the Copyback on and off seem to have no effect.

OK

also, for the console, we have it set at SMC1, standard/generic serial...

SMC1 - therefore no modem control (this was going to be my next guess). By the way, don't try to set the baud rate too high - it won't work on and SMC. A nice easy 9600 is good to use.

i'm unclear as to what you mean by: you must have a virtual memory mapping set up once the mmu is turned

on

• the head.S file sets one up for the IMMR and the first 8M of RAM

until

the kernel takes over.

Do you mean that BRx and ORx need to be set up again? (btw, i'm a

newbie

at this stuff)

No, a virtual memory mapping in the MMU. Linux takes care of this stuff, but if you are going to be poking values into a hardware device, you need to set up a virtual to physical address mapping and use the virtual address when the MMU is turned on, and the physical address when it is turned off. The mapping also needs to be non-cached.

For example, something like:

volatile phys_addr_t phys_addr = (phys_addr_t)0xXXXXXXXX; volatile void *virt_addr; volatile led_struct *led_ptr;

virt_addr = ioremap(phys_addr, size);

/* if MMU is off */ led_ptr = (led_struct *)phys_addr; led_ptr->...

/* if MMU is on */ led_ptr = (led_struct *)virt_addr; led_ptr->...

Don't take this literally - its just quick notes to give you an idea. Note the BRx/ORx stuff sets the "physical" address of devices, while the MMU mappings set the "virtual" address (you don't need a mapping to access the IMMRs - this is done for you). Also, most places in Linux have the MMU on, except for certain routines in the startup, and the exception handlers (in assembly). Cheers! Murray...