[U-Boot] Linux boot and list loading feature

[U-Boot] Linux boot and list loading feature

[Simon Schwarz]

Hi Aneesh,

I am working on the OS booting right now and have a bigger change of 
your code in spl.c in mind.

Hope you can say one or two words what you think about it.

THE PROBLEM
For the direct OS boot and in some other situations - env image e.g., I 
have to load more than one image in SPL.

This can be done by hardcoding these cases and use #ifdef or ifs to 
switch between them. Or I can implement a general image loading with lists.
(This was discussed here: 
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)

I already implemented the list for NAND - and now start prototyping it 
also for MMC. There will be some change to your spl.c-code so I decided 
to ask what you think about it.

These are the modifications in the board config:

/* Assemble boot lists */
/* Last image in list is image to boot! */
/* NAND boot lists */
#define CONFIG_SPL_NAND_OS_LOAD {CONFIG_CMD_SAVEBP_NAND_OFS, \
                                         CONFIG_SYS_NAND_SPL_KERNEL_OFFS}

#ifdef CONFIG_NAND_ENV_DST
#ifdef CONFIG_ENV_OFFSET_REDUND
#define CONFIG_SPL_NAND_UBOOT_LOAD {CONFIG_ENV_OFFSET_REDUND, \
                                         CONFIG_ENV_OFFSET, \
                                         CONFIG_SYS_NAND_U_BOOT_OFFS}
#endif
#define CONFIG_SPL_NAND_UBOOT_LOAD {CONFIG_ENV_OFFSET, \
                                         CONFIG_SYS_NAND_U_BOOT_OFFS}
#else
#define CONFIG_SPL_NAND_UBOOT_LOAD {CONFIG_SYS_NAND_U_BOOT_OFFS}
#endif

/* MMC RAW boot lists */
#define CONFIG_SPL_MMCSD_RAW_OS_LOAD {0x0, 0x0} /* XXX: define me */
#define CONFIG_SPL_MMCSD_RAW_UBOOT_LOAD {\
                         CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR}

/* MMC RAW boot lists */
#define CONFIG_SPL_MMCSD_FAT_OS_LOAD {"uImage", "fdt_params.img"}
#define CONFIG_SPL_MMCSD_FAT_UBOOT_LOAD {CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME}

Essentially just putting together the lists for all the different boot 
devices/modes.

Your mmc_load_image_raw will then look like this:
static void mmc_load_image_raw(struct mmc *mmc)
{
         u32 image_size_sectors, err;
         const struct image_header *header;
         uint32_t i;
#ifdef CONFIG_SPL_OS_BOOT
         uint32_t load_list_os[] = CONFIG_SPL_MMCSD_RAW_OS_LOAD;
#endif
         uint32_t load_list_uboot[] = CONFIG_SPL_MMCSD_RAW_UBOOT_LOAD;
         uint32_t *load_list = load_list_uboot;

         header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
                                                 sizeof(struct 
image_header));

#ifdef CONFIG_SPL_OS_BOOT
         if (!uboot_key())
                 load_list = load_list_os;
#endif

         for(i = 0; i < N_LOAD_LIST_ENTRYS; i++) {
                 /* read image header to find the image size & load 
address */
                 err = mmc->block_dev.block_read(0, load_list[i], 1,
                         (void *)header);
                 if (err <= 0)
                         goto end;
                 parse_image_header(header);
                 /* convert size to sectors - round up */
                 image_size_sectors = (image_size + MMCSD_SECTOR_SIZE - 1) /
                         MMCSD_SECTOR_SIZE;
                 /* Read the header too to avoid extra memcpy */
                 err = mmc->block_dev.block_read(0,
                         load_list[i], image_size_sectors, 
                                (void *)image_load_addr);
         }

end:
         if (err <= 0) {
                 printf("spl: mmc blk read err - %d\n", err);
                 hang();
         }
}

This is just a protoype - quick, dirty & untested. I would be happy to 
hear what you think about the approach.

Regards
Simon

[U-Boot] Linux boot and list loading feature

[Aneesh V]

Hi Simon,

On Monday 01 August 2011 04:50 PM, Simon Schwarz wrote:
> Hi Aneesh,
>
> I am working on the OS booting right now and have a bigger change of
> your code in spl.c in mind.
>
> Hope you can say one or two words what you think about it.
>
> THE PROBLEM
> For the direct OS boot and in some other situations - env image e.g., I
> have to load more than one image in SPL.
>
> This can be done by hardcoding these cases and use #ifdef or ifs to
> switch between them. Or I can implement a general image loading with lists.
> (This was discussed here:
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)

At the outset, wonder why we can not use the default bootargs string in
the kernel image instead of passing it from the bootloader. For direct
kernel boot from SPL, that looks like the best option for me. Then we
will not need all this. Am I missing something?

best regards,
Aneesh

[U-Boot] Linux boot and list loading feature

[Simon Schwarz]

Hi Aneesh,

On 08/01/2011 02:56 PM, Aneesh V wrote:
> Hi Simon,
>
> On Monday 01 August 2011 04:50 PM, Simon Schwarz wrote:
>> Hi Aneesh,
>>
>> I am working on the OS booting right now and have a bigger change of
>> your code in spl.c in mind.
>>
>> Hope you can say one or two words what you think about it.
>>
>> THE PROBLEM
>> For the direct OS boot and in some other situations - env image e.g., I
>> have to load more than one image in SPL.
>>
>> This can be done by hardcoding these cases and use #ifdef or ifs to
>> switch between them. Or I can implement a general image loading with
>> lists.
>> (This was discussed here:
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)
>
> At the outset, wonder why we can not use the default bootargs string in
> the kernel image instead of passing it from the bootloader. For direct
> kernel boot from SPL, that looks like the best option for me. Then we
> will not need all this. Am I missing something?
>
 From the documentation it is mandatory for ARM to pass ATAGS (or FDT I 
assume): http://www.arm.linux.org.uk/developer/booting.php

So I think your solution would work - but IMHO would be too simple.

The beauty is that we can save the config of ATAGS/FDT directly in 
u-boot and pass this image at the next boot to the SPL. This means we 
can boot the exact same configuration with the SPL as with standard 
u-boot - without recompiling the kernel. Trade-off: a more complex SPL.

> best regards,
> Aneesh

Regards
Simon

[U-Boot] Linux boot and list loading feature

[Aneesh V]

Hi Simon,

On Monday 01 August 2011 07:43 PM, Simon Schwarz wrote:
> Hi Aneesh,
>
> On 08/01/2011 02:56 PM, Aneesh V wrote:
>> Hi Simon,
>>
>> On Monday 01 August 2011 04:50 PM, Simon Schwarz wrote:
>>> Hi Aneesh,
>>>
>>> I am working on the OS booting right now and have a bigger change of
>>> your code in spl.c in mind.
>>>
>>> Hope you can say one or two words what you think about it.
>>>
>>> THE PROBLEM
>>> For the direct OS boot and in some other situations - env image e.g., I
>>> have to load more than one image in SPL.
>>>
>>> This can be done by hardcoding these cases and use #ifdef or ifs to
>>> switch between them. Or I can implement a general image loading with
>>> lists.
>>> (This was discussed here:
>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)
>>
>> At the outset, wonder why we can not use the default bootargs string in
>> the kernel image instead of passing it from the bootloader. For direct
>> kernel boot from SPL, that looks like the best option for me. Then we
>> will not need all this. Am I missing something?
>>
>  From the documentation it is mandatory for ARM to pass ATAGS (or FDT I
> assume): http://www.arm.linux.org.uk/developer/booting.php
>
> So I think your solution would work - but IMHO would be too simple.
>
> The beauty is that we can save the config of ATAGS/FDT directly in
> u-boot and pass this image at the next boot to the SPL. This means we
> can boot the exact same configuration with the SPL as with standard
> u-boot - without recompiling the kernel. Trade-off: a more complex SPL.

