All of lore.kernel.org
 help / color / mirror / Atom feed
From: Angus Ainslie <angus@akkea.ca>
To: Oleh Kravchenko <oleg@kaa.org.ua>
Cc: Sean Anderson <sean.anderson@seco.com>,
	u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
	Patrick Delaunay <patrick.delaunay@foss.st.com>,
	Roman Stratiienko <r.stratiienko@gmail.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	kernel@puri.sm
Subject: Re: [PATCH v2 1/1] fastboot: fb_getvar: Add getvar_logical_blocksize for NXP mfgtool
Date: Wed, 29 Dec 2021 07:15:43 -0800	[thread overview]
Message-ID: <22255e4f9fd562b8a41b8a486a6454af@akkea.ca> (raw)
In-Reply-To: <25cb5e9a-d023-ecff-a2f9-2bba1264cc1e@kaa.org.ua>

Hi Oleh,

On 2021-12-29 07:07, Oleh Kravchenko wrote:
> Hello Angus,
> 
> 29.12.21 15:35, Angus Ainslie пише:
>> The version of uuu that we are using requires the block-size for the 
>> sparse upload
>> 
>> https://source.puri.sm/Librem5/mfgtools/-/blob/pureos/amber/libuuu/fastboot.cpp#L501
> 
> This version is outdated (2 years old).
> Maybe it is time to upgrade to the latest one?
> 

That was one of my suggested solutions but it would still leave older 
uuu implementations out there that won't work with mainline u-boot.

>> It looks like the upstream version will default to 4096 if the 
>> block-size is not provided
>> 
>> https://github.com/NXPmicro/mfgtools/blob/5397913ad97db422c1d70f314dedff4cb7d976b9/libuuu/fastboot.cpp#L642
>> 
>> Instead of making assumptions about the block size wouldn't it be 
>> better to provide one if requested ?
> 
> +1 if it works faster ^_^
> 

I haven't done any speed tests so I can't really comment about the 
speed.

>> We could also remove that being a required parameter from the uuu that 
>> we are using but that still leaves versions out there that won't work 
>> with a mainline u-boot.
> 
> Why does mainline use fixed block size 4096?
> 

That's a fall back if the fastboot implementation doesn't provide a 
block-size , probably so that it can work with mainline u-boot.

> 
> Excuse me for direct questions I'm just curious.

NP that's what review is for.

Angus

  reply	other threads:[~2021-12-29 15:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-19 16:15 [PATCH v2 0/1] Add more support for NXP's mfgtool Angus Ainslie
2021-12-19 16:15 ` [PATCH v2 1/1] fastboot: fb_getvar: Add getvar_logical_blocksize for NXP mfgtool Angus Ainslie
2021-12-28 16:59   ` Sean Anderson
2021-12-29 13:35     ` Angus Ainslie
2021-12-29 15:07       ` Oleh Kravchenko
2021-12-29 15:15         ` Angus Ainslie [this message]
2021-12-30 16:21       ` Sean Anderson
2022-01-03 13:27         ` Angus Ainslie
2022-01-04 16:22           ` Sean Anderson

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=22255e4f9fd562b8a41b8a486a6454af@akkea.ca \
    --to=angus@akkea.ca \
    --cc=kernel@puri.sm \
    --cc=m.szyprowski@samsung.com \
    --cc=oleg@kaa.org.ua \
    --cc=patrick.delaunay@foss.st.com \
    --cc=r.stratiienko@gmail.com \
    --cc=sean.anderson@seco.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.