[U-Boot] U-boot resets when booting Linux kernel

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

Hi!

I'm trying to install a Linux kernel 2.6.22 on my U-boot git from October 2008.
It look like this:

=> bootm fc010000 - fc008000
## Booting kernel from Legacy Image at fc010000 ...
   Image Name:   Linux-2.6.22
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    773524 Bytes = 755.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at fc008000
   Booting using the fdt blob at 0xfc008000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 007fb000, end 007fff5a ... OK
Resetting the board.

And then U-boot has restarted. I have set "autostart no" but still it
is rebooting.
When my ethernet interface doesn't work I am using the serial
interface to transfer the linux kernel image and save it to the flash.

Any suggest why U-boot act like this?

TIA
Simon

[U-Boot] U-boot resets when booting Linux kernel

[Wolfgang Denk]

Dear Simon,

In message <28d526a60811200646m4495f30dic4e1b6edbc2cab3d@mail.gmail.com> you wrote:
> 
> I'm trying to install a Linux kernel 2.6.22 on my U-boot git from October 2008.
> It look like this:
> 
> => bootm fc010000 - fc008000
> ## Booting kernel from Legacy Image at fc010000 ...
>    Image Name:   Linux-2.6.22
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    773524 Bytes = 755.4 kB
----------------------------------^^^^^^^^

Which architecture are you talking about? PowerPC?

> Any suggest why U-boot act like this?

Your kernel image looks way too small for a 2.6.2x PowerPC kernel
image. Are you sure you are using a sane configuration which includes
all the essentiual things?

And did you try a port-mortem dump of the log buffer?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There's another way to survive.  Mutual trust -- and help.
	-- Kirk, "Day of the Dove", stardate unknown

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

2008/11/20 Wolfgang Denk <wd@denx.de>:
> Dear Simon,
>
> In message <28d526a60811200646m4495f30dic4e1b6edbc2cab3d@mail.gmail.com> you wrote:
>>
>> I'm trying to install a Linux kernel 2.6.22 on my U-boot git from October 2008.
>> It look like this:
>>
>> => bootm fc010000 - fc008000
>> ## Booting kernel from Legacy Image at fc010000 ...
>>    Image Name:   Linux-2.6.22
>>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>    Data Size:    773524 Bytes = 755.4 kB
> ----------------------------------^^^^^^^^
>
> Which architecture are you talking about? PowerPC?
>
>> Any suggest why U-boot act like this?
>
> Your kernel image looks way too small for a 2.6.2x PowerPC kernel
> image. Are you sure you are using a sane configuration which includes
> all the essentiual things?
>
> And did you try a port-mortem dump of the log buffer?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> There's another way to survive.  Mutual trust -- and help.
>        -- Kirk, "Day of the Dove", stardate unknown
>

I'm sorry,
It is a modified MPC8360 platform.

I'm quite sure about kernel, the only interface I am going to use is
the serial interface.

When the kernel does'nt booting up there is nothing in the log to see.
(Disabled autostart)

Do you know where I can find the file where maps the U-boot code to RAM?
Or how is it made?
U-boot.map shows only where the functions is stored at flash but I
need to know where they are executing in RAM...

/Simon

[U-Boot] U-boot resets when booting Linux kernel

[Wolfgang Denk]

Dear "Simon Boman",

In message <28d526a60811200736x3c8b5fc0lcb4be405c690aeab@mail.gmail.com> you wrote:
>
> I'm quite sure about kernel, the only interface I am going to use is
> the serial interface.

early debug?

> Do you know where I can find the file where maps the U-boot code to RAM?
> Or how is it made?

lib_ppc/board.c

> U-boot.map shows only where the functions is stored at flash but I
> need to know where they are executing in RAM...

A simple method is to print the relocation offset in the debugger -
register r2 holds the global data pointer.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Was hei?t Windows auf Indianisch? - "Wei?er  Mann,  der  auf  Sanduhr
wartet!"

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

2008/11/20 Wolfgang Denk <wd@denx.de>:
> Dear "Simon Boman",
>
> In message <28d526a60811200736x3c8b5fc0lcb4be405c690aeab@mail.gmail.com> you wrote:
>>
>> I'm quite sure about kernel, the only interface I am going to use is
>> the serial interface.
>
> early debug?
>
>> Do you know where I can find the file where maps the U-boot code to RAM?
>> Or how is it made?
>
> lib_ppc/board.c
>
>> U-boot.map shows only where the functions is stored at flash but I
>> need to know where they are executing in RAM...
>
> A simple method is to print the relocation offset in the debugger -
> register r2 holds the global data pointer.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Was hei?t Windows auf Indianisch? - "Wei?er  Mann,  der  auf  Sanduhr
> wartet!"
>

Thank you for your help, I find your example at your site
http://www.denx.de/wiki/DULG/DecodingUBootCrashDumps which was great!

Now I have got find where the U-boot goes wrong:

FDT_ERR_NOSPACE in the file: /libfdt/fdt_rw.c

