[U-Boot-Users] PPC 8260 Linux boot

[U-Boot-Users] PPC 8260 Linux boot

[Ori Idan]

I am trying to boot Linux 2.4.25 (code from denx linux-2-4-devel)
The board is similar to MPC8260ADS
What happens is that the kernel is starting but after a short while gets 
an exception and the board is reset again.
We tried looking at the kernel sources to see where we get, we did this 
by lighting hardware LEDS we have on the board.
We tried to find where in the kernel we get the exception, we could not 
find exactly where it happens, but we did find that it happens somewhere 
in the function prom_init called from early_init inside 
arch/ppc/kernel/setup.c

Does anyone have any idea what we should look next?

--
Ori Idan

[U-Boot-Users] PPC 8260 Linux boot

[Wolfgang Denk]

In message <4105294D.5070508@helicontech.co.il> you wrote:
> I am trying to boot Linux 2.4.25 (code from denx linux-2-4-devel)
> The board is similar to MPC8260ADS

Arghh...  A  description  like  this  is  absolutley   useless,   and
misleading.  Your probably even fooling yourself. Similar? In that it
uses the same processor? Or is everything IDENTICAL?

> What happens is that the kernel is starting but after a short while gets 
> an exception and the board is reset again.

Please define "after a short while". Do you see any boot messages  on
the  console?  Do you see any messages when you do a post mortem dump
of the log_buf memory?
[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]

> We tried looking at the kernel sources to see where we get, we did this 
> by lighting hardware LEDS we have on the board.

I see. Please remove ALL this code and try again. perhaps it is  just
your  debugging  code  which  crashes  the  system.  [This  has  been
discussed before, both here and in the linuxppc mailing lists. Search
the archives.]

> We tried to find where in the kernel we get the exception, we could not 
> find exactly where it happens, but we did find that it happens somewhere 
> in the function prom_init called from early_init inside 
> arch/ppc/kernel/setup.c
> 
> Does anyone have any idea what we should look next?

OK, I'll give you two hints:

1) get yourself a BDI2000. You will need it.

