[U-Boot-Users] booting linux from u-boot - help!

[My-Hong Vuong]

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 at csiro.au> 12/17/02 04:24pm >>>
On Tue, 17 Dec 2002 14:17:50 +1100, My-Hong Vuong
<My-Hong.Vuong at 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...
-- 
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3
9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3
9662 7853
Internet: Murray.Jensen at csiro.au 

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ 

To the extent permitted by law, CSIRO does not represent, warrant
and/or
guarantee that the integrity of this communication has been maintained
or
that the communication is free of errors, virus, interception or
interference.

The information contained in this e-mail may be confidential or
privileged.
Any unauthorised use or disclosure is prohibited. If you have received
this
e-mail in error, please delete it immediately and notify Murray Jensen
on
+61 3 9662 7763. Thank you.