where the values is:
end: 007faff2 oldlen: 0 newlen: 16, fdt: 007fa000, totsize: 4096

Before fdt_splice is called the values is:
end: 007faff2 oldlen: 8 newlen: 8, fdt: 007fa000, totsize: 22219

Do you have any clue why it's missing 2 bytes for the fdt??

TIA
Simon

[U-Boot] U-boot resets when booting Linux kernel

[Jerry Van Baren]

Simon Boman wrote:
> 2008/11/20 Wolfgang Denk <wd@denx.de>:
>> Dear "Simon Boman",

[snip]

> 
> Thank you for your help, I find your example at your site
> http://www.denx.de/wiki/DULG/DecodingUBootCrashDumps which was great!
> 
> Now I have got find where the U-boot goes wrong:
> 
> FDT_ERR_NOSPACE in the file: /libfdt/fdt_rw.c
> 
> where the values is:
> end: 007faff2 oldlen: 0 newlen: 16, fdt: 007fa000, totsize: 4096
> 
> Before fdt_splice is called the values is:
> end: 007faff2 oldlen: 8 newlen: 8, fdt: 007fa000, totsize: 22219
> 
> Do you have any clue why it's missing 2 bytes for the fdt??
> 
> TIA
> Simon

Hi Simon,

You probably need to use the dtc -p (pad) option when you build your fdt 
blob so that there is more space.  The error message is indicating you 
are running out of space to add/modify the blob you are currently using.

HTH,
gvb

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

2008/11/21 Jerry Van Baren <gerald.vanbaren@ge.com>:
> Simon Boman wrote:
>>
>> 2008/11/20 Wolfgang Denk <wd@denx.de>:
>>>
>>> Dear "Simon Boman",
>
> [snip]
>
>>
>> Thank you for your help, I find your example at your site
>> http://www.denx.de/wiki/DULG/DecodingUBootCrashDumps which was great!
>>
>> Now I have got find where the U-boot goes wrong:
>>
>> FDT_ERR_NOSPACE in the file: /libfdt/fdt_rw.c
>>
>> where the values is:
>> end: 007faff2 oldlen: 0 newlen: 16, fdt: 007fa000, totsize: 4096
>>
>> Before fdt_splice is called the values is:
>> end: 007faff2 oldlen: 8 newlen: 8, fdt: 007fa000, totsize: 22219
>>
>> Do you have any clue why it's missing 2 bytes for the fdt??
>>
>> TIA
>> Simon
>
> Hi Simon,
>
> You probably need to use the dtc -p (pad) option when you build your fdt
> blob so that there is more space.  The error message is indicating you are
> running out of space to add/modify the blob you are currently using.
>
> HTH,
> gvb
>

Hi Jerry!

I have tried that, but after have used 6000 bytes padding of 3900
bytes code i don't think that is the solution.
and at the example above the fdt is 22219 bytes (19000 padding) = 0x56CB
and then the totalsize is changed to 4096 = 0x1000 which give an end
of the fdt to 007fb000 and the comparing is false when the "real end"
is 007faff2 + 10 = 007fb002
So what is going wrong?
/Simon

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

2008/11/21 Simon Boman <simon.boman@gmail.com>:
> 2008/11/21 Jerry Van Baren <gerald.vanbaren@ge.com>:
>> Simon Boman wrote:
>>>
>>> 2008/11/20 Wolfgang Denk <wd@denx.de>:
>>>>
>>>> Dear "Simon Boman",
>>
>> [snip]
>>
>>>
>>> Thank you for your help, I find your example at your site
>>> http://www.denx.de/wiki/DULG/DecodingUBootCrashDumps which was great!
>>>
>>> Now I have got find where the U-boot goes wrong:
>>>
>>> FDT_ERR_NOSPACE in the file: /libfdt/fdt_rw.c
>>>
>>> where the values is:
>>> end: 007faff2 oldlen: 0 newlen: 16, fdt: 007fa000, totsize: 4096
>>>
>>> Before fdt_splice is called the values is:
>>> end: 007faff2 oldlen: 8 newlen: 8, fdt: 007fa000, totsize: 22219
>>>
>>> Do you have any clue why it's missing 2 bytes for the fdt??
>>>
>>> TIA
>>> Simon
>>
>> Hi Simon,
>>
>> You probably need to use the dtc -p (pad) option when you build your fdt
>> blob so that there is more space.  The error message is indicating you are
>> running out of space to add/modify the blob you are currently using.
>>
>> HTH,
>> gvb
>>
>
> Hi Jerry!
>
> I have tried that, but after have used 6000 bytes padding of 3900
> bytes code i don't think that is the solution.
> and at the example above the fdt is 22219 bytes (19000 padding) = 0x56CB
> and then the totalsize is changed to 4096 = 0x1000 which give an end
> of the fdt to 007fb000 and the comparing is false when the "real end"
> is 007faff2 + 10 = 007fb002
> So what is going wrong?
> /Simon
>

I can add that this occur after "Delete the old LMB reservation" in
bootm.c and the function fdt_resize(of_flat_tree) is executing. The
problem as I have understood it, is that the blob is resized so its
fits one block 0x1000. But the boundary is two bytes too small..
007faff2 + 10 = 007fb002
/Simon

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

2008/11/24 Simon Boman <simon.boman@gmail.com>:
> 2008/11/21 Simon Boman <simon.boman@gmail.com>:
>> 2008/11/21 Jerry Van Baren <gerald.vanbaren@ge.com>:
>>> Simon Boman wrote:
>>>>
>>>> 2008/11/20 Wolfgang Denk <wd@denx.de>:
>>>>>
>>>>> Dear "Simon Boman",
>>>
>>> [snip]
>>>
>>>>
>>>> Thank you for your help, I find your example at your site
>>>> http://www.denx.de/wiki/DULG/DecodingUBootCrashDumps which was great!
>>>>
>>>> Now I have got find where the U-boot goes wrong:
>>>>
>>>> FDT_ERR_NOSPACE in the file: /libfdt/fdt_rw.c
>>>>
>>>> where the values is:
>>>> end: 007faff2 oldlen: 0 newlen: 16, fdt: 007fa000, totsize: 4096
>>>>
>>>> Before fdt_splice is called the values is:
>>>> end: 007faff2 oldlen: 8 newlen: 8, fdt: 007fa000, totsize: 22219
>>>>
>>>> Do you have any clue why it's missing 2 bytes for the fdt??
>>>>
>>>> TIA
>>>> Simon
>>>
>>> Hi Simon,
>>>
>>> You probably need to use the dtc -p (pad) option when you build your fdt
>>> blob so that there is more space.  The error message is indicating you are
>>> running out of space to add/modify the blob you are currently using.
>>>
>>> HTH,
>>> gvb
>>>
>>
>> Hi Jerry!
>>
>> I have tried that, but after have used 6000 bytes padding of 3900
>> bytes code i don't think that is the solution.
>> and at the example above the fdt is 22219 bytes (19000 padding) = 0x56CB
>> and then the totalsize is changed to 4096 = 0x1000 which give an end
>> of the fdt to 007fb000 and the comparing is false when the "real end"
>> is 007faff2 + 10 = 007fb002
>> So what is going wrong?
>> /Simon
>>
>
> I can add that this occur after "Delete the old LMB reservation" in
> bootm.c and the function fdt_resize(of_flat_tree) is executing. The
> problem as I have understood it, is that the blob is resized so its
> fits one block 0x1000. But the boundary is two bytes too small..
> 007faff2 + 10 = 007fb002
> /Simon
>

I have no figured out what the problem was. My blob wasn't adapt
correctly to my platform but now it is!
Thanks anyway!
Simon

[U-Boot] U-boot resets when booting Linux kernel

[Jerry Van Baren]

Simon Boman wrote:
> 2008/11/24 Simon Boman <simon.boman@gmail.com>:

[snip]

>> I can add that this occur after "Delete the old LMB reservation" in
>> bootm.c and the function fdt_resize(of_flat_tree) is executing. The
>> problem as I have understood it, is that the blob is resized so its
>> fits one block 0x1000. But the boundary is two bytes too small..
>> 007faff2 + 10 = 007fb002
>> /Simon
>>
> 
> I have no figured out what the problem was. My blob wasn't adapt
> correctly to my platform but now it is!
> Thanks anyway!
> Simon

Hi Simon,

Thanks for the update.  I (and the list) was out of bright ideas of what 
could be wrong.  Your observation of the resizing apparently causing 
problems was very disconcerting.  I'm glad it was fairly simple in the 
end.  (Funny, it always seems a lot simpler once you figure out what is 
wrong.  Must be a corollary to the law that you always find your car 
keys in the last place you look.)

Thanks,
gvb

[U-Boot] U-boot resets when booting Linux kernel

[Simon Boman]

2008/11/26 Jerry Van Baren <gvb.uboot@gmail.com>:
> Simon Boman wrote:
>>
>> 2008/11/24 Simon Boman <simon.boman@gmail.com>:
>
> [snip]
>
>>> I can add that this occur after "Delete the old LMB reservation" in
>>> bootm.c and the function fdt_resize(of_flat_tree) is executing. The
>>> problem as I have understood it, is that the blob is resized so its
>>> fits one block 0x1000. But the boundary is two bytes too small..
>>> 007faff2 + 10 = 007fb002
>>> /Simon
>>>
>>
>> I have no figured out what the problem was. My blob wasn't adapt
>> correctly to my platform but now it is!
>> Thanks anyway!
>> Simon
>
> Hi Simon,
>
> Thanks for the update.  I (and the list) was out of bright ideas of what
> could be wrong.  Your observation of the resizing apparently causing
> problems was very disconcerting.  I'm glad it was fairly simple in the end.
>  (Funny, it always seems a lot simpler once you figure out what is wrong.
>  Must be a corollary to the law that you always find your car keys in the
> last place you look.)
>
> Thanks,
> gvb
>

Haha, you got a point there! =)