If my suggestion works I would still prefer that. If you want better
configurability you can always use u-boot! Direct kernel boot from SPL
is likely to be used in production systems for improved boot-time,
where it should be OK to hard-code the boot-args. Using u-boot seems to
be a better option if changing bootargs frequently is a requirement.

Please note that any scheme that you comes up with should also work for
FAT boot from SD/MMC card, which means you need to have a way of
converting your ATAGS list into a file, reading it and so on. A lot of
trouble without much value-add in my opinion(assuming that hard-coded
bootargs works).

In the worst case I would prefer hard-coding bootargs in SPL in a
config flag and using it to build the list in SPL.

I would love to hear others' views on this.

best regards,
Aneesh

[U-Boot] Linux boot and list loading feature

[Heiko Schocher]

Hello Aneesh,

Aneesh V wrote:
> Hi Simon,
> 
> On Monday 01 August 2011 07:43 PM, Simon Schwarz wrote:
>> Hi Aneesh,
>>
>> On 08/01/2011 02:56 PM, Aneesh V wrote:
>>> Hi Simon,
>>>
>>> On Monday 01 August 2011 04:50 PM, Simon Schwarz wrote:
>>>> Hi Aneesh,
>>>>
>>>> I am working on the OS booting right now and have a bigger change of
>>>> your code in spl.c in mind.
>>>>
>>>> Hope you can say one or two words what you think about it.
>>>>
>>>> THE PROBLEM
>>>> For the direct OS boot and in some other situations - env image e.g., I
>>>> have to load more than one image in SPL.
>>>>
>>>> This can be done by hardcoding these cases and use #ifdef or ifs to
>>>> switch between them. Or I can implement a general image loading with
>>>> lists.
>>>> (This was discussed here:
>>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)
>>>
>>> At the outset, wonder why we can not use the default bootargs string in
>>> the kernel image instead of passing it from the bootloader. For direct
>>> kernel boot from SPL, that looks like the best option for me. Then we
>>> will not need all this. Am I missing something?
>>>
>>  From the documentation it is mandatory for ARM to pass ATAGS (or FDT I
>> assume): http://www.arm.linux.org.uk/developer/booting.php
>>
>> So I think your solution would work - but IMHO would be too simple.
>>
>> The beauty is that we can save the config of ATAGS/FDT directly in
>> u-boot and pass this image at the next boot to the SPL. This means we
>> can boot the exact same configuration with the SPL as with standard
>> u-boot - without recompiling the kernel. Trade-off: a more complex SPL.
> 
> If my suggestion works I would still prefer that. If you want better
> configurability you can always use u-boot! Direct kernel boot from SPL
> is likely to be used in production systems for improved boot-time,
> where it should be OK to hard-code the boot-args. Using u-boot seems to
> be a better option if changing bootargs frequently is a requirement.
> 
> Please note that any scheme that you comes up with should also work for
> FAT boot from SD/MMC card, which means you need to have a way of

Does this actually work?

> converting your ATAGS list into a file, reading it and so on. A lot of
> trouble without much value-add in my opinion(assuming that hard-coded
> bootargs works).
> 
> In the worst case I would prefer hard-coding bootargs in SPL in a
> config flag and using it to build the list in SPL.
> 
> I would love to hear others' views on this.

The pro for the way I pointed out here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345

is that we have no fix coded solution, instead we can add a list of
"binaries" to load in mem, and jump to the destination address.
In future we will have DT instead of ATAGS maybe + Ramdisk, or not
Linux, maybe an other OS, which needs n other binaries in mem
before starting ...

Or we can parse the state from a GPIO and load an u-boot instead
Linux ...

that was just an idea ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Linux boot and list loading feature

[Wolfgang Denk]

Dear Aneesh V,

In message <4E37F082.9060402@ti.com> you wrote:
> 
> If my suggestion works I would still prefer that. If you want better
> configurability you can always use u-boot! Direct kernel boot from SPL
> is likely to be used in production systems for improved boot-time,
> where it should be OK to hard-code the boot-args. Using u-boot seems to
> be a better option if changing bootargs frequently is a requirement.

Hard-coding the boot args in the kernel image is a major pain and
thus something you really want to avoid.

> Please note that any scheme that you comes up with should also work for
> FAT boot from SD/MMC card, which means you need to have a way of
> converting your ATAGS list into a file, reading it and so on. A lot of
> trouble without much value-add in my opinion(assuming that hard-coded
> bootargs works).

You get a pretty big amount of flexibility at very low cost.  We
should not give this up lightly.

> In the worst case I would prefer hard-coding bootargs in SPL in a
> config flag and using it to build the list in SPL.

No, please don't. That'd be even worse because you will try to avoid
updating the SPL at all cost.

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 am not now, nor have I ever been, a member of the demigodic party.
                                                   -- Dennis Ritchie

[U-Boot] Linux boot and list loading feature

[Simon Schwarz]

Hi Aneesh,

sorry for answering this late...

On 08/02/2011 02:41 PM, Aneesh V wrote:
> Hi Simon,
>
> On Monday 01 August 2011 07:43 PM, Simon Schwarz wrote:
>> Hi Aneesh,
>>
>> On 08/01/2011 02:56 PM, Aneesh V wrote:
>>> Hi Simon,
>>>
>>> On Monday 01 August 2011 04:50 PM, Simon Schwarz wrote:
>>>> Hi Aneesh,
>>>>
>>>> I am working on the OS booting right now and have a bigger change of
>>>> your code in spl.c in mind.
>>>>
>>>> Hope you can say one or two words what you think about it.
>>>>
>>>> THE PROBLEM
>>>> For the direct OS boot and in some other situations - env image e.g., I
>>>> have to load more than one image in SPL.
>>>>
>>>> This can be done by hardcoding these cases and use #ifdef or ifs to
>>>> switch between them. Or I can implement a general image loading with
>>>> lists.
>>>> (This was discussed here:
>>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)
>>>
>>> At the outset, wonder why we can not use the default bootargs string in
>>> the kernel image instead of passing it from the bootloader. For direct
>>> kernel boot from SPL, that looks like the best option for me. Then we
>>> will not need all this. Am I missing something?
>>>
>> From the documentation it is mandatory for ARM to pass ATAGS (or FDT I
>> assume): http://www.arm.linux.org.uk/developer/booting.php
>>
>> So I think your solution would work - but IMHO would be too simple.
>>
>> The beauty is that we can save the config of ATAGS/FDT directly in
>> u-boot and pass this image at the next boot to the SPL. This means we
>> can boot the exact same configuration with the SPL as with standard
>> u-boot - without recompiling the kernel. Trade-off: a more complex SPL.
>
> If my suggestion works I would still prefer that. If you want better
> configurability you can always use u-boot! Direct kernel boot from SPL
> is likely to be used in production systems for improved boot-time,
> where it should be OK to hard-code the boot-args. Using u-boot seems to
> be a better option if changing bootargs frequently is a requirement.

I see your point. I will try both approaches in my BA.

>
> Please note that any scheme that you comes up with should also work for
> FAT boot from SD/MMC card, which means you need to have a way of
> converting your ATAGS list into a file, reading it and so on. A lot of
> trouble without much value-add in my opinion(assuming that hard-coded
> bootargs works).

This was something I didn't have on the radar. I haven't used FAT in 
u-boot. So we have a read-only implementation?

How are the chances to get this into mainline if it supports only NAND 
at first - but is designed to be able to be used with others also?

>
> In the worst case I would prefer hard-coding bootargs in SPL in a
> config flag and using it to build the list in SPL.
>
> I would love to hear others' views on this.
>

So in conclusion: I will implement it. I will have to do this anyway for 
my BA. I know that there is some interest for this feature - so a 
prototype to base the discussion on is not too bad I think.

As soon as there is something runnable I will post it for discussion.

Regards
Simon