From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 0/3] sunxi: support FEL-provided environment vars and "fel" boot target
Date: Mon, 14 Sep 2015 16:12:25 +0200 [thread overview]
Message-ID: <55F6D5C9.3070505@redhat.com> (raw)
In-Reply-To: <1442236530-24382-1-git-send-email-bernhard.nortmann@web.de>
Hi,
On 14-09-15 15:15, Bernhard Nortmann wrote:
> This patch series builds upon
> http://lists.denx.de/pipermail/u-boot/2015-September/226515.html
> http://lists.denx.de/pipermail/u-boot/2015-September/226688.html
>
> v2 combines the previous submissions, and adds some suggested
> fixes/changes.
>
> The sunxi-tool side of things is discussed here:
> https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg13071.html
>
> * Hans de Goede already pointed out that it might be preferable to
> make use of the spl_boot_device() function even from the main
> (non-SPL) U-Boot binary (e.g. for the "NAND" case). Currently this
> function is only available with CONFIG_SPL_BUILD set, and
> implemented in arch/arm/cpu/armv7/sunxi/board.c
> Would it be safe to enable it for non-SPL builds and use something
> like "(spl_boot_device == BOOT_DEVICE_BOARD)" for misc_init_r()?
>
> * Side note: the sunxi spl_boot_device() will probably require
> some future refinement anyway, to account for the 'oddball' A80.
> That SoC requires the SPL at a different address (0x10000 instead
> of 0x0).
>
> * The test for FEL boot mode ("eGON.BT0") in spl_boot_device()
> explicitly uses the "io" function readl() to access the signature.
> Is there a specific reason for this? Marex pointed out (on IRC)
> that the SRAM might as well be read directly. For now, I have
> followed the existing code, and used readl() and readb() to work
> with the SPL header information.
>
> * The check_signature() function somewhat duplicates very similar
> code from arch/arm/include/asm/io.h. That particular piece of code
> depends on the presence of a "__mem_pci" symbol. However, it seems
> 'generic' enough - so it may be worth to factor out and reuse it?
>
> Regards, B. Nortmann
>
> Changes in v2:
> - Rename field to fel_script_address, discard fel_data_size
> - Clearing header fields is no longer needed, as mksunxiboot.c zeroes entire image first
> - renamed fel_data_addr to fel_script_addr, discarded fel_data_size
> - make sure that FEL-related environment vars are always cleared first
> - support minimum and maximum SPL (header) version, more verbose error messages
> - renamed fel_data_addr to fel_scriptaddr
> - combined both tests into one as suggested by Hans de Goede
>
> Bernhard Nortmann (3):
> sunxi: (mksunxiboot) signature to indicate "sunxi" SPL variant
> sunxi: retrieve FEL-provided values to environment variables
> sunxi: add "fel" boot target
Thanks, series looks good to me. Siarhei, can I have your Acked-by
for this series (indicating that you are ok with them from having
matching changes in sunxi-tools pov) ? Once I've your acked by
I'll queue this up for merging.
Should we target this for v2015.10, or for the next cycle ?
The changes look quite safe to me, so I'm ok with putting this
on v2015.10, but I wonder what others think.
Regards,
Hans
next prev parent reply other threads:[~2015-09-14 14:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 13:15 [U-Boot] [PATCH v2 0/3] sunxi: support FEL-provided environment vars and "fel" boot target Bernhard Nortmann
2015-09-14 13:15 ` [U-Boot] [PATCH v2 1/3] sunxi: (mksunxiboot) signature to indicate "sunxi" SPL variant Bernhard Nortmann
2015-09-16 1:03 ` Siarhei Siamashka
2015-09-14 13:15 ` [U-Boot] [PATCH v2 2/3] sunxi: retrieve FEL-provided values to environment variables Bernhard Nortmann
2015-09-16 1:00 ` Siarhei Siamashka
2015-09-17 14:05 ` Bernhard Nortmann
2015-09-14 13:15 ` [U-Boot] [PATCH v2 3/3] sunxi: add "fel" boot target Bernhard Nortmann
2015-09-16 1:04 ` Siarhei Siamashka
2015-09-14 14:12 ` Hans de Goede [this message]
2015-09-16 1:34 ` [U-Boot] [PATCH v2 0/3] sunxi: support FEL-provided environment vars and " Siarhei Siamashka
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=55F6D5C9.3070505@redhat.com \
--to=hdegoede@redhat.com \
--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.