* [PATCH] xload: be more flexible when searching for second stage bootloader. @ 2015-09-27 14:08 Vicente Bergas 2015-09-29 7:05 ` Sascha Hauer 0 siblings, 1 reply; 10+ messages in thread From: Vicente Bergas @ 2015-09-27 14:08 UTC (permalink / raw) To: barebox; +Cc: Vicente Bergas A first stage bootloader can read fat and ext4 filesystems, and even both can be compiled-in at the same time. But then xload has a hardcoded fat filesystem mount option which renders ext4 unusable. This patch tries to mount it as ext4 if the fat attempt fails. Then, a typical use case of an ext4 formatted filesystem is it to be a standard linux filesystem, which contains boot-related files in /boot. So, when searching for the second stage bootloader, try /boot/barebox.bin after not finding it in /barebox.bin Signed-off-by: Vicente Bergas <vicencb@gmail.com> --- arch/arm/mach-omap/xload.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c index ebcbcbc..c5e29f8 100644 --- a/arch/arm/mach-omap/xload.c +++ b/arch/arm/mach-omap/xload.c @@ -118,6 +118,8 @@ static void *omap_xload_boot_mmc(void) partname = asprintf("%s.0", diskdev); ret = mount(partname, "fat", "/", NULL); + if (ret) + ret = mount(partname, "ext4", "/", NULL); if (ret) { printf("Unable to mount %s (%d)\n", partname, ret); @@ -128,6 +130,8 @@ static void *omap_xload_boot_mmc(void) free(partname); buf = read_file("/barebox.bin", &len); + if (!buf) + buf = read_file("/boot/barebox.bin", &len); if (!buf) { printf("could not read barebox.bin from sd card\n"); return NULL; -- 2.5.3 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xload: be more flexible when searching for second stage bootloader. 2015-09-27 14:08 [PATCH] xload: be more flexible when searching for second stage bootloader Vicente Bergas @ 2015-09-29 7:05 ` Sascha Hauer 2015-09-29 19:06 ` vj 0 siblings, 1 reply; 10+ messages in thread From: Sascha Hauer @ 2015-09-29 7:05 UTC (permalink / raw) To: Vicente Bergas; +Cc: barebox On Sun, Sep 27, 2015 at 03:08:51PM +0100, Vicente Bergas wrote: > A first stage bootloader can read fat and ext4 filesystems, and > even both can be compiled-in at the same time. > But then xload has a hardcoded fat filesystem mount option which > renders ext4 unusable. > This patch tries to mount it as ext4 if the fat attempt fails. > > Then, a typical use case of an ext4 formatted filesystem > is it to be a standard linux filesystem, which contains > boot-related files in /boot. So, when searching for the second stage > bootloader, try /boot/barebox.bin after not finding it in /barebox.bin > > Signed-off-by: Vicente Bergas <vicencb@gmail.com> > --- > arch/arm/mach-omap/xload.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c > index ebcbcbc..c5e29f8 100644 > --- a/arch/arm/mach-omap/xload.c > +++ b/arch/arm/mach-omap/xload.c > @@ -118,6 +118,8 @@ static void *omap_xload_boot_mmc(void) > partname = asprintf("%s.0", diskdev); > > ret = mount(partname, "fat", "/", NULL); > + if (ret) > + ret = mount(partname, "ext4", "/", NULL); It should also be possible to pass NULL as fs type in which case we automatically detect the fs type. Could you check that? Where does the MLO come from when you don't have a FAT on your MMC/SD device? Don't we need FAT on the first partition to let the boot ROM load the MLO? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xload: be more flexible when searching for second stage bootloader. 2015-09-29 7:05 ` Sascha Hauer @ 2015-09-29 19:06 ` vj 2015-09-30 7:19 ` Sascha Hauer 0 siblings, 1 reply; 10+ messages in thread From: vj @ 2015-09-29 19:06 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox On Tue, Sep 29, 2015 at 8:05 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Sun, Sep 27, 2015 at 03:08:51PM +0100, Vicente Bergas wrote: >> A first stage bootloader can read fat and ext4 filesystems, and >> even both can be compiled-in at the same time. >> But then xload has a hardcoded fat filesystem mount option which >> renders ext4 unusable. >> This patch tries to mount it as ext4 if the fat attempt fails. >> >> Then, a typical use case of an ext4 formatted filesystem >> is it to be a standard linux filesystem, which contains >> boot-related files in /boot. So, when searching for the second stage >> bootloader, try /boot/barebox.bin after not finding it in /barebox.bin >> >> Signed-off-by: Vicente Bergas <vicencb@gmail.com> >> --- >> arch/arm/mach-omap/xload.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c >> index ebcbcbc..c5e29f8 100644 >> --- a/arch/arm/mach-omap/xload.c >> +++ b/arch/arm/mach-omap/xload.c >> @@ -118,6 +118,8 @@ static void *omap_xload_boot_mmc(void) >> partname = asprintf("%s.0", diskdev); >> >> ret = mount(partname, "fat", "/", NULL); >> + if (ret) >> + ret = mount(partname, "ext4", "/", NULL); > > It should also be possible to pass NULL as fs type in which case we > automatically detect the fs type. Could you check that? I didn't know that. This way it would be nicer and cleaner! So it has been tested but it didn't work :( mount calls detect_fs, detect_fs calls file_name_detect_type and file_name_detect_type calls open. open fails to open the "mmc0.0" file name Then I changed the name to "/dev/mmc0.0" but it failed the same way. The open return code is -2. (It's been tested on a BeagleBoneBlack) > > Where does the MLO come from when you don't have a FAT on your MMC/SD > device? Don't we need FAT on the first partition to let the boot ROM > load the MLO? There are small differences in OMAP variants, so here there is only one example that refers to the AM3359 on board of a BeagleBoneBlack: As stated in the AM335x Sitara Processors Technical Reference Manual Rev L.pdf (http://www.ti.com/lit/pdf/spruh73) Section 26.1.7.5.5 page 4940 In raw mode the booting image can be located at one of the four consecutive locations in the main area: offset 0x0 / 0x20000 (128KB) / 0x40000 (256KB) / 0x60000 (384KB). The raw mode is detected by reading sectors #0, #256, #512, #768. So, the first 128KB block can hold an MBR plus partition table, then a raw image of the MLO file can be present at offset 128KB followed by the disk partitions. In section 26.1.7.5.3 page 4939 figure 26-17 MMC/SD Booting states that raw mode detection is performed before searching for the MLO file in a filesystem. All in all, it is possible to have a "fat-free" SD-card. Regards, Vicente. > > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xload: be more flexible when searching for second stage bootloader. 2015-09-29 19:06 ` vj @ 2015-09-30 7:19 ` Sascha Hauer 2015-09-30 17:49 ` vj 0 siblings, 1 reply; 10+ messages in thread From: Sascha Hauer @ 2015-09-30 7:19 UTC (permalink / raw) To: vj; +Cc: barebox On Tue, Sep 29, 2015 at 08:06:35PM +0100, vj wrote: > On Tue, Sep 29, 2015 at 8:05 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > On Sun, Sep 27, 2015 at 03:08:51PM +0100, Vicente Bergas wrote: > >> A first stage bootloader can read fat and ext4 filesystems, and > >> even both can be compiled-in at the same time. > >> But then xload has a hardcoded fat filesystem mount option which > >> renders ext4 unusable. > >> This patch tries to mount it as ext4 if the fat attempt fails. > >> > >> Then, a typical use case of an ext4 formatted filesystem > >> is it to be a standard linux filesystem, which contains > >> boot-related files in /boot. So, when searching for the second stage > >> bootloader, try /boot/barebox.bin after not finding it in /barebox.bin > >> > >> Signed-off-by: Vicente Bergas <vicencb@gmail.com> > >> --- > >> arch/arm/mach-omap/xload.c | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c > >> index ebcbcbc..c5e29f8 100644 > >> --- a/arch/arm/mach-omap/xload.c > >> +++ b/arch/arm/mach-omap/xload.c > >> @@ -118,6 +118,8 @@ static void *omap_xload_boot_mmc(void) > >> partname = asprintf("%s.0", diskdev); > >> > >> ret = mount(partname, "fat", "/", NULL); > >> + if (ret) > >> + ret = mount(partname, "ext4", "/", NULL); > > > > It should also be possible to pass NULL as fs type in which case we > > automatically detect the fs type. Could you check that? > > I didn't know that. This way it would be nicer and cleaner! > So it has been tested but it didn't work :( > mount calls detect_fs, detect_fs calls file_name_detect_type and > file_name_detect_type calls open. > open fails to open the "mmc0.0" file name Ok, I see. This indeed can't work as it depends on devfs being mounted on /dev/. For this to work we would need a cdev_detect_filetype(const char *name) which uses the cdev_* operations to read a buffer and pass that to file_detect_type(). You're invited to implement that ;) > So, the first 128KB block can hold an MBR plus partition table, then a > raw image of the MLO file can be present at offset 128KB followed by > the disk partitions. > > In section 26.1.7.5.3 page 4939 figure 26-17 MMC/SD Booting > states that raw mode detection is performed before searching for the > MLO file in a filesystem. > > All in all, it is possible to have a "fat-free" SD-card. Now that you say it I remember having read about this before. Does this work well with the rest of barebox? In omap_env_init() we mount the first mmc partition to /boot and put the environment to /boot/barebox.env. That doesn't work when the first partition doesn't contain a FAT. Do you put your environment somewhere else? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xload: be more flexible when searching for second stage bootloader. 2015-09-30 7:19 ` Sascha Hauer @ 2015-09-30 17:49 ` vj 2015-10-01 6:04 ` Sascha Hauer 0 siblings, 1 reply; 10+ messages in thread From: vj @ 2015-09-30 17:49 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox On Wed, Sep 30, 2015 at 8:19 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Tue, Sep 29, 2015 at 08:06:35PM +0100, vj wrote: >> On Tue, Sep 29, 2015 at 8:05 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: >> > On Sun, Sep 27, 2015 at 03:08:51PM +0100, Vicente Bergas wrote: >> >> A first stage bootloader can read fat and ext4 filesystems, and >> >> even both can be compiled-in at the same time. >> >> But then xload has a hardcoded fat filesystem mount option which >> >> renders ext4 unusable. >> >> This patch tries to mount it as ext4 if the fat attempt fails. >> >> >> >> Then, a typical use case of an ext4 formatted filesystem >> >> is it to be a standard linux filesystem, which contains >> >> boot-related files in /boot. So, when searching for the second stage >> >> bootloader, try /boot/barebox.bin after not finding it in /barebox.bin >> >> >> >> Signed-off-by: Vicente Bergas <vicencb@gmail.com> >> >> --- >> >> arch/arm/mach-omap/xload.c | 4 ++++ >> >> 1 file changed, 4 insertions(+) >> >> >> >> diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c >> >> index ebcbcbc..c5e29f8 100644 >> >> --- a/arch/arm/mach-omap/xload.c >> >> +++ b/arch/arm/mach-omap/xload.c >> >> @@ -118,6 +118,8 @@ static void *omap_xload_boot_mmc(void) >> >> partname = asprintf("%s.0", diskdev); >> >> >> >> ret = mount(partname, "fat", "/", NULL); >> >> + if (ret) >> >> + ret = mount(partname, "ext4", "/", NULL); >> > >> > It should also be possible to pass NULL as fs type in which case we >> > automatically detect the fs type. Could you check that? >> >> I didn't know that. This way it would be nicer and cleaner! >> So it has been tested but it didn't work :( >> mount calls detect_fs, detect_fs calls file_name_detect_type and >> file_name_detect_type calls open. >> open fails to open the "mmc0.0" file name > > Ok, I see. This indeed can't work as it depends on devfs being mounted > on /dev/. For this to work we would need a cdev_detect_filetype(const > char *name) which uses the cdev_* operations to read a buffer and pass > that to file_detect_type(). You're invited to implement that ;) > >> So, the first 128KB block can hold an MBR plus partition table, then a >> raw image of the MLO file can be present at offset 128KB followed by >> the disk partitions. >> >> In section 26.1.7.5.3 page 4939 figure 26-17 MMC/SD Booting >> states that raw mode detection is performed before searching for the >> MLO file in a filesystem. >> >> All in all, it is possible to have a "fat-free" SD-card. > > Now that you say it I remember having read about this before. > > Does this work well with the rest of barebox? In omap_env_init() we > mount the first mmc partition to /boot and put the environment to > /boot/barebox.env. That doesn't work when the first partition doesn't > contain a FAT. Do you put your environment somewhere else? I was not using the environment save/restore feature and was unaware that it was broken. The environment retrieval could be improved in a similar way: try mounting all supported filesystems and search in "mountpoint/" and "mountpoint/boot/" But the environment save feature can't be easily supported on ext4 because the driver does not support writes. Still I think that this patch is an improvement, is not the patch itself that broke the env save/restore, it was a new use case enabled by it. > > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xload: be more flexible when searching for second stage bootloader. 2015-09-30 17:49 ` vj @ 2015-10-01 6:04 ` Sascha Hauer 2015-10-01 23:08 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Vicente Bergas 0 siblings, 1 reply; 10+ messages in thread From: Sascha Hauer @ 2015-10-01 6:04 UTC (permalink / raw) To: vj; +Cc: barebox On Wed, Sep 30, 2015 at 06:49:11PM +0100, vj wrote: > On Wed, Sep 30, 2015 at 8:19 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > On Tue, Sep 29, 2015 at 08:06:35PM +0100, vj wrote: > >> On Tue, Sep 29, 2015 at 8:05 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > >> > On Sun, Sep 27, 2015 at 03:08:51PM +0100, Vicente Bergas wrote: > >> >> A first stage bootloader can read fat and ext4 filesystems, and > >> >> even both can be compiled-in at the same time. > >> >> But then xload has a hardcoded fat filesystem mount option which > >> >> renders ext4 unusable. > >> >> This patch tries to mount it as ext4 if the fat attempt fails. > >> >> > >> >> Then, a typical use case of an ext4 formatted filesystem > >> >> is it to be a standard linux filesystem, which contains > >> >> boot-related files in /boot. So, when searching for the second stage > >> >> bootloader, try /boot/barebox.bin after not finding it in /barebox.bin > >> >> > >> >> Signed-off-by: Vicente Bergas <vicencb@gmail.com> > >> >> --- > >> >> arch/arm/mach-omap/xload.c | 4 ++++ > >> >> 1 file changed, 4 insertions(+) > >> >> > >> >> diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c > >> >> index ebcbcbc..c5e29f8 100644 > >> >> --- a/arch/arm/mach-omap/xload.c > >> >> +++ b/arch/arm/mach-omap/xload.c > >> >> @@ -118,6 +118,8 @@ static void *omap_xload_boot_mmc(void) > >> >> partname = asprintf("%s.0", diskdev); > >> >> > >> >> ret = mount(partname, "fat", "/", NULL); > >> >> + if (ret) > >> >> + ret = mount(partname, "ext4", "/", NULL); > >> > > >> > It should also be possible to pass NULL as fs type in which case we > >> > automatically detect the fs type. Could you check that? > >> > >> I didn't know that. This way it would be nicer and cleaner! > >> So it has been tested but it didn't work :( > >> mount calls detect_fs, detect_fs calls file_name_detect_type and > >> file_name_detect_type calls open. > >> open fails to open the "mmc0.0" file name > > > > Ok, I see. This indeed can't work as it depends on devfs being mounted > > on /dev/. For this to work we would need a cdev_detect_filetype(const > > char *name) which uses the cdev_* operations to read a buffer and pass > > that to file_detect_type(). You're invited to implement that ;) > > > >> So, the first 128KB block can hold an MBR plus partition table, then a > >> raw image of the MLO file can be present at offset 128KB followed by > >> the disk partitions. > >> > >> In section 26.1.7.5.3 page 4939 figure 26-17 MMC/SD Booting > >> states that raw mode detection is performed before searching for the > >> MLO file in a filesystem. > >> > >> All in all, it is possible to have a "fat-free" SD-card. > > > > Now that you say it I remember having read about this before. > > > > Does this work well with the rest of barebox? In omap_env_init() we > > mount the first mmc partition to /boot and put the environment to > > /boot/barebox.env. That doesn't work when the first partition doesn't > > contain a FAT. Do you put your environment somewhere else? > > I was not using the environment save/restore feature and was unaware > that it was broken. > The environment retrieval could be improved in a similar way: try > mounting all supported filesystems and search in "mountpoint/" and > "mountpoint/boot/" > But the environment save feature can't be easily supported on ext4 > because the driver does not support writes. > Still I think that this patch is an improvement, is not the patch > itself that broke the env save/restore, it was a new use case enabled > by it. Indeed. Could you create that cdev_detect_filetype() we talked about, then this patch is good to go. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 0/2] second version for "be more flexible when searching for second stage" 2015-10-01 6:04 ` Sascha Hauer @ 2015-10-01 23:08 ` Vicente Bergas 2015-10-01 23:08 ` [PATCH 1/2] detect_fs: use device instead of file Vicente Bergas ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Vicente Bergas @ 2015-10-01 23:08 UTC (permalink / raw) To: barebox, s.hauer; +Cc: Vicente Bergas Hello, as suggested I've improved the filesystem-type detection, but, as am not familiar with barebox internals was fumbling a bit and the resulting cdev_detect_type is a version of file_name_detect_type. During testing it autodetected MBR+FAT and MBR+EXT4 correctly. Regards, Vicente. Vicente Bergas (2): detect_fs: use device instead of file xload: be more flexible when searching for second stage bootloader. arch/arm/mach-omap/xload.c | 4 +++- common/filetype.c | 37 +++++++++++++++++++++++++++++++++++++++ fs/fs.c | 2 +- include/filetype.h | 1 + 4 files changed, 44 insertions(+), 2 deletions(-) -- 2.6.0 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/2] detect_fs: use device instead of file 2015-10-01 23:08 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Vicente Bergas @ 2015-10-01 23:08 ` Vicente Bergas 2015-10-01 23:08 ` [PATCH 2/2] xload: be more flexible when searching for second stage bootloader Vicente Bergas 2015-10-02 7:11 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Sascha Hauer 2 siblings, 0 replies; 10+ messages in thread From: Vicente Bergas @ 2015-10-01 23:08 UTC (permalink / raw) To: barebox, s.hauer; +Cc: Vicente Bergas detect_fs would usually mount a device on a directory, so, use a device-specific type detection. Signed-off-by: Vicente Bergas <vicencb@gmail.com> --- common/filetype.c | 37 +++++++++++++++++++++++++++++++++++++++ fs/fs.c | 2 +- include/filetype.h | 1 + 3 files changed, 41 insertions(+), 1 deletion(-) diff --git a/common/filetype.c b/common/filetype.c index 28a4b2c..6240fd1 100644 --- a/common/filetype.c +++ b/common/filetype.c @@ -361,3 +361,40 @@ err_out: return type; } + +enum filetype cdev_detect_type(const char *name) +{ + enum filetype type = filetype_unknown; + int ret; + struct cdev *cdev; + void *buf; + + cdev = cdev_by_name(name); + if (!cdev) + return type; + buf = xzalloc(FILE_TYPE_SAFE_BUFSIZE); + ret = cdev_read(cdev, buf, FILE_TYPE_SAFE_BUFSIZE, 0, 0); + if (ret < 0) + goto err_out; + + type = file_detect_type(buf, ret); + + if (type == filetype_mbr) { + unsigned long bootsec; + /* + * Get the first partition start sector + * and check for FAT in it + */ + is_fat_or_mbr(buf, &bootsec); + + ret = cdev_read(cdev, buf, 512, bootsec * 512, 0); + if (ret < 0) + goto err_out; + + type = is_fat_or_mbr((u8 *)buf, NULL); + } + +err_out: + free(buf); + return type; +} diff --git a/fs/fs.c b/fs/fs.c index 67c78cd..c041e41 100644 --- a/fs/fs.c +++ b/fs/fs.c @@ -1201,7 +1201,7 @@ EXPORT_SYMBOL(register_fs_driver); static const char *detect_fs(const char *filename) { - enum filetype type = file_name_detect_type(filename); + enum filetype type = cdev_detect_type(filename); struct driver_d *drv; struct fs_driver_d *fdrv; diff --git a/include/filetype.h b/include/filetype.h index e452b7a..cde543e 100644 --- a/include/filetype.h +++ b/include/filetype.h @@ -45,6 +45,7 @@ const char *file_type_to_short_string(enum filetype f); enum filetype file_detect_partition_table(const void *_buf, size_t bufsize); enum filetype file_detect_type(const void *_buf, size_t bufsize); enum filetype file_name_detect_type(const char *filename); +enum filetype cdev_detect_type(const char *name); enum filetype is_fat_or_mbr(const unsigned char *sector, unsigned long *bootsec); int is_fat_boot_sector(const void *_buf); -- 2.6.0 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/2] xload: be more flexible when searching for second stage bootloader. 2015-10-01 23:08 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Vicente Bergas 2015-10-01 23:08 ` [PATCH 1/2] detect_fs: use device instead of file Vicente Bergas @ 2015-10-01 23:08 ` Vicente Bergas 2015-10-02 7:11 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Sascha Hauer 2 siblings, 0 replies; 10+ messages in thread From: Vicente Bergas @ 2015-10-01 23:08 UTC (permalink / raw) To: barebox, s.hauer; +Cc: Vicente Bergas A first stage bootloader can read fat and ext4 filesystems, and even both can be compiled-in at the same time. But then xload has a hardcoded fat filesystem mount option which renders ext4 unusable. This patch tries to mount it as ext4 if the fat attempt fails. Then, a typical use case of an ext4 formatted filesystem is it to be a standard linux filesystem, which contains boot-related files in /boot. So, when searching for the second stage bootloader, try /boot/barebox.bin after not finding it in /barebox.bin Signed-off-by: Vicente Bergas <vicencb@gmail.com> --- arch/arm/mach-omap/xload.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c index ebcbcbc..8805930 100644 --- a/arch/arm/mach-omap/xload.c +++ b/arch/arm/mach-omap/xload.c @@ -117,7 +117,7 @@ static void *omap_xload_boot_mmc(void) partname = asprintf("%s.0", diskdev); - ret = mount(partname, "fat", "/", NULL); + ret = mount(partname, NULL, "/", NULL); if (ret) { printf("Unable to mount %s (%d)\n", partname, ret); @@ -128,6 +128,8 @@ static void *omap_xload_boot_mmc(void) free(partname); buf = read_file("/barebox.bin", &len); + if (!buf) + buf = read_file("/boot/barebox.bin", &len); if (!buf) { printf("could not read barebox.bin from sd card\n"); return NULL; -- 2.6.0 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/2] second version for "be more flexible when searching for second stage" 2015-10-01 23:08 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Vicente Bergas 2015-10-01 23:08 ` [PATCH 1/2] detect_fs: use device instead of file Vicente Bergas 2015-10-01 23:08 ` [PATCH 2/2] xload: be more flexible when searching for second stage bootloader Vicente Bergas @ 2015-10-02 7:11 ` Sascha Hauer 2 siblings, 0 replies; 10+ messages in thread From: Sascha Hauer @ 2015-10-02 7:11 UTC (permalink / raw) To: Vicente Bergas; +Cc: barebox On Fri, Oct 02, 2015 at 12:08:37AM +0100, Vicente Bergas wrote: > Hello, > as suggested I've improved the filesystem-type detection, but, as am not > familiar with barebox internals was fumbling a bit and the resulting > cdev_detect_type is a version of file_name_detect_type. > > During testing it autodetected MBR+FAT and MBR+EXT4 correctly. Applied, thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-10-02 7:11 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-09-27 14:08 [PATCH] xload: be more flexible when searching for second stage bootloader Vicente Bergas 2015-09-29 7:05 ` Sascha Hauer 2015-09-29 19:06 ` vj 2015-09-30 7:19 ` Sascha Hauer 2015-09-30 17:49 ` vj 2015-10-01 6:04 ` Sascha Hauer 2015-10-01 23:08 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Vicente Bergas 2015-10-01 23:08 ` [PATCH 1/2] detect_fs: use device instead of file Vicente Bergas 2015-10-01 23:08 ` [PATCH 2/2] xload: be more flexible when searching for second stage bootloader Vicente Bergas 2015-10-02 7:11 ` [PATCH 0/2] second version for "be more flexible when searching for second stage" Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox