From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support
Date: Wed, 25 Apr 2018 09:40:22 +0200 [thread overview]
Message-ID: <20180425094022.3eb559ee@jawa> (raw)
In-Reply-To: <CAO5Uq5S7i2_Rvf5+Yx9M4QmuVuDuE_a+KihY1d73BztciLduYw@mail.gmail.com>
Hi Alex,
> On Tue, Apr 24, 2018 at 11:24 AM, Alex Deymo <deymo+@google.com>
> wrote:
> > +Jocelyn.
> >
> > Thanks Alex for taking the time to port this!!
>
> It turned out to be a great opportunity to play with coccinelle on
> something trivial, which I'd been meaning to do for ages... the
> refactor to add response into the fastboot_okay/fail call chain was a
> breeze with it.
>
> > 2018-04-24 11:37 GMT+02:00 Alex Kiernan <alex.kiernan@gmail.com>:
> >>
> >>
> >> This series merges the fastboot UDP support from AOSP into mainline
> >> U-Boot.
> >>
> >> Open questions:
> >>
> >> - what's the correct way of attributing the original authors? I've
> >> added Co-authored-by, is that right? checkpatch doesn't seem to
> >> know any of the co- tags
> >> - currently there's no NAND support and I've no way of testing
> >> that, so my inclination is towards leaving it like that until
> >> someone with that particular itch to scratch can look at it
> >
> >
> > Fastboot uses partition names, like "system" and "boot" which have
> > a meaning in the Android partition scheme. For GPT, we just use the
> > partition names as the android names; but if you are booting from
> > some other storage like NAND where you don't have that then you
> > need some mapping glue ("system" --> device and partition number).
> > I've seen U-Boot modifications for several devices where they just
> > stick a table hard-coded in the U-Boot code; which works great for
> > that device but it isn't really a generic approach. Other than
> > handling the names issue, I don't see any problem with supporting
> > NAND here, but a generic way to set global names / alias would be
> > needed for this.
>
> With the fastboot NAND support in mainline it looks like we end up in
> mtdparts to deliver that mapping through environment variables.
When you mentioned about NAND partitions - I also have thought about
mtdparts. They are well supported in mainline.
> No
> actual idea what that looks like when you're driving it.
Many boards use them - so there should not be any issue with finding
examples.
>
> >>
> >> - you can select both USB and UDP fastboot, but the comments in the
> >> AOSP code suggest that needs fixing - again, I've no board I can
> >> test USB fastboot on
> >
> >
> > I thought we checked in the Kconfig that you couldn't enable both.
> > I don't remember the details now but yeah you can't wait for
> > network or USB traffic on the current code.
> >
>
> The version I picked from (o-mr1-iot-preview-8) has them as
> independent symbols, but making them a choice would resolve the issue
> for now.
>
> >> I've not tested all the code paths yet, but the obvious stuff works
> >> (basic interaction, download, boot) - every interaction elicits a
> >> `WARNING: unknown variable: slot-count` on the console; I'm
> >> guessing that my local end is sending a getvar for that, but I've
> >> not investigated.
> >
> >
> > Yes, there's a bit of different handling of partitions for A/B
> > android devices. Instead of "system" you have two partitions:
> > "system_a" and "system_b" (potentially more although 2 is the most
> > common case) so to know whether you have an old device or a newer
> > device the fastboot client checks the "slot-count" variable.
> > Undefined means of course that you have an old-style device, but if
> > you return something like "2" you would be able to flash "system"
> > on the "slot A" which is translated (again in the fastboot client)
> > to flash "system_a" partition. This is useful when using the higher
> > level operations like flashall/update and you want to specify to
> > flash only "slot A", "slot B" or even both of them. There are other
> > fastboot variables that require some plumbing, such as
> > "has-slot:<partition>" to tell whether "system" is a partition that
> > indeed has the two versions _a and _b. Typically some partitions
> > are twice (like "system" and "boot") and some other are not (like
> > "misc" or "userdata"). Anyway, this as is should work for either
> > old-style partition schemes or by force flashing "system_a" with
> > the system.img.
>
> Cool, thanks... that saves me a bunch of investigation!
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180425/f5ded8ea/attachment.sig>
next prev parent reply other threads:[~2018-04-25 7:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 9:37 [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 1/5] dfu: Refactor fastboot_okay/fail to take response Alex Kiernan
2018-04-25 7:27 ` Lukasz Majewski
2018-04-25 8:10 ` Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 2/5] dfu: Extract fastboot_okay/fail to fb_common.c Alex Kiernan
2018-04-25 7:32 ` Lukasz Majewski
2018-04-25 8:15 ` Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 3/5] net: dfu: Merge AOSP UDP fastboot Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 4/5] dfu: Resolve Kconfig dependency loops Alex Kiernan
2018-04-25 7:53 ` Lukasz Majewski
2018-04-25 8:55 ` Alex Deymo
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 5/5] net: dfu: Support building without MMC Alex Kiernan
2018-04-24 10:24 ` [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support Alex Deymo
2018-04-24 11:58 ` Alex Kiernan
2018-04-24 17:10 ` Jocelyn Bohr
2018-04-25 7:53 ` Alex Kiernan
2018-04-25 12:50 ` Alex Kiernan
2018-04-25 15:19 ` Lukasz Majewski
2018-04-26 3:27 ` Kever Yang
2018-04-27 8:04 ` Lukasz Majewski
2018-04-27 12:20 ` Alex Kiernan
2018-04-30 8:37 ` Alex Kiernan
2018-05-01 6:16 ` Jocelyn Bohr
2018-04-25 7:40 ` Lukasz Majewski [this message]
2018-04-25 7:52 ` Lukasz Majewski
2018-04-25 7:57 ` Lukasz Majewski
2018-04-25 8:43 ` Alex Kiernan
2018-04-25 8:46 ` Alex Deymo
2018-04-27 19:10 ` Sam Protsenko
2018-04-27 19:23 ` Alex Kiernan
2018-04-30 8:56 ` Alex Deymo
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=20180425094022.3eb559ee@jawa \
--to=lukma@denx.de \
--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.