Re: [PATCH v5 08/11] doc: devicetree: Updates for devicetree-rebasing subtree

[Ian Campbell]

On Wed, 2024-02-14 at 19:02 +0530, Sumit Garg wrote:
> 
> > 
> > Also, is devicetree-rebasing a "forked copy"? A fork would imply some
> > difference from upstream. I would guess this is more like a mirror.
> 
> AFAIK, it's a mirror from upstream with a different directory
> (Makefile) structure. Ian may clarify further as to how this mirror is
> kept updated.

It's not really a mirror nor a fork, I guess it is something in
between.

It's a rewritten tree which extracts the DTS bits only from the kernel
source into a standalone source repo. It's produced using "git filter-
branch", all the scripting to do so is at:

https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/scripts

The conversion state is part of
https://github.com/ijc/devicetree-conversion-state-v3/, that repo
contains all of upstream Linux commits too, since the branches there
track the most recently converted inputs to support incremental
updates.

There's also the filter-map branch which maintains the state needed to
not have to redo the conversion every time (which from scratch took
days last time...)

Ian

Re: [U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration

[Ian Campbell]

(massively trimmed cc list, leaving the current sunxi custodians and
Hans who is a fellow emeritus custodian)

On Mon, 2018-11-19 at 14:58 -0700, Simon Glass wrote:
> Thank you very much to the many maintainers who have met the deadline
> and converted their boards. Apologies to those who converted, and
> still got this email.

TBH I'm still unsure why I was copied. I stepped down as sunxi
custodian ages ago. I checked in u-boot.git and I am listed in
board/sunxi/MAINTAINERS for Cubieboard and Mele M5, but neither of
those (nor any sunxi board generally) seems to be the subject of this
series. My address doesn't appear anywhere else in the repo.

Do I (or the sunxi folks) need to be doing anything?

Or has ./scripts/get_maintainer.pl just been overzealous somewhere?

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] MAINTAINERS: SUNXI: Update maintainership

[Ian Campbell]

On Mon, 2016-11-21 at 22:50 +0530, Jagan Teki wrote:
> Add Jagan and Maxime as Maintainers for SUNXI
> 
> Cc: Maxime Ripard 
> Signed-off-by: Jagan Teki 
> ---
>  MAINTAINERS | 3 ++-

You most likely want to update doc/git-mailrc too.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MAINTAINERS: mark sunxi status as Orphan

[Ian Campbell]

On Mon, 2016-11-14 at 12:53 +0100, Hans de Goede wrote:
> Ian has not had any time for sunxi for some time now and I'm
> in the same situation now, so I'm stepping down as sunxi
> custodian and marking the sunxi support as Orphan.
> 
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Ian Campbell <i...@hellion.org.uk>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

:-(

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Mele_M5_defconfig: Drop non existing STATUSLED setting

[Ian Campbell]

On Sun, 2016-11-13 at 19:54 +0100, Hans de Goede wrote:
> And also remove it from scripts/config_whitelist.txt as the
> Mele_M5_defconfig was the only one defining it.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: musb: Re-init musb controller on repeated probe calls

[Ian Campbell]

On Sun, 2016-09-18 at 16:53 +0200, Hans de Goede wrote:
> With sunxi-musb musb_lowlevel_init() can fail when a charger; or no
> cable
> is plugged into the otg port.
> 
> To avoid leaking the struct musb allocated by musb_init_controller()
> on repeated musb_usb_probe() calls, we were caching its result.
> But musb_init_controller() does more, such as calling
> sunxi_musb_init()
> which enables the clocks.
> 
> Not calling sunxi_musb_init() causes the musb controller to stop
> working
> after a "usb reset" since that calls musb_usb_remove() which disables
> the
> clocks.
> 
> This commit fixes this by removing the caching of the struct returned
> from musb_init_controller(), it replaces this by free-ing the
> allocated
> memory in musb_usb_remove() and calling musb_usb_remove() on
> musb_usb_probe() errors to ensure proper cleanup.
> 
> While at it also make musb_usb_probe() and musb_usb_remove() static.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

LGTM in so far as it seems like a more normal way to do things, but
maybe an Ack from a USB-in-uboot-savvy person might be nice?

Anyway: Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: axp2xx: disable ldoio0/1 at boot

[Ian Campbell]

On Mon, 2016-09-12 at 15:24 +0200, Hans de Goede wrote:
> When cold-booting the ldoio0/1 regulators are always off / the
> gpios are always at tristate. But when re-booting from android these
> are sometimes on. Disable them at axp_init time (iow as early as
> possible)
> to remove this difference between a cold boot and a reboot.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: axp2xx: disable ldoio0/1 at boot

[Ian Campbell]

On Mon, 2016-09-12 at 09:55 +0200, Hans de Goede wrote:
> @@ -223,7 +223,14 @@ int axp_init(void)
> >     if (!(axp_chip_id == 0x6 || axp_chip_id == 0x7 || axp_chip_id == 0x17))
> >     return -ENODEV;
>  
> > -   return 0;
> > +   /*
> > +    * Turn off LDOIO regulators / tri-state GPIO pins, when rebooting
> > +    * from android these are sometimes on.
> > +    */
> > +   ret |= pmic_bus_write(AXP_GPIO0_CTRL, AXP_GPIO_CTRL_INPUT);
> > +   ret |= pmic_bus_write(AXP_GPIO1_CTRL, AXP_GPIO_CTRL_INPUT);

If ret values are errno's (as the context suggests by containing
-ENODEV) then or-ing them together could result in corruption from
combining two distinct errno values.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: musb: Power off OTG port VBUS when disabled

[Ian Campbell]

On Wed, 2016-09-07 at 14:25 +0800, Chen-Yu Tsai wrote:
> The Linux kernel musb driver expects...

I don't much like this line of reasoning/explanation for changes to u-
boot. I appreciate that it might seem like all the world is Linux
(especially in sunxi context) but the right way to descibe these
changes IMHO is "A sensible behaviour for firmware is to ... because
..." i.e. to consider the general case.

Otherwise I might be tempted to say things like...

>  VBUS to be off while initializing
> musb. Having it on results in a repeating string of warnings, followed
> > by an unusable peripheral.

... this sounds like it might be a Linux bug, perhaps it should be
fixed there?

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sunxi: Sync h3-orangepi dts files with kernel

[Ian Campbell]

On Sat, 2016-09-03 at 13:12 +0200, Hans de Goede wrote:
> This adds an emac node to the orangepi-2 dts (not yet merged
> upstream,
> but in u-boot we already have emac support); fixes the alphetically
> sorting of nodes in sun8i-h3-orangepi-plus.dts and disables some
> usb controllers in sun8i-h3-orangepi-plus.dts which are only used
> on the plus2e, as upstream has decided to do a separate dts files
> for the plus2e.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

After these three patches does the state of the dts files now match the
state of the files upstream, modulo things which are still in flight to
upstream (so maybe I should ask "...match the intended/eventual
state...")? If so then:

Acked-by: Ian Campbell <i...@hellion.org.uk>


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: display: Use PWM to drive backlight where applicable

[Ian Campbell]

On Fri, 2016-08-26 at 16:21 +0200, Hans de Goede wrote:
> 
> > 
> > Reviewed by: Peter Korsgaard <pe...@korsgaard.com>
> 
> Thank you.

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sun5i: Add defconfig and dts file for the Empire Electronix M712 tablet

[Ian Campbell]

On Fri, 2016-08-26 at 16:11 +0200, Hans de Goede wrote:
> Add a defconfig and dts file for the Empire Electronix M712 tablet,
> this
> is a 7" A13 tablet, with micro-usb (otg), headphone and micro-sd
> slots on
> the outside. It uses a Goodix gt811 touchscreen controller, a
> RTL8188CTV
> wifi chip and a DMART06 (1238a4) accelerometer.
> 
> The dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

(sorry for the delay, I was on vacation and this got mixed in with all
the other random u-boot stuff I get cc-d on so I missed it)

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Sync dts files with upstream kernel

[Ian Campbell]

On Fri, 2016-08-19 at 08:52 +0200, Hans de Goede wrote:
> Sync dts files with the current (Aug 18th 2016) state of Maxime's
> linux/sunxi/for-next repo.

Is that a rebasing tree, or is the sha of the specific commit stable
and therefore worth including here?

> Note this commit also updates configs/MSI_Primo81_defconfig,
> adding: "# CONFIG_REQUIRE_SERIAL_CONSOLE is not set", this is necessary
> because the tablet does not have a reachable uart so the dts sync
> drops its serial0 alias.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: dts: sun6i: Add defconfig and dts file for tablets using the inet-q972 PCB

[Ian Campbell]

On Thu, 2016-08-18 at 19:52 +0200, Hans de Goede wrote:
> Add a defconfig and dts file for tablets using the generic inet-q972 PCB.
> 
> Tablets with this PCB feature a mini-hdmi output, micro-usb usb-host,
> micro-usb usb-otg, 3.5mm headphone jack, a micro sd slot,
> (mini) power-barrel and an usb wifi module.
> 
> This has been tested on a 9.7" 1024x768 qware qw tb9718-qhd tablet.
> 
> The dts files are identical to the ones submitted to the upstream kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sunxi: On newer SoCs use words 1-3 instead of just word 3 from the SID

[Ian Campbell]

On Sat, 2016-07-30 at 14:43 +0200, Hans de Goede wrote:
> It seems that bytes 13-14 of the SID / bytes 1-2 from word 3 of the
> SID
> are always 0 on H3 making it a poor candidate to use as source for
> the
> serialnr / mac-address, and the other non constant words (1 and 2)
> also
> have quite a few bits which are the same for some boards,
> 
> This commits switches to using the crc32 of words 1 - 3 to get a
> more unique value for the mac-address / serialnr.
> 
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Corentin LABBE <clabbe.montj...@gmail.com>
> Cc: Amit Singh Tomar <amittome...@gmail.com>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

Two minor thoughts:

At some point it might be nice to switch from using sid[3] as the
temporary variable to contain the csum since it is no longer the 3rd
element of the sid in any meaningful way. If you decide to do so for a
v4, then please do keep my ack from above.

Likewise if you decide to express the big chain of ifndef's via Kconfig
instead, you can keep the ack.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sun8i: On H3 Use words 1-3 instead of just word 3 from the SID

[Ian Campbell]

On Fri, 2016-07-29 at 11:49 +0200, Hans de Goede wrote:
> It seems that bytes 13-14 of the SID / bytes 1-2 from word 3 of the
> SID
> are always 0 on H3 making it a poor candidate to use as source for
> the
> serialnr / mac-address, and the other non constant words (1 and 2)
> also
> have quite a few bits which are the same for some boards,
> 
> This commits switches to using words 1 - 3 ex-or-ed together to get a
> more unique value for the mac-address / serialnr.
> 
> Cc: Chen-Yu Tsai 
> Cc: Corentin LABBE 
> Cc: Amit Singh Tomar 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -ex-or all 3 words together instead of picking a different word
> ---
>  board/sunxi/board.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ef3fe26..e0734fb 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -623,6 +623,21 @@ static void setup_environment(const void *fdt)
>  
>   ret = sunxi_get_sid(sid);
>   if (ret == 0 && sid[0] != 0 && sid[3] != 0) {

Could/should this check be removed now? Or should sid[1]/sid[2] be
included?

> +#ifdef CONFIG_MACH_SUN8I_H3
> > +   /*
> > +    * The single words 1 - 3 of the SID have quite a few bits
> > +    * which are the same on many models on the H3, so we ex-or
> > +    * them together to get a bit more unique value.
> > +    *
> > +    * Note we only do this on the H3 as we cannot change the
> > +    * algorithm on other SoCs since those have been using
> > +    * fixed mac-addresses based on only using word 3 for a
> > +    * a long time and changing a fixed mac-address with an
> > > +  * u-boot update is not good.

I wonder if we should invert this, i.e. make it not use this new method
on all existing models. That would mean that all future models will
automatically use this new (IMHO better) scheme instead of requiring it
to be manually added each time (which we are sure to forget to do).

Main downside is the ifdef is going to be pretty long, but at least it
would be static. Maybe doing it with select in Kconfig (i.e. select
SUNXI_LEGACY_MAC_SID_THINGY on the existing platforms) would be a more
tollerable approach?

> > > > > > +    */
> > +   sid[3] ^= sid[1] ^ sid[2];
> +#endif
> +
> >     /* Ensure the NIC specific bytes of the mac are not all 0 */
>   if ((sid[3] & 0xff) == 0)
>   sid[3] |= 0x80;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] net: sun8i_emac: Fix DMA alignment issues with the rx / tx buffers

[Ian Campbell]

On Fri, 2016-07-29 at 12:01 +0200, Hans de Goede wrote:
> This fixes the following CACHE warnings when using sun8i_emac:
> 
> => dhcp
> BOOTP broadcast 1
> BOOTP broadcast 2
> CACHE: Misaligned operation at range [7bf594a8, 7bf59628]
> BOOTP broadcast 3
> CACHE: Misaligned operation at range [7bf59c90, 7bf59e10]
> CACHE: Misaligned operation at range [7bf5a478, 7bf5a5f8]
> DHCP client bound to address 10.42.43.80 (1009 ms)
> 
> Note this commit also changes the max rx size from 2024 to 2044,
> matching what the kernel driver uses.
> 
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Corentin LABBE <clabbe.montj...@gmail.com>
> Cc: Amit Singh Tomar <amittome...@gmail.com>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sun8i: On H3 Use word 1 instead of word 3 from the SID

[Ian Campbell]

On Wed, 2016-07-27 at 18:10 +0200, Hans de Goede wrote:
> It seems that bytes 13-14 of the SID / bytes 1-2 from word 3 of the
> SID
> are always 0 on H3 making it a poor candidate to use as source for
> the
> serialnr / mac-address, switch to word1 which seems to be more
> random.
> 
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Corentin LABBE <clabbe.montj...@gmail.com>
> Cc: Amit Singh Tomar <amittome...@gmail.com>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] sunxi: Re-enable h3 emac support

[Ian Campbell]

On Wed, 2016-07-27 at 18:10 +0200, Hans de Goede wrote:
> With the recent bug fixes for the sun8i_emac driver all known issues
> are resolved, so we can re-enable the driver.
> 
> While at it, also enable the emac on the Orange Pi One.
> 
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Corentin LABBE <clabbe.montj...@gmail.com>
> Cc: Amit Singh Tomar <amittome...@gmail.com>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] sunxi: Ensure that the NIC specific bytes of the mac are not all 0

[Ian Campbell]

On Wed, 2016-07-27 at 18:10 +0200, Hans de Goede wrote:
> On 2 of my H3 boards bytes 13-15 of the SID are all 0 leading to
> the NIC specific bytes of the mac all being 0, which leads to the
> boards not getting an ipv6 address from the dhcp server.
> 
> This commits adds a check to ensure this does not happen.
> 
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Corentin LABBE <clabbe.montj...@gmail.com>
> Cc: Amit Singh Tomar <amittome...@gmail.com>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] net: sun8i_emac: Fix DMA alignment issues with the rx / tx buffers

[Ian Campbell]

On Wed, 2016-07-27 at 18:10 +0200, Hans de Goede wrote:
> This fixes the following CACHE warnings when using sun8i_emac:
> 
> => dhcp
> BOOTP broadcast 1
> BOOTP broadcast 2
> CACHE: Misaligned operation at range [7bf594a8, 7bf59628]
> BOOTP broadcast 3
> CACHE: Misaligned operation at range [7bf59c90, 7bf59e10]
> CACHE: Misaligned operation at range [7bf5a478, 7bf5a5f8]
> DHCP client bound to address 10.42.43.80 (1009 ms)
> 
> Cc: Chen-Yu Tsai 
> Cc: Corentin LABBE 
> Cc: Amit Singh Tomar 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/net/sun8i_emac.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index 7c088c3..877859c 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -32,7 +32,8 @@
>  
>  #define CONFIG_TX_DESCR_NUM  32
>  #define CONFIG_RX_DESCR_NUM  32
> -#define CONFIG_ETH_BUFSIZE   2024
> +#define CONFIG_ETH_BUFSIZE   2048
> +#define CONFIG_ETH_RXSIZE2024 /* Note most fit in ETH_BUFSIZE */

s/most/must/?

A comment (perhaps in the commit message rather than the code) as to
how/why RXSIZE and BUFSIZE interact to affect the alignment in the
desired fasion would be useful, since it is non-obvious to me at
least. 

I was about to speculate on the difference of 14 bytes relating to the
Ethernet frame header, but then I realised it's 24 not 14 and deleted
those paragraphs, which I think underscores the need for a comment ;-)

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Disable sun8i emac driver

[Ian Campbell]

On Wed, 2016-07-27 at 00:28 +0200, Hans de Goede wrote:
> Disable the sun8i emac driver for now, there are 2 issues with it:
> 
> 1) It is causing issues with network connectivity under the kernel
> driver,
> when booting the kernel with v2 of Corentin's sun8i-h3 emac driver, I
> get
> the connection status bouncing between connected at 100mbps full-
> duplex
> and being down every second.
> 
> The second issue is that when trying to use it from u-boot
> I get a number of unaligned cache flush errors:
> 
> => dhcp
> BOOTP broadcast 1
> BOOTP broadcast 2
> CACHE: Misaligned operation at range [7bf594a8, 7bf59628]
> BOOTP broadcast 3
> CACHE: Misaligned operation at range [7bf59c90, 7bf59e10]
> CACHE: Misaligned operation at range [7bf5a478, 7bf5a5f8]
> DHCP client bound to address 10.42.43.80 (1009 ms)
> 
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Corentin LABBE <clabbe.montj...@gmail.com>
> Cc: Amit Singh Tomar <amittome...@gmail.com>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Is someone (in the Cc?) looking into this so we can eventually
reenable?

Anyway, for now disabling makes sense I guess:

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts file for the Orange Pi PC Plus SBC

[Ian Campbell]

On Wed, 2016-07-27 at 00:28 +0200, Hans de Goede wrote:
> There is a new Orange Pi PC *Plus* version available now,
> this is an extended version of the regular Orange Pi PC
> with sdio wifi and an eMMC.
> 
> The upstream kernel devs have decided that they want a separate
> dts for the PC Plus rather then sharing a single dts between the
> regular PC and the PC Plus. So add a new orangepi_pc_plus_defconfig
> to match.
> 
> The added dts file matches the one submitted to the upstream kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 29/30] RFC: Use binman for a sunxi board

[Ian Campbell]

(adding Hans)

On Mon, 2016-07-25 at 18:59 -0600, Simon Glass wrote:
> Add an example usage of binman for a sunxi board. This involves adding the
> > image definition to the device tree and using it in the Makefile.

My concern with this approach is that the *.dts(i) files used for sunxi
are sync'd unmodified from the upstream repo. I think this is a
valuable property to retain in terms of maintenance burden for us
(resync is trivial only if there are no local changes).

The conflict is then whether the device tree people would consider this
new block to be "describing the hardware" or not and therefore whether
these changes would be welcomed/allowed upstream. I'm not sure which
way it would go TBH.

There is also an issue with duplication, since this stanza is going to
be the same for all the dozens of sunxi platforms. I suppose this can
be addressed by putting it in a suitable .dtsi file, but that does sort
of start to suggest that this information belongs outside the per-board 
.dts in a per-platform file (at which point I would have have to ask if
.dts is the best/most convenient syntax?).

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: Add support for multiple ethadrr-esses

[Ian Campbell]

On Mon, 2016-07-11 at 11:02 +0200, Hans de Goede wrote:
> > On Sat, 2016-07-09 at 15:12 +0200, Hans de Goede wrote:
> > > 
> > > [...]
> > > +static void setup_environment(const void *fdt)
> > 
> > It might be worth adding a commit to this function noting that it
> > must
> > remain idempotent.
> 
> Done, although I avoided the use of the word idempotent, I had to google
> it to make sure it meant what I thought it meant, so using a simpler
> description for us non native Enlgish speakers seemed better :)

Fair enough.

Ian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] sunxi: Use BROM stored boot_media value to determine our boot-source

[Ian Campbell]

On Sat, 2016-07-09 at 22:22 +0200, Hans de Goede wrote:
> Now that we know that the BROM stores a value indicating the boot-
> source
> at the beginning of SRAM, use that instead of trying to recreate the
> BROM's boot probing.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

All 4 patches:
Acked-by: Ian Campbell <i...@hellion.org.uk>

You might want to s/3th/3rd/ in the third patch's description.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: Add support for multiple ethadrr-esses

[Ian Campbell]

On Sat, 2016-07-09 at 15:12 +0200, Hans de Goede wrote:
> Currently we fill ethaddr with a fixed unique address based on the
> SoCs
> serial (from the sid) to make sure that boards which use the
> integrated
> emac / gmac get a fixed mac rather then a random one.
> 
> On some boards the wifi does not come with a fixed mac either, so we
> need
> to also set eth1addr.
> 
> This commit changes the ethaddr setting code to check for ethernet%d
> aliases (as fdt_fixup_ethernet does) and set an ethaddr variable for
> all present aliases.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

> [...]
> +static void setup_environment(const void *fdt)

It might be worth adding a commit to this function noting that it must
remain idempotent.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Remove some unnecessary #ifdefs

[Ian Campbell]

On Sat, 2016-07-09 at 15:05 +0200, Hans de Goede wrote:
> We always define CONFIG_MISC_INIT_R on sunxi and misc_init_r is never
> called in the spl, so the linker will optimize it and
> parse_spl_header(),
> of which it is the only caller, away.
> 
> On the tests I've done (Orange Pi PC build) the SPL actually becomes
> 8 bytes smaller with this patch.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add support for eth1addr

[Ian Campbell]

On Thu, 2016-06-30 at 17:07 +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-06-16 15:52, Ian Campbell wrote:
> > On Thu, 2016-06-30 at 13:15 +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 30-06-16 12:50, Ian Campbell wrote:
> > > > On Sun, 2016-06-26 at 13:54 +0200, Hans de Goede wrote:
> > > > > Currently we will already fill ethaddr with a fixed unique
> > > > > address
> > > > > based on the SoCs serial (from the sid) to make sure that
> > > > > boards which
> > > > > use the integrated emac / gmac get a fixed mac rather then a
> > > > > random one.
> > > > > 
> > > > > On some boards (observed on 2 tablets using sdio rtl8703as
> > > > > wifi chips)
> > > > > the wifi does not come with a fixed mac either, so also set
> > > > > eth1addr,
> > > > > so that dts files can set an ethernet1 alias to get mac-
> > > > > address and
> > > > > local-mac-address filled for dt nodes describing the wifi
> > > > > controller.
> > > > 
> > > > This does it unconditionally, won't having eth1addr show up for
> > > > boards
> > > > which only have one network device (WIFI or otherwise) be
> > > > potentially
> > > > confusing for users? i.e. lacking it would be a sign that the
> > > > online
> > > > guide you are following might not exactly be relevant to your
> > > > board, or
> > > > people seeing it and then wasting time trying to figure out how
> > > > to use
> > > > the second device. Of secondary concern (since I think it is
> > > > far less
> > > > liklely) would be confusing some software somewhere.
> > > > 
> > [...]
> > > This just sets eth1addr in the u-boot env,
> > 
> > It's this which I worried might confuse people, people who notice
> > eth1addr (perhaps due to tab completion on "printenv eth"?) will
> > wonder
> > where the eth1 device is and/or why it is not working for them.
> 
> People who use the u-boot cmdline at all really are experienced users
> so TBH I'm not all that worried about this.

I know that I personally once wasted quite a bit of time (on arndale,
but still) being mislead/confused by different eth*addr variables
(arndale has another possible prefix too, usbaddr IIRC, which makes it
doubly confusing) and what applies to what and when. So IME having
irrelevant envvars like that floating around in the default env really
does lead to confusion even for people who (supposedly) know what they
are doing.

Even naive users will find random guides online which don't quite apply
to their particular board (especially likely with the vast number of
sunxi variants in existence) and get lead down the wrong path (which
should be "fail early since the envvar discussed doesn't exist)

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add support for eth1addr

[Ian Campbell]

On Thu, 2016-06-30 at 13:15 +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-06-16 12:50, Ian Campbell wrote:
> > On Sun, 2016-06-26 at 13:54 +0200, Hans de Goede wrote:
> > > Currently we will already fill ethaddr with a fixed unique address
> > > based on the SoCs serial (from the sid) to make sure that boards which
> > > use the integrated emac / gmac get a fixed mac rather then a random one.
> > > 
> > > On some boards (observed on 2 tablets using sdio rtl8703as wifi chips)
> > > the wifi does not come with a fixed mac either, so also set eth1addr,
> > > so that dts files can set an ethernet1 alias to get mac-address and
> > > local-mac-address filled for dt nodes describing the wifi controller.
> > 
> > This does it unconditionally, won't having eth1addr show up for boards
> > which only have one network device (WIFI or otherwise) be potentially
> > confusing for users? i.e. lacking it would be a sign that the online
> > guide you are following might not exactly be relevant to your board, or
> > people seeing it and then wasting time trying to figure out how to use
> > the second device. Of secondary concern (since I think it is far less
> > liklely) would be confusing some software somewhere.
> > 
[...]
> This just sets eth1addr in the u-boot env,

It's this which I worried might confuse people, people who notice
eth1addr (perhaps due to tab completion on "printenv eth"?) will wonder
where the eth1 device is and/or why it is not working for them.

The rest of what you say regarding how this goes on to interact with
Linux makes sense to me, although even then having an eth1addr which
does't correspond to the MAC used by the device under Linux (because it
is burnt in and therefore eth1addr is ignored) still seems potentially
confusing to me.

I see at least some platforms use a CONFIG_HAS_ETH1 to control this. It
could also perhaps be gated on the DTB used by u-boot itself by looking
at the mac-address for the ethernet1 alias (and ethernet2 too I
suppose).

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add support for eth1addr

[Ian Campbell]

On Sun, 2016-06-26 at 13:54 +0200, Hans de Goede wrote:
> Currently we will already fill ethaddr with a fixed unique address
> based on the SoCs serial (from the sid) to make sure that boards which
> use the integrated emac / gmac get a fixed mac rather then a random one.
> 
> On some boards (observed on 2 tablets using sdio rtl8703as wifi chips)
> the wifi does not come with a fixed mac either, so also set eth1addr,
> so that dts files can set an ethernet1 alias to get mac-address and
> local-mac-address filled for dt nodes describing the wifi controller.

This does it unconditionally, won't having eth1addr show up for boards
which only have one network device (WIFI or otherwise) be potentially
confusing for users? i.e. lacking it would be a sign that the online
guide you are following might not exactly be relevant to your board, or
people seeing it and then wasting time trying to figure out how to use
the second device. Of secondary concern (since I think it is far less
liklely) would be confusing some software somewhere.

Also what is the impact on boards which have a second network device
which does have a proper MAC address, either one which is part of the
board or e.g. on a USB dongle? I think we don't want to override any
burnt in MAC addresses.

Ian.

> 
> Signed-off-by: Hans de Goede 
> ---
>  board/sunxi/board.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index b5a50f4..41d796c 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -641,6 +641,18 @@ int misc_init_r(void)
>   eth_setenv_enetaddr("ethaddr", mac_addr);
>   }
>  
> + if (!getenv("eth1addr")) {
> + /* Non OUI / registered MAC address */
> + mac_addr[0] = 0x12;
> + mac_addr[1] = (sid[0] >>  0) & 0xff;
> + mac_addr[2] = (sid[3] >> 24) & 0xff;
> + mac_addr[3] = (sid[3] >> 16) & 0xff;
> + mac_addr[4] = (sid[3] >>  8) & 0xff;
> + mac_addr[5] = (sid[3] >>  0) & 0xff;
> +
> + eth_setenv_enetaddr("eth1addr", mac_addr);
> + }
> +
>   if (!getenv("serial#")) {
>   snprintf(serial_string,
> sizeof(serial_string),
>   "%08x%08x", sid[0], sid[3]);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: spl: Fix DRAM info printing

[Ian Campbell]

On Sun, 2016-06-26 at 13:57 +0200, Hans de Goede wrote:
> The switch to simple_printf was causing the SPL dram info to show as:
> 
> DRAM: u MiB
> 
> This fixes this by switching from %lu to %d for printing the DRAM size.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig for Olinuxino Lime 2 EMMC version

[Ian Campbell]

On Wed, 2016-06-15 at 05:29 +0200, Emmanuel Vadot wrote:

Please include a short description of the board, in this case
explaining the distinction (and defconfig differences) from the non-
EMMC version would be useful.

Have a look at some of the previous patches which add defconfig (e.g.
those from Hans) for some examples of best practice.

> Signed-off-by: Emmanuel Vadot 
> ---
>  configs/A20-OLinuXino-Lime2-emmc_defconfig | 21 +

This patch should also touch board/sunxi/MAINTAINERS, to add an entry
with your name for this board. 

> +CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime2-emmc"

This file doesn't appear to be in the u-boot tree already so usually we
would import the upstream version as part of this patch.

In fact I'm not sure how this patch builds without it, we configure u-
boot itself via DM for at least some subsystems, which requires it to
be present a build time to be concatenated onto the basic image.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts file for inet86dz board

[Ian Campbell]

On Sun, 2016-06-12 at 19:50 +0200, Hans de Goede wrote:
> The inet86dz board is a board used in 7" tablets from various oems.
> 
> These tablets are a23 based 7" tablets featuring a 1024x600 LCD,
> 512MB RAM, 4G NAND, rtl8188etv usb wifi, gsl1680 touchschreen,
> micro-sd slot, 3.5mm headphone jack and a micro-usb otg connector
> which doubles as charging port.
> 
> The dts file this commit adds is identical to the one submitted to
> the upstream kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] sunxi: Select USE_TINY_PRINTF

[Ian Campbell]

On Fri, 2016-06-10 at 21:04 +0200, Hans de Goede wrote:
> This gives us a bit more breathing room wrt our SPL size.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

(and the first one too, FWIW)

> ---
>  arch/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e75c4c0..4aeb4d2 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -611,6 +611,7 @@ config ARCH_SUNXI
>   select USB
>   select USB_STORAGE
>   select USB_KEYBOARD
> + select USE_TINY_PRINTF
>  
>  config TARGET_TS4800
>   bool "Support TS4800"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: musb: Properly turn of musb controller before booting

[Ian Campbell]

On Sun, 2016-06-05 at 16:54 +0200, Hans de Goede wrote:
> Turn of the clock and assert the reset when musb_stop gets called, so
> that
> the os gets the musb controller in a pristine state. This fixes a
> spurious
> VBus error interrupt triggering as soon as the Linux musb driver
> loads.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add INITIAL_USB_SCAN_DELAY to Mele_A1000G_quad_defconfig

[Ian Campbell]

On Sun, 2016-06-05 at 14:50 +0200, Hans de Goede wrote:
> The Mele_A1000G_quad has an onboard usb <-> sata conversion which
> needs
> longer then the usb-spec allows to connect after getting power.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>
> ---
>  configs/Mele_A1000G_quad_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/Mele_A1000G_quad_defconfig
> b/configs/Mele_A1000G_quad_defconfig
> index b3f825e..838be56 100644
> --- a/configs/Mele_A1000G_quad_defconfig
> +++ b/configs/Mele_A1000G_quad_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_MACH_SUN6I=y
>  CONFIG_DRAM_ZQ=120
> +CONFIG_INITIAL_USB_SCAN_DELAY=500
>  CONFIG_USB1_VBUS_PIN="PC27"
>  CONFIG_USB2_VBUS_PIN=""
>  CONFIG_DEFAULT_DEVICE_TREE="sun6i-a31-mele-a1000g-quad"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable ALDO3 and ALDO4 in Wobo_i5_defconfig

[Ian Campbell]

On Fri, 2016-06-03 at 20:11 +0200, Hans de Goede wrote:
> These are used for the usb wifi and if we leave the enabling up to the
> kernel, we get hit by the axp209 issues with enabling ldo3 or 4 post boot
> and the systems hangs as soon as it is enabled.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

(sorry for the lateness on this one)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts file for Polaroid MID2407PXE03 tablet

[Ian Campbell]

On Sat, 2016-06-11 at 15:54 +0200, Hans de Goede wrote:
> The Polaroid MID2407PXE03 is an a23 based 7" tablet based on a M86_MB
> V2.0
> PCB, featuring a 800x480 LCD, 512MB RAM, 4G NAND, esp8089 wifi,
> gsl1680
> touchschreen, micro-sd slot, 3.5mm headphone jack and a micro-usb otg
> connector which doubles as charging port.
> 
> The dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Revert "sunxi: make SoC variant choice mandatory"

[Ian Campbell]

On Sun, 2016-06-12 at 13:03 +0200, Hans de Goede wrote:
> This reverts commit 1a5f0de08e86("sunxi: make SoC variant choice
> mandatory").
> 
> With the optional marking in the Kconfig "make savedefconfig"
> will drop CONFIG_MACH_SUN4I=y from all the A10 boards, making it
> hard to see at a glance which family of sunxi chips the defconfig
> is for.
> 
> This commit therefore restores the optional, and restores
> CONFIG_MACH_SUN4I=y to all defconfig's which had it dropped
> because of this.

Is this because the first config in a choice is considered the default
and hence is omitted by savedefconfig or is something else going on?

In any case:

> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable a bunch of commands by default on sunxi

[Ian Campbell]

On Sun, 2016-05-15 at 14:27 +0200, Hans de Goede wrote:
> Recently a set of CONFIG_CMD_FOO defines was moved from being defined
> in config_distro_defaults to Kconfig, and added to all sunxi defconfigs
> to compensate.

I wonder if some of them ought to be "default y" globally, since they
seem like they should be enabled on most boards by default, but that's
outside my balliwick. So as far as this sunxi change goes:

> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6b65d8e..491577f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -538,7 +538,16 @@ config TARGET_CM_T43
>  
>  config ARCH_SUNXI
>   bool "Support sunxi (Allwinner) SoCs"
> + select CMD_BOOTZ
> + select CMD_DHCP
> + select CMD_EXT2
> + select CMD_EXT4
> + select CMD_FAT
> + select CMD_FS_GENERIC
>   select CMD_GPIO
> + select CMD_MII
> + select CMD_MMC if MMC
> + select CMD_PING
>   select CMD_USB
>   select DM
>   select DM_ETH
> @@ -546,6 +555,7 @@ config ARCH_SUNXI
>   select DM_KEYBOARD
>   select DM_SERIAL
>   select DM_USB
> + select HUSH_PARSER
>   select OF_BOARD_SETUP
>   select OF_CONTROL
>   select OF_SEPARATE
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index 059e914..c1ae6f5 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -368,6 +368,7 @@ config I2C0_ENABLE
>   bool "Enable I2C/TWI controller 0"
>   default y if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
>   default n if MACH_SUN6I || MACH_SUN8I
> + select CMD_I2C
>   ---help---
>   This allows enabling I2C/TWI controller 0 by muxing its pins, enabling
>   its clock and setting up the bus. This is especially useful on devices
> @@ -377,12 +378,14 @@ config I2C0_ENABLE
>  config I2C1_ENABLE
>   bool "Enable I2C/TWI controller 1"
>   default n
> + select CMD_I2C
>   ---help---
>   See I2C0_ENABLE help text.
>  
>  config I2C2_ENABLE
>   bool "Enable I2C/TWI controller 2"
>   default n
> + select CMD_I2C
>   ---help---
>   See I2C0_ENABLE help text.
>  
> @@ -390,6 +393,7 @@ if MACH_SUN6I || MACH_SUN7I
>  config I2C3_ENABLE
>   bool "Enable I2C/TWI controller 3"
>   default n
> + select CMD_I2C
>   ---help---
>   See I2C0_ENABLE help text.
>  endif
> @@ -399,6 +403,7 @@ config R_I2C_ENABLE
>   bool "Enable the PRCM I2C/TWI controller"
>   # This is used for the pmic on H3
>   default y if SY8106A_POWER
> + select CMD_I2C
>   ---help---
>   Set this to y to enable the I2C controller which is part of the PRCM.
>  endif
> @@ -407,6 +412,7 @@ if MACH_SUN7I
>  config I2C4_ENABLE
>   bool "Enable I2C/TWI controller 4"
>   default n
> + select CMD_I2C
>   ---help---
>   See I2C0_ENABLE help text.
>  endif
> @@ -535,6 +541,7 @@ config VIDEO_LCD_PANEL_I2C
>   bool "LCD panel needs to be configured via i2c"
>   depends on VIDEO
>   default n
> + select CMD_I2C
>   ---help---
>   Say y here if the LCD panel needs to be configured via i2c. This
>   will add a bitbang i2c controller using gpios to talk to the LCD.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable USB host in CHIP defconfig

[Ian Campbell]

On Thu, 2016-05-12 at 19:29 +0200, Hans de Goede wrote:
> Reported-and-tested-by: Dennis Gilmore <den...@ausil.us>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND] arm/arm64: Move barrier instructions into separate header

[Ian Campbell]

On Thu, 2016-05-12 at 12:14 +0100, Andre Przywara wrote:
> ---
> Hi Hans, Ian,
> 
> can I get an ACK on this please?

I'm afraid that given:
[...]
>  arch/arm/include/asm/armv7.h   | 21 +-
>  arch/arm/include/asm/barriers.h| 44 
> ++
>  arch/arm/mach-sunxi/dram_helpers.c |  2 +-

It's not really our Ack you need, but the overall arm maintainer's
(Albert) ack. (AFAIK there is no separate armv8 maintainer.)

FIW for the sunxi hunk:
Acked-by: Ian Campbell <i...@hellion.org.uk>

Although it is so trivial as to be hardly worth it.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Ian Campbell]

On Fri, 2016-04-22 at 14:12 +0100, Andre Przywara wrote:
> Hi,
> 
> On 22/04/16 13:09, Hans de Goede wrote:
> > 
> > Hi,
> > 
> > On 22-04-16 13:46, Andre Przywara wrote:
> > > 
> > > Hi Hans,
> > > 
> > > thanks for the information and the heads up!
> > > 
> > > On 22/04/16 11:48, Hans de Goede wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On 22-04-16 11:32, Ian Campbell wrote:
> > > > > 
> > > > > On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
> > > > > > 
> > > > > > > 
> > > > > > > I wonder if what you are observing could be possibly
> > > > > > > explained by
> > > > > > > just
> > > > > > > a usual data corruption problem? Which may be happening
> > > > > > > when the DRAM
> > > > > > > clock speed is set higher than this particular device is
> > > > > > > able to
> > > > > > > handle
> > > > > > > in a reliable way. Inserting just one or more NOP
> > > > > > > instructions
> > > > > > > instead
> > > > > > > of the barrier could possibly change some timings too.
> > > > > > > 
> > > > > > > If this patch helps, then it's fine. But I wonder if it
> > > > > > > is not merely
> > > > > > > making the problem latent instead of fixing the root
> > > > > > > cause?
> > > > > > I do believe that this patch addresses a real problem and
> > > > > > is not
> > > > > > hiding
> > > > > > some dram timing issues, I might be wrong about the write-
> > > > > > buffer being
> > > > > > the cause, it could simply be that the compiler is doing
> > > > > > something bad
> > > > > > (despite the accesses being marked as volatile)  and that
> > > > > > the DSB
> > > > > > stops
> > > > > > the compiler from optimizing things too much.
> > > > > I have a _very_ vague memory of seeing something not
> > > > > disimilar to this
> > > > > (apparent write buffer interactions with MMU disabled) in the
> > > > > early
> > > > > days of Xen development, but that was probably on models and
> > > > > so may not
> > > > > have been representative of the intended behaviour of
> > > > > eventual silicon.
> > > > > 
> > > > > It might be interesting to have a look at the generated
> > > > > assembly and
> > > > > see if it differs in more or less than the addition of the
> > > > > single
> > > > > instruction and perhaps experiment with just a compiler
> > > > > barrier.
> > > > > 
> > > > > Andre, do you have any insights on this?
> > > Agree on the compiler barrier, frankly I don't see how this
> > > should break
> > > with caches on or off unless the actual instruction order is
> > > wrong or
> > > the compiler optimized something away.
> > > Regardless of the write buffer the core should make sure the
> > > subsequent
> > > reads return the value written before - especially if we are
> > > talking UP
> > > here.
> > "the core should make sure the subsequent reads return the value
> > written
> > before"
> > that is exactly the problem, we are writing 2 different values
> > to so DRAM_BASE and DRAM_BASE + 512MiB, then read them both back
> > and compare them, expecting them to be the same (both reads
> > returning
> > the last written value) if the ramsize is 512MiB (this is used in
> > several places
> > in the dram controller code to auto-config number of rows, columns,
> > etc.).
> > 
> > But the core seems to just return the last written value,
> > rather then actually going out to the RAM and reading it from
> > there, which results in the function always returning false
> > (i.o.w. it claims no DRAM phys address wraparound is happening
> >  at 512MiB).
> Oh, right, I missed that part, sorry.
> So this is about physical aliasing?
> The DRAM controller has only n address lines connected, and changing a
> line >n shouldn't make a difference, right?

Correct, it's a technique used to try and size the DRAM by determing n
by observation of the aliasing patterns.

> And the write succeeds and does trigger an asynchronous abort?

                                 ^n't

> So I did a quick poll around the office and people say that "dsb" is the
> right thing to do here (with MMU off).
> As this is backed by practical experience, I'd just say: good to go!

Patch therefore:

Acked-by: Ian Campbell <i...@hellion.org.uk>

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable LDO3 at 3.3V on A13-OLinuXino board

[Ian Campbell]

On Thu, 2016-04-14 at 16:51 +0200, Hans de Goede wrote:
> LDO3 is used for the VGA output, this fixes a regression where the
> VGA
> output on these boards would no longer work.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Ian Campbell]

On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
> > I wonder if what you are observing could be possibly explained by just
> > a usual data corruption problem? Which may be happening when the DRAM
> > clock speed is set higher than this particular device is able to handle
> > in a reliable way. Inserting just one or more NOP instructions instead
> > of the barrier could possibly change some timings too.
> > 
> > If this patch helps, then it's fine. But I wonder if it is not merely
> > making the problem latent instead of fixing the root cause?
> I do believe that this patch addresses a real problem and is not hiding
> some dram timing issues, I might be wrong about the write-buffer being
> the cause, it could simply be that the compiler is doing something bad
> (despite the accesses being marked as volatile)  and that the DSB stops
> the compiler from optimizing things too much.

I have a _very_ vague memory of seeing something not disimilar to this
(apparent write buffer interactions with MMU disabled) in the early
days of Xen development, but that was probably on models and so may not
have been representative of the intended behaviour of eventual silicon.

It might be interesting to have a look at the generated assembly and
see if it differs in more or less than the addition of the single
instruction and perhaps experiment with just a compiler barrier.

Andre, do you have any insights on this?

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts file for Orange Pi One SBC

[Ian Campbell]

On Sat, 2016-04-09 at 15:23 +0200, Hans de Goede wrote:
> The Orange Pi One SBC, is a stripped down version of the popular
> Orange Pi PC. The one is a H3 based SBC, with 512M of RAM,
> micro-sd slot, 1 host usb, 1 otg usb, hdmi and 100Mbit ethernet.
> 
> The dts is identical to the dts submitted to the upstream kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: H3: Do not clear usb companion clk-gate / reset on remove

[Ian Campbell]

On Sat, 2016-04-09 at 15:23 +0200, Hans de Goede wrote:
> On the H3 we need to enable the clk and de-assert the reset of the
> companion to be able to talk to the actual usb host controller.
> 
> Before this commit we were also disabling the companion clk-gate /
> asserting its reset on remove, causing the later remove callback of
> the companion itself to (sometimes) fail with:
> 
> ERROR: USB HC reset timed out!
> 
> This commit fixes this by not disabling the companion's clk-gate nor
> asserting its reset on remove.

This sounds like a bug (or perhaps lack of expressiveness) in the DM
clk bindings to me, but I can see why we want to do it this way shirt
term:

> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

