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

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

[Juergen Beisert]

Hi all,

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

Other constraints on different architectures that comes into your minds?

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

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:32 Mon 03 Sep     , Juergen Beisert wrote:
> Hi all,
> 
> 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

Best Regards,
J.

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

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

[Sascha Hauer]

On Mon, Sep 03, 2012 at 12:55:34PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:32 Mon 03 Sep     , Juergen Beisert wrote:
> > Hi all,
> > 
> > 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

A command has the advantage that for example we could also check for
valid images before flashing them (does it have a correct barebox
header?). This could be checked before actually erasing a sector.
Also, flashing boot images is not limited to mtd devices, it could also
be mmc, or for OMAP, not a device at all but a file inside a FAT on SD
card.

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

Re: [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/  |

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

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:30 Mon 03 Sep     , Sascha Hauer wrote:
> On Mon, Sep 03, 2012 at 12:55:34PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:32 Mon 03 Sep     , Juergen Beisert wrote:
> > > Hi all,
> > > 
> > > 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
> 
> A command has the advantage that for example we could also check for
> valid images before flashing them (does it have a correct barebox
> header?). This could be checked before actually erasing a sector.
> Also, flashing boot images is not limited to mtd devices, it could also
> be mmc, or for OMAP, not a device at all but a file inside a FAT on SD
> card.
for this part I agree but for the oob we must handle it at mtd level otherwise
the mtdcore will taint on bad ecc as example

Best Regards,
J.

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