[U-Boot] Linux boot and list loading feature
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
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
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
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
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
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
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
participants (4)
-
Aneesh V -
Heiko Schocher -
Simon Schwarz -
Wolfgang Denk