Hi Ryan,

I'm replying with a copy to linaro-dev@ as I believe adding support to UEFI into l-m-c will require a new hwpack format, which is something that needs discussion with a wider audience.

On 11/01/12 13:51, Ryan Harkin wrote:

Hi Danilo,

Ok, as we agreed, I've had a hack at the l-m-c script to produce an image with UEFI instead of (or as well as) U-Boot.

I've attached a diff for the changes I made.

As I have no prior experience with this script, my changes are purely for "demo" purposes. You're allowed to laugh at my basic perl skills ;-)

I hope you meant Python? Or did you include some perl code here as well? ;)

The changes are "generic", i.e. don't take into account that platforms like Snowball have special "magic" for U-Boot and will probably need special magic for UEFI. I expect "someone" will make those changes whenever UEFI is developed for such platforms.

Is it implemented for any of our supported platforms already? If not, do you have any idea when that might happen?

Also, the attached diff is only for hacking l-m-c. I haven't done android-l-m-c, although I expect it's similar. And I haven't touched the hwpack creation scripts so far.

I'm writing this before I've gone through the diff, but I'd expect the hwpacks would have to grow some config options for that, which means a new hwpack format. If that's the case, we'll need to invite more people into the discussion and probably agree on what the new hwpack should look like before we change l-m-c. Sounds like a good candidate for a Connect session. :)

So, what have I done? Quite simple, really: I've added a --bootloader option to linaro-media-create. The option takes the values: none, uboot, uefi or all. Default is "uboot" to mimic current behaviour.

What is the desired behaviour of this option?

none - no bootloader is copied to the disk image uboot - only U-Boot images are copied to the disk image uefi - only UEFI images are copied to the disk image all - all bootloaders in the hwpack are copied to the disk image

I'm wondering... do you have any use cases for the none and all options?

If you specify a bootloader that doesn't exist in the hwpack, the script will fail horribly. This is like current behaviour: if uboot is not in

Right, but currently we know that the hwpacks for boards that use u-boot will include the u-boot binary, whereas with your changes users will have to first check that the bootloader they want is in the hwpack.

I wonder if it wouldn't be better to make hwpacks include just one bootloader (whichever is chosen by the hwpack author)?

the hwpack, l-m-c will fail. I think this is only a problem for the 'all' case. As a user, I'd expect the 'all' case to work if UEFI, U-Boot or both were missing. But I'm not sure how best to fix that.

How did I test it?

• un-tar an existing hwpack
• add a 'uefi' directory with the files 'uefi.bin' and 'sec_uefi.bin'
• edit 'metadata' to add the UEFI keys: UEFI=uefi/uefi.bin SEC_UEFI=uefi/sec_uefi.bin UEFI_IN_BOOT_PART=Yes
• re-tar it as before.
• run l-m-c

What next? I'd like you to review my changes and see if they make sense. As mentioned earlier, I'd expect you to have a lot of criticisms about the way I've implemented it, but I hope my example can help you understand the direction I'd like the script to take.

Your implementation seems straightforward to me, but given what I said above, I think there's not much point in discussing the implementation in l-m-c before we have agreed on what the new hwpack format should look like.

Then, I need to work on the hwpack create scripts. I am a bit in the dark with this as I don't know enough about hwpack creation. I believe that to get the scripts to create a hwpack with UEFI inside, I am going to have to package UEFI somehow. This is the area that I am not familiar with: all of the packaging in the ARM LT has been done by either Ricardo or Tixy. So, any links, docs, or hints would be appreciated.

A hwpack is just a bunch of .deb packages, some board-specific configs and the bootloader binary. In the case of UEFI, we'll probably only need a binary file to copy to the boot partition, so in theory there's no need for a .deb package. However, the hwpack creation script will need to get that from somewhere and given it already knows where to get .debs from, that might be easier. We do that for u-boot, but given its special nature, it doesn't need to be in the rootfs, so we just extract the actual bootloader from the .deb and put that in a fixed place for l-m-c to find. I imagine we'd do something similar for UEFI.