Re: [RFC] fitImage support on ARM64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Bhupesh,

Thanks for your answer.

On 14/06/2018 07:50, Bhupesh Sharma wrote:
FIT is a u-boot construct - so one question to understand the
background better - are you using u-boot bootloader to boot the Linux
kernel on your arm64 platforms?
We are indeed using u-boot (this is a Marvell Armada 3700-based board).

If yes, can you please confirm that it is not a product targeting
server markets?
It is not, actually we are building an IoT gateway.

For the normal kexec -p operation (i.e. not the kexec file_load
operation), we rely on passing the device tree to the crashkernel via
dtb= option (which is done by kexec-tools), so how do you plan to
handle the same?
I added 2 fields to the kexec_info structure for the dtb, and another 2 for the initrd:

    char *initrd;
    off_t initrd_size;
    char *dtb;
    off_t dtb_size;

While parsing the FIT image, I just fill these fields with the right data pointers & size, and for arm64 these are to be used within the arm64_load_other_segments function in kexec-arm64.c:

     if (arm64_opts.dtb) {
         dtb.name = "dtb_user";
         dtb.buf = slurp_file(arm64_opts.dtb, &dtb.size);
+    } else if (info->dtb) {
+        dtb.name = "dtb_fit";
+        dtb.buf = info->dtb;
+        dtb.size = info->dtb_size;
     } else {
         result = read_1st_dtb(&dtb);

Same kind of processing is used for the initrd.

For this architecture at least, FIT image support is only a few lines of arch-specific code ; the big part (FIT image parsing and binary blobs extraction) can be shared, just like the code for uImage support is.

If we need to bring out the dtb from the FIT image to support the
current design, do we really require the piecemeal FIT image support
in kexec-tools?
It doesn't look like a huge piece of dev to me, actually I already have a working implementation (a basic one, only extracting the kernel/dtb/initrd binary blobs from the FIT image and feeding them to kexec_load, with no hash or signature checking) using the libfdt currently included in kexec-tools.

Regards,
Arnaud

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




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux