[U-Boot] [ARM]: File type for u-boot elf file
hi Albert, I am facing an issue with generation of AIS signed binaries for hawkboard. The aisgen utility takes the u-boot elf file as input and generates a ais binary, which is the file format recognised by the hawkboard's RBL(rom bootloader). After the relocation support for ARM, the elf file generated has file type as 'DYN (shared object)'. With this, the aisgen tool rejects the file as not being an elf file.
Can you please tell me what could have caused this change. I compiled u-boot for a powerpc board, and found that the file type in that case is 'ELF Executable'. Is there any specific reason why the file type has changed for ARM, as powerpc also supports relocation.
sughosh@Hardy:/tmp/u-boot$ /home/sughosh/hawk/tools/arm-2009q3/bin/arm-none-linux-gnueabi-readelf -h u-boot ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: ARM Version: 0x1 Entry point address: 0xc1080000 Start of program headers: 52 (bytes into file) Start of section headers: 488968 (bytes into file) Flags: 0x5000002, has entry point, Version5 EABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 24 Section header string table index: 21
-sughosh
Hi Sughosh,
Le 24/02/2011 11:01, sughosh ganu a écrit :
hi Albert, I am facing an issue with generation of AIS signed binaries for hawkboard. The aisgen utility takes the u-boot elf file as input and generates a ais binary, which is the file format recognised by the hawkboard's RBL(rom bootloader). After the relocation support for ARM, the elf file generated has file type as 'DYN (shared object)'. With this, the aisgen tool rejects the file as not being an elf file.
Can you please tell me what could have caused this change. I compiled u-boot for a powerpc board, and found that the file type in that case is 'ELF Executable'. Is there any specific reason why the file type has changed for ARM, as powerpc also supports relocation.
You have already answered your own question: the move to relocatable executable caused the change you see.
I suspect the utility freaks out because it thinks the ELF cannot be made into a binary like it would previously, but actually the binary generation process did not change when we refactored the relocation -- maybe the utility would work on our relocatable ELFs with just the check for ELF type bypassed.
In any case, you should see with the makers of the utility how it should be updated to handle -pie generated elf files.
-sughosh
Amicalement,
hi Albert,
On Thu, Feb 24, 2011 at 4:27 PM, Albert ARIBAUD albert.aribaud@free.frwrote:
Hi Sughosh,
Le 24/02/2011 11:01, sughosh ganu a écrit :
Can you please tell me what could have caused this change. I compiled
u-boot for a powerpc board, and found that the file type in that case is 'ELF Executable'. Is there any specific reason why the file type has changed for ARM, as powerpc also supports relocation.
You have already answered your own question: the move to relocatable executable caused the change you see.
Yes, this is true, what i wanted to understand was the reason why the 'Type' field is different for ARM now, compared to the u-boot elf image for powerpc. Not sure if i am missing something, but powerpc also supports relocation, so what is the reason for the difference in the two image types. Prior to relocation, we used to get the file type as 'Executable', same as powerpc.
I suspect the utility freaks out because it thinks the ELF cannot be made
into a binary like it would previously, but actually the binary generation process did not change when we refactored the relocation -- maybe the utility would work on our relocatable ELFs with just the check for ELF type bypassed.
Yes, even i think that would be the case, but i guess that would call for changes in the utility. Perhaps someone from TI can look into this.
-sughosh
Le 24/02/2011 12:08, sughosh ganu a écrit :
hi Albert,
On Thu, Feb 24, 2011 at 4:27 PM, Albert ARIBAUD <albert.aribaud@free.fr mailto:albert.aribaud@free.fr> wrote:
Hi Sughosh, Le 24/02/2011 11:01, sughosh ganu a écrit : Can you please tell me what could have caused this change. I compiled u-boot for a powerpc board, and found that the file type in that case is 'ELF Executable'. Is there any specific reason why the file type has changed for ARM, as powerpc also supports relocation. You have already answered your own question: the move to relocatable executable caused the change you see.Yes, this is true, what i wanted to understand was the reason why the 'Type' field is different for ARM now, compared to the u-boot elf image for powerpc. Not sure if i am missing something, but powerpc also supports relocation, so what is the reason for the difference in the two image types. Prior to relocation, we used to get the file type as 'Executable', same as powerpc.
PPC and ARM have different architectures, different toolchains, different methods for relocation -- that explains the different ELF type.
I suspect the utility freaks out because it thinks the ELF cannot be made into a binary like it would previously, but actually the binary generation process did not change when we refactored the relocation -- maybe the utility would work on our relocatable ELFs with just the check for ELF type bypassed.Yes, even i think that would be the case, but i guess that would call for changes in the utility. Perhaps someone from TI can look into this.
Isn't there some official support channel?
-sughosh
Amicalement,
hi Albert,
On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD albert.aribaud@free.frwrote:
Le 24/02/2011 12:08, sughosh ganu a écrit :
I suspect the utility freaks out because it thinks the ELF cannot be
made into a binary like it would previously, but actually the binary generation process did not change when we refactored the relocation -- maybe the utility would work on our relocatable ELFs with just the check for ELF type bypassed.
Yes, even i think that would be the case, but i guess that would call for changes in the utility. Perhaps someone from TI can look into this.
Isn't there some official support channel?
I am not sure on this one. Hawkboard was a open source project, so hoping someone from TI on the list can take a look into this.
Sandeep, if you can point me to the person/list where this can be taken up, i can follow up. Thanks.
-sughosh
Hi sughosh,
hi Albert,
On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD albert.aribaud@free.frwrote:
Le 24/02/2011 12:08, sughosh ganu a écrit :
I suspect the utility freaks out because it thinks the ELF cannot be
made into a binary like it would previously, but actually the binary generation process did not change when we refactored the relocation -- maybe the utility would work on our relocatable ELFs with just the check for ELF type bypassed.
Yes, even i think that would be the case, but i guess that would call for changes in the utility. Perhaps someone from TI can look into this.
Isn't there some official support channel?
I am not sure on this one. Hawkboard was a open source project, so hoping someone from TI on the list can take a look into this.
Sandeep, if you can point me to the person/list where this can be taken up, i can follow up. Thanks.
We should really strive to get the functionality of the utility into U-Boot itself. Our mkimage already supports "custom wrappers" for i.MX and Kirkwood (cf. tools/{imximage,kwbimage}.c), so why not extend it for the AIS stuff?
Dependencies on external utilities is always a bad thing and breaks easily as was just demonstrated.
Cheers Detlev
Le 24/02/2011 14:26, Detlev Zundel a écrit :
Hi sughosh,
hi Albert,
On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUDalbert.aribaud@free.frwrote:
Le 24/02/2011 12:08, sughosh ganu a écrit :
I suspect the utility freaks out because it thinks the ELF cannot bemade into a binary like it would previously, but actually the binary generation process did not change when we refactored the relocation -- maybe the utility would work on our relocatable ELFs with just the check for ELF type bypassed.Yes, even i think that would be the case, but i guess that would call for changes in the utility. Perhaps someone from TI can look into this.
Isn't there some official support channel?
I am not sure on this one. Hawkboard was a open source project, so hoping someone from TI on the list can take a look into this.
Sandeep, if you can point me to the person/list where this can be taken up, i can follow up. Thanks.
We should really strive to get the functionality of the utility into U-Boot itself. Our mkimage already supports "custom wrappers" for i.MX and Kirkwood (cf. tools/{imximage,kwbimage}.c), so why not extend it for the AIS stuff?
From the general search I did while responding in this thread, AIS is not documented publically -- but I may have missed it.
Dependencies on external utilities is always a bad thing and breaks easily as was just demonstrated.
Agreed -- although actually, its the dependency on *binary, closed* external utilities that causes the issue.
Cheers Detlev
Amicalement,
Hi Albert,
On Fri, Feb 25, 2011 at 2:18 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
[...] From the general search I did while responding in this thread, AIS is not documented publically -- but I may have missed it.
I've been around this before so it rang a few bells. The "Application Image Script (AIS) Boot" section of the OMAPL138's "Using the OMAP-L1x8 Bootloader" document [1] has a pretty good summary of AIS. Hope this helps.
[...] Le 24/02/2011 14:26, Detlev Zundel a écrit :
Dependencies on external utilities is always a bad thing and breaks easily as was just demonstrated.
Agreed -- although actually, its the dependency on *binary, closed* external utilities that causes the issue.
+1
I would be happy to help with testing any new *image tools to replace AISGen.
Best Regards, Ben Gardiner
[1] http://www.ti.com/litv/pdf/sprab41c
--- Nanometrics Inc. http://www.nanometrics.ca
hi Ben,
On Fri, Feb 25, 2011 at 7:11 PM, Ben Gardiner bengardiner@nanometrics.cawrote:
Hi Albert,
On Fri, Feb 25, 2011 at 2:18 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
[...] From the general search I did while responding in this thread, AIS is not documented publically -- but I may have missed it.
I've been around this before so it rang a few bells. The "Application Image Script (AIS) Boot" section of the OMAPL138's "Using the OMAP-L1x8 Bootloader" document [1] has a pretty good summary of AIS. Hope this helps.
I have been trying to compile the HexAIS files found in the tarball, but facing some issues. Will check this problem, to see if a way can be found to change the elf file recognition method of the utility.
But it would be great if this utility can be added to mainline, as Detlev suggested.
-sughosh
Le 25/02/2011 15:55, sughosh ganu a écrit :
I have been trying to compile the HexAIS files found in the tarball, but facing some issues. Will check this problem, to see if a way can be found to change the elf file recognition method of the utility.
But it would be great if this utility can be added to mainline, as Detlev suggested.
Not speaking for Wolfgang here, but IIUC, aisgen is a binary Windows application, and in this form, it is not going to be added to mainline. Now if you meant an open source utility derived from the AIS info made available e.g. by Ben, then all we need is a volunteer. :)
-sughosh
Amicalement,
Dear Albert ARIBAUD,
In message 4D67E64A.1090500@free.fr you wrote:
I have been trying to compile the HexAIS files found in the tarball, but facing some issues. Will check this problem, to see if a way can be found to change the elf file recognition method of the utility.
But it would be great if this utility can be added to mainline, as Detlev suggested.
Not speaking for Wolfgang here, but IIUC, aisgen is a binary Windows application, and in this form, it is not going to be added to mainline. Now if you meant an open source utility derived from the AIS info made available e.g. by Ben, then all we need is a volunteer. :)
You probably misunderstand. We do not want to add this tool, but it's functionality - similar like today mkimages is capable of building several other, similar custom image formats.
Best regards,
Wolfgang Denk
On Sun, Feb 27, 2011 at 10:32, Wolfgang Denk wd@denx.de wrote:
Dear Albert ARIBAUD,
In message 4D67E64A.1090500@free.fr you wrote:
I have been trying to compile the HexAIS files found in the tarball, but facing some issues. Will check this problem, to see if a way can be found to change the elf file recognition method of the utility.
But it would be great if this utility can be added to mainline, as Detlev suggested.
Not speaking for Wolfgang here, but IIUC, aisgen is a binary Windows application, and in this form, it is not going to be added to mainline. Now if you meant an open source utility derived from the AIS info made available e.g. by Ben, then all we need is a volunteer. :)
You probably misunderstand. We do not want to add this tool, but it's functionality - similar like today mkimages is capable of building several other, similar custom image formats.
The x-loader 1st stage bootloader for OMAP includes a tool to generate images to allow booting at least OMAP 35xx parts from MMC/SD and NAND memories.
http://gitorious.org/x-load-omap3/mainline/blobs/master/Makefile (see the x-load.bin.ift target) http://gitorious.org/x-load-omap3/mainline/blobs/master/scripts/signGP.c (the utility itself)
signGP doesn't have a lot of documentation in it for what all the magic values mean. You can use section 25.4.8 in the OMAP tech ref. manual to decrypt the structures.
Dear Andrew Dyer,
In message AANLkTik10yZKNgvOc3BOSA=TZbNOF1Ck2BWy_Nh5ouzj@mail.gmail.com you wrote:
The x-loader 1st stage bootloader for OMAP includes a tool to generate images to allow booting at least OMAP 35xx parts from MMC/SD and NAND memories.
Right, and it makes absolutly no sense to me to have this as a separate tool. The NAND boot code would map nicely into the nand_spl framework, and the same could/should be done for the MMC boot part.
signGP doesn't have a lot of documentation in it for what all the magic values mean. You can use section 25.4.8 in the OMAP tech ref. manual to decrypt the structures.
And again I see nothing in it that could not be done in mkimage - eventually with less code and effort.
Best regards,
Wolfgang Denk
participants (6)
-
Albert ARIBAUD -
Andrew Dyer -
Ben Gardiner -
Detlev Zundel -
sughosh ganu -
Wolfgang Denk