[U-Boot] [ARM]: File type for u-boot elf file

[U-Boot] [ARM]: File type for u-boot elf file

[sughosh ganu]

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 at 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

[U-Boot] [ARM]: File type for u-boot elf file

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] [ARM]: File type for u-boot elf file

[sughosh ganu]

hi Albert,

On Thu, Feb 24, 2011 at 4:27 PM, Albert ARIBAUD <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.

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

[U-Boot] [ARM]: File type for u-boot elf file

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] [ARM]: File type for u-boot elf file

[sughosh ganu]

hi Albert,

On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD <albert.aribaud@free.fr>wrote:

> 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

[U-Boot] [ARM]: File type for u-boot elf file

[Detlev Zundel]

Hi sughosh,

> hi Albert,
>
> On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD <albert.aribaud@free.fr>wrote:
>
>> 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

-- 
Whenever you find yourself on the side of the majority it is
time to pause and reflect.
                                                -- Mark Twain
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [ARM]: File type for u-boot elf file

[Albert ARIBAUD]

Le 24/02/2011 14:26, Detlev Zundel a ?crit :
> Hi sughosh,
>
>> hi Albert,
>>
>> On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD<albert.aribaud@free.fr>wrote:
>>
>>> 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?

 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,
-- 
Albert.

[U-Boot] [ARM]: File type for u-boot elf file

[Ben Gardiner]

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

[U-Boot] [ARM]: File type for u-boot elf file

[sughosh ganu]

hi Ben,

On Fri, Feb 25, 2011 at 7:11 PM, Ben Gardiner <bengardiner@nanometrics.ca>wrote:

> 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

[U-Boot] [ARM]: File type for u-boot elf file

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] [ARM]: File type for u-boot elf file

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I refuse to have a battle of wits with an unarmed person."

[U-Boot] [ARM]: File type for u-boot elf file

[Andrew Dyer]

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.

[U-Boot] [ARM]: File type for u-boot elf file

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of anthropomorphic terminology when  dealing  with  computing
systems is a symptom of professional immaturity.   -- Edsger Dijkstra

[U-Boot] [ARM]: File type for u-boot elf file

[rojan]

 I have OMAP L138 Hawkboard which is loaded with some other program.
I am new to this hawkboard and tried to boot as per instructions from
user guide in http://www.hawkboard.org/ , system is not coming to
hawkboard.org > to access command. It is coming as follows.
 
Please help me to make it ready.
 
Switch positions made as follows
 
Pin1 = ON
Pin2 = OFF
Pin3 = OFF
Pin4 = OFF
 
Terminal data as follows:
 
U-Boot 2009.01-dirty (Nov 26 2009 - 02:15:00)
 
DRAM:  128 MB
NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron NAND
128MiB 1,8
V 8-bit)
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x03500000
nand_read_bbt: Bad block at 0x049a0000
128 MiB
In:    serial
Out:   serial
Err:   serial
ARM Clock : 300000000 Hz
DDR Clock : 150000000 Hz
Ethernet PHY: GENERIC @ 0x07
Hit any key to stop autoboot:  0
 
NAND read: device 0 offset 0x200000, size 0x300000
..
 
 
Regards,
Rojan Joy
 

[U-Boot] [ARM]: File type for u-boot elf file

[Tom Rini]

On Mon, Dec 5, 2011 at 2:19 AM, rojan <rojan.joy@bpltelecom.com> wrote:
> ?I have OMAP L138 Hawkboard which is loaded with some other program.
> I am new to this hawkboard and tried to boot as per instructions from
> user guide in http://www.hawkboard.org/ , system is not coming to
> hawkboard.org > to access command. It is coming as follows.
>
> Please help me to make it ready.
>
> Switch positions made as follows
>
> Pin1 = ON
> Pin2 = OFF
> Pin3 = OFF
> Pin4 = OFF
>
> Terminal data as follows:
>
> U-Boot 2009.01-dirty (Nov 26 2009 - 02:15:00)
>
> DRAM: ?128 MB
> NAND: ?NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron NAND
> 128MiB 1,8
> V 8-bit)
> Bad block table found at page 65472, version 0x01
> Bad block table found at page 65408, version 0x01
> nand_read_bbt: Bad block at 0x03500000
> nand_read_bbt: Bad block at 0x049a0000
> 128 MiB
> In: ? ?serial
> Out: ? serial
> Err: ? serial
> ARM Clock : 300000000 Hz
> DDR Clock : 150000000 Hz
> Ethernet PHY: GENERIC @ 0x07
> Hit any key to stop autoboot: ?0

During this countdown you need to 'hit any key' to stop the boot from
happening and give you the U-Boot prompt.

-- 
Tom