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

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

[My-Hong Vuong]

Hi,

I've finally resolved my ethernet reset problem - we just happened to
be moving things arount on our development area, and found that upon
removal of the mpcbdm cable, our board no longer sporadically reset and
our ethernet worked just fine.  Can anyone shed some light on this? I'm
open to suggestions and I'm sure users developing for custom boards
would also find this information useful.

Anyway, I'm now up to the stage of booting linux.  i've tftp'd a
pImage, loaded it into flash and have tried to boot it using:

setenv bootargs root=/dev/hda1
bootm 04880000
## Booting image at 04880000 ...
   Image Name:   Linux-2.4.19-pre7
   Created:      2002-12-16   8:04:21 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    599083 Bytes = 585 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

At this point, it hangs.  I've double-checked 

linux/include/asm-ppc/ppcboot.h
with u-boot/include/asm-ppc/ppcboot.h

and the only difference is the following line:

mon_fnc_t	*bi_mon_fnc;	/* Pointer to monitor functions	*/

which is required(?)

I've also tried it with the clocks_in_mhz turned on and off with no
avail.
I modified linux/arch/ppc/kernel/head_8xx.S to flash some LEDs on the
board at _start and that works, suggesting to me that at least the
memory map parsed to linux is ok.  however, trying to flash our leds to
try and find out where our system hangs, it fails when i get to
start_here.  it appears that the system crashes after the "rfi", which
enables our mmu.  to "prove" this, we replaced the turn_on_mmu block
with a simple "b start_here".  what could possibly be the problem
here??

in desperate need of help... and thanks in advance,
My Hong Vuong

[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@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...
-- 
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.

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

[Wolfgang Denk]

In message <sdff7591.075@au.thalesgroup.com> you wrote:
> I used smc1 because i was unable to get ppcboot running with smc2.  our

This is something you should investigate. U-Boot is working  fine  on
all  MC and SCC ports. If it doesn't work for you this means there is
some problem on your board and/or with your  configuration.  Ignoring
such problems in the early phases whiletrying to go on and "make some
progress"  might  seem to be useful for some demonstration with upper
management, but will have to be paied for double  and  triple  later,
when  you  run  into  the  same  problem  again  without  knowing and
expecting it. -- Just my $ 0.02. [I must live with a  very  primitive
mind  -  I tend to solve problems one by one, step by step. But then,
this is working not too bad for me ;-) ]

> where r25 is the pattern I want to write into address 0x81000000.  I've

As Murray already pointed out: under Linux you cannot simply write to
any physical address you  like.  Linux  sets  up  a  virtual  address
mapping,  and  each  part  of your physical address space you want to
access must be explicitely mapped into this virtual memory.

> any other ideas would be muchly appreciated,

Well, standard recommendation applies again: get yourself a BDI2000.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
On our campus the UNIX system has proved to be not only an  effective
software tool, but an agent of technical and social change within the
University.                          - John Lions (U. of Toronto (?))

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

[Murray Jensen]

On Tue, 17 Dec 2002 19:04:41 +1100, My-Hong Vuong <My-Hong.Vuong@au.thalesgroup.com> writes:
>with the cache, i've disabled MSR_DR in head_8xx.S

You mustn't do this - virtual memory will not work if you do this.

>which then seems to
>get to start_here fine.

This is giving you false hope - you must leave the virtual memory on.

>but inserting the same code just before
>early_init doesn't seem to work...

One problem that you need to look out for is that you only have 0x100 bytes
available to you at that point. This is executing the reset exception handler
at 0x...100 and the next exception handler must start at 0x...200. Don't insert
too much code (you should get an error from the assembler - saying that you
are trying to set the location backwards or something like that).

>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...

r25 and r26 (and others) are used to save the arguments passed to kernel from
the boot loader (in r3, r4, ..., r7) - it's like the first few instructions
ever executed by Linux - you mustn't clobber these registers.

Besides this, if you leave virtual memory on, this will not do what you
think it will - you must first set up a temporary translation in the TLB before
you can access that physical location, as is done for the Internal Memory
Mapped Registers (IMMR) area.

Of course, the appropriate BRx/ORx for the LEDs must have been set up by the
boot loader so that the physical address 0x81000000 really does access the
LED hardware (I assume this is the case - since you say this code works
elsewhere).

>I'm not sure how do do it otherwise (i.e. restoring the original
>register values)

Use some other registers (if you're careful) - e.g. r3, r4, r5 - these will be
restored later when required (see call to identify_machine - or some name like
that).

>any other ideas would be muchly appreciated,

I just got my BDI2000 - it's great. Other than that - pull out all code you
have inserted and go back to the original Linux code - after carefully
examining all the config options. If your hardware is correct and your
linux config matches it properly, it should "just work" :-) Good luck.
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.