mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Juergen Beisert <jbe@pengutronix.de>
To: barebox@lists.infradead.org
Subject: [RFC] Dedicated command to make a target bootable with Barebox
Date: Mon, 3 Sep 2012 12:32:56 +0200	[thread overview]
Message-ID: <201209031232.56813.jbe@pengutronix.de> (raw)

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

             reply	other threads:[~2012-09-03 10:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 10:32 Juergen Beisert [this message]
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

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=201209031232.56813.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