mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Juergen Beisert <jbe@pengutronix.de>
To: barebox@lists.infradead.org
Subject: Re: [RFC] Dedicated command to make a target bootable with Barebox
Date: Mon, 3 Sep 2012 13:37:54 +0200	[thread overview]
Message-ID: <201209031337.54462.jbe@pengutronix.de> (raw)
In-Reply-To: <20120903105534.GA19931@game.jcrosoft.org>

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:32 Mon 03 Sep     , Juergen Beisert wrote:
> > currently I'm working on the difficult process to make an i.MX35 SoC boot
> > from an externally connected NAND device.
> >
> > Nothing special with it, only the NAND flash controller in the i.MX35
> > (also in i.MX25, i.MX27 and i.MX31) is braindamaged broken. This
> > controller loses the factory bad block markers when used without a
> > workaround and losing these markers is a _really_ bad idea.
> >
> > But to use the workaround on these SoCs it needs a complicated
> > preparation of the NAND. Doing it manually is very error prone. And this
> > kind of preparation has to be kept when the system should be updated and
> > so on. Not easy to explain and so much more chances for the user to brick
> > the system while the update process.
> >
> > This makes me think about a dedicated command which is responsible to
> > make the target bootable and does all the (more or less complicated)
> > steps to ensure the next time it gets powered it's able to boot again.
> >
> > There are more architectures which needs a complicated setup to be able
> > to boot it from some kind of externally connected devices like NAND or
> > eMMCs for example. Some needs special NAND checksums only for the
> > bootloader, others needs to keep the partition table even if the
> > bootloader gets updated and so on.
> >
> > Would it be possible to share one command (or one group of commands) by
> > all architectures? And each architecture adds its special code to the
> > command?
> >
> > What kind of setup procedures we must cover with such a command?
> >
> > My examples:
> >
> > - for the Freescale i.MX SoCs with the broken NFC we must write the
> > bootloader in a different way than all the remaining data into the NAND
> > device - for the Samsung S36410 we must save the factory bad block
> > markers first to support booting from NAND as its internal ROM expects
> > the checksums at a strange offset in the OOB area
>
> On some ST SoC it's the same I think we do not need any command we just
> need to specify it as mtd level for a specific mtd part

I think we need something with an overview about the scene. Doing it at the 
mtd level needs some tweaks in the driver and in addition these tweaks have 
to be very special from platform to platform.

A command on top of everything would have more information, like the processor 
type, the real boot device and its physical layout and all of the 
constraints. With this command we could provide a generic solution at the 
driver's layer (for example switching some behaviour via an IOCTL).

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      parent reply	other threads:[~2012-09-03 11:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 10:32 Juergen Beisert
2012-09-03 10:55 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-03 11:30   ` Sascha Hauer
2012-09-03 11:52     ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-03 11:37   ` Juergen Beisert [this message]

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=201209031337.54462.jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /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