[RFC] Dedicated command to make a target bootable with Barebox

[Juergen Beisert]

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/  |