[RFC] fitImage support on ARM64

[RFC] fitImage support on ARM64

[Arnaud Ferraris]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

Hi,

I started working on implementing fitImage support in kexec.

Regarding image parsing & loading, things are going quite well, but I 
realized the only way to load a device tree and/or initramfs for now was 
to have them stored in files separated from the kernel.

I came up with a solution that requires appending new fields to the 
kexec_info structure (see attached patch), and wonder if that sounds 
right to you ? I guess other architectures might benefit from this 
support, so I didn't want an ARM64-specific solution.

Any comment will be welcome !

Regards,
Arnaud

[-- Attachment #2: kexec-arm64-fitimage-loading.patch --]
[-- Type: text/x-patch, Size: 1308 bytes --]

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 62f3758..5888a6c 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -544,6 +544,10 @@ int arm64_load_other_segments(struct kexec_info *info,
 	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);

@@ -568,8 +572,13 @@ int arm64_load_other_segments(struct kexec_info *info,
 	else
 		hole_max = ULONG_MAX;

-	if (arm64_opts.initrd) {
-		initrd_buf = slurp_file(arm64_opts.initrd, &initrd_size);
+	if (arm64_opts.initrd || info->initrd) {
+		if (arm64_opts.initrd)
+			initrd_buf = slurp_file(arm64_opts.initrd, &initrd_size);
+		else {
+			initrd_buf = info->initrd;
+			initrd_size = info->initrd_size;
+		}

 		if (!initrd_buf)
 			fprintf(stderr, "kexec: Empty ramdisk file.\n");
diff --git a/kexec/kexec.h b/kexec/kexec.h
index d445fbe..9ac1537 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -166,6 +166,10 @@ struct kexec_info {
 	int initrd_fd;
 	char *command_line;
 	int command_line_len;
+	char *initrd;
+	off_t initrd_size;
+	char *dtb;
+	off_t dtb_size;
 };

 struct arch_map_entry {

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: [RFC] fitImage support on ARM64

[Bhupesh Sharma]

Hello Arnaud,

On Tue, Jun 12, 2018 at 7:05 PM, Arnaud Ferraris
<arnaud.ferraris.external@sigfox.com> wrote:
> Hi,
>
> I started working on implementing fitImage support in kexec.

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?

If yes, can you please confirm that it is not a product targeting
server markets? As for the server markets, the ARM SBBR requires one
to use a UEFI compliant firmware as the boot and system firmware (see
[1] for details).

For EFI opensource implementations like Tianocore EDK2 firmware, we
decided against using the FIT format (see [2] for details)

> Regarding image parsing & loading, things are going quite well, but I
> realized the only way to load a device tree and/or initramfs for now was to
> have them stored in files separated from the kernel.
>
> I came up with a solution that requires appending new fields to the
> kexec_info structure (see attached patch), and wonder if that sounds right
> to you ? I guess other architectures might benefit from this support, so I
> didn't want an ARM64-specific solution.
>
> Any comment will be welcome !

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?

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?

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044c/Server_Base_Boot_Requirements_v1_1_Arm_DEN_0044C.pdf
[2] https://www.mail-archive.com/search?l=edk2-devel@lists.01.org&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C%5D+%5C%5BPATCH%5C%5D+ArmVirtPkg%5C%3A+align+ARM+BDS+build+with+LinuxLoader%09changes%22&o=newest&f=1

Thanks,
Bhupesh

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

Re: [RFC] fitImage support on ARM64

[Arnaud Ferraris]

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec