Re: [linux-sunxi] [PATCH] ARM: dts: sun8i: Add dts file for NanoPi NEO Air
On Tue, Feb 07, 2017 at 05:08:16AM +0800, Icenowy Zheng wrote: > > 2017年2月7日 03:14于 Jelle van der Waa 写道： > > > > add support for the NanoPi NEO Air H3 board from friendlyarm.com . This > > board contains WiFi, Bluetooth, 8GB eMMC storage and 512 MB DDR3 ram. > > Is WiFi/BT/eMMC really enabled in this DT? It's not what is said either. It says that this board has wifi and BT, which is true. The current state of the DT doesn't change that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [linux-sunxi] [PATCH] Add the Allwinner A31/A31s PWM driver.
On Sat, Feb 4, 2017 at 10:55 PM, wrote: > From: Siarhei Volkau > > A31 SoC have a different map of PWM registers than others Allwinner > SoCs, so the operation of access to the registers reworked for all > existing in driver SoCs. > > Tested on Onda V972 (a31) and Marsboard A20, but only PWM > channel 0, because other channels pins are not routed or > have another function on these boards. > > Signed-off-by: Siarhei Volkau Please use scripts/get_maintainers.pl in the kernel tree to get the relevant list of maintainers and mailing lists you should send this patch to. Not having them means a) no proper public record of reviews and acceptance, and b) maintainers that are supposed to ack and/or merge the patch will not know about it. ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] ARM: dts: sun8i: Add dts file for NanoPi NEO Air
On Tue, Feb 7, 2017 at 5:08 AM, Icenowy Zheng wrote:
>
> 2017年2月7日 03:14于 Jelle van der Waa 写道：
>>
>> add support for the NanoPi NEO Air H3 board from friendlyarm.com . This
>> board contains WiFi, Bluetooth, 8GB eMMC storage and 512 MB DDR3 ram.
>
> Is WiFi/BT/eMMC really enabled in this DT?
>
>>
>> Signed-off-by: Jelle van der Waa
>> ---
>> arch/arm/boot/dts/Makefile| 1 +
>> arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts | 117
>> ++
>> 2 files changed, 118 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index f10fe8526239..5e1361e704f5 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -848,6 +848,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>> sun8i-h3-bananapi-m2-plus.dtb \
>> sun8i-h3-nanopi-m1.dtb \
>> sun8i-h3-nanopi-neo.dtb \
>> + sun8i-h3-nanopi-neo-air.dtb \
>> sun8i-h3-orangepi-2.dtb \
>> sun8i-h3-orangepi-lite.dtb \
>> sun8i-h3-orangepi-one.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
>> b/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
>> new file mode 100644
>> index ..2387bb143b65
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
>> @@ -0,0 +1,117 @@
>> +/*
>> + * Copyright (C) 2017 Jelle van der Waa
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include
>> +#include
>> +
>> +/ {
>> + model = "FriendlyARM NanoPi NEO Air";
>> + compatible = "friendlyarm,nanopi-neo-air", "allwinner,sun8i-h3";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&leds_nanopi_neo>, <&leds_r_nanopi_neo>;
>> +
>> + pwr {
>> + label = "nanopi:green:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
>> + default-state = "on";
>> + };
>> +
>> + status {
>> + label = "nanopi:blue:status";
>> + gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>; /* PA10 */
>> + };
>> + };
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&pio {
>> + leds_nanopi_neo: led-pins {
>> + allwinner,pins = "PA10";
>> + allwinner,function = "gpio_out";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +};
>> +
>> +&r_pio {
>> + leds_r_nanopi_neo: led-pins {
>> + allwinner,pins = "PL10";
>> + allwinner,function = "gpio_out";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +};
>
> New DTs shouldn't use the obsolute allwinner,-prefixed pinctrl properties,
> and GPIO pinctrl nodes are also expected to be dropped. (
[linux-sunxi] [PATCH] ARM: dts: sun8i: Add dts file for NanoPi NEO Air
add support for the NanoPi NEO Air H3 board from friendlyarm.com . This
board contains WiFi, Bluetooth, 8GB eMMC storage and 512 MB DDR3 ram.
Signed-off-by: Jelle van der Waa
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts | 117 ++
2 files changed, 118 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f10fe8526239..5e1361e704f5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -848,6 +848,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
+ sun8i-h3-nanopi-neo-air.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
sun8i-h3-orangepi-one.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
b/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
new file mode 100644
index ..2387bb143b65
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2017 Jelle van der Waa
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "FriendlyARM NanoPi NEO Air";
+ compatible = "friendlyarm,nanopi-neo-air", "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_nanopi_neo>, <&leds_r_nanopi_neo>;
+
+ pwr {
+ label = "nanopi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+ default-state = "on";
+ };
+
+ status {
+ label = "nanopi:blue:status";
+ gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>; /* PA10 */
+ };
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&pio {
+ leds_nanopi_neo: led-pins {
+ allwinner,pins = "PA10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+};
+
+&r_pio {
+ leds_r_nanopi_neo: led-pins {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ stat
[linux-sunxi] Re: [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)
Hi Andrew,
On 06/02/17 16:17, Andrew F. Davis wrote:
> On 02/06/2017 09:33 AM, Simon Glass wrote:
>> Hi Andre,
>>
>> On 27 January 2017 at 17:47, André Przywara wrote:
>>> On 27/01/17 21:29, Simon Glass wrote:
>>>
>>> Hi Simon,
>>>
On 19 January 2017 at 18:53, Andre Przywara wrote:
> Currently the FIT format is not used to its full potential in the SPL:
> It only loads the first image from the /images node and appends the
> proper FDT.
> Some boards and platforms would benefit from loading more images before
> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
> which use an ARM Trusted Firmware (ATF) image to be executed before
> U-Boot.
>
> This series tries to solve this in a board agnostic and generic way:
> We extend the SPL FIT loading scheme to allow loading multiple images.
> So apart from loading the image which is referenced by the "firmware"
> property in the respective configuration node and placing the DTB right
> behind it, we iterate over all strings in the "loadable" property.
> Each image referenced there will be loaded to its specified load address.
> The entry point U-Boot eventually branches to will be taken from the
> first image to explicitly provide the "entry" property, or, if none
> of them does so, from the load address of the "firmware" image.
> This keeps the scheme compatible with the FIT images our Makefile creates
> automatically at the moment.
>
> Apart from the already mentioned ATF scenario this opens up more usage
> scenarios, of which the commit message of patch 04/11 lists some.
>
> The first three patches rework the SPL FIT support to be more flexible
> and to allow easier usage in the fourth patch, which introduces the
> multiple-image loading facility.
> The remaining patches enable that support for the Pine64 board to make
> its SPL support finally useful and to demonstrate usage of this scheme:
> patches 5-7 extend the usable SPL size by about 4 KB to allow AArch64
> compilation of the SPL with FIT support enabled. Patch 8 implements the
> board selector routine, which selects either the Pine64 or Pine64+ DTB
> depending on the detected DRAM size. Patch 9 enables SPL FIT support in
> the Pine64 defconfig.
> To demonstrate the usage, patch 10 provides a FIT source file, which
> loads and executes ATF before the U-Boot proper. Users are expected to
> compile this with "mkimage -f boards/sunxi/pine64_atf.its -E pine64.itb",
> then write the resulting file behind the SPL on an SD card (or any other
> U-Boot supported boot media, for that matter).
> Patch 11 then adds FIT support to the sunxi SPL SPI loading routine,
> which allows to load ATF on boards with SPI flash as well.
>
> Questions:
> 1) Is this scheme the right one (usage of "firmware" and "loadables",
>determination of entry point)? Shall we make use of the "setup"
>property?
Seems reasonable to me.
> 2) Shall we extend mkimage to allow supplying "loadable" files on the
>command line, which would allow to build the .itb file automatically?
Yes.
>>>
>>> I was thinking about this a bit more, as Andrew pointed out before it
>>> may become hairy to add tons of options to mkimage.
>>> I came up with a simple shell script, mostly using here documents
>>> (cat << _EOF) to generate the .its file on the fly, adding all DTs given
>>> on the command line. It's pretty easy, yet readable and adaptable. So
>>> each platform could provide one, if needed, and could hard code things
>>> like ATF in here.
>>
>> That sounds reasonable. But I do think it is valuable to support the
>> basic case without needing a script, so long as you can do it with
>> only a few mkimage options?
>>
>
> We already have a few mkimage option for auto-generating FIT for basic
> cases (Executable and DTBs). I've seen internally confusion caused by
> having mkimage accept dtb's on the command-line while we work to add
> more complex FIT schemes. I think our time is best spent working on
> simplifying generating custom .its files during build, and less on
> patching mkimage to support increasingly complex build configurations.
>
> How about we have template .its files for platforms and for simple build
> cases, then simply define a way to fill in these using mkimage:
>
>> / {
>> description = "U-Boot fitImage for PlatformX";
>> #address-cells = <1>;
>>
>> images {
>> u-boot@1 {
>> description = "U-Boot";
>> data = /incbin/("u-boot.bin");
>> arch = "arm";
>> load = <[u_boot_load]>;
>> };
>> [dtb_name] {
>> description = "Flattened Device Tree blob";
>> data = /incbin/("arch/arm/boot/dts
[linux-sunxi] Re: [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)
Hi Simon, On 06/02/17 15:33, Simon Glass wrote: > Hi Andre, > > On 27 January 2017 at 17:47, André Przywara wrote: >> On 27/01/17 21:29, Simon Glass wrote: >> >> Hi Simon, >> >>> On 19 January 2017 at 18:53, Andre Przywara wrote: Currently the FIT format is not used to its full potential in the SPL: It only loads the first image from the /images node and appends the proper FDT. Some boards and platforms would benefit from loading more images before starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards, which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot. This series tries to solve this in a board agnostic and generic way: We extend the SPL FIT loading scheme to allow loading multiple images. So apart from loading the image which is referenced by the "firmware" property in the respective configuration node and placing the DTB right behind it, we iterate over all strings in the "loadable" property. Each image referenced there will be loaded to its specified load address. The entry point U-Boot eventually branches to will be taken from the first image to explicitly provide the "entry" property, or, if none of them does so, from the load address of the "firmware" image. This keeps the scheme compatible with the FIT images our Makefile creates automatically at the moment. Apart from the already mentioned ATF scenario this opens up more usage scenarios, of which the commit message of patch 04/11 lists some. The first three patches rework the SPL FIT support to be more flexible and to allow easier usage in the fourth patch, which introduces the multiple-image loading facility. The remaining patches enable that support for the Pine64 board to make its SPL support finally useful and to demonstrate usage of this scheme: patches 5-7 extend the usable SPL size by about 4 KB to allow AArch64 compilation of the SPL with FIT support enabled. Patch 8 implements the board selector routine, which selects either the Pine64 or Pine64+ DTB depending on the detected DRAM size. Patch 9 enables SPL FIT support in the Pine64 defconfig. To demonstrate the usage, patch 10 provides a FIT source file, which loads and executes ATF before the U-Boot proper. Users are expected to compile this with "mkimage -f boards/sunxi/pine64_atf.its -E pine64.itb", then write the resulting file behind the SPL on an SD card (or any other U-Boot supported boot media, for that matter). Patch 11 then adds FIT support to the sunxi SPL SPI loading routine, which allows to load ATF on boards with SPI flash as well. Questions: 1) Is this scheme the right one (usage of "firmware" and "loadables", determination of entry point)? Shall we make use of the "setup" property? >>> >>> Seems reasonable to me. >>> 2) Shall we extend mkimage to allow supplying "loadable" files on the command line, which would allow to build the .itb file automatically? >>> >>> Yes. >> >> I was thinking about this a bit more, as Andrew pointed out before it >> may become hairy to add tons of options to mkimage. >> I came up with a simple shell script, mostly using here documents >> (cat << _EOF) to generate the .its file on the fly, adding all DTs given >> on the command line. It's pretty easy, yet readable and adaptable. So >> each platform could provide one, if needed, and could hard code things >> like ATF in here. > > That sounds reasonable. But I do think it is valuable to support the > basic case without needing a script, so long as you can do it with > only a few mkimage options? Well, the problem is that aside from the loadable name we would need to communicate at least the load address, probably also the entry point. So we could go with: $ mkimage ... -l 0x123400:some.img -l 0x876500:another.img to specify at least the load address, but that wouldn't cover entry points or other parameters. I think at this point it becomes a bit messy. My understanding is that using FDT as the base for a FIT image allows us to flexibly describe this in a source file, so we should use that features instead of stuffing more special cases into mkimage. My current thinking is: - there can be a CONFIG_FIT_SOURCE variable, which points to a board (or platform) specific .its source - there can be a CONFIG_FIT_GENERATOR symbol, which points to a generator _script_ The Makefile checks for either of those and generates the image file accordingly. In case it calls the generator script, it passes CONFIG_OF_LIST (or other parameters). I am in the process of stuffing this into the Makefile, which is not fun, really ;-) So what do you think: Is it still worth to enhance mkimage? I would prototype this CONFIG_FIT_ approach now and we can discuss this in the series, then, I guess. Cheers, Andre. -- You received this message beca
[linux-sunxi] Re: [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)
Hi Andre, On 27 January 2017 at 17:47, André Przywara wrote: > On 27/01/17 21:29, Simon Glass wrote: > > Hi Simon, > >> On 19 January 2017 at 18:53, Andre Przywara wrote: >>> Currently the FIT format is not used to its full potential in the SPL: >>> It only loads the first image from the /images node and appends the >>> proper FDT. >>> Some boards and platforms would benefit from loading more images before >>> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards, >>> which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot. >>> >>> This series tries to solve this in a board agnostic and generic way: >>> We extend the SPL FIT loading scheme to allow loading multiple images. >>> So apart from loading the image which is referenced by the "firmware" >>> property in the respective configuration node and placing the DTB right >>> behind it, we iterate over all strings in the "loadable" property. >>> Each image referenced there will be loaded to its specified load address. >>> The entry point U-Boot eventually branches to will be taken from the >>> first image to explicitly provide the "entry" property, or, if none >>> of them does so, from the load address of the "firmware" image. >>> This keeps the scheme compatible with the FIT images our Makefile creates >>> automatically at the moment. >>> >>> Apart from the already mentioned ATF scenario this opens up more usage >>> scenarios, of which the commit message of patch 04/11 lists some. >>> >>> The first three patches rework the SPL FIT support to be more flexible >>> and to allow easier usage in the fourth patch, which introduces the >>> multiple-image loading facility. >>> The remaining patches enable that support for the Pine64 board to make >>> its SPL support finally useful and to demonstrate usage of this scheme: >>> patches 5-7 extend the usable SPL size by about 4 KB to allow AArch64 >>> compilation of the SPL with FIT support enabled. Patch 8 implements the >>> board selector routine, which selects either the Pine64 or Pine64+ DTB >>> depending on the detected DRAM size. Patch 9 enables SPL FIT support in >>> the Pine64 defconfig. >>> To demonstrate the usage, patch 10 provides a FIT source file, which >>> loads and executes ATF before the U-Boot proper. Users are expected to >>> compile this with "mkimage -f boards/sunxi/pine64_atf.its -E pine64.itb", >>> then write the resulting file behind the SPL on an SD card (or any other >>> U-Boot supported boot media, for that matter). >>> Patch 11 then adds FIT support to the sunxi SPL SPI loading routine, >>> which allows to load ATF on boards with SPI flash as well. >>> >>> Questions: >>> 1) Is this scheme the right one (usage of "firmware" and "loadables", >>>determination of entry point)? Shall we make use of the "setup" >>>property? >> >> Seems reasonable to me. >> >>> 2) Shall we extend mkimage to allow supplying "loadable" files on the >>>command line, which would allow to build the .itb file automatically? >> >> Yes. > > I was thinking about this a bit more, as Andrew pointed out before it > may become hairy to add tons of options to mkimage. > I came up with a simple shell script, mostly using here documents > (cat << _EOF) to generate the .its file on the fly, adding all DTs given > on the command line. It's pretty easy, yet readable and adaptable. So > each platform could provide one, if needed, and could hard code things > like ATF in here. That sounds reasonable. But I do think it is valuable to support the basic case without needing a script, so long as you can do it with only a few mkimage options? [..] Regards, Simon -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v3 04/13] sunxi: simplify ACTLR.SMP bit set #ifdef
Hi, On 03/02/17 10:52, Jagan Teki wrote: > On Wed, Feb 1, 2017 at 2:36 AM, Andre Przywara wrote: >> Instead of enumerating all SoC families that need that bit set, let's >> just express this more clearly: The SMP bits needs to be set on >> SMP capable ARMv7 CPUs. It's much easier in Kconfig to express it the >> other way round, so we use ! CPU_IS_UP and ! ARM64. >> >> Signed-off-by: Andre Przywara >> Acked-by: Maxime Ripard >> --- >> arch/arm/Kconfig| 4 >> arch/arm/mach-sunxi/board.c | 5 + >> board/sunxi/Kconfig | 2 ++ >> 3 files changed, 7 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index fc36723..98791c0 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -126,6 +126,10 @@ config ENABLE_ARM_SOC_BOOT0_HOOK >> ARM_SOC_BOOT0_HOOK which contains the required assembler >> preprocessor code. >> >> +config ARM_CORTEX_CPU_IS_UP >> + bool >> + default n > > Better to place this in sunxi, since no other code using this expect > sunxi and the name CORTEX may also refer arm64 use something 32 > related. Sigh, can you please check back with Maxime on what's the right thing here? http://lists.denx.de/pipermail/u-boot/2017-January/279417.html If it's about the name, shall we use ARM_CORTEX_V7_CPU_IS_UP? I was briefly tempted to unify all ACTLR.SMP bit sets from all over the ARM code, but this looks like a can of worms to me, so I'd rather keep this one closed. Cheers, Andre. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v3 12/13] sunxi: dts: add basic OrangePi PC 2 device tree file
Hi, On 03/02/17 11:14, Jagan Teki wrote: > On Wed, Feb 1, 2017 at 2:36 AM, Andre Przywara wrote: >> The OrangePi PC 2 is a typical SBC with the 64-bit Allwinner H5 SoC. >> Create a new .dts file for it by including the (32-bit) H3 SoC .dtsi >> and changing the differing components accordingly. >> This is a preliminary device tree mostly for U-Boot's own sake, it >> is expected to be updated once the official DT gets accepted upstream. >> >> Signed-off-by: Andre Przywara >> --- >> arch/arm/dts/Makefile | 2 + >> arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 147 >> > > Please squash 13/13 with this, I would see a single patch for initial support. How comes? I think those two are really separate topics, and having a DT file in this directory really doesn't hurt anything, until it actually gets referenced in the next patch. I'd keep DT patches separate, really, and in general always would prefer more, but smaller patches to fewer, but bigger ones. Cheers, Andre. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [U-Boot] [PATCH v3 09/13] sunxi: DRAM: add Allwinner H5 support
Hi,
Chen-Yu, thanks for your comments.
On 03/02/17 16:36, Chen-Yu Tsai wrote:
> Hi,
>
> On Fri, Feb 3, 2017 at 11:26 PM, Jagan Teki wrote:
>> On Feb 1, 2017 2:37 AM, "Andre Przywara" wrote:
>>
>> The DRAM controller in the Allwinner H5 SoC is again very similar to
>> the one in the H3 and A64.
>> Based on the existing socid parameter, add support for this controller
>> by reusing the bulk of the code and only deviating where needed.
>> These new bits set or cleared here and there have been mostly found by
>> looking at DRAM register dumps after using the H5 boot0 and comparing
>> them to what we set in the code. So for now it's mostly unclear what
>> those bits actually mean - hence the missing names and comments.
>> Also add the delay line parameters taken from the boot0 and libdram
>> disassembly.
>>
>>
>> Can you split this patch with delay line params as separate patch.
>
> It looks like the delay lines are for the H5, merely taken from
> different sources. They are and should be part of the same patch
> adding support for DRAM on the H5.
Yeah, I think they really belong into this patch. I don't see how
separating them would help, short of creating bisectability problems.
>>
>> Register setup differences between H5 and H3 are courtesy of Jens Kuske.
>>
>> Signed-off-by: Andre Przywara
>> Acked-by: Maxime Ripard
>> ---
>> arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
>> arch/arm/mach-sunxi/dram_sun8i_h3.c | 97
>> +--
>> 2 files changed, 82 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
>> b/arch/arm/include/asm/arch-sunxi/cpu.h
>> index 6f96a97..e8e670e 100644
>> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
>> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
>> @@ -15,5 +15,6 @@
>>
>> #define SOCID_A64 0x1689
>> #define SOCID_H3 0x1680
>> +#define SOCID_H5 0x1718
>>
>> #endif /* _SUNXI_CPU_H */
>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> index 9f7cc7f..d681a9d 100644
>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> @@ -177,6 +177,34 @@ static void mctl_set_master_priority_a64(void)
>> writel(0x8104, &mctl_com->mdfs_bwlr[2]);
>> }
>>
>> +static void mctl_set_master_priority_h5(void)
>> +{
>> + struct sunxi_mctl_com_reg * const mctl_com =
>> + (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
>> +
>> + /* enable bandwidth limit windows and set windows size 1us */
>> + writel(399, &mctl_com->tmr);
>> + writel((1 << 16), &mctl_com->bwcr);
>>
>>
>> I'm not fond of using direct numerical values make code unhealthy please use
>> macros with bitops. Note that this comment will apply rest of the code where
>> it applies.
>
> I think you are being unreasonable. The commit message clearly states that
> the added code either comes from register dumps, disassembled blobs, or
> comparison of released code:
>
> """
> These new bits set or cleared here and there have been mostly found by
> looking at DRAM register dumps after using the H5 boot0 and comparing
> them to what we set in the code. So for now it's mostly unclear what
> those bits actually mean - hence the missing names and comments.
> """
>
> For this particular instance, see
>
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/u-boot-sunxi/arch/arm/cpu/armv7/sun8iw11p1/dram/lib-dram/mctl_hal.c#L197
>
> which gives the exact same comment, and no named macros. Adding a macro
> for it and calling it H5_DRAM_BW_UNKNOWN_MAGIC is not an improvement.
> Same goes for the next few lines.
>
> Allwinner has _never_ released documents for the DRAM controllers or DRAM
> PHYs,
> and only sometimes releases code for DRAM init for some SoCs, sometimes with
> questionable licenses (or lack of), of which some don't match what is actually
> seen in provided blobs. Considering what the community has access to. This
> patch seems to be quite good.
I think we have some sort of rewrite of this code ahead of us anyway,
hopefully we can address some of these points then in a reasonable manner.
But until then I'd like to keep it at "399" instead of using
WINDOW_SIZE_1US or _guessing_ how this is computed from some frequency.
Cheers,
Andre.
>>
>> +
>> + /* set cpu high priority */
>> + writel(0x0001, &mctl_com->mapr);
>> +
>> + /* Port 2 is reserved per Allwinner's linux-3.10 source, yet
>> +* they initialise it */
>> + MBUS_CONF( CPU, true, HIGHEST, 0, 300, 260, 150);
>> + MBUS_CONF( GPU, true, HIGHEST, 0, 600, 400, 200);
>> + MBUS_CONF(UNUSED, true, HIGHEST, 0, 512, 256, 96);
>> + MBUS_CONF( DMA, true, HIGHEST, 0, 256, 128, 32);
>> + MBUS_CONF(VE, true, HIGHEST, 0, 1900, 1500, 1000);
>> + MBUS_CONF( CSI, true, HIGHEST, 0, 150, 120, 100);
>> + MBUS_CONF( NAND, true,HIGH, 0, 256, 128, 64);
>> + MBUS_CO
[linux-sunxi] Re: [PATCH v3 2/3] nvmem: sunxi-sid: add support for H3's SID controller
On Thu, Feb 02, 2017 at 09:13:37PM +0800, Icenowy Zheng wrote:
> The H3 SoC have a bigger SID controller, which has its direct read
> address at 0x200 position in the SID block, not 0x0.
>
> Also, H3 SID controller has some silicon bug that makes the direct read
> value wrong at cold boot, add code to workaround the bug. (This bug has
> already been fixed on A64 and later SoCs)
>
> Signed-off-by: Icenowy Zheng
> ---
> This patch is the part of [PATCH v2 1/1] that adds support for H3 SID
> controller.
>
> .../bindings/nvmem/allwinner,sunxi-sid.txt | 12 +++-
> drivers/nvmem/sunxi_sid.c | 72
> +-
> 2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> index d543ed3f5363..9ab9e75a6351 100644
> --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> @@ -1,7 +1,11 @@
> Allwinner sunxi-sid
>
> Required properties:
> -- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
> +- compatible: Should be one of the following (depending on your SoC):
> + "allwinner,sun4i-a10-sid"
> + "allwinner,sun7i-a20-sid"
> + "allwinner,sun8i-h3-sid"
> +
> - reg: Should contain registers location and length
>
> = Data cells =
> @@ -19,3 +23,9 @@ Example for sun7i:
> compatible = "allwinner,sun7i-a20-sid";
> reg = <0x01c23800 0x200>
> };
> +
> +Example for sun8i-h3:
> + sid@01c14000 {
> + compatible = "allwinner,sun8i-h3-sid";
> + reg = <0x01c14000 0x400>;
> + };
> diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> index 69524b67007f..476a161ff23a 100644
> --- a/drivers/nvmem/sunxi_sid.c
> +++ b/drivers/nvmem/sunxi_sid.c
> @@ -25,6 +25,16 @@
> #include
> #include
>
> +/* Registers and special values for doing register-based SID readout on H3 */
> +#define SUN8I_SID_PRCTL 0x40
> +#define SUN8I_SID_RDKEY 0x60
> +
> +#define SUN8I_SID_OP_LOCK0xAC
> +#define SUN8I_SID_OFFSET_MASK0x1FF
> +#define SUN8I_SID_OFFSET_SHIFT 16
> +#define SUN8I_SID_LOCK_SHIFT 8
> +#define SUN8I_SID_READ BIT(1)
> +
> static struct nvmem_config econfig = {
> .name = "sunxi-sid",
> .read_only = true,
> @@ -34,11 +44,14 @@ static struct nvmem_config econfig = {
> };
>
> struct sunxi_sid_cfg {
> + u32 value_offset;
> u32 size;
> + boolneed_register_readout;
> };
>
> struct sunxi_sid {
> void __iomem*base;
> + u32 value_offset;
> };
>
> /* We read the entire key, due to a 32 bit read alignment requirement. Since
> we
> @@ -51,7 +64,8 @@ static u8 sunxi_sid_read_byte(const struct sunxi_sid *sid,
> {
> u32 sid_key;
>
> - sid_key = ioread32be(sid->base + round_down(offset, 4));
> + sid_key = ioread32be(sid->base + sid->value_offset +
> + round_down(offset, 4));
This would probably be more logical to have this in sunxi_sid_read.
> sid_key >>= (offset % 4) * 8;
>
> return sid_key; /* Only return the last byte */
> @@ -69,6 +83,33 @@ static int sunxi_sid_read(void *context, unsigned int
> offset,
> return 0;
> }
>
> +static int sun8i_sid_register_readout(const struct sunxi_sid *sid,
> + const unsigned int word,
> + u32 *out)
> +{
> + u32 reg_val;
> + unsigned long expire = jiffies + msecs_to_jiffies(250);
> +
> + /* Set word, lock access, and set read command */
> + reg_val = (word & SUN8I_SID_OFFSET_MASK)
> + << SUN8I_SID_OFFSET_SHIFT;
> + reg_val |= SUN8I_SID_OP_LOCK << SUN8I_SID_LOCK_SHIFT;
You're not using those mask and shifts anywhere else, why not just
define the value / macro you need directly?
> + reg_val |= SUN8I_SID_READ;
> + writel(reg_val, sid->base + SUN8I_SID_PRCTL);
> +
> + do {
> + reg_val = readl(sid->base + SUN8I_SID_PRCTL);
> + } while (time_before(jiffies, expire) && (reg_val & SUN8I_SID_READ));
readl_poll_timeout?
> + if (reg_val & SUN8I_SID_READ)
> + return -EIO;
> +
> + if (out)
> + *out = readl(sid->base + SUN8I_SID_RDKEY);
Why do you need that out parameter?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
[linux-sunxi] Re: [PATCH v3 1/3] nvmem: sunxi-sid: read NVMEM size from device compatible
On Thu, Feb 02, 2017 at 09:13:36PM +0800, Icenowy Zheng wrote: > Sometimes the SID device have more memory address space than the real > NVMEM size (for the registers used to read/write the SID). > > Fetch the NVMEM size from device compatible, rather than the memory > address space's length, in order to prepare for adding some > registers-based read support. > > Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
