linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Tanya Brokhman <tlinder@codeaurora.org>, ricard.wanderlof@axis.com
Cc: linux-mtd@lists.infradead.org, Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 2/2] ubi-utils: ubinize: Add fastmap suport to image creation
Date: Wed, 18 Mar 2015 13:19:57 +0100	[thread overview]
Message-ID: <55096D6D.5000707@nod.at> (raw)
In-Reply-To: <55096BA6.1030708@codeaurora.org>

Am 18.03.2015 um 13:12 schrieb Tanya Brokhman:
>> We should still add a big and fat warning.
> 
> In ubinize? yes, you're probably right. Will do. But if it's ok with you, I'll wait to get some inputs on the code before uploading another version.

In ubinize. Yes, there no need to hurry. :-)

>>
>>>> Maybe it would make sense to but the whole fastmap creation logic into the flasher.
>>>
>>> But then you will delay the flashing process and this time is valuable. We're always looking for ways to decrease flashing of the images and the first boot duration.
>>
>> But if your flasher will invalidate fastmap if it faces a bad block a certain amount of board will still boot slowly. Can you deal with that?
>> As I said NAND is allowed to be shipped with bad blocks.
> 
> If my flasher finds bad blocks and invalidates fastmap - then the boot time will be as it was before, without this enhancement. The flashing time will be delayed by T_erase +
> T_write_header for one PEB -> can be neglected. If We implement the whole fastmap generation in flasher then the  flashing time will increase significantly.

I'm sure I miss something, how log does the fastmap creation take?
If you update the image in memory it should be extremely fast.
I.e. scan the NAND for bad blocks, amend the image and flash it.

>>
>>> Also, if you move this logic inside the flasher, perhaps we can skip ubinize at all since it feels like the logic will be just duplicated.
>>
>> It is not uncommon to skip ubinize.
>>
>>>> We could create a libfastmap (LGPLv2) such that everyone is allowed to use it in his custom
>>>> flasher.
>>>
>>> Perhaps. It wont work for us though, so unfortunately I wont be able to help out with that if this is the solution you prefer.
>>
>> Why would this not work for your? Don't you have the sources of your flasher?
>> Of course we'd have to write libfastmap in a way such that one can use it on non-Linux systems like a bootloader.
> 
> I do have the source (just updated it). I meant that implementing libfastmap and integrating it into our flasher will be too much work and it's just not justified in our case, so I
> wont be able to do it. Sorry....

Okay.

Thanks,
//richard

  reply	other threads:[~2015-03-18 12:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18  8:52 [PATCH 2/2] ubi-utils: ubinize: Add fastmap suport to image creation Tanya Brokhman
2015-03-18 10:22 ` Richard Weinberger
2015-03-18 10:43   ` Tanya Brokhman
2015-03-18 11:15     ` Richard Weinberger
2015-03-18 12:12       ` Tanya Brokhman
2015-03-18 12:19         ` Richard Weinberger [this message]
2015-03-18 12:41           ` Tanya Brokhman
2015-03-18 16:33             ` Richard Weinberger

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=55096D6D.5000707@nod.at \
    --to=richard@nod.at \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.com \
    --cc=tlinder@codeaurora.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;
as well as URLs for NNTP newsgroup(s).