mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: vj <vicencb@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] xload: be more flexible when searching for second stage bootloader.
Date: Thu, 1 Oct 2015 08:04:47 +0200	[thread overview]
Message-ID: <20151001060447.GG7858@pengutronix.de> (raw)
In-Reply-To: <CAAMcf8Deb_J79z+YzptSjw1_=5AN5ToX7c=SOhx+HSPPXcJjkg@mail.gmail.com>

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

  reply	other threads:[~2015-10-01  6:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-27 14:08 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151001060447.GG7858@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=vicencb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox