mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <>
To: Trent Piepho <>
Cc: Barebox List <>, Yunus Bas <>
Subject: Re: [PATCH 3/3] imx-bbu-nand-fcb: Add command to help debug FCB issues
Date: Thu, 14 Oct 2021 14:09:34 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Oct 13, 2021 at 03:14:01AM -0700, Trent Piepho wrote:
> On Tue, Oct 12, 2021 at 1:21 AM Sascha Hauer <> wrote:
> > On Mon, Oct 11, 2021 at 06:53:59PM -0700, Trent Piepho wrote:
> > > Add new "fcb" command.  It can save a decoded copy of the FCB to a file,
> > > do a hexdump of the decoded FCB, or display the FCB fields.  Or simply
> > > read and validate the FCB.
> > Not sure if we need to control this command in such a fine grained way.
> > For me just extracting all possible FCBs including the firmware images,
> > maybe printing consistency information would be enough. That's just a
> > personal opinion though, feel free to override it.
> Originally I was having issues creating correct FCBs, mostly due to
> kobs-ng (I wonder how hard it would be to port barebox_update to
> Linux?) and wanted to extract factory FCB and kobs-ng generated FCB.
> But copying data from Barebox to Linux and looking at hexdumps was
> very tedious.  Really, one wants to see fields of FCB decoded and
> Barebox already had code that did this.
> So the -i flag that prints out FCB fields and -o to save a copy were
> what I wrote originally as debug aid, with -i the most useful to me.
> I don't actually want to extract firmware images.  It was the FCB that
> was the issue.  I didn't think it would be useful enough to other
> people to bother sending it to the list.
> But then later there was a thread from Yunas at Phytec about the
> difficulty of doing a flash crc check on NAND when one does not know
> where data will be due to possible bad blocks.  Extracting this
> information from the FCB seemed like the correct way to do it and I
> realized it would be easy to add into the command I had written.  So
> that is why this feature is there.  And this was evidence that this
> would be useful to someone besides myself.
> I added hexdump because it seemed like someone might like it and it
> was one line.  I could drop this part.
> Extracting all possible FCBs has issues.  Number and location of FCBs
> varies.  Pin strapping and possibly OTP memory fuses control what the
> boot ROM does.  However, the boot ROM's search, what is actually in
> flash, and what kobs-ng wants to write, can all be different.  I did
> write this debug aid for a real problem!
> If it did just write dump everything, then how would it work?  Some
> details are not clear to me.
> Where does the data go?  Assume /tmp?  Or argument to supply directory name?
> It will need multiple files.  How to name?  Arguments for each
> filename?  Seems too many arguments.  Or have a fixed filename
> pattern?  FCB1, FCB2, firmware1.img, firmware2.img, etc.  Not really a
> huge fan of hardcoded filenames.

Either way would be fine with me. I would use the current directory for
writing files with hardcoded filenames.

> What happens if the FCBs are not where Barebox thinks they are?  This
> really does happen.
> What if all the FCBs do not agree on the location/size of the firmware images?

I would write out all found FCBs by default. Additionally an option to
pass the block number of which FCB should be used like you already did

Generally I think when by default all possible information is extracted
including the FCB/Firmware images, maybe sha256sums of the firmware
imags. That way we could easily add more information if we get new
ideas which infos might be useful additionally. With dedicated options
for each and every piece of information it will become difficult to
parse and hard to track which option is compatible/useful with which
other option. In the end this mostly useful for debugging anyway. I
don't think we should extend this command to do anything useful in a
production case.


Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       |  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

barebox mailing list

      reply	other threads:[~2021-10-14 12:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12  1:53 [PATCH 1/3] imx-bbu-nand-fcb: Show additional information from decoded FCB Trent Piepho
2021-10-12  1:53 ` [PATCH 2/3] imx-bbu-nand-fcb: Save bootloader location into device parameters Trent Piepho
2021-10-12  8:11   ` Sascha Hauer
2021-10-12  1:53 ` [PATCH 3/3] imx-bbu-nand-fcb: Add command to help debug FCB issues Trent Piepho
2021-10-12  8:21   ` Sascha Hauer
2021-10-13 10:14     ` Trent Piepho
2021-10-14 12:09       ` Sascha Hauer [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:

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

  git send-email \ \ \ \ \ \

* 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