Re: Re: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
On Thu, Feb 26, 2026 at 08:15:14AM +, Dorde Stojicevic wrote: > Hi all, > > yup, I completely understand and agree with you. > > One way would be to detect the characteristic string Lynx has in the > beginning of the FIT image " eLynxSecure" : > > mkimage: > FIT description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 19 11:44:07 2026 > Image 0 (kernel-1) > Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 19 11:44:07 2026 > Type: Kernel Image > Compression: uncompressed > Data Size: > Architecture: AArch64 > OS: Linux > Load Address: > Entry Point: > Image 1 (fdt-1) > Description: Flattened Device Tree blob for LynxSecure > 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 19 11:44:07 2026 > Type: Flat Device Tree > Compression: uncompressed > Data Size: > Architecture: AArch64 > Default Configuration: 'conf-1' > Configuration 0 (conf-1) > Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Kernel: kernel-1 > FDT: fdt-1 > > xxd -l 128 > : d00d feed 1dea 3bd5 0030 1dea 3b64 ..;0..;d > 0010: 0030 0011 0010 ...0 > 0020: 0071 1dea 3b34 ...q..;4 > 0030: 0001 0003 002e > 0040: 0065 4c79 6e78 5365 6375 7265 2032 ...eLynxSecure 2 > 0050: 3032 352e 3130 2e30 2d33 3938 3434 6238 025.10.0-39844b8 > 0060: 3065 3020 5352 5020 2861 6172 6368 3634 0e0 SRP (aarch64 > 0070: 2900 0003 0004 0056 )..V > > Thing is I am currently pretty busy with other stuff, so wont be able to > commit myself to it at the moment. > Maybe you can work out a proper solution, based on info I provided. > To my understanding, shouldn’t actually be that complex, e.g. just add check > for eLynxSecure in the code location where my patch is. > But may be I don’t see the whole picture of U-Boot and missing something. > > Let me know if I can be of help somehow I was suggesting adding a new IH_OS type because otherwise we're going to be opening ourselves up to invalid (or malicious) images being passed in. Thanks! -- Tom signature.asc Description: PGP signature
RE: Re: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
Hi all, yup, I completely understand and agree with you. One way would be to detect the characteristic string Lynx has in the beginning of the FIT image " eLynxSecure" : mkimage: FIT description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Created: Thu Feb 19 11:44:07 2026 Image 0 (kernel-1) Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Created: Thu Feb 19 11:44:07 2026 Type: Kernel Image Compression: uncompressed Data Size: Architecture: AArch64 OS: Linux Load Address: Entry Point: Image 1 (fdt-1) Description: Flattened Device Tree blob for LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Created: Thu Feb 19 11:44:07 2026 Type: Flat Device Tree Compression: uncompressed Data Size: Architecture: AArch64 Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Kernel: kernel-1 FDT: fdt-1 xxd -l 128 : d00d feed 1dea 3bd5 0030 1dea 3b64 ..;0..;d 0010: 0030 0011 0010 ...0 0020: 0071 1dea 3b34 ...q..;4 0030: 0001 0003 002e 0040: 0065 4c79 6e78 5365 6375 7265 2032 ...eLynxSecure 2 0050: 3032 352e 3130 2e30 2d33 3938 3434 6238 025.10.0-39844b8 0060: 3065 3020 5352 5020 2861 6172 6368 3634 0e0 SRP (aarch64 0070: 2900 0003 0004 0056 )..V Thing is I am currently pretty busy with other stuff, so wont be able to commit myself to it at the moment. Maybe you can work out a proper solution, based on info I provided. To my understanding, shouldn’t actually be that complex, e.g. just add check for eLynxSecure in the code location where my patch is. But may be I don’t see the whole picture of U-Boot and missing something. Let me know if I can be of help somehow Dj Dorde Stojicevic Networks and Cybersecurity Rohde & Schwarz SIT GmbH Hemminger Strasse 41 | 70499 Stuttgart-Weilimdorf | Germany Phone: +4971169945195 Internet: www.rohde-schwarz.com Geschäftsführer / Managing Director: Ralf Koenzen Aufsichtsratsvorsitzender / Chair of the Supervisory Board: Mario Paoli Sitz / Registered Office: Stuttgart Handelsregister / Commercial Register: AG Stuttgart HRB 759 934 Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE 121 963 283 Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 877 727 67 -Original Message- From: Tom Rini Sent: Wednesday, February 25, 2026 11:24 PM To: Stojicevic Dorde (11SIEPT1) Cc: Quentin Schulz ; [email protected] Subject: *EXT* Re: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04 ***CAUTION_Invalid_Signature*** On Tue, Feb 24, 2026 at 07:30:13AM +, Dorde Stojicevic wrote: > Hi all, > > sorry that it took a while to get the response from Lynx but it couldn´t be > helped unfortunately. > > I got the response from Lynx: > > " Hello Dorde. > > I’ve got a replay from our engineering team. We do not support u-boot, so we > don’t have any plans to make SRP “ARM64 kernel“ compatible. > > We work with board with default u-boot (for now it is U-Boot SPL 2020.04). > > So, you are free to make any changes in u-boot to make SRP run in newest > version of u-boot. > " > > I am a bit surprised by the response that they don´t seem really interested > in it, but it is how it is. So we are free to apply the patch to our liking. > > Let me know how we proceed from here Well, if they aren't going to do the work, someone needs to do the work to support the OS. What's happened since 2020.04 is that we now correctly detect and fail something that claims to be a Linux ARM64 Image, but is not. We aren't going to go back and re-allow that, it was a bug. The proposal I outlined for how I think it should look, for proper support, is something that I hope someone interested / motivated can look in to doing. -- Tom
Re: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
On Tue, Feb 24, 2026 at 07:30:13AM +, Dorde Stojicevic wrote: > Hi all, > > sorry that it took a while to get the response from Lynx but it couldn´t be > helped unfortunately. > > I got the response from Lynx: > > " Hello Dorde. > > I’ve got a replay from our engineering team. We do not support u-boot, so we > don’t have any plans to make SRP “ARM64 kernel“ compatible. > > We work with board with default u-boot (for now it is U-Boot SPL 2020.04). > > So, you are free to make any changes in u-boot to make SRP run in newest > version of u-boot. > " > > I am a bit surprised by the response that they don´t seem really interested > in it, but it is how it is. So we are free to apply the patch to our liking. > > Let me know how we proceed from here Well, if they aren't going to do the work, someone needs to do the work to support the OS. What's happened since 2020.04 is that we now correctly detect and fail something that claims to be a Linux ARM64 Image, but is not. We aren't going to go back and re-allow that, it was a bug. The proposal I outlined for how I think it should look, for proper support, is something that I hope someone interested / motivated can look in to doing. -- Tom signature.asc Description: PGP signature
RE: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
Hi all, sorry that it took a while to get the response from Lynx but it couldn´t be helped unfortunately. I got the response from Lynx: " Hello Dorde. I’ve got a replay from our engineering team. We do not support u-boot, so we don’t have any plans to make SRP “ARM64 kernel“ compatible. We work with board with default u-boot (for now it is U-Boot SPL 2020.04). So, you are free to make any changes in u-boot to make SRP run in newest version of u-boot. " I am a bit surprised by the response that they don´t seem really interested in it, but it is how it is. So we are free to apply the patch to our liking. Let me know how we proceed from here Dorde Dorde Stojicevic Networks and Cybersecurity Rohde & Schwarz SIT GmbH Hemminger Strasse 41 | 70499 Stuttgart-Weilimdorf | Germany Phone: +4971169945195 Internet: www.rohde-schwarz.com Geschäftsführer / Managing Director: Ralf Koenzen Aufsichtsratsvorsitzender / Chair of the Supervisory Board: Mario Paoli Sitz / Registered Office: Stuttgart Handelsregister / Commercial Register: AG Stuttgart HRB 759 934 Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE 121 963 283 Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 877 727 67 -Original Message- From: Stojicevic Dorde (11SIEPT1) Sent: Friday, February 6, 2026 4:17 PM To: 'Tom Rini' Cc: Quentin Schulz ; [email protected] Subject: RE: *EXT* Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04 ***CAUTION_Invalid_Signature*** Nice. 😊 From what I know, Lynx wanted the "feature" of being able to impersonate Linux, so once it´s builtin between real OS and U-Boot, it is a no-brainer with "nothing to be changed". But it seems like that detection in U-Boot was not working properly, then Lynx built on top (unaware of the check that needed to be inplace), and then I came with my "quick´n´dirty" solution. 😊 Maybe the really-proper-solution would be that Lynx just does the complete proper impersonation of Linux, if that is what they really want as a feature. But to clarify this, we would need some one from their side. I have contact with them, should I establish a trilateral talk on this topic? Greetings and nice weekend Dorde -Original Message- From: Tom Rini Sent: Friday, February 6, 2026 4:04 PM To: Stojicevic Dorde (11SIEPT1) Cc: Quentin Schulz ; [email protected] Subject: *EXT* Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04 ***CAUTION_Invalid_Signature*** On Fri, Feb 06, 2026 at 06:28:39AM +, Dorde Stojicevic wrote: > Hi, > > yes of course. > > Here it is: > > $ mkimage -l build/ed7ct-cb.srp > FIT description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 5 13:58:31 2026 > Image 0 (kernel-1) > Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 5 13:58:31 2026 > Type: Kernel Image > Compression: uncompressed > Data Size:262512264 Bytes = 256359.63 KiB = 250.35 MiB > Architecture: AArch64 > OS: Linux So, we're getting somewhere. It seems like before our validation check wasn't working and so claiming to be Linux, but not being Linux, wasn't caught and failed. The right path here is to add IH_OS_LYNXSECURE to include/image.h and handling of it in the various boot/ files that need it. Then the its should have 'os = "lynxsecure"' so that it sets that field correctly. -- Tom
RE: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
Nice. 😊 From what I know, Lynx wanted the "feature" of being able to impersonate Linux, so once it´s builtin between real OS and U-Boot, it is a no-brainer with "nothing to be changed". But it seems like that detection in U-Boot was not working properly, then Lynx built on top (unaware of the check that needed to be inplace), and then I came with my "quick´n´dirty" solution. 😊 Maybe the really-proper-solution would be that Lynx just does the complete proper impersonation of Linux, if that is what they really want as a feature. But to clarify this, we would need some one from their side. I have contact with them, should I establish a trilateral talk on this topic? Greetings and nice weekend Dorde Dorde Stojicevic Networks and Cybersecurity Rohde & Schwarz SIT GmbH Hemminger Strasse 41 | 70499 Stuttgart-Weilimdorf | Germany Phone: +4971169945195 Internet: www.rohde-schwarz.com Geschäftsführer / Managing Director: Ralf Koenzen Aufsichtsratsvorsitzender / Chair of the Supervisory Board: Mario Paoli Sitz / Registered Office: Stuttgart Handelsregister / Commercial Register: AG Stuttgart HRB 759 934 Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE 121 963 283 Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 877 727 67 -Original Message- From: Tom Rini Sent: Friday, February 6, 2026 4:04 PM To: Stojicevic Dorde (11SIEPT1) Cc: Quentin Schulz ; [email protected] Subject: *EXT* Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04 ***CAUTION_Invalid_Signature*** On Fri, Feb 06, 2026 at 06:28:39AM +, Dorde Stojicevic wrote: > Hi, > > yes of course. > > Here it is: > > $ mkimage -l build/ed7ct-cb.srp > FIT description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 5 13:58:31 2026 > Image 0 (kernel-1) > Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 5 13:58:31 2026 > Type: Kernel Image > Compression: uncompressed > Data Size:262512264 Bytes = 256359.63 KiB = 250.35 MiB > Architecture: AArch64 > OS: Linux So, we're getting somewhere. It seems like before our validation check wasn't working and so claiming to be Linux, but not being Linux, wasn't caught and failed. The right path here is to add IH_OS_LYNXSECURE to include/image.h and handling of it in the various boot/ files that need it. Then the its should have 'os = "lynxsecure"' so that it sets that field correctly. -- Tom
Re: Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
On Fri, Feb 06, 2026 at 03:17:15PM +, Dorde Stojicevic wrote: > Nice. 😊 > > From what I know, Lynx wanted the "feature" of being able to impersonate > Linux, so once it´s builtin between real OS and U-Boot, it is a no-brainer > with "nothing to be changed". > > But it seems like that detection in U-Boot was not working properly, then > Lynx built on top (unaware of the check that needed to be inplace), and then > I came with my "quick´n´dirty" solution. 😊 > > Maybe the really-proper-solution would be that Lynx just does the complete > proper impersonation of Linux, if that is what they really want as a feature. > But to clarify this, we would need some one from their side. I have contact > with them, should I establish a trilateral talk on this topic? Yes, it would be great if someone from Lynx could chime in and we can all work to solve the problem here. Thanks! -- Tom signature.asc Description: PGP signature
Re: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
On Fri, Feb 06, 2026 at 06:28:39AM +, Dorde Stojicevic wrote: > Hi, > > yes of course. > > Here it is: > > $ mkimage -l build/ed7ct-cb.srp > FIT description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 5 13:58:31 2026 > Image 0 (kernel-1) > Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) > Created: Thu Feb 5 13:58:31 2026 > Type: Kernel Image > Compression: uncompressed > Data Size:262512264 Bytes = 256359.63 KiB = 250.35 MiB > Architecture: AArch64 > OS: Linux So, we're getting somewhere. It seems like before our validation check wasn't working and so claiming to be Linux, but not being Linux, wasn't caught and failed. The right path here is to add IH_OS_LYNXSECURE to include/image.h and handling of it in the various boot/ files that need it. Then the its should have 'os = "lynxsecure"' so that it sets that field correctly. -- Tom signature.asc Description: PGP signature
RE: Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
Hi, yes of course. Here it is: $ mkimage -l build/ed7ct-cb.srp FIT description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Created: Thu Feb 5 13:58:31 2026 Image 0 (kernel-1) Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Created: Thu Feb 5 13:58:31 2026 Type: Kernel Image Compression: uncompressed Data Size:262512264 Bytes = 256359.63 KiB = 250.35 MiB Architecture: AArch64 OS: Linux Load Address: 0x4020 Entry Point: 0x40200040 Image 1 (fdt-1) Description: Flattened Device Tree blob for LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Created: Thu Feb 5 13:58:31 2026 Type: Flat Device Tree Compression: uncompressed Data Size:79519 Bytes = 77.66 KiB = 0.08 MiB Architecture: AArch64 Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: LynxSecure 2025.10.0-39844b80e0 SRP (aarch64) Kernel: kernel-1 FDT: fdt-1 Pls keep me in to loop, I am quite interested in this Greetings Dorde Dorde Stojicevic Networks and Cybersecurity Rohde & Schwarz SIT GmbH Hemminger Strasse 41 | 70499 Stuttgart-Weilimdorf | Germany Phone: +4971169945195 Internet: www.rohde-schwarz.com Geschäftsführer / Managing Director: Ralf Koenzen Aufsichtsratsvorsitzender / Chair of the Supervisory Board: Mario Paoli Sitz / Registered Office: Stuttgart Handelsregister / Commercial Register: AG Stuttgart HRB 759 934 Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE 121 963 283 Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 877 727 67 -Original Message- From: Tom Rini Sent: Friday, February 6, 2026 2:55 AM To: Stojicevic Dorde (11SIEPT1) Cc: Quentin Schulz ; [email protected] Subject: *EXT* Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04 ***CAUTION_Invalid_Signature*** On Thu, Feb 05, 2026 at 12:20:27PM +, Dorde Stojicevic wrote: > Hi guys, > > and thanks for your fast response. > > Sorry for the formatting issue, I am bound to our company Outlook, which > hard-codes our signatures, so this one will not be possible to take out. I am > not quite sure git send-email would work, for the same reason + corporate > stuff > > Anyhow, an update/clarification on the things going on here (I could/should > have sent initially, sorry for that): > > 1) Lynx Toolchain compiles a FIT Image with the following structure: > { > Images{ > Kernel-1 { > Data=Image; > } > Fdt-1 { > Data=system.dtb; > } > } > Configurations { > Here kernel-1 and fdt-1 used as default conf-1 > } > } > 2) Data=Image does not have the Magic Code 0x644d5241 > 3) It is booting with U-Boot SPL 2020.04+g1ccc9d93576+p1 according to Lynx. I > haven´t tested myself since we started with 2024.04, and we need it for some > other features. > 4) Then I investigated differences v2020.04 vs v2024.04, and found this part > of code came in. > 5) The finding is consistent with last error reported by U-Boot prior to > reset "Bad Linux ARM64 Image magic!" > > 6) I 1st tried patching the Data=Image in Lynx FIT with the magic code, but > it didn’t work. > 7) once I patched bootm in U-Boot to skip this part and behaves as in > v2020.04 (excluded all restructuring etc.) it booted the Lynx kernel > > Basically, v2024.04 correctly detects "Bad Linux ARM64 Image magic!", as none > is there at the moment, but in order to boot Lynx Hypervisor as-is this > backward compatibility to v2020.04 is needed. > > Does this shine more light on it? This is helpful, yes, thanks. Can you provide an "mkimage -l" of one of these failing to boot FIT images? -- Tom
Re: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
On Thu, Feb 05, 2026 at 12:20:27PM +, Dorde Stojicevic wrote:
> Hi guys,
>
> and thanks for your fast response.
>
> Sorry for the formatting issue, I am bound to our company Outlook, which
> hard-codes our signatures, so this one will not be possible to take out. I am
> not quite sure git send-email would work, for the same reason + corporate
> stuff
>
> Anyhow, an update/clarification on the things going on here (I could/should
> have sent initially, sorry for that):
>
> 1) Lynx Toolchain compiles a FIT Image with the following structure:
> {
> Images{
> Kernel-1 {
> Data=Image;
> }
> Fdt-1 {
> Data=system.dtb;
> }
> }
> Configurations {
> Here kernel-1 and fdt-1 used as default conf-1
> }
> }
> 2) Data=Image does not have the Magic Code 0x644d5241
> 3) It is booting with U-Boot SPL 2020.04+g1ccc9d93576+p1 according to Lynx. I
> haven´t tested myself since we started with 2024.04, and we need it for some
> other features.
> 4) Then I investigated differences v2020.04 vs v2024.04, and found this part
> of code came in.
> 5) The finding is consistent with last error reported by U-Boot prior to
> reset "Bad Linux ARM64 Image magic!"
>
> 6) I 1st tried patching the Data=Image in Lynx FIT with the magic code, but
> it didn’t work.
> 7) once I patched bootm in U-Boot to skip this part and behaves as in
> v2020.04 (excluded all restructuring etc.) it booted the Lynx kernel
>
> Basically, v2024.04 correctly detects "Bad Linux ARM64 Image magic!", as none
> is there at the moment, but in order to boot Lynx Hypervisor as-is this
> backward compatibility to v2020.04 is needed.
>
> Does this shine more light on it?
This is helpful, yes, thanks. Can you provide an "mkimage -l" of one of
these failing to boot FIT images?
--
Tom
signature.asc
Description: PGP signature
RE: Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
Hi guys,
and thanks for your fast response.
Sorry for the formatting issue, I am bound to our company Outlook, which
hard-codes our signatures, so this one will not be possible to take out. I am
not quite sure git send-email would work, for the same reason + corporate
stuff
Anyhow, an update/clarification on the things going on here (I could/should
have sent initially, sorry for that):
1) Lynx Toolchain compiles a FIT Image with the following structure:
{
Images{
Kernel-1 {
Data=Image;
}
Fdt-1 {
Data=system.dtb;
}
}
Configurations {
Here kernel-1 and fdt-1 used as default conf-1
}
}
2) Data=Image does not have the Magic Code 0x644d5241
3) It is booting with U-Boot SPL 2020.04+g1ccc9d93576+p1 according to Lynx. I
haven´t tested myself since we started with 2024.04, and we need it for some
other features.
4) Then I investigated differences v2020.04 vs v2024.04, and found this part of
code came in.
5) The finding is consistent with last error reported by U-Boot prior to reset
"Bad Linux ARM64 Image magic!"
6) I 1st tried patching the Data=Image in Lynx FIT with the magic code, but it
didn’t work.
7) once I patched bootm in U-Boot to skip this part and behaves as in v2020.04
(excluded all restructuring etc.) it booted the Lynx kernel
Basically, v2024.04 correctly detects "Bad Linux ARM64 Image magic!", as none
is there at the moment, but in order to boot Lynx Hypervisor as-is this
backward compatibility to v2020.04 is needed.
Does this shine more light on it?
Greetings
Dorde
Dorde Stojicevic
Networks and Cybersecurity
Rohde & Schwarz SIT GmbH
Hemminger Strasse 41 | 70499 Stuttgart-Weilimdorf | Germany
Phone: +4971169945195
Internet: www.rohde-schwarz.com
Geschäftsführer / Managing Director: Ralf Koenzen
Aufsichtsratsvorsitzender / Chair of the Supervisory Board: Mario Paoli
Sitz / Registered Office: Stuttgart
Handelsregister / Commercial Register: AG Stuttgart HRB 759 934
Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE 121
963 283
Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 877 727 67
-Original Message-
From: Tom Rini
Sent: Tuesday, February 3, 2026 6:00 PM
To: Stojicevic Dorde (11SIEPT1)
Cc: [email protected]
Subject: *EXT* Re: [PATCH] arm: Backward compatibility to U-Boot v2020.04
***CAUTION_Invalid_Signature***
On Tue, Feb 03, 2026 at 03:41:05PM +, Dorde Stojicevic wrote:
> From ae3f90922f5c31bd6198deb149edb9476ecfe4ef Mon Sep 17 00:00:00 2001
> From: Dorde Stojicevic
> [email protected] rz.com>
> Date: Tue, 3 Feb 2026 14:48:36 +0100
> Subject: [PATCH] arm: Backward compatibility to U-Boot v2020.04
> Series-to: [email protected]
> Series-version: 1
> Signed-off-by: Dorde Stojicevic
> [email protected] rz.com>
>
> Cover-letter:
> Backward compatibility with U-Boot v2020.04 Needed in order to boot
> LynxSecure Hypervisor, otherwise U-Boot will fail at this position and
> reset the controller END
> Commit-notes:
> Backward compatibility with U-Boot v2020.04 Needed in order to boot
> LynxSecure Hypervisor, otherwise U-Boot will fail at this position and
> reset the controller END
> ---
> boot/bootm.c | 27 ---
> 1 file changed, 12 insertions(+), 15 deletions(-)
This is an interesting find. And everything Quentin said applies. Also, the
patch as-sent doesn't apply cleanly due to spacing issues, possibly from
copy/paste to your email client?
Now, taking this patch and re-formatting things a bit, if do a "git diff
--ignore-all-space":
diff --git a/boot/bootm.c b/boot/bootm.c index 4bdca22ea8cf..9743051160ed 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -684,11 +684,7 @@ static int bootm_load_os(struct bootm_headers *images, int
boot_progress)
int ret;
ret = booti_setup(load, &relocated_addr, &image_size, false);
- if (ret) {
- printf("Failed to prep arm64 kernel (err=%d)\n", ret);
- return BOOTM_ERR_RESET;
- }
-
+ if (ret == 0) {
/* Handle BOOTM_STATE_LOADOS */
if (relocated_addr != load) {
printf("Moving Image from 0x%lx to 0x%lx,
end=0x%lx\n",
Is the interesting part. And you say this is on ARM, so we look at booti_setup
in arch/arm/lib/image.c. The failure cases of the function is only "Bad Linux
ARM64 Image magic!". So what are you trying to boot here, and is it really
acting like a Linux Kernel "Image" file, which has a specific magic value? Or
are we falling down to this c