> ---
>  drivers/usb/host/ehci-sunxi.c | 10 +++---
>  drivers/usb/host/ohci-sunxi.c | 10 +++---
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-
> sunxi.c
> index d5eb492..f2d83e3 100644
> --- a/drivers/usb/host/ehci-sunxi.c
> +++ b/drivers/usb/host/ehci-sunxi.c
> @@ -38,6 +38,7 @@ static int ehci_usb_probe(struct udevice *dev)
>   struct ehci_sunxi_priv *priv = dev_get_priv(dev);
>   struct ehci_hccr *hccr = (struct ehci_hccr
> *)dev_get_addr(dev);
>   struct ehci_hcor *hcor;
> + int extra_ahb_gate_mask = 0;
>  
>   /*
>    * This should go away once we've moved to the driver model
> for
> @@ -45,15 +46,18 @@ static int ehci_usb_probe(struct udevice *dev)
>    */
>   priv->ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_EHCI0;
>  #ifdef CONFIG_MACH_SUN8I_H3
> - priv->ahb_gate_mask |= 1 << AHB_GATE_OFFSET_USB_OHCI0;
> + extra_ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_OHCI0;
>  #endif
>   priv->phy_index = ((u32)hccr - SUNXI_USB1_BASE) / BASE_DIST;
>   priv->ahb_gate_mask <<= priv->phy_index * AHB_CLK_DIST;
> + extra_ahb_gate_mask <<= priv->phy_index * AHB_CLK_DIST;
>   priv->phy_index++; /* Non otg phys start at 1 */
>  
> - setbits_le32(>ahb_gate0, priv->ahb_gate_mask);
> + setbits_le32(>ahb_gate0,
> +  priv->ahb_gate_mask | extra_ahb_gate_mask);
>  #ifdef CONFIG_SUNXI_GEN_SUN6I
> - setbits_le32(>ahb_reset0_cfg, priv->ahb_gate_mask);
> + setbits_le32(>ahb_reset0_cfg,
> +  priv->ahb_gate_mask | extra_ahb_gate_mask);
>  #endif
>  
>   sunxi_usb_phy_init(priv->phy_index);
> diff --git a/drivers/usb/host/ohci-sunxi.c b/drivers/usb/host/ohci-
> sunxi.c
> index 6f3f4ce..2a1e8bf 100644
> --- a/drivers/usb/host/ohci-sunxi.c
> +++ b/drivers/usb/host/ohci-sunxi.c
> @@ -38,6 +38,7 @@ static int ohci_usb_probe(struct udevice *dev)
>   struct usb_bus_priv *bus_priv = dev_get_uclass_priv(dev);
>   struct ohci_sunxi_priv *priv = dev_get_priv(dev);
>   struct ohci_regs *regs = (struct ohci_regs
> *)dev_get_addr(dev);
> + int extra_ahb_gate_mask = 0;
>  
>   bus_priv->companion = true;
>  
> @@ -47,18 +48,21 @@ static int ohci_usb_probe(struct udevice *dev)
>    */
>   priv->ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_OHCI0;
>  #ifdef CONFIG_MACH_SUN8I_H3
> - priv->ahb_gate_mask |= 1 << AHB_GATE_OFFSET_USB_EHCI0;
> + extra_ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_EHCI0;
>  #endif
>   priv->usb_gate_mask = CCM_USB_CTRL_OHCI0_CLK;
>   priv->phy_index = ((u32)regs - (SUNXI_USB1_BASE + 0x400)) /
> BASE_DIST;
>   priv->ahb_gate_mask <<= priv->phy_index * AHB_CLK_DIST;
> + extra_ahb_gate_mask <<= priv->phy_index * AHB_CLK_DIST;
>   priv->usb_gate_mask <<= priv->phy_index;
>   priv->phy_index++; /* Non otg phys start at 1 */
>  
> - setbits_le32(>ahb_gate0, priv->ahb_gate_mask);
> + setbits_le32(>ahb_gate0,
> +  priv->ahb_gate_mask | extra_ahb_gate_mask);
>   setbits_le32(>usb_clk_cfg, priv->usb_gate_mask);
>  #ifdef CONFIG_SUNXI_GEN_SUN6I
> - setbits_le32(>ahb_reset0_cfg, priv->ahb_gate_mask);
> + setbits_le32(>ahb_reset0_cfg,
> +  priv->ahb_gate_mask | extra_ahb_gate_mask);
>  #endif
>  
>   sunxi_usb_phy_init(priv->phy_index);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sunxi: Enable usb ports on the Sinovoip BPI M3

[Ian Campbell]

On Tue, 2016-04-05 at 11:51 +0200, Hans de Goede wrote:
> Hi,
> 
> On 05-04-16 11:44, Ian Campbell wrote:
> > 
> > On Sat, 2016-04-02 at 21:10 +0200, Hans de Goede wrote:
> > > 
> > > DLDO3 is used to provide Port-D power and PD is used for the
> > > usb-hub / sata-5v enable pins. The 2.5V comes from the schematic
> > > and matches the factory image fex file.
> > Is the dts update being sync'd from the kernel?
> Erm, no actually, the A83t USB support for the kernel is not entirely
> ready, so we've some very minimal nodes in u-boot's a83t.dtsi for
> now,
> which will get replaced with the real deal when we sync in the
> future.
> 
> The only thing u-boot cares about are controller base address and
> the compatible string, and there is no discussion about those,
> which is why I merged ChenYu's .dtsi patches with the minimal nodes,
> this commit just enables these nodes in the M3 dts.

Ah, ok. Is it worth mentioning that in the commit log for clarity
(think of someone doing a resync with the kernel and getting confused
by the non-kernel bits)?

Maybe the commit message on the orignal addition makes it unnecessary?
If you think that's the case then you can keep my Ack.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable CMD_GPIO on all sunxi boards

[Ian Campbell]

On Sun, 2016-04-03 at 09:43 +0200, Hans de Goede wrote:
> We have CONFIG_CMD_GPIO=y in almost all sunxi boards, but after
> its Kconfig conversion it has ended up missing on some recently
> added boards.

The "almost all" is entirely down to the accidental omissions, right?
i.e. are no boards where GPIO support is deliberately disabled I think
(because all SoCs have them and it'd be practically impossible to build
a system without using at least one of them).


> Simply select it for ARCH_SUNXI, so that we get it on all
> sunxi boards for both a consistent user experience and simpler
> defconfig files.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Regardless of the question above (which is just curiosity really):

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sunxi: Enable usb ports on the Sinovoip BPI M3

[Ian Campbell]

On Sat, 2016-04-02 at 21:10 +0200, Hans de Goede wrote:
> DLDO3 is used to provide Port-D power and PD is used for the
> usb-hub / sata-5v enable pins. The 2.5V comes from the schematic
> and matches the factory image fex file.

Is the dts update being sync'd from the kernel?

If yes:

> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

If you also want to mention the kernel sync in the commit message, you
can also retain the ack (of course).


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] sunxi: Set DCDC1 to 3.3V on the Sinovoip BPI M3

[Ian Campbell]

On Sat, 2016-04-02 at 21:10 +0200, Hans de Goede wrote:
> This is the value used in the fex file of the manufacturer images,
> and also the DCDC1 default. Sometimes lower values are used to save
> battery power, but that does not apply to a SBC.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sunxi: Add INITIAL_USB_SCAN_DELAY Kconfig option

[Ian Campbell]

On Sat, 2016-04-02 at 21:10 +0200, Hans de Goede wrote:
> Some boards have on board usb devices which need longer then the USB
                                                          ^than

(and in the Kconfig too)

> spec's 1 second to connect from board powerup. Add a config option which
> when non 0 adds an extra delay before the first usb bus scan.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Apart from that:

Acked-by: Ian Campbell <i...@hellion.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] musb: sunxi: Do not allocate musb struct multiple times

[Ian Campbell]

On Sat, 2016-04-02 at 23:39 +0200, Hans de Goede wrote:
> Hi,
> 
> On 04/02/2016 08:57 PM, Peter Korsgaard wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > "Hans" == Hans de Goede <hdego...@redhat.com> writes:
> >   > The probe function of the musb host driver can be called
> > multiple
> >   > times. The code assumes that it can safe the pointer to the
> > allocated
> >   > musb struct in the driver model priv_auto_alloc data, but this
> > data
> >   > gets free-ed on a probe failure or on removal, so we must safe
> > the
> >   > pointer elsewhere.
> > 
> > s/safe/save/ (twice).
> Thanks, fixed in my tree.

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64

[Ian Campbell]

On Fri, 2016-04-01 at 13:08 +0200, Alexander Graf wrote:
> 
> On 01.04.16 13:06, Ian Campbell wrote:
> > 
> > On Wed, 2016-03-30 at 17:53 +0200, Alexander Graf wrote:
> > > 
> > > On the A64 we usually boot with ATF running in EL3. ATF as it is available
> > > today resides in the first 16MB of RAM. So we should make sure we reserve
> > > that space in our memory maps.
> > Would using fdt_add_mem_rsv() be better than fiddling with the DRAM
> > banks?
> Nope, because that wouldn't populate into the EFI memory descriptors ;).

Isn't that a bug? ;-)

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64

[Ian Campbell]

On Wed, 2016-03-30 at 17:53 +0200, Alexander Graf wrote:
> On the A64 we usually boot with ATF running in EL3. ATF as it is available
> today resides in the first 16MB of RAM. So we should make sure we reserve
> that space in our memory maps.

Would using fdt_add_mem_rsv() be better than fiddling with the DRAM
banks?

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: Add conditional magic sram poke for A33

[Ian Campbell]

On Fri, 2016-03-25 at 01:10 +0100, Karsten Merker wrote: 
> > -   if ((version & 0x) == 0x1650)
> > +   /*
> > +    * Ideally this would be a switch case, bit we do not know exactly
> 
> s/bit/but/

Other than that, both patches:
Acked-by: Ian Campbell <i...@hellion.org.uk>

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sunxi: Select CONFIG_OF_BOARD_SETUP from arch/arm/Kconfig

[Ian Campbell]

On Wed, 2016-03-23 at 11:13 +0100, Hans de Goede wrote:
> Always select OF_BOARD_SETUP on sunxi, rather then having it in
> almost
> all our defconfigs. This also fixes it missing from some recently
> added defconfigs.
> 
> This commit also modifies our ft_board_setup() to not cause warnings
> when CONFIG_VIDEO_DT_SIMPLEFB is not set, since we will now always
> build it.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> ---
> Changes in v2:
> -Only select CONFIG_OF_BOARD_SETUP when CONFIG_VIDEO is set, rather then 
> always
> Changes in v3:
> -Back to always enabling CONFIG_OF_BOARD_SETUP on sunxi + fix the compile
>  warning in ft_board_setup when CONFIG_VIDEO_DT_SIMPLEFB is not set

I agree this approach is better:
Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts for Orange Pi 2 SBC

[Ian Campbell]

On Wed, 2016-03-23 at 11:13 +0100, Hans de Goede wrote:
> The Orange Pi 2 is a SBC based on the Allwinner H3 SoC with a uSD
> slot,
> 4 USB ports connected via a USB-2 hub, a 10/100M ethernet port using
> the
> SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, USB OTG,
> HDMI,
> a TRRS headphone jack for stereo out and composite out, a microphone,
> an IR receiver, a CSI connector, 2 LEDs, a 3 pin UART header
> and a 40-pin GPIO header.
> 
> The added dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: Select CONFIG_OF_BOARD_SETUP from CONFIG_VIDEO

[Ian Campbell]

On Tue, 2016-03-22 at 23:08 +0100, Hans de Goede wrote:
> Select OF_BOARD_SETUP when CONFIG_VIDEO is set, rather then having it
> in
> almost all our defconfigs. This also fixes it missing from some
> recently
> added defconfigs.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Only select CONFIG_OF_BOARD_SETUP when CONFIG_VIDEO is set, rather
> then always

What were the warning you got with the first version? Is that something
we should consider addressing instead? The link between OF_BOARD_SETUP
and VIDEO is not entirely clear to me.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Select OF_BOARD_SETUP from arch/arm/Kconfig

[Ian Campbell]

On Tue, 2016-03-22 at 22:56 +0100, Hans de Goede wrote:
> Select OF_BOARD_SETUP from arch/arm/Kconfig when building for sunxi,
> rather then having it in all our defconfigs. This also fixes it
> missing
> from some recently added defconfigs.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-byL Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: Turn satapwr on from board_init

[Ian Campbell]

On Tue, 2016-03-22 at 21:49 +0100, Hans de Goede wrote:
> There are 2 reasons for doing this:
> 
> 1) The main reason for doing this is to move it outside of
>    board/sunxi/ahci.c, so that it can be used on boards which use
>    a usb<->sata chip too;
> 2) While doing this I realized that doing it from board_init also
> meant
>    doing it much earlier. Some printf get_timer(0) calls show that
> the
>    time between board_init() and scsi_init() is more then 600 ms,
>    so we can drop the mdelay(500)
> 
> While at it also drop the printf("SUNXI SCSI INIT\n") AHCI init is
> noisy enough by itself.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Both: Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Fix 2nd usb controller on sun4i/sun7i no longer working

[Ian Campbell]

On Mon, 2016-03-21 at 14:50 +0100, Hans de Goede wrote:
> The 2nd usb controller on sun4i/sun7i has its base address 0x8000
> bytes from the 1st one, rather then 0x1000. Also the ahb clk gates
> are interleaved with the ohci clk-gates introducing a hole between
> the clks for usb1 and usb2.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable support for the eMMC found on the orangepi plus

[Ian Campbell]

On Mon, 2016-03-21 at 22:46 +0100, Hans de Goede wrote:
> Hi,
> 
> On 21-03-16 07:05, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Sun, Mar 20, 2016 at 9:21 PM, Hans de Goede <hdego...@redhat.com
> > wrote:
> >> This enables support for the eMMC found on the orangepi plus.
> >>
> >> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> >> ---
> >>   configs/orangepi_plus_defconfig | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/configs/orangepi_plus_defconfig
> b/configs/orangepi_plus_defconfig
> >> index c4885f4..770bd98 100644
> >> --- a/configs/orangepi_plus_defconfig
> >> +++ b/configs/orangepi_plus_defconfig
> >> @@ -4,6 +4,8 @@ CONFIG_MACH_SUN8I_H3=y
> >>   CONFIG_DRAM_CLK=672
> >>   CONFIG_DRAM_ZQ=3881979
> >>   CONFIG_DRAM_ODT_EN=y
> >> +CONFIG_MMC0_CD_PIN="PF6"
> >> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> >
> > Does CONFIG_MMC2_PINS also need to be set?
> 
> No there only is one pinmux option for MMC2 on H8, so there is no
> need to set this.

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sunxi: Add support for USB vbus pin for USB3

[Ian Campbell]

On Fri, 2016-03-18 at 08:55 +0100, Hans de Goede wrote:
> The H3 has USB0 - USB3, add support for having a USB vbus pin for
> USB3.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

All three of these patches:
Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Fix gmac not working due to cpu_eth_init no longer being called

[Ian Campbell]

On Thu, 2016-03-17 at 15:38 +0100, Hans de Goede wrote:
> Hi,
> 
> On 17-03-16 14:21, Ian Campbell wrote:
> > 
> > On Thu, 2016-03-17 at 14:02 +0100, Hans de Goede wrote:
> > > 
> > > cpu_eth_init is no longer called for dm enabled eth drivers, this
> > > was causing the sunxi gmac eth controller to no longer work in u-
> > > boot.
> > > 
> > > This commit fixes this by moving the gpio setup to gpio_init()
> > > and by
> > > calling the clock, reset and pinmux setup function from s_init().
> > > 
> > > Note that the mdelay is dropped as the phy gets enabled much
> > > earlier
> > > now, so it is no longer needed.
> > Everything is DM_ETH based now, right? Which is why this final hunk is
> > OK?
> Correct, we only do DM for eth in sunxi now,

Super. Acked-by: Ian Campbell <i...@hellion.org.uk>

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable realtek phy support

[Ian Campbell]

On Wed, 2016-03-16 at 15:23 +0100, Hans de Goede wrote:
> Enable building of drivers/net/phy/realtek.c so that realtek phys
> get properly initialized.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sunxi: Fix clock_twi_onoff for sun6i

[Ian Campbell]

On Wed, 2016-03-16 at 21:07 +0100, Hans de Goede wrote:
> The clock_sun6i.c implementation was not deasserting the reset for
> the regular i2c controllers, this commit fixes this.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

All 3 patches: Acked-by: Ian Campbell <i...@hellion.org.uk>

> ---
>  arch/arm/cpu/armv7/sunxi/clock_sun6i.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
> b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
> index 700b605..4e1e1a4 100644
> --- a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
> +++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
> @@ -100,13 +100,18 @@ int clock_twi_onoff(int port, int state)
>   return 0;
>   }
>  
> - /* set the apb clock gate for twi */
> - if (state)
> + /* set the apb clock gate and reset for twi */
> + if (state) {
>   setbits_le32(>apb2_gate,
>    CLK_GATE_OPEN <<
> (APB2_GATE_TWI_SHIFT+port));
> - else
> + setbits_le32(>apb2_reset_cfg,
> +  1 << (APB2_RESET_TWI_SHIFT + port));
> + } else {
> + clrbits_le32(>apb2_reset_cfg,
> +  1 << (APB2_RESET_TWI_SHIFT + port));
>   clrbits_le32(>apb2_gate,
>    CLK_GATE_OPEN <<
> (APB2_GATE_TWI_SHIFT+port));
> + }
>  
>   return 0;
>  }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] include/dt-bindings: Sync some files with the kernel

[Ian Campbell]

