Re: some questions about elf_ppc64_load

[Laurent Dufour <ldufour@linux.vnet.ibm.com>]

On 06/01/2015 10:20, liu.song11@zte.com.cn wrote:
> 
> 
> Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote on 2015-01-06 16:37:03:
> 
>> From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>> To: liu.song11@zte.com.cn,
>> Cc: kexec@lists.infradead.org
>> Date: 2015-01-06 16:37
>> Subject: Re: some questions about elf_ppc64_load
>>
>> On 06/01/2015 07:44, liu.song11@zte.com.cn wrote:
>>>
>>> hi all，
>>>
>>> I use kexec-tools-2.0.8 for ppc64, in fuction elf_ppc64_load prompt "Can't use ramdisk with device tree blob input".
>>>
>>> I don't know why here ramdisk can't together with dtb,and need some help.
>>
>> The device tree is also specifying initrd (see kexec/fs2dt.c putnode),
>> so there is 2 initrd specify in that case. The code is a bit rough here,
>> but I guess this is because there is not yet a valid use case.
> hi Cheers,
> In "elf_ppc64_load", if we haven't assign a special dtb by --dtb=<filename>, then here will use "create_flatten_tree" to
> create one. However, My board need assign a dtb, so I use --dtb=my.dtb to assign it. The dtb file is valid which I use it
> to start kernel under uboot. For now, I just confuse is why the "create_flatten_tree" create dtb could work, but I assigned
> dtb couldn't, my.dtb is 40KB and smaller than create dtb's 76KB. The two ways both use add_buffer with param "buf_end = -1",
> so will add segment for the top of the valid mem range, and my.dtb is smaller which less chance of overlap some data in memory.

The service create_flatten_tree create a DTB from the one inherited at
the boot time of the currently running kernel (/proc/device-tree). I
guess this device tree is valid since the current kernel is running ;)

You may try to see what the device tree passed to your kexed kernel is,
may be there is something wrong there. Also looking at what going wrong
when the kexed kernel is panicing may be helpful.

Cheers,
Laurent.

> 
>>
>>> I also have some questions, when I just ./kexe -l vmlinux then ./kexec -e, will jump to second kernel sucessfully,
>>>
>>> but without useful dtb, then device can't init correct. But, when I input ./kexec -l vmlinux --dtb=my.dtb , then
>>>
>>> ./kexec -e, the kernel couldn't work and crash in head_64.S, this problem also make me confused.
>>
>> It's hard to state with no more details. I guess the device tree blob
>> you're using is not valid, or contain bad data.
>>
>> Cheers,
>> Laurent.
>>
>>> Thanks
>>> Regards
>>> --------------------------------------------------------
>>> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>
>>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec