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,
Quoted 7 lines · Simon Schwarz
Hi Aneesh,
I am working on the OS booting right now and have a bigger change of your code in
spl.cin mind.Hope you can say one or two words what you think about it.
Quoted 8 lines
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,
Quoted 20 lines · Aneesh V
Hi Simon,
Quoted 11 lines · Simon Schwarz
Hi Aneesh,
I am working on the OS booting right now and have a bigger change of your code in
spl.cin 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.Quoted 5 lines
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)
Quoted 5 lines
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.
Quoted 2 lines
best regards,
Aneesh
Regards
Simon
Hi Simon,
Quoted 31 lines · Simon Schwarz
Hi Aneesh,
Quoted 20 lines · Aneesh V
Hi Simon,
Quoted 11 lines · Simon Schwarz
Hi Aneesh,
I am working on the OS booting right now and have a bigger change of your code in
spl.cin 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.Quoted 5 lines
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)Quoted 5 lines
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
Quoted 6 lines
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,
Quoted 41 lines · Aneesh V
Hi Simon,
Quoted 31 lines · Simon Schwarz
Hi Aneesh,
Quoted 20 lines · Aneesh V
Hi Simon,
Quoted 11 lines · Simon Schwarz
Hi Aneesh,
I am working on the OS booting right now and have a bigger change of your code in
spl.cin 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.Quoted 5 lines
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)Quoted 5 lines
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.phpQuoted 6 lines
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.
Quoted 8 lines
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?
Quoted 8 lines
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
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Dear Aneesh V,
Quoted 6 lines · In message <[email protected]> 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.
Quoted 5 lines
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.
Quoted 2 lines
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
Signature · 5 lines
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 RitchieHi Aneesh,
sorry for answering this late...
Quoted 41 lines · Aneesh V
Hi Simon,
Quoted 31 lines · Simon Schwarz
Hi Aneesh,
Quoted 20 lines · Aneesh V
Hi Simon,
Quoted 11 lines · Simon Schwarz
Hi Aneesh,
I am working on the OS booting right now and have a bigger change of your code in
spl.cin 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.Quoted 5 lines
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)Quoted 5 lines
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
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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?
Quoted 6 lines
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