On Wed, 2016-03-16 at 10:24 -0400, Tom Rini wrote:
> On Wed, Mar 16, 2016 at 01:47:54PM +0100, Hans de Goede wrote:
> 
> > 
> > This commit syncs the dt-bindings/input/* headers with the kernel
> > (v4.5)
> > and adds dt-bindings/clock/sun4i-a10-pll2.h, both are necessary for
> > newer
> > sunxi dts files to build.
> > 
> > Signed-off-by: Hans de Goede <hdego...@redhat.com>
> Reviewed-by: Tom Rini <tr...@konsulko.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Fix gmac not working due to cpu_eth_init no longer being called

[Ian Campbell]

On Thu, 2016-03-17 at 14:02 +0100, Hans de Goede wrote:
> cpu_eth_init is no longer called for dm enabled eth drivers, this
> was causing the sunxi gmac eth controller to no longer work in u-
> boot.
> 
> This commit fixes this by moving the gpio setup to gpio_init() and by
> calling the clock, reset and pinmux setup function from s_init().
> 
> Note that the mdelay is dropped as the phy gets enabled much earlier
> now, so it is no longer needed.

Everything is DM_ETH based now, right? Which is why this final hunk is
OK?

> [...]
> @@ -79,16 +79,4 @@ int sunxi_gmac_initialize(bd_t *bis)
>   for (pin = SUNXI_GPA(26); pin <= SUNXI_GPA(27); pin++)
>   sunxi_gpio_set_cfgpin(pin, SUN6I_GPA_GMAC);
>  #endif
> -
> -#ifdef CONFIG_DM_ETH
> - return 0;
> -#else
> -# ifdef CONFIG_RGMII
> - return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_RGMII);
> -# elif defined CONFIG_GMII
> - return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_GMII);
> -# else
> - return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_MII);
> -# endif
> -#endif
>  }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: Sync dts files with the upstream kernel

[Ian Campbell]

On Mon, 2016-03-14 at 21:49 +0100, Hans de Goede wrote:
> Sync dts files with the upstream kernel including
> changes queued for 4.6:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/dt-for-4.6
> 
> Note this adds a number of new unused board dts files. I've asked the
> authors of the kernel commits adding these to submit a matching defconfig
> to u-boot.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Both patches here: Acked-by: Ian Campbell <i...@hellion.org.uk>

Do you have a script or something which (semi-)automates these imports,
or is it manual faff each time?

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts for Difrence DIT4350 tablet

[Ian Campbell]

On Thu, 2016-03-10 at 22:38 +0100, Hans de Goede wrote:
> The Difrnce dit4350 tablet is a tiny tablet with a 4.3" 16:9 480x272
> LCD,
> A13 SoC, 512M RAM, 4G NAND, solomon systech ssd2532qn6 touchscreen at
> i2c1 address 0x48, Memsic MXC622X accelerometer at i2c1 address 0x15
> and
> rtl8188etv wifi.
> 
> The dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: A23: Fix some revisions needing a different magic sram poke

[Ian Campbell]

On Wed, 2016-03-09 at 22:51 +0100, Hans de Goede wrote:
> -  * access gets messed up (seems cache related) */
> + /*
> +  * Undocmented magic taken from boot0, without this DRAM

"Undocumented" (ah. I see this was wrong before too, oops!)

Otherwise this and the second one:

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] kbuild: use $(call cmd, ) rather than $(call if_changed, ) where possible

[Ian Campbell]

On Fri, 2016-02-05 at 14:33 +0900, Masahiro Yamada wrote:
> >> These build commands are constant (mostly, just concatenating
> images,
> >> or just copying).  No need to use $(call if_changed,...) for them.
> >
> >
> > I disagree, since I believe this change means that if someone /does/ change
> > the command in the future (e.g. to replace it with more complex processing,
> > or add additional dependencies), then the Makefile will/may not
> > automatically rebuild those targets, which is the entire point of using
> > if_changed, and is a huge benefit of using Kbuild.
> 
> I do not a strong opinion about this, so
> I will drop 3/5 and submit v2.

I think the same logic applies to that part of the change in patch 2 as
well.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARMv8: Use U-Boot to boot Xen?

[Ian Campbell]

On Fri, 2016-01-29 at 12:04 +0800, Peng Fan wrote:
> Hi Dirk,
> 
> Cc Ian xen experts.
> 
> On Thu, Jan 28, 2016 at 08:06:30PM +0100, Dirk Behme wrote:
> > Hi,
> > 
> > are there any U-Boot examples/patches to boot Xen on an ARMv8/aarch64
> > system?
> > 
> > I've found
> > 
> > http://lists.denx.de/pipermail/u-boot/2015-October/230077.html
> > 
> > what might be helpful.
> > 
> > But maybe I missed anything else?
> 
> I guess you are asking steps how to boot xen using uboot?
> 
> You may need to take this:
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions

Indeed.

In addition one AArch64 system which uses u-boot and which has concrete
instructions is the APM X-Gene/Mustang:

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/APMXGeneMustang
which would likely be helpful. There are other ARMv7 systems linked from
the main page which would have other examples, but for 32-bit.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARMv8: Use U-Boot to boot Xen?

[Ian Campbell]

On Fri, 2016-01-29 at 16:54 +0100, Dirk Behme wrote:
> On 29.01.2016 10:18, Ian Campbell wrote:
> > On Fri, 2016-01-29 at 12:04 +0800, Peng Fan wrote:
> > > Hi Dirk,
> > > 
> > > Cc Ian xen experts.
> > > 
> > > On Thu, Jan 28, 2016 at 08:06:30PM +0100, Dirk Behme wrote:
> > > > Hi,
> > > > 
> > > > are there any U-Boot examples/patches to boot Xen on an
> > > > ARMv8/aarch64
> > > > system?
> > > > 
> > > > I've found
> > > > 
> > > > http://lists.denx.de/pipermail/u-boot/2015-October/230077.html
> > > > 
> > > > what might be helpful.
> > > > 
> > > > But maybe I missed anything else?
> > > 
> > > I guess you are asking steps how to boot xen using uboot?
> > > 
> > > You may need to take this:
> > > http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions
> > 
> > Indeed.
> > 
> > In addition one AArch64 system which uses u-boot and which has concrete
> > instructions is the APM X-Gene/Mustang:
> >  http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/AP
> > MXGeneMustang
> > which would likely be helpful.
> 
> 
> Yes, that page is very helpful, thanks!
> 
> But I think it misses one information, or most probably the 
> configuration on that board is different. Above page just do a 'run 
> xen_run' which in the end does the necessary tftp loading and finally 
> the bootm to start Xen.
> 
> So I'd assume that on that board U-Boot runs at EL3 or EL2 (?).
> 
> In my environment, U-Boot runs at EL1. I.e. after loading Xen by tftp 
> I somehow need to switch to EL2 to be able to start Xen.

Once you are in EL1 you cannot get back to EL2 (or EL3) without support
from a lower level firmware running in those exception levels. If you have
no such underlying firmware then you should arrange for u-boot to run at
EL3.

> 
> And this is what I think I miss. How to switch from U-Boot running at 
> EL1 to hypervisor mode EL2? Therefore I'd think that
> 
> http://lists.denx.de/pipermail/u-boot/2015-October/230077.html

You need to arrange for U-boot to run in EL3 and enter the "kernel" (Xen in
this case) in NS EL2. This likely means implementing the PSCI interface for
the kernel to use to manage CPUs.

If you were running on a 32-bit system I would direct you towards the
CONFIG_ARMV7_PSCI, CONFIG_ARMV7_NONSEC and ARMV7_VIRT u-boot options (which
in turn would require your platform code to provide some support). I'm not
sure what the equivalent for 64-bit is, sorry.

The link you post is, AFAICT, about the other end i.e. allowing u-boot to
talk to an existing secure world firmware beneath it.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Remove Orangepi PC RAM speed to 624 MHz

[Ian Campbell]

On Wed, 2015-12-23 at 11:50 +0100, Hans de Goede wrote:
> There are some reports of stability issues at 672 MHz, see:
> http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit

Looks like only one (in that table at least)? And do we expect this
data to remain in the wiki, I suppose so.

In any case, this...
> So reduce the DRAM speed to 624MHz which seems to be reliable
> everywhere.

...seems reasonable to me.

> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Select DM_KEYBOARD

[Ian Campbell]

On Mon, 2015-12-21 at 20:23 +0100, Hans de Goede wrote:
> We need to select DM_KEYBOARD now that the usb-kbd code has been
> converted
> to this, otherwise usb keyboards do not work.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sun5i: Add defconfig and dts file for the Empire Electronix D709 tablet

[Ian Campbell]

On Mon, 2015-12-21 at 20:38 +0100, Hans de Goede wrote:
> Hi,
> 
> On 20-12-15 21:12, Ian Campbell wrote:
> > On Sun, 2015-12-20 at 12:44 +0100, Hans de Goede wrote:
> >> The Empire Electronix D709 tablet is a fairly standard 7" A13
> tablet,
> >> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone
> >> jack.
> >>
> >> Empire Electronix is written on the back of the tablet, the D709
> >> model
> >> info can be found in the about tablet menu in android.
> >>
> >> The PCB has no markings to speak of.
> >>
> >> This dts file is identical to the one submitted to the upstream
> >> kernel.
> >>
> >> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> >
> > Acked-by: Ian Campbell <ian.campb...@citrix.com>
> 
> Thanks for the reviews, I've taken the liberty to update your
> email to your hellion address.

Bah, yes, that's right (damn finger macros...)

> 
> Regards,
> 
> Hans
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Add a new poweroff command and implement it for sunxi

[Ian Campbell]

On Sun, 2015-12-20 at 16:41 +0100, Hans de Goede wrote:
> Hi All,
> 
> I've had this idea that it would be good to have a poweroff command in
> u-boot in my head for a while now. The reason being that during u-boot
> development one often stays in just u-boot (e.g. when testing usb kbd
> support), when I'm then done testing having a poweroff command would
> be useful, esp. on devices with builtin batteries like tablets where
> one cannot just pull the powerplug.

Patches #2..#4: Acked-by: Ian Campbell <i...@hellion.org.uk>

#1 looks fine to me too, modulo Tom's comments.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sun5i: Add defconfig and dts file for the Empire Electronix D709 tablet

[Ian Campbell]

On Sun, 2015-12-20 at 12:44 +0100, Hans de Goede wrote:
> The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone
> jack.
> 
> Empire Electronix is written on the back of the tablet, the D709
> model
> info can be found in the about tablet menu in android.
> 
> The PCB has no markings to speak of.
> 
> This dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <ian.campb...@citrix.com>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ATAGS for Tegra, Sunxi, etc.

[Ian Campbell]

On Thu, 2015-12-17 at 07:40 +0100, Karsten Merker wrote:
> On Thu, Dec 17, 2015 at 01:59:57PM +0900, Masahiro Yamada wrote:
> > 2015-12-17 13:58 GMT+09:00 Masahiro Yamada  > om>:
> > > Hi,
> > > 
> > > I noticed some well-maintained new SoC families still
> > > define CONFIG_CMDLINE_TAG.
> > > 
> > > 
> > > For example,
> [...]
> > > include/configs/sunxi-common.h
> > > 
> > >  #define CONFIG_SETUP_MEMORY_TAGS
> > >  #define CONFIG_CMDLINE_TAG
> > >  #define CONFIG_INITRD_TAG
> > >  #define CONFIG_SERIAL_TAG
> 
> > > Do they still use ATAGS, not device tree?
> 
> Sunxi uses devicetree for mainline kernels, but AFAIK ATAG
> support is necessary to enable booting legacy vendor kernels.
> There is still new sunxi-based hardware sold today that comes
> with legacy 3.4-based kernels.

That legacy kernel is FEX (allwinners own description blob) based, I don't
know to what extent that involves ATAGs in some way though.

There are also people who use the 3.4 based fork from linux-sunxi.org, but
I don't know if that is DT or ATAGS or FEX.

A dependency on CONFIG_OLD_SUNXI_KERNEL_COMPAT might be an option depending
on what the kernels need, Hans probably knows better than I do.

Ian.

> CCing Hans de Goede and Ian Cambell (sunxi maintainers).

> 
> Regards,
> Karsten
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Set AHB1 clock to PLL6/3 on all clock_sun6i.h using SoCs

[Ian Campbell]

On Mon, 2015-11-23 at 14:47 +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Sun, Nov 22, 2015 at 11:40 PM, Hans de Goede <hdego...@redhat.com>
> wrote:
> > Hi,
> >
> > On 22-11-15 15:14, Chen-Yu Tsai wrote:
> >>
> >> On Sat, Nov 21, 2015 at 11:48 PM, Ian Campbell <
> ijc+ub...@hellion.org.uk>
> >> wrote:
> >>>
> >>> On Fri, 2015-11-20 at 19:32 +0100, Hans de Goede wrote:
> >>>>
> >>>> According to the datasheets the max speed of AHB1 is 276 MHz, so
> >>>> setting it to PLL6 / 3 which gives us 200MHz everywhere is fine,
> >>>> and gives us a nice speed-up in certain workloads.
> >>>>
> >>>> Suggested-by: Chen-Yu Tsai <w...@csie.org>
> >>>> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> >>>
> >>>
> >>> I suppose you've tested this on at least one such board? In that
> case:
> >>> Acked-by: Ian Campbell <i...@hellion.org.uk>
> >>
> >>
> >> I've tested this on some of my boards. It works fine on my
> Hummingbird A31
> >> and A23 Q8 tablet. However my Sinlinx SinA33 is giving me kernel
> Oops
> >> which
> >> I haven't looked into yet.
> >
> >
> > Works for me on a q8 A33 tablet. But lets investigate your oops
> before
> > including
> > this in the next pull-req. Thanks for the testing!
> 
> I retested it with a proper clean build, and it works now. No idea
> what
> the oops was about.
> 
> Also tested on my Sinlinx SinA31s. So it now works on all my sun6i
> generation
> boards.
> 
> Tested-by: Chen-Yu Tsai <w...@csie.org>

Good enough for me, my original Ack stands...

> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Set AHB1 clock to PLL6/3 on all clock_sun6i.h using SoCs

[Ian Campbell]

On Fri, 2015-11-20 at 19:32 +0100, Hans de Goede wrote:
> According to the datasheets the max speed of AHB1 is 276 MHz, so
> setting it to PLL6 / 3 which gives us 200MHz everywhere is fine,
> and gives us a nice speed-up in certain workloads.
> 
> Suggested-by: Chen-Yu Tsai <w...@csie.org>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

I suppose you've tested this on at least one such board? In that case:
Acked-by: Ian Campbell <i...@hellion.org.uk>

> ---
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index 09337a1..5c76275 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -220,11 +220,7 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL11_CTRL_UPD   (0x1 << 30)
>  #define CCM_PLL11_CTRL_EN(0x1 << 31)
>  
> -#if defined CONFIG_MACH_SUN8I_H3
>  #define AHB1_ABP1_DIV_DEFAULT0x3180 /*
> AHB1=PLL6/3,APB1=AHB1/2 */
> -#else
> -#define AHB1_ABP1_DIV_DEFAULT0x2020 /*
> AHB1=AXI/4, APB1=AHB1/2 */
> -#endif
>  
>  #define AXI_GATE_OFFSET_DRAM 0
>  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] musb: sunxi: Implement dfu_usb_get_reset()

[Ian Campbell]

On Sun, 2015-10-25 at 22:16 +0100, Albert ARIBAUD wrote:
> Hello Ian,
> 
> On Sun, 25 Oct 2015 19:22:00 +0000, Ian Campbell
> <ijc+ub...@hellion.org.uk> wrote:
> > On Sun, 2015-10-25 at 14:22 +0100, Albert ARIBAUD wrote:
> > > On Sun, 25 Oct 2015 12:40:45 +, Ian Campbell
> > > > Doesn't the bool return type already cause that to happen?
> (from the
> > > > PoV of the caller at least)
> > > 
> > > When all is said and done, a C bool is a C int,
> > 
> > Not if it is a _Bool (via stdbool.h or some other way).
> > 
> > A _Bool is always either 0 or 1, and scalar value which is
> converted to
> > a _Bool is converted to either 0 or 1.
> >
> > > So no, types, bool or otherwise, do not cause any implicit '!!'
> to
> > > happen.
> > 
> > I believe this is not correct when _Bool is used.
> > 
> > In u-boot a bool is indeed a _Bool (or at least I don't see any
> other
> > typedef's and I can see various includes on stdbool.h, I therefore
> > didn't feel the need to check how bool is arrived at in this
> particular
> > file).
> 
> What you write is possibly correct for C++, but certainly not for C,
> for which booleans are integers, with no compiler-enforced constraint
> on their value domains.

I know next to nothing about C++ so I am certainly not confusing things
with that.

The _Bool type in C99 is an integer which may take on exactly the
values 0 or 1. Since the code which started this subthread was using
"bool" from  it is _Bool which is being discussed here.

The actual standard costs money (and is therefore unlinkable) but 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf is a late
draft and I believe this aspect is unchanged. Section 6.3.1.2 is one
relevant part explaining that a _Bool must always be either 0 or 1:

When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1.

Many of the other clauses dealing with Integers (e.g. 6.3.1.3.1) have
had "other than _Bool" or some similar wording added to them since
_Bool does indeed behave a little differently.

So I'm afraid I disagree with your statement, at least for C >= C99 (I
can't recall if _Bool was in C89, but I think the answer is no).

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] musb: sunxi: Implement dfu_usb_get_reset()

[Ian Campbell]