2) Check your memory map, and the init sequence of  your  SDRAM  [no,
   I'm not going to explain this here again. Search the archives.]

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
And now remains  That we find out the cause of this effect, Or rather
say, the cause of this defect...           -- Hamlet, Act II, Scene 2

[U-Boot-Users] PPC 8260 Linux boot

[Ori Idan]

Thank you for your quick answer.

>>I am trying to boot Linux 2.4.25 (code from denx linux-2-4-devel)
>>The board is similar to MPC8260ADS
>>    
>>
>
>Arghh...  A  description  like  this  is  absolutley   useless,   and
>misleading.  Your probably even fooling yourself. Similar? In that it
>uses the same processor? Or is everything IDENTICAL?
>  
>
If it was not IDENTICAL I would not have mentioned this board.

>  
>
>>What happens is that the kernel is starting but after a short while gets 
>>an exception and the board is reset again.
>>    
>>
>
>Please define "after a short while". Do you see any boot messages  on
>the  console?  Do you see any messages when you do a post mortem dump
>of the log_buf memory?
>[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]
>
>  
>
I do not see any boot messages, I can't exactly define how long it takes 
until the reset
but it is a very short time that during this time I expected at least 
one line saying this is
the kernel.

>>We tried looking at the kernel sources to see where we get, we did this 
>>by lighting hardware LEDS we have on the board.
>>    
>>
>
>I see. Please remove ALL this code and try again. perhaps it is  just
>your  debugging  code  which  crashes  the  system.  [This  has  been
>discussed before, both here and in the linuxppc mailing lists. Search
>the archives.]
>  
>
I tried removing all my code and tried again, that was the first thing I 
thought
that maybe I crash the system.
I tried again and again and the problem was the same.

>  
>
>>We tried to find where in the kernel we get the exception, we could not 
>>find exactly where it happens, but we did find that it happens somewhere 
>>in the function prom_init called from early_init inside 
>>arch/ppc/kernel/setup.c
>>
>>Does anyone have any idea what we should look next?
>>    
>>
>
>OK, I'll give you two hints:
>
>1) get yourself a BDI2000. You will need it.
>
>2) Check your memory map, and the init sequence of  your  SDRAM  [no,
>   I'm not going to explain this here again. Search the archives.]
>  
>
Unfortunatly the archives are not searchable, otherwise that would be 
the first thing I would
do, could you give me some hints on what do you mean init sequence of SDRAM?
As for the memory map, I made sure I have RAM starting from 0x0000, I 
have 128Mb of RAM.
The IMMR is set to 0xF0000000.

--
Ori Idan

[U-Boot-Users] PPC 8260 Linux boot

[Wolfgang Denk]

In message <4105FA9D.30400@helicontech.co.il> you wrote:
> 
> >>I am trying to boot Linux 2.4.25 (code from denx linux-2-4-devel)
> >>The board is similar to MPC8260ADS
...
> If it was not IDENTICAL I would not have mentioned this board.

So it is identical? Then why did you write "similar to" in the first place?

And if it's really identical I thinkt  he  standard  MPC8260ADS  code
should work identical, too.

> >Please define "after a short while". Do you see any boot messages  on
> >the  console?  Do you see any messages when you do a post mortem dump
> >of the log_buf memory?
> >[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]
> >  
> >
> I do not see any boot messages, I can't exactly define how long it takes 
> until the reset
> but it is a very short time that during this time I expected at least 
> one line saying this is
> the kernel.

I repeat:

Do you see any messages when you do a post mortem dump of the log_buf
memory?
[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]

????

> I tried removing all my code and tried again, that was the first thing I 
> thought
> that maybe I crash the system.
> I tried again and again and the problem was the same.

You cannot make such a claim. The _symptoms_ may have been the  same.
The problem may have been a different one.

> >2) Check your memory map, and the init sequence of  your  SDRAM  [no,
> >   I'm not going to explain this here again. Search the archives.]
> >  
> >
> Unfortunatly the archives are not searchable, otherwise that would be 
> the first thing I would

The GMANE archive _is_ searchable.

> do, could you give me some hints on what do you mean init sequence of SDRAM?

IO mean the initialization sequence that is required  for  the  SDRAM
chips. In 98% of all porting problems this is the culprit.

> As for the memory map, I made sure I have RAM starting from 0x0000, I 
> have 128Mb of RAM.
> The IMMR is set to 0xF0000000.

Did you read the FAQ? How about the "clocks_in_mhz" setting?  Or  the
bd_info structure used by the Linux kernel?

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
Life is a process, not a principle, a mystery  to  be  lived,  not  a
problem to be solved. - Gerard Straub, television producer and author
(stolen from Frank Herbert??)

[U-Boot-Users] PPC 8260 Linux boot

[Ori Idan]

>I repeat:
>
>Do you see any messages when you do a post mortem dump of the log_buf
>memory?
>[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]
>
>????
>  
>
I think I don't understand something in your explenation of post mortem, 
how can I do
grep log_buf system.map
when I have nothing but UBOOT prompt?

>  
>
>>I tried removing all my code and tried again, that was the first thing I 
>>thought
>>that maybe I crash the system.
>>I tried again and again and the problem was the same.
>>    
>>
>
>You cannot make such a claim. The _symptoms_ may have been the  same.
>The problem may have been a different one.
>
>  
>
>>>2) Check your memory map, and the init sequence of  your  SDRAM  [no,
>>>  I'm not going to explain this here again. Search the archives.]
>>> 
>>>
>>>      
>>>
>>Unfortunatly the archives are not searchable, otherwise that would be 
>>the first thing I would
>>    
>>
>
>The GMANE archive _is_ searchable.
>  
>
What is the GNAME archive?

>  
>
>>do, could you give me some hints on what do you mean init sequence of SDRAM?
>>    
>>
>
>IO mean the initialization sequence that is required  for  the  SDRAM
>chips. In 98% of all porting problems this is the culprit.
>  
>
I still do not understand what do you mean by init sequence of SDRAM, If 
I had any hint of what you mean by that I would check for it.
All I know is that I have 128MB of RAM mapped from 0x0000 I have checked 
it again.

>Did you read the FAQ? How about the "clocks_in_mhz" setting?  Or  the
>bd_info structure used by the Linux kernel?
>  
>
Yes, I have thought about the clock value and made sure it is passed Ok, 
since I am using
kernel 2.4.25 I understand that the clock should be in Hz and that is 
what U-boot transfers.

--
Ori Idan

[U-Boot-Users] PPC 8260 Linux boot

[Wolfgang Denk]

In message <4106D6BF.6090600@helicontech.co.il> you wrote:
> 
> >Do you see any messages when you do a post mortem dump of the log_buf
> >memory?
> >[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]
> >
> >????
> >  
> >
> I think I don't understand something in your explenation of post mortem, 
> how can I do
> grep log_buf system.map
> when I have nothing but UBOOT prompt?

You do have a development system which you used to compile  and  link
your  Linux  kernel,  don't  you?  And you do have the "grep" command
installed on that host, right?

> >The GMANE archive _is_ searchable.
> >
> What is the GNAME archive?

http://news.gmane.org/gmane.comp.boot-loaders.u-boot

[Why didn't a google search for "gmane u-boot" return useful links for you?]

> I still do not understand what do you mean by init sequence of SDRAM, If 
> I had any hint of what you mean by that I would check for it.

Read the documentation provided  by  the  manufacturer  of  your  RAM
chips. It shosuld contain a section about the SDRAM init sequence.

> >Did you read the FAQ? How about the "clocks_in_mhz" setting?  Or  the
> >bd_info structure used by the Linux kernel?
> >  
> >
> Yes, I have thought about the clock value and made sure it is passed Ok, 
> since I am using
> kernel 2.4.25 I understand that the clock should be in Hz and that is 
> what U-boot transfers.

And what about bd_info?

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
"The one charm of marriage is that it makes a  life  of  deception  a
neccessity."                                            - Oscar Wilde

[U-Boot-Users] PPC 8260 Linux boot

[Ori Idan]

>You do have a development system which you used to compile  and  link
>your  Linux  kernel,  don't  you?  And you do have the "grep" command
>installed on that host, right?
>  
>
Ok, I think it should be written clearly in the wiki that this is the 
host system.

>  
>
>>>The GMANE archive _is_ searchable.
>>>
>>>      
>>>
>>What is the GNAME archive?
>>    
>>
>
>http://news.gmane.org/gmane.comp.boot-loaders.u-boot
>
>[Why didn't a google search for "gmane u-boot" return useful links for you?]
>
>  
>
>>I still do not understand what do you mean by init sequence of SDRAM, If 
>>I had any hint of what you mean by that I would check for it.
>>    
>>
>
>Read the documentation provided  by  the  manufacturer  of  your  RAM
>chips. It shosuld contain a section about the SDRAM init sequence.
>  
>
Isn't the fact that I have RAM from 0x0000 means that RAM is initialized?
I have checked in Uboot that I can write and read this RAM so I am sure 
I have it.
What other initialization should be done?

>  
>
>>>Did you read the FAQ? How about the "clocks_in_mhz" setting?  Or  the
>>>bd_info structure used by the Linux kernel?
>>> 
>>>
>>>      
>>>
>>Yes, I have thought about the clock value and made sure it is passed Ok, 
>>since I am using
>>kernel 2.4.25 I understand that the clock should be in Hz and that is 
>>what U-boot transfers.
>>    
>>
>
>And what about bd_info?
>  
>
I have checked bd_info and it transfers the clock in Hz and also 
transfer the right RAM
and IMMR information.

--
Ori Idan

[U-Boot-Users] PPC 8260 Linux boot

[Wolfgang Denk]

In message <41079531.2000204@helicontech.co.il> you wrote:
> 
> >You do have a development system which you used to compile  and  link
> >your  Linux  kernel,  don't  you?  And you do have the "grep" command
> >installed on that host, right?
> >
> Ok, I think it should be written clearly in the wiki that this is the 
> host system.

You are the first person to misunderstand this.

> >Read the documentation provided  by  the  manufacturer  of  your  RAM
> >chips. It shosuld contain a section about the SDRAM init sequence.
> >  
> Isn't the fact that I have RAM from 0x0000 means that RAM is initialized?

No, it does not. Mapping some address space in the memory  controller
and actually initializing a device are completely different issues.

> I have checked in Uboot that I can write and read this RAM so I am sure 
> I have it.

Please read the archives. Simple read and write access are easy; this
still does not give any guarantee that burst mode accesses will work.

> What other initialization should be done?

I already told you:

READ THE DOCUMENTATION PROVIDED  BY  THE  MANUFACTURER  OF  YOUR  RAM
CHIPS. IT SHOULD CONTAIN A SECTION ABOUT THE REQUIRED INIT SEQUENCE.

And _please_ read the mail list archive.


> >And what about bd_info?
> >
> I have checked bd_info and it transfers the clock in Hz and also 
> transfer the right RAM
> and IMMR information.

Argh... You make it really difficult to help you.

Did you check ALL items of the FAQ "Linux hangs  after  uncompressing
the kernel", i. e. did you really make sure that U-Boot and Linux are
using the SAME version of bd_info?

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
Schshschshchsch.
	-- The Gorn, "Arena", stardate 3046.2

[U-Boot-Users] PPC 8260 Linux boot

[Ori Idan]

Ok, it seems Linux is booting now or at least we think so
There is not exception now but all we get is few unmeaningfull character 
on the terminal
We belive Linux is booting but the kernel is miscalculating the baud rate.
The clock information in bd_info seems to be Ok but I will double check 
this tomorow.

Does someone has any clue for what may cause this problem?

--
Ori Idan

Wolfgang Denk wrote:

>In message <4105294D.5070508@helicontech.co.il> you wrote:
>  
>
>>I am trying to boot Linux 2.4.25 (code from denx linux-2-4-devel)
>>The board is similar to MPC8260ADS
>>    
>>
>
>Arghh...  A  description  like  this  is  absolutley   useless,   and
>misleading.  Your probably even fooling yourself. Similar? In that it
>uses the same processor? Or is everything IDENTICAL?
>
>  
>
>>What happens is that the kernel is starting but after a short while gets 
>>an exception and the board is reset again.
>>    
>>
>
>Please define "after a short while". Do you see any boot messages  on
>the  console?  Do you see any messages when you do a post mortem dump
>of the log_buf memory?
>[See http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis]
>
>  
>
>>We tried looking at the kernel sources to see where we get, we did this 
>>by lighting hardware LEDS we have on the board.
>>    
>>
>
>I see. Please remove ALL this code and try again. perhaps it is  just
>your  debugging  code  which  crashes  the  system.  [This  has  been
>discussed before, both here and in the linuxppc mailing lists. Search
>the archives.]
>
>  
>
>>We tried to find where in the kernel we get the exception, we could not 
>>find exactly where it happens, but we did find that it happens somewhere 
>>in the function prom_init called from early_init inside 
>>arch/ppc/kernel/setup.c
>>
>>Does anyone have any idea what we should look next?
>>    
>>
>
>OK, I'll give you two hints:
>
>1) get yourself a BDI2000. You will need it.
>
>2) Check your memory map, and the init sequence of  your  SDRAM  [no,
>   I'm not going to explain this here again. Search the archives.]
>
>Best regards,
>
>Wolfgang Denk
>
>  
>