On Sun, 2015-10-25 at 12:46 +0100, Albert ARIBAUD wrote:
> > > +static u8 last_int_usb;
> > > +
> > > +bool dfu_usb_get_reset(void)
> > > +{
> > > + return !!(last_int_usb & MUSB_INTR_RESET);
> > 
> > The !! is not needed.
> 
> Except if you want to be sure that you return 0 or 1 rather than 0 or
> (1 << something).

Doesn't the bool return type already cause that to happen? (from the
PoV of the caller at least)

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] musb: sunxi: Implement dfu_usb_get_reset()

[Ian Campbell]

On Sun, 2015-10-25 at 16:46 +0200, Siarhei Siamashka wrote:
> replace "#include " with "typedef int bool;" and try it
> again.

So don't do that then.

In u-boot the "bool" type comes from stdbool.h and it is therefore
completely reasonable to assume that bool in u-boot has the properties
which this implies.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] musb: sunxi: Implement dfu_usb_get_reset()

[Ian Campbell]

On Sun, 2015-10-25 at 14:22 +0100, Albert ARIBAUD wrote:
> On Sun, 25 Oct 2015 12:40:45 +0000, Ian Campbell
> > Doesn't the bool return type already cause that to happen? (from the
> > PoV of the caller at least)
> 
> When all is said and done, a C bool is a C int,

Not if it is a _Bool (via stdbool.h or some other way).

A _Bool is always either 0 or 1, and scalar value which is converted to
a _Bool is converted to either 0 or 1.

> So no, types, bool or otherwise, do not cause any implicit '!!' to
> happen.

I believe this is not correct when _Bool is used.

In u-boot a bool is indeed a _Bool (or at least I don't see any other
typedef's and I can see various includes on stdbool.h, I therefore
didn't feel the need to check how bool is arrived at in this particular
file).

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Ian Campbell]

On Mon, 2015-10-19 at 13:42 +0200, Hans de Goede wrote:
> 
> I'm sorry but I'm not going to budge on this one, having
> CONFIG_OLD_SUNXI_KERNEL_COMPAT=y in a defconfig is simply not acceptable
> IMHO. It is not a board specific thing, and there are very good reasons
> why it defaults to n in board/sunxi/Kconfig

Agreed.

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Ian Campbell]

On Mon, 2015-10-19 at 13:44 +0200, Hans de Goede wrote:
> > Okay. Hans, do you want me to change this (and potential other
> > changes as well - see file naming above) via a follow-up patch
> > once its available in mainline U-Boot?
> 
> Actually I would prefer to get this right in one go, esp. the
> filename bits, having u-boot and the kernel disagreeing on the
> dtb filename is no good. So I plan to remove this version of
> the patch from u-boot-sunxi/next for now. Once you and Maxime
> agree on a dts / dtb filename please submit a new version and
> I'll merge that one instead.

Wasn't our policy supposed to be that we (u-boot) would only take DTS
files which were at least on their way to mainline Linux (i.e. in
Maxime's tree)?

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] sunxi: Add defconfig for the Sinovoip BPI-M2 board

[Ian Campbell]

On Thu, 2015-10-15 at 16:33 +0200, Hans de Goede wrote:
> The Sinovoip BPI-M2 is a SBC board based on the A31s SoC it features
> 1G RAM, a microsd slot, Gbit ethernet, 4 usb-a USB-2 ports, ir
> receiver,
> stereo headphone jack and hdmi video output.
> 
> The dts changes are identical to the dts files submitted upstream.
> 
> A few notes on the use if dldo and aldo regulators. DLDO1 is used
> for Vdd for the ethernet phy, ALDO2 is used for AVdd for the ethernet
> phy. ALDO1 is used to power the sdio wifi module.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

and for the 1/2 as well, which hardly needs an ack IMHO.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 12/14] sunxi: Add support for android boot image

[Ian Campbell]

On Thu, 2015-10-15 at 14:34 +0200, Maxime Ripard wrote:
> When using the fastboot boot command, the image sent to U-Boot will be an
> Android boot image. If the support is missing, that won't obviously work,

  obviously won't ??

> so we need it in our configuration.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

> ---
>  include/configs/sunxi-common.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi
> -common.h
> index e1ba7914cda1..d7fc9ea7d099 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -347,6 +347,7 @@ extern int soft_i2c_gpio_scl;
>  #define CONFIG_CMD_FASTBOOT
>  #define CONFIG_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR
>  #define CONFIG_FASTBOOT_BUF_SIZE 0x200
> +#define CONFIG_ANDROID_BOOT_IMAGE
>  
>  #define CONFIG_FASTBOOT_FLASH
>  #define CONFIG_FASTBOOT_FLASH_MMC_DEV0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add a bootcmd_old to the default environment to boot old kernels

[Ian Campbell]

On Fri, 2015-10-09 at 18:15 +0200, Hans de Goede wrote:
> Add a bootcmd_old value to the default environment when building with
> CONFIG_OLD_SUNXI_KERNEL_COMPAT, this way people who occasionally want
> to boot an old kernel can do so by simply typing "run bootcmd_old"
> rather then needing to have 2 separe setups / sdcards for old and

"separate"?


"old" is a bit non-specific (e.g. there are also old mainline kernels).
Perhaps bootcmd_sunxi_compat? It's a bit of a mouthful but it will tab
complete bsun or close to that.

> +#ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT
> +#define BOOTCMD_OLD \
> + "root=/dev/mmcblk0p3 rootwait\0" \

Does something other than the below setenv bootargs rely on this? It'd
be better not to pollute the default env with such a generically named
thing. I suggest following the naming of the command, so
root_sunxi_compat.

If it is important to have root= present e.g. for script.bin or
uEnv.txt then perhaps put setenv root ${root_sunxi_compat} at the start
of the command?

> + "bootcmd_old=" \
> + "if ext2load mmc 0 0x4400 uEnv.txt; then " \
> + "echo Loaded environment from uEnv.txt; " \
> + "env import -t 0x4400 ${filesize}; " \
> + "fi; " \
> + "setenv bootargs console=${console} root=${root}
> ${extraargs}; " \
> + "ext2load mmc 0 0x4300 script.bin && " \
> + "ext2load mmc 0 0x4800 uImage && " \
> + "bootm 0x4800\0"
> +#else
> +#define BOOTCMD_OLD
> +#endif
> +
>  #include 
>  
>  #ifdef CONFIG_USB_KEYBOARD
> @@ -495,6 +511,7 @@ extern int soft_i2c_gpio_scl;
>   MTD_ENV_SETTINGS \
>   "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
>   "console=ttyS0,115200\0" \
> + BOOTCMD_OLD \
>   BOOTENV
>  
>  #else /* ifndef CONFIG_SPL_BUILD */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: Kconfig-ify CONFIG_AXP152_POWER and _AXP209_POWER

[Ian Campbell]

On Sat, 2015-10-10 at 14:24 +0200, Hans de Goede wrote:
> [...]
> + Select this to enable support for the axp152 pmic found on
most
> + A10s boards.
> [...]
> + Select this to enable support for the axp209 pmic found on most
> + A10, A13 and A20 boards.
> [...]
> + Select this to enable support for the axp221/axp223 pmic found on most
>   sun6i (A31) / sun8i (A23) boards.

Some inconsistency with the SoC naming ["Axx" vs "sunxi (Axx)"], but
nonetheless:

Acked-by: Ian Campbell <i...@hellion.org.uk>

Feel free to retain if adding the appropriate sunXi to the first two or
removing them from the 3rd as you like.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] sunxi: power: Unify axp pmic function names

[Ian Campbell]

On Sat, 2015-10-03 at 16:26 +0200, Hans de Goede wrote:
> Stop prefixing the axp functions for setting voltages, etc. with the
> model number, there ever is only one pmic driver built into u-boot,
> this allows simplifying the callers.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

@@ -1217,10 +1217,10 @@ static void sunxi_mode_set(const struct
> ctfb_res_modes *mode,
>  >>   > if 
> (IS_ENABLED(CONFIG_VIDEO_LCD_PANEL_EDP_4_LANE_1620M_VIA_ANX9804)) {
>  >>   >   > /*
>  >>   >   >  * The anx9804 needs 1.8V from eldo3, we do this here
> ->>   >   >  * and not via CONFIG_AXP221_ELDO3 from board_init()
> +>>   >   >  * and not via CONFIG_AXP_ELDO3_VOLT from board_init()

I think strictly speaking that hunk belonged in a previous patch, but
nevermind (or feel to retain acks on both if you want to move it).

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: Add a bootcmd_sunxi_compat to the default environment to boot old kernels

[Ian Campbell]

On Sun, 2015-10-11 at 12:47 +0200, Hans de Goede wrote:
> Add a bootcmd_sunxi_compat value to the default environment when
> building
> with CONFIG_OLD_SUNXI_KERNEL_COMPAT, this way people who occasionally
> want
> to boot an old kernel can do so by simply typing "run
> bootcmd_sunxi_compat"
> rather then needing to have 2 separate setups / sdcards for old and
> new kernels.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sunxi: power: Add support for disabling axp209 regulators

[Ian Campbell]

On Sat, 2015-10-10 at 14:40 +0200, Hans de Goede wrote:
> Add support for disabling the regulators found on the axp209 pmic.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

All 3 patches in this series: Acked-by: Ian Campbell <i...@hellion.org.uk>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] sunxi: power: Change A23/A33 VDD-SYS default from 1.2V to 1.1V

[Ian Campbell]

On Sat, 2015-10-03 at 16:26 +0200, Hans de Goede wrote:
> Change the axp223 dcdc2 / VDD-SYS default from 1.2V to 1.1V, 1.1V is the
> value recommended by Allwinner and is what most fex files specify.
> 
> This has been tested on a number of A23/A33 tablets including on an
> A23 Ippo-q8h-v1.2 PCB tablet which has a fex file which specifies 1.2V
> (which is where our original 1.2V default comes from).
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] sunxi: power: Unify axp pmic function names

[Ian Campbell]

On Sat, 2015-10-03 at 22:16 +0200, Hans de Goede wrote:
> Hi,
> 
> On 03-10-15 16:32, Chen-Yu Tsai wrote:
> > On Sat, Oct 3, 2015 at 10:26 PM, Hans de Goede 
> > wrote:
> > > Stop prefixing the axp functions for setting voltages, etc. with the
> > > model number, there ever is only one pmic driver built into u-boot,
> > > this allows simplifying the callers.
> > 
> > Hmm... What's going to happen with the A80, which has 2 PMICs? IIRC
> > a subset of their LDOs share the same name, which would be a problem.
> 
> My plan for that is to use a different function name for the ldo-s
> on the secondary pmic, e.g. something like axp2_set_xldo1(...), or
> somesuch. Actually this patch should help adding support for the
> other pmics since it will make it less of an #ifdef fest.

Is it going to be (or very likely to be) the case that a given AXPxxx
device will only ever be a primary or a secondary,  but never used as both
(perhaps on different boards)?

Is there some property of these devices which causes them to be only usable
as one or the other?

If there is some possibility of this not being the case then this
unification + my comments on patch #1 might be seen in a different light.

Having a board which uses two of the same AXPxxx device looks like it would
be even more problematic, if such a thing is possible.

Or is the plan to just cross that bridge if/when we get there? (I think I'm
 OK with that).

Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/7] sunxi: power: Drop protection against multiple calls from axp221 axp_init()

[Ian Campbell]

On Sat, 2015-10-03 at 16:26 +0200, Hans de Goede wrote:
> The only thing axp221.c's axp_init() does which needs protection
> against multiple calls is calling pmic_bus_init, and pmic_bus_init()
> itself is already protected against being called multiple times.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Ian Campbell <i...@hellion.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot