Re: [U-Boot] [U-Boot,1/2] armv8: Reduce exception handling code
On Wed, Jul 25, 2018 at 12:57:00AM +0100, Andre Przywara wrote: > The arm64 exception handling code is quite big, mostly due to > architectural alignment requirements. Each exception entry spans 32 > instructions, which sounds generous, but is too small to fit all of the > save/branch/restore code in there. So at the moment we use only four > instructions, branching into shared save and restore routines. > To not leave the space for those remaining 28 instructions wasted, let's > split the save and restore routines and stuff them into the gaps. > This saves about 250 bytes of code, which is helpful for those tight > SPLs. > > Signed-off-by: Andre Przywara Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/9] configs: stm32f429-evaluation: Enable CONFIG_BLK
On Wed, Jul 25, 2018 at 05:49:04PM +0200, Patrice Chotard wrote: > CONFIG_BLK config flag becomes mandatory, enable it. > > Signed-off-by: Patrice Chotard Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 7/9] ARM: dts: stm32: remove cd-inverted for stm32429i-eval
On Wed, Jul 25, 2018 at 05:49:10PM +0200, Patrice Chotard wrote: > As cd-inverted property is no more used by arm_pl180_mmci driver, > remove it. Update cd-gpios active level accordingly. > > Reported-by: Tuomas Tynkkynen > Signed-off-by: Patrice Chotard Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] bootcount: Fix misaligned cache operation
On Wed, Jul 25, 2018 at 11:45:58AM +, Alex Kiernan wrote:
> 1947c2d2a0 introduces cache line flushes for the bootcounter, but if
> the start address is not aligned then the flush causes warnings of
> the form:
>
> CACHE: Misaligned operation at range [4030b7fc, 4030b83c]
>
> Align both the start and end of the buffer (possibly crossing multiple
> lines).
>
> Fixes: 1947c2d2a0 ("bootcount: flush after storing the bootcounter")
> Signed-off-by: Alex Kiernan
> Acked-by: Stefano Babic
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] armv8: make SPL exception vectors optional
On Wed, Jul 25, 2018 at 12:57:01AM +0100, Andre Przywara wrote: > Even though the exception vector table is a fundamental part of the ARM > architecture, U-Boot mostly does not make real use of it, except when > crash dumping. But having it in takes up quite some space, partly due to > the architectural alignment requirement of 2KB. Since we don't take special > care of that, the compiler adds a more or less random amount of padding > space, which increases the image size quite a bit, especially for the SPL. > > On a typical Allwinner build this is around 1.5KB of padding, plus 1KB > for the vector table (mostly padding space again), then some extra code > to do the actual handling. This amounts to almost 10% of the maximum image > size, which is quite a lot for a pure debugging feature. > > Add a Kconfig symbol to allow the exception vector table to be left out > of the build for the SPL. > For now this is "default y" for everyone, but specific defconfigs, > platforms or .config files can opt out here at will, to mitigate the code > size pressure we see for some SPLs. > > Signed-off-by: Andre Przywara Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 2/9] configs: stm32f746-disco: Enable CONFIG_BLK
On Wed, Jul 25, 2018 at 05:49:05PM +0200, Patrice Chotard wrote: > CONFIG_BLK config flag becomes mandatory, enable it. > > Signed-off-by: Patrice Chotard > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 5/9] mmc: arm_pl180_mmci: Add missing clk_free
On Wed, Jul 25, 2018 at 05:49:08PM +0200, Patrice Chotard wrote: > Add missing clk_free() call in case of failure > when enabling the clock. > > Signed-off-by: Patrice Chotard > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] docproc: Remove
On Wed, Jul 25, 2018 at 11:42:58AM -0400, Tom Rini wrote: > Now that we have moved to Sphinx documentation we don't need the docproc > app anymore, remove. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,5/6] configs: stm32mp15: enable ADC
On Tue, Jul 24, 2018 at 04:31:32PM +0200, Fabrice Gasnier wrote: > Enable ADC on stm32mp15. > - CONFIG_CMD_ADC > - CONFIG_STM32_ADC > > Signed-off-by: Fabrice Gasnier > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] clk: clk_set_default: accept no-op skip fields
On Thu, Jul 26, 2018 at 03:19:32PM +0200, Neil Armstrong wrote: > The Assigned Clock parents and rates misses the fact that a "0" entry can > be passed to skip setting a parent or rate of an assigned clock as > described in the Linux clock bindings at [1]. > > This patch simply skips the clock reparenting if the DT parsing returns > -ENOENT and the clock rate setting if "0" is passed as clock rate. > > [1] > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/clock/clock-bindings.txt#L135 > > Fixes: f4fcba5c5baa "clk: implement clk_set_defaults()" > Signed-off-by: Neil Armstrong > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/6] dm: adc: uclass: get reference regulator once
On Tue, Jul 24, 2018 at 04:31:29PM +0200, Fabrice Gasnier wrote: > device_get_supply_regulator() only needs to be called once. > But each time there's call to adc_vxx_value() for instance, it calls > adc_vxx_platdata_update() -> device_get_supply_regulator(). > > So, move device_get_supply_regulator() to pre_probe() routine. > > This also allows vdd_supply/vss_supply to be provided directly from > uc_pdata, e.g dt-binding variant like stm32-adc provide its own > 'vref-supply'. > > Signed-off-by: Fabrice Gasnier > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mailmap: Update mail address (lukma)
On Thu, Jul 26, 2018 at 12:37:14AM +0200, Lukasz Majewski wrote: > Update my e-mail address from samsung.com to denx.de > > Signed-off-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2] ti_omap3_common: Add CONFIG_SYS_NS16550_COMx entries
On Tue, Jul 24, 2018 at 06:06:04PM -0500, Adam Ford wrote: > Several boards do not use the default UART3, so they do a check > for ifdef CONFIG_SPL_BUILD and enable the pointer for > CONFIG_SYS_NS16550_COMx to point to OMAP34XX_UARTx. > > Let's consoldate this all into one place, and remove them from the > individual boards. > > Signed-off-by: Adam Ford Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 4/9] mmc: arm_pl180_mmci: Update to support CONFIG_BLK
On Wed, Jul 25, 2018 at 05:49:07PM +0200, Patrice Chotard wrote: > Config flag CONFIG_BLK becomes mandatory, update arm_pl180_mmci > to support this config. > > This driver is used by STM32Fx and by Vexpress platforms. > Only STM32Fx are DM ready. No DM code is isolated and will be > removed easily when wexpress will be converted to DM. > > Signed-off-by: Patrice Chotard Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 3/9] configs: stm32f469-disco: Enable CONFIG_BLK
On Wed, Jul 25, 2018 at 05:49:06PM +0200, Patrice Chotard wrote: > CONFIG_BLK config flag becomes mandatory, enable it. > > Signed-off-by: Patrice Chotard Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] kconfig: Replace spaces with tabs
On Tue, Jul 24, 2018 at 02:47:43PM +0200, Michal Simek wrote: > Trivial Kconfig cleanup. Use tabs instead of spaces. > > Signed-off-by: Michal Simek > Reviewed-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/6] dt-bindings: Document STM32 ADC DT bindings
On Tue, Jul 24, 2018 at 04:31:30PM +0200, Fabrice Gasnier wrote: > This patch adds documentation of device tree bindings for the STM32 ADC. > It's based on linux-v4.18-rc* dt-bindings, at the time of writing: > - Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt > > Signed-off-by: Fabrice Gasnier > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,6/6] ARM: dts: stm32mp157: Add ADC DT node
On Tue, Jul 24, 2018 at 04:31:33PM +0200, Fabrice Gasnier wrote: > Add ADC device tree node. This allows to get analog conversions on > stm32mp157. > > Signed-off-by: Fabrice Gasnier > Reviewed-by: Simon Glass This doesn't apply currently, please rebase, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 6/9] mmc: arm_pl180_mmci: Remove cd_inverted host's struct field
On Wed, Jul 25, 2018 at 05:49:09PM +0200, Patrice Chotard wrote: > As platform uses GPIOs for card detection, it's > simpler and more readable to use GPIO_ACTIVE_(LOW|HIGH) > in the gpio flags instead of using the cd-inverted > property. > > Reported-by: Tuomas Tynkkynen > Signed-off-by: Patrice Chotard Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,1/6] clk: add clk_valid()
On Tue, Jul 24, 2018 at 04:31:28PM +0200, Fabrice Gasnier wrote: > Add clk_valid() to check for optional clocks are valid. > Call clk_valid() in test/dm/clk.c and add relevant test routine to > sandbox clk tests. > > Signed-off-by: Fabrice Gasnier > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] Add Beaglebone Enhanced support
On Wed, Jul 18, 2018 at 10:13:59AM +0200, Koen Kooi wrote: > The "Beaglebone Enhanced" by Sancloud is based on the Beaglebone Black, > but with the following differences: > > * Gigabit capable PHY > * Extra USB hub, optional i2c control > * lps3331ap barometer connected over i2c > * MPU6050 6 axis MEMS accelerometer/gyro connected over i2c > * 1GiB DDR3 RAM > * RTL8723 Wifi/Bluetooth connected over USB > > Signed-off-by: Koen Kooi > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,4/6] adc: Add driver for STM32 ADC
On Tue, Jul 24, 2018 at 04:31:31PM +0200, Fabrice Gasnier wrote: > This patch adds support for STMicroelectronics STM32 ADC (analog to > digital converter). It's originally based on Linux kernel v4.18-rcs > drivers/iio/adc/stm32-adc*. It's composed of: > - core driver (UCLASS_SIMPLE_BUS) manages common resources (clk, regu). > - child drivers (UCLASS_ADC) declare each ADC, channels and handle > conversions. > This driver currently supports STM32H7 and STM32MP1 ADC. > > Signed-off-by: Fabrice Gasnier > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 9/9] ARM: dts: stm32: remove cd-inverted for stm32f746-disco
On Wed, Jul 25, 2018 at 05:49:12PM +0200, Patrice Chotard wrote:
> As cd-inverted property is no more used by arm_pl180_mmci driver,
> remove it. Update cd-gpios active level accordingly.
>
> Reported-by: Tuomas Tynkkynen
> Signed-off-by: Patrice Chotard
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/dts/stm32f746-disco.dts | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/stm32f746-disco.dts
> b/arch/arm/dts/stm32f746-disco.dts
> index e47f762e54dc..187c94b99bfa 100644
> --- a/arch/arm/dts/stm32f746-disco.dts
> +++ b/arch/arm/dts/stm32f746-disco.dts
> @@ -307,8 +307,7 @@
>
> {
> status = "okay";
> - cd-gpios = < 13 0>;
> - cd-inverted;
> + cd-gpios = < 13 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default", "opendrain";
> pinctrl-0 = <_pins>;
> pinctrl-1 = <_pins_od>;
So I can't apply this one as it breaks the build for stm32f746-disco as
dt-bindings/gpio/gpio.h isn't being included by this dts tree.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, u-boot, 2/2] clk: clk_meson: Add mux and div support for reparent and rate setting
On Thu, Jul 26, 2018 at 03:54:04PM +0200, Neil Armstrong wrote:
> This patch adds support for :
> - Rate calculation through muxes and generic dividers
> - Basic gate setting propagation
> - Reparenting for muxes
> - Clock rate setting through generic dividers without reparenting
>
> Support is only added to the Composite VPU and VAPB clocks in order
> to support the Video Processing Unit Power Domain clock setup.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Simon Glass
I get:
Building current source for 1 boards (1 thread, 16 jobs per thread)
aarch64: + khadas-vim
+(khadas-vim) In file included from include/linux/bug.h:7:0,
+(khadas-vim) from include/common.h:25,
+(khadas-vim) from drivers/clk/clk_meson.c:8:
+(khadas-vim) debug("%s: %sabling %d\n", __func__, on ? "en" : "dis", id);
+(khadas-vim) ^
+(khadas-vim) include/linux/printk.h:37:21: note: in definition of macro
'pr_fmt'
+(khadas-vim) #define pr_fmt(fmt) fmt
+(khadas-vim) ^~~
+(khadas-vim) include/log.h:141:2: note: in expansion of macro 'debug_cond'
+(khadas-vim) debug_cond(_DEBUG, fmt, ##args)
+(khadas-vim) ^~
+(khadas-vim) drivers/clk/clk_meson.c:198:2: note: in expansion of macro 'debug'
+(khadas-vim) ^
+(khadas-vim) debug("%s: really %sabling %d\n", __func__, on ? "en" : "dis",
id);
+(khadas-vim) drivers/clk/clk_meson.c:218:2: note: in expansion of macro 'debug'
+(khadas-vim) arch/arm/dts/meson-gxl-s905x-khadas-vim.dtb: Warning
(avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
w+(khadas-vim) drivers/clk/clk_meson.c: In function 'meson_set_gate_by_id':
w+(khadas-vim) drivers/clk/clk_meson.c:198:8: warning: format '%d' expects
argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
w+(khadas-vim) drivers/clk/clk_meson.c:218:8: warning: format '%d' expects
argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: armv7-a: Compile and tune for armv7-a instead of armv5
arch/arm/Makefile references armv5 for backwards compatibility with
older compilers. This patch removes those references to armv5,
since by now newer compilers are required which should have armv7
support enabled.
The Makefile also also has a list of options for mtune, but the
entry for CONFIG_CPU_V7A is empty, so this patch tunes the
CPU_V7A architecture to generic-armv7-a.
The following size changed apply to omap3_logic using GCC.
Stock
text data bss dec hex filename
50910 429 67580 118919 1d087 spl/u-boot-spl
540713 22700 327072 890485 d9675 u-boot
Without Armv5
text data bss dec hex filename
50916 429 67580 118925 1d08d spl/u-boot-spl
540719 22700 327064 890483 d9673 u-boot
mtune=generic-armv7-a
text data bss dec hex filename
50932 429 67580 118941 1d09d spl/u-boot-spl
540519 22700 327080 890299 d95bb u-boot
Signed-off-by: Adam Ford
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index cac58bdc4d..4e1b8cfa35 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -15,7 +15,7 @@ arch-$(CONFIG_CPU_PXA)=
arch-$(CONFIG_CPU_ARM1136) =-march=armv5
arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
-$(call cc-option, -march=armv7, -march=armv5))
+$(call cc-option, -march=armv7))
arch-$(CONFIG_CPU_V7M) =-march=armv7-m
arch-$(CONFIG_CPU_V7R) =-march=armv7-r
arch-$(CONFIG_ARM64) =-march=armv8-a
@@ -40,7 +40,7 @@ tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100
tune-$(CONFIG_CPU_PXA) =-mcpu=xscale
tune-$(CONFIG_CPU_ARM1136) =
tune-$(CONFIG_CPU_ARM1176) =
-tune-$(CONFIG_CPU_V7A) =
+tune-$(CONFIG_CPU_V7A) =-mtune=generic-armv7-a
tune-$(CONFIG_CPU_V7R) =
tune-$(CONFIG_ARM64) =
diff --git a/arch/arm/mach-omap2/omap3/lowlevel_init.S
b/arch/arm/mach-omap2/omap3/lowlevel_init.S
index e6e907d11f..2a05b5e521 100644
--- a/arch/arm/mach-omap2/omap3/lowlevel_init.S
+++ b/arch/arm/mach-omap2/omap3/lowlevel_init.S
@@ -21,6 +21,7 @@
* R0 - Service ID
* R1 - paramer list
*/
+/* TODO: Re-evaluate the comment at the end regarding armv5 vs armv7 */
ENTRY(do_omap3_emu_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy the Secure Service ID in R12
diff --git a/doc/README.omap3 b/doc/README.omap3
index e09ac032c0..00bcbdba9a 100644
--- a/doc/README.omap3
+++ b/doc/README.omap3
@@ -23,13 +23,6 @@ Currently the following boards are supported:
* CompuLab Ltd. CM-T35 [8]
-Toolchain
-=
-
-While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
-with -march=armv5 to allow more compilers to work. For U-Boot code this has
-no performance impact.
-
Build
=
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 1/1] efi_loader: relocate pointer to tables
When applying a virtual memory map we have to update the pointer to the
list of configuration tables.
Fixes: 4182a129ef73 ("efi_loader: allocate configuration table array")
Reported-by: Mark Kettenis
Signed-off-by: Heinrich Schuchardt
---
Hello Mark,
could you, please, test if this solves the problem.
Best regards
Heinrich
---
lib/efi_loader/efi_runtime.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 06958f23fa..45b7809dec 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -360,6 +360,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
efi_physical_addr_t map_start = map->physical_start;
efi_physical_addr_t map_len = map->num_pages << EFI_PAGE_SHIFT;
efi_physical_addr_t map_end = map_start + map_len;
+ u64 off = map->virtual_start - map_start;
/* Adjust all mmio pointers in this region */
list_for_each(lhandle, _runtime_mmio) {
@@ -370,11 +371,17 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
link);
if ((map_start <= lmmio->paddr) &&
(map_end >= lmmio->paddr)) {
- u64 off = map->virtual_start - map_start;
uintptr_t new_addr = lmmio->paddr + off;
*lmmio->ptr = (void *)new_addr;
}
}
+ if ((map_start <= (uintptr_t)systab.tables) &&
+ (map_end >= (uintptr_t)systab.tables)) {
+ char *ptr = (char *)systab.tables;
+
+ ptr += off;
+ systab.tables = (struct efi_configuration_table *)ptr;
+ }
}
/* Move the actual runtime code over */
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 1/1] efi_loader: relocate pointer to tables
When applying a virtual memory map we have to update the pointer to the
list of configuration tables.
Fixes: 4182a129ef73 ("efi_loader: allocate configuration table array")
Reported-by: Mark Kettenis
Signed-off-by: Heinrich Schuchardt
---
Hello Mark,
could you, please, test if this solves the problem.
Best regards
Heinrich
---
lib/efi_loader/efi_runtime.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 06958f23fa..45b7809dec 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -360,6 +360,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
efi_physical_addr_t map_start = map->physical_start;
efi_physical_addr_t map_len = map->num_pages << EFI_PAGE_SHIFT;
efi_physical_addr_t map_end = map_start + map_len;
+ u64 off = map->virtual_start - map_start;
/* Adjust all mmio pointers in this region */
list_for_each(lhandle, _runtime_mmio) {
@@ -370,11 +371,17 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
link);
if ((map_start <= lmmio->paddr) &&
(map_end >= lmmio->paddr)) {
- u64 off = map->virtual_start - map_start;
uintptr_t new_addr = lmmio->paddr + off;
*lmmio->ptr = (void *)new_addr;
}
}
+ if ((map_start <= (uintptr_t)systab.tables) &&
+ (map_end >= (uintptr_t)systab.tables)) {
+ char *ptr = (char *)systab.tables;
+
+ ptr += off;
+ systab.tables = (struct efi_configuration_table *)ptr;
+ }
}
/* Move the actual runtime code over */
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Sun, Aug 05, 2018 at 02:58:46AM +0800, Icenowy Zheng wrote: > > > 于 2018年8月5日 GMT+08:00 上午2:51:43, Tom Rini 写到: > >On Sat, Aug 04, 2018 at 11:18:43PM +0530, Jagan Teki wrote: > >> On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: > >> > On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: > >> >> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini > >wrote: > >> >> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: > >> >> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > > wrote: > >> >> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini > >wrote: > >> >> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: > >> >> >> >> > >> >> >> >>> Hi Tom, > >> >> >> >>> > >> >> >> >>> Please pull this PR. > >> >> >> >>> > >> >> >> >>> thanks, > >> >> >> >>> Jagan. > >> >> >> >>> > >> >> >> >>> The following changes since commit > >5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: > >> >> >> >>> > >> >> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) > >> >> >> >>> > >> >> >> >>> are available in the Git repository at: > >> >> >> >>> > >> >> >> >>> git://git.denx.de/u-boot-sunxi.git master > >> >> >> >>> > >> >> >> >>> for you to fetch changes up to > >89a897fc4d78e31332e5899e977d8bf3c82abafa: > >> >> >> >>> > >> >> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support > >(2018-07-31 20:50:01 +0530) > >> >> >> >>> > >> >> >> >> > >> >> >> >> For the moment, on hold. pine_h64 doesn't link (see > >> >> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet > >Andre's > >> >> >> >> changes to save some space on aarch64 will get it to fit in, > >and I need > >> >> >> >> to see if I'm ready to apply them. > >> >> >> > > >> >> >> > I though of inform the same, but for h6 atf need to use it > >from > >> >> >> > mainline here all a64 boards seems failing. I didn't > >reproduce this > >> >> >> > manually. > >> >> >> > > >> >> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is > >non-functional > >> >> >> > >> >> >> The cause is obvious. The ATF blob is missing from the > >environment. > >> >> >> If TravisCI is only used to test building, maybe we could just > >put an > >> >> >> empty bl31.bin there to make it happy. > >> >> > > >> >> > Please note that the above is NOT the problem. That's the > >non-fatal > >> >> > warning that your resulting binary won't work as there's no > >bl31.bin. > >> >> > The problem is: > >> >> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will > >not fit in region `.sram' > >> >> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes > >> >> > +make[2]: *** [spl/u-boot-spl] Error 1 > >> >> > +make[1]: *** [spl/u-boot-spl] Error 2 > >> >> > +make: *** [sub-make] Error 2 > >> >> > >> >> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 > >> > > >> > Travis-CI uses gcc-7.3 from kernel.org. > >> > >> Look like we have size issues wrt gcc versions, Icenowy tried glibc > >> variant, 2018.07-3 bleeding edge and it work it seems. can't we > >> upgrade Travis-CI to use the same or if not specific for h6? > > > >I'm testing Andre's series currently and that should resolve this > > Do you mention the exception handling series? Yes. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/7] ARM: dts: sunxi: Update dts(i) files from Linux-4.18-rc3
This series is trying to update SoC dtsi and board dts files for Allwinner sun4i, 5i, 6i, 8i-a23/a33/a83t, r40 SoC's from Linux-4.18-rc3 These update is useful for supporting features CLK, RESET, DM_MMC etc Since H3/H5/A64 is already updated with Linux-4.18-rc3, this series use same version to maintain proper compatibility for all SoC platforms syncs. thanks, Jagan. Jagan Teki (7): ARM: dts: sun4i: Update A10 dts(i) files from Linux ARM: dts: sun5i: Update A10s/A13/gr8/r8 dts(i) files from Linux ARM: dts: sun6i: Update A31/A31s dts(i) files from Linux ARM: dts: sun7i: Update A20 dts(i) files from Linux ARM: dts: sun8i: Update A23/A33/r16 dts(i) files from Linux ARM: dts: sun8i: Update A83T dts(i) files from Linux ARM: dts: sun8i: Update R40/V40 dts(i) files from Linux arch/arm/dts/axp209.dtsi | 17 +- arch/arm/dts/axp81x.dtsi | 169 ++ arch/arm/dts/sun4i-a10-a1000.dts | 61 +- arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 23 +- arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts| 37 +- arch/arm/dts/sun4i-a10-cubieboard.dts | 67 +- arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 76 +- arch/arm/dts/sun4i-a10-gemei-g9.dts | 28 +- arch/arm/dts/sun4i-a10-hackberry.dts | 32 +- arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 31 +- arch/arm/dts/sun4i-a10-inet-3f.dts|2 +- arch/arm/dts/sun4i-a10-inet-3w.dts|2 +- arch/arm/dts/sun4i-a10-inet1.dts | 58 +- arch/arm/dts/sun4i-a10-inet97fv2.dts | 41 +- arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 101 +- .../dts/sun4i-a10-itead-iteaduino-plus.dts| 24 +- arch/arm/dts/sun4i-a10-jesurun-q5.dts | 34 +- arch/arm/dts/sun4i-a10-marsboard.dts | 38 +- arch/arm/dts/sun4i-a10-mini-xplus.dts | 16 +- arch/arm/dts/sun4i-a10-mk802.dts | 59 +- arch/arm/dts/sun4i-a10-mk802ii.dts|9 +- arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 75 +- arch/arm/dts/sun4i-a10-pcduino.dts| 47 +- arch/arm/dts/sun4i-a10-pcduino2.dts | 11 - arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 89 +- arch/arm/dts/sun4i-a10.dtsi | 1349 +++ arch/arm/dts/sun5i-a10s-auxtek-t003.dts | 26 +- arch/arm/dts/sun5i-a10s-auxtek-t004.dts | 42 +- arch/arm/dts/sun5i-a10s-mk802.dts | 24 +- arch/arm/dts/sun5i-a10s-olinuxino-micro.dts | 82 +- arch/arm/dts/sun5i-a10s-r7-tv-dongle.dts | 24 +- arch/arm/dts/sun5i-a10s-wobo-i5.dts | 29 +- arch/arm/dts/sun5i-a10s.dtsi | 224 +-- .../dts/sun5i-a13-empire-electronix-d709.dts | 29 +- arch/arm/dts/sun5i-a13-hsg-h702.dts | 29 +- arch/arm/dts/sun5i-a13-inet-98v-rev2.dts | 164 +- arch/arm/dts/sun5i-a13-olinuxino-micro.dts| 44 +- arch/arm/dts/sun5i-a13-olinuxino.dts | 100 +- arch/arm/dts/sun5i-a13-utoo-p66.dts | 49 +- arch/arm/dts/sun5i-a13.dtsi | 268 +-- arch/arm/dts/sun5i-gr8-chip-pro.dts | 16 +- arch/arm/dts/sun5i-gr8.dtsi | 1082 +--- arch/arm/dts/sun5i-r8-chip.dts| 91 +- arch/arm/dts/sun5i-r8.dtsi| 40 - .../dts/sun5i-reference-design-tablet.dtsi| 69 +- arch/arm/dts/sun5i.dtsi | 792 - arch/arm/dts/sun6i-a31-app4-evb1.dts |7 +- arch/arm/dts/sun6i-a31-colombus.dts | 26 +- arch/arm/dts/sun6i-a31-hummingbird.dts| 153 +- arch/arm/dts/sun6i-a31-i7.dts | 82 +- arch/arm/dts/sun6i-a31-m9.dts | 23 +- arch/arm/dts/sun6i-a31-mele-a1000g-quad.dts | 23 +- arch/arm/dts/sun6i-a31.dtsi | 1151 - arch/arm/dts/sun6i-a31s-cs908.dts |2 - arch/arm/dts/sun6i-a31s-primo81.dts | 69 +- arch/arm/dts/sun6i-a31s-sina31s-core.dtsi |1 - arch/arm/dts/sun6i-a31s-sina31s.dts | 77 +- arch/arm/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 154 +- .../sun6i-a31s-yones-toptech-bs1078-v2.dts| 13 +- arch/arm/dts/sun6i-a31s.dtsi |8 + .../dts/sun6i-reference-design-tablet.dtsi| 18 +- arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 32 +- arch/arm/dts/sun7i-a20-bananapi.dts | 106 +- arch/arm/dts/sun7i-a20-bananapro.dts | 73 +- arch/arm/dts/sun7i-a20-cubieboard2.dts| 56 +- arch/arm/dts/sun7i-a20-cubietruck.dts | 84 +- arch/arm/dts/sun7i-a20-hummingbird.dts| 30 +- arch/arm/dts/sun7i-a20-i12-tvbox.dts | 34 +- arch/arm/dts/sun7i-a20-icnova-swac.dts|6 +- arch/arm/dts/sun7i-a20-itead-ibox.dts | 12 +- arch/arm/dts/sun7i-a20-lamobo-r1.dts | 73 +- arch/arm/dts/sun7i-a20-m3.dts | 12 +- arch/arm/dts/sun7i-a20-mk808c.dts | 43 +-
[U-Boot] [PATCH 7/7] ARM: dts: sun8i: Update R40/V40 dts(i) files from Linux
Update all R40/V40 devicetree dtsi and dtsi files from Linux-v4.18-rc3
with below commit:
R40:
commit c36fd5a48bd20820855e3e91a89297eeaa31836e
Author: Chen-Yu Tsai
Date: Wed May 2 00:12:25 2018 +0800
ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller
V40:
commit c5f0bb472795170ab5c33be12e29ce7465fb31ed
Author: Icenowy Zheng
Date: Fri Apr 6 22:03:44 2018 +0800
ARM: sun8i: v40: enable USB host ports for Banana Pi M2 Berry
Signed-off-by: Jagan Teki
---
arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts | 168 +-
arch/arm/dts/sun8i-r40.dtsi | 303 +--
arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts | 50 +++
3 files changed, 486 insertions(+), 35 deletions(-)
diff --git a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
index 28c9158302..25fb048c7d 100644
--- a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2016 Chen-Yu Tsai
+ * Copyright (C) 2017 Chen-Yu Tsai
+ * Copyright (C) 2017 Icenowy Zheng
*
* 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
@@ -43,6 +44,8 @@
/dts-v1/;
#include "sun8i-r40.dtsi"
+#include
+
/ {
model = "Banana Pi BPI-M2-Ultra";
compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
@@ -55,17 +58,47 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ pwr-led {
+ label = "bananapi:red:pwr";
+ gpios = < 7 20 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ user-led-green {
+ label = "bananapi:green:user";
+ gpios = < 7 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led-blue {
+ label = "bananapi:blue:user";
+ gpios = < 7 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ reg_vcc5v0: vcc5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 7 23 GPIO_ACTIVE_HIGH>; /* PH23 */
+ enable-active-high;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = < 6 10 GPIO_ACTIVE_LOW>; /* PG10 WIFI_EN */
+ };
};
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
+ {
status = "okay";
};
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pb_pins>;
+ {
status = "okay";
};
@@ -74,6 +107,7 @@
pinctrl-0 = <_rgmii_pins>;
phy-handle = <>;
phy-mode = "rgmii";
+ phy-supply = <_dc1sw>;
status = "okay";
};
@@ -83,3 +117,123 @@
reg = <1>;
};
};
+
+ {
+ status = "okay";
+
+ axp22x: pmic@34 {
+ compatible = "x-powers,axp221";
+ reg = <0x34>;
+ interrupt-parent = <_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+ {
+ vmmc-supply = <_dcdc1>;
+ bus-width = <4>;
+ cd-gpios = < 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
+ cd-inverted;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pg_pins>;
+ vmmc-supply = <_dldo2>;
+ vqmmc-supply = <_dldo1>;
+ mmc-pwrseq = <_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+ {
+ vmmc-supply = <_dcdc1>;
+ vqmmc-supply = <_dcdc1>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <250>;
+ regulator-name = "vcc-pa";
+};
+
+_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "avcc";
+};
+
+_dc1sw {
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-gmac-phy";
+};
+
+_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <130>;
+ regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <130>;
+ regulator-name =
[U-Boot] [PATCH 6/7] ARM: dts: sun8i: Update A83T dts(i) files from Linux
Update all A83T devicetree dtsi and dtsi files from Linux-v4.18-rc3
with below commit:
commit 221cb9fd2ee3042689fe0e6613d0f34eb46a5af6
Author: Mylène Josserand
Date: Fri May 4 21:05:44 2018 +0200
ARM: dts: sun8i: Add enable-method for SMP support for the A83T SoC
Note: bananapi-m3 and cubietruck-plus board dts files has
usb_otg enabled in U-Boot which were not present in Linux.
Signed-off-by: Jagan Teki
---
arch/arm/dts/axp81x.dtsi | 169
.../dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 195 +++-
arch/arm/dts/sun8i-a83t-bananapi-m3.dts | 298 +-
arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 322 ++-
arch/arm/dts/sun8i-a83t-tbs-a711.dts | 355 ++-
arch/arm/dts/sun8i-a83t.dtsi | 885 --
include/dt-bindings/clock/sun8i-a83t-ccu.h| 140 +++
include/dt-bindings/reset/sun8i-a83t-ccu.h| 98 ++
8 files changed, 2382 insertions(+), 80 deletions(-)
create mode 100644 arch/arm/dts/axp81x.dtsi
create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h
diff --git a/arch/arm/dts/axp81x.dtsi b/arch/arm/dts/axp81x.dtsi
new file mode 100644
index 00..043c717dce
--- /dev/null
+++ b/arch/arm/dts/axp81x.dtsi
@@ -0,0 +1,169 @@
+/*
+ * Copyright 2017 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * 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.
+ */
+
+/* AXP813/818 Integrated Power Management Chip */
+
+ {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ axp_adc: adc {
+ compatible = "x-powers,axp813-adc";
+ #io-channel-cells = <1>;
+ };
+
+ axp_gpio: gpio {
+ compatible = "x-powers,axp813-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio0_ldo: gpio0-ldo {
+ pins = "GPIO0";
+ function = "ldo";
+ };
+
+ gpio1_ldo: gpio1-ldo {
+ pins = "GPIO1";
+ function = "ldo";
+ };
+ };
+
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp813-battery-power-supply";
+ status = "disabled";
+ };
+
+ regulators {
+ /* Default work frequency for buck regulators */
+ x-powers,dcdc-freq = <3000>;
+
+ reg_dcdc1: dcdc1 {
+ };
+
+ reg_dcdc2: dcdc2 {
+ };
+
+ reg_dcdc3: dcdc3 {
+ };
+
+ reg_dcdc4: dcdc4 {
+ };
+
+ reg_dcdc5: dcdc5 {
+ };
+
+ reg_dcdc6: dcdc6 {
+ };
+
+ reg_dcdc7: dcdc7 {
+ };
+
+ reg_aldo1: aldo1 {
+ };
+
+ reg_aldo2: aldo2 {
+ };
+
+ reg_aldo3: aldo3 {
+ };
+
+ reg_dldo1: dldo1 {
+ };
+
+ reg_dldo2: dldo2 {
+
[U-Boot] [PATCH 5/7] ARM: dts: sun8i: Update A23/A33/r16 dts(i) files from Linux
Update all A23/A33/r16 devicetree dtsi and dtsi files from
Linux-v4.18-rc3 with below commits.
A23:
commit bc3bd041fe766219a44688b182c260064007f0cc
Author: Miquel Raynal
Date: Tue Apr 24 17:55:02 2018 +0200
ARM: dts: sun8i: a23/a33: declare NAND pins
A33:
commit 88fe315d2c0a397ef42d7639addab0e021ae911d
Author: Maxime Ripard
Date: Wed Apr 4 11:57:15 2018 +0200
ARM: dts: sun8i: a33: Add the DSI-related nodes
r16:
commit 9621d0bd1b0d61167e1853ac68cf4869c31bcc96
Author: Miquel Raynal
Date: Tue Apr 24 17:55:03 2018 +0200
ARM: dts: nes: add Nintendo NES/SuperNES Classic Edition support
Note:
- Drop pinctrl from sun8i-r16-nintendo-nes-classic-edition.dts since
sun8i-a23-a33.dtsi is added with Linux sync.
- Don't sync non U-Boot supported dts files
sun8i-a23-ippo-q8h-v1.2.dts
sun8i-a23-ippo-q8h-v5.dts
sun8i-a33-et-q8-v1.6.dts
sun8i-a33-ippo-q8h-v1.2.dts
sun8i-r16-nintendo-nes-classic.dts
sun8i-r16-nintendo-super-nes-classic.dts
Signed-off-by: Jagan Teki
---
arch/arm/dts/sun8i-a23-a33.dtsi | 112 ++
arch/arm/dts/sun8i-a23-evb.dts| 11 +-
arch/arm/dts/sun8i-a23-gt90h-v4.dts | 5 +-
arch/arm/dts/sun8i-a23-inet86dz.dts | 6 +-
.../dts/sun8i-a23-polaroid-mid2407pxe03.dts | 34 +++---
.../dts/sun8i-a23-polaroid-mid2809pxe04.dts | 25 ++--
arch/arm/dts/sun8i-a23-q8-tablet.dts | 13 ++
arch/arm/dts/sun8i-a23.dtsi | 4 +-
arch/arm/dts/sun8i-a33-ga10h-v1.1.dts | 5 +-
arch/arm/dts/sun8i-a33-inet-d978-rev2.dts | 29 -
arch/arm/dts/sun8i-a33-olinuxino.dts | 66 ++-
arch/arm/dts/sun8i-a33-sinlinx-sina33.dts | 53 +++--
arch/arm/dts/sun8i-a33.dtsi | 63 --
arch/arm/dts/sun8i-q8-common.dtsi | 30 +
arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 3 +-
...sun8i-r16-nintendo-nes-classic-edition.dts | 2 -
arch/arm/dts/sun8i-r16-parrot.dts | 50
.../dts/sun8i-reference-design-tablet.dtsi| 59 -
18 files changed, 338 insertions(+), 232 deletions(-)
diff --git a/arch/arm/dts/sun8i-a23-a33.dtsi b/arch/arm/dts/sun8i-a23-a33.dtsi
index ffd21487dc..44f3cad3de 100644
--- a/arch/arm/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/dts/sun8i-a23-a33.dtsi
@@ -118,13 +118,13 @@
};
};
- soc@01c0 {
+ soc@1c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
- dma: dma-controller@01c02000 {
+ dma: dma-controller@1c02000 {
compatible = "allwinner,sun8i-a23-dma";
reg = <0x01c02000 0x1000>;
interrupts = ;
@@ -133,7 +133,7 @@
#dma-cells = <1>;
};
- mmc0: mmc@01c0f000 {
+ mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
clocks = < CLK_BUS_MMC0>,
@@ -152,7 +152,7 @@
#size-cells = <0>;
};
- mmc1: mmc@01c1 {
+ mmc1: mmc@1c1 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c1 0x1000>;
clocks = < CLK_BUS_MMC1>,
@@ -171,7 +171,7 @@
#size-cells = <0>;
};
- mmc2: mmc@01c11000 {
+ mmc2: mmc@1c11000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c11000 0x1000>;
clocks = < CLK_BUS_MMC2>,
@@ -190,7 +190,7 @@
#size-cells = <0>;
};
- nfc: nand@01c03000 {
+ nfc: nand@1c03000 {
compatible = "allwinner,sun4i-a10-nand";
reg = <0x01c03000 0x1000>;
interrupts = ;
@@ -198,12 +198,14 @@
clock-names = "ahb", "mod";
resets = < RST_BUS_NAND>;
reset-names = "ahb";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins _pins_cs0 _pins_rb0>;
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
};
- usb_otg: usb@01c19000 {
+ usb_otg: usb@1c19000 {
/* compatible gets set in SoC specific dtsi file */
reg = <0x01c19000 0x0400>;
clocks = < CLK_BUS_OTG>;
@@ -216,7 +218,7 @@
status = "disabled";
};
- usbphy: phy@01c19400 {
+ usbphy: phy@1c19400 {
/*
[U-Boot] [PATCH 3/7] ARM: dts: sun6i: Update A31/A31s dts(i) files from Linux
Update all A31/A31s devicetree dtsi and dtsi files from
Linux-v4.18-rc3 with below commit:
commit b240b419db5d624ce7a5a397d6f62a1a686009ec
Merge: 9c2dd8405c0c 518d2f43c358
Author: Linus Torvalds
Date: Thu Apr 5 21:18:09 2018 -0700
Merge tag 'armsoc-dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Signed-off-by: Jagan Teki
---
arch/arm/dts/sun6i-a31-app4-evb1.dts |7 +-
arch/arm/dts/sun6i-a31-colombus.dts | 26 +-
arch/arm/dts/sun6i-a31-hummingbird.dts| 153 ++-
arch/arm/dts/sun6i-a31-i7.dts | 82 +-
arch/arm/dts/sun6i-a31-m9.dts | 23 +-
arch/arm/dts/sun6i-a31-mele-a1000g-quad.dts | 23 +-
arch/arm/dts/sun6i-a31.dtsi | 1151 ++---
arch/arm/dts/sun6i-a31s-cs908.dts |2 -
arch/arm/dts/sun6i-a31s-primo81.dts | 69 +-
arch/arm/dts/sun6i-a31s-sina31s-core.dtsi |1 -
arch/arm/dts/sun6i-a31s-sina31s.dts | 77 +-
arch/arm/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 154 ++-
.../sun6i-a31s-yones-toptech-bs1078-v2.dts| 13 +-
arch/arm/dts/sun6i-a31s.dtsi |8 +
.../dts/sun6i-reference-design-tablet.dtsi| 18 +-
include/dt-bindings/clock/sun6i-a31-ccu.h | 191 +++
include/dt-bindings/reset/sun6i-a31-ccu.h | 106 ++
17 files changed, 1476 insertions(+), 628 deletions(-)
create mode 100644 include/dt-bindings/clock/sun6i-a31-ccu.h
create mode 100644 include/dt-bindings/reset/sun6i-a31-ccu.h
diff --git a/arch/arm/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/dts/sun6i-a31-app4-evb1.dts
index 2f8cfab771..7f34323a66 100644
--- a/arch/arm/dts/sun6i-a31-app4-evb1.dts
+++ b/arch/arm/dts/sun6i-a31-app4-evb1.dts
@@ -47,7 +47,6 @@
#include "sunxi-common-regulators.dtsi"
#include
-#include
/ {
model = "Allwinner A31 APP4 EVB1 Evaluation Board";
@@ -68,10 +67,8 @@
{
usb1_vbus_pin_a: usb1_vbus_pin@0 {
- allwinner,pins = "PH27";
- allwinner,function = "gpio_out";
- allwinner,drive = ;
- allwinner,pull = ;
+ pins = "PH27";
+ function = "gpio_out";
};
};
diff --git a/arch/arm/dts/sun6i-a31-colombus.dts
b/arch/arm/dts/sun6i-a31-colombus.dts
index f9cf36888d..939c497a6f 100644
--- a/arch/arm/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/dts/sun6i-a31-colombus.dts
@@ -47,7 +47,6 @@
#include "sunxi-common-regulators.dtsi"
#include
-#include
/ {
model = "WITS A31 Colombus Evaluation Board";
@@ -118,35 +117,30 @@
pinctrl-0 = <_pins_a>, <_cd_pin_colombus>;
vmmc-supply = <_vcc3v0>;
bus-width = <4>;
- cd-gpios = < 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
- cd-inverted;
+ cd-gpios = < 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
status = "okay";
};
_pins_a {
- allwinner,pull = ;
+ bias-pull-up;
};
{
mmc0_cd_pin_colombus: mmc0_cd_pin@0 {
- allwinner,pins = "PA8";
- allwinner,function = "gpio_in";
- allwinner,drive = ;
- allwinner,pull = ;
+ pins = "PA8";
+ function = "gpio_in";
+ bias-pull-up;
};
usb2_vbus_pin_colombus: usb2_vbus_pin@0 {
- allwinner,pins = "PH24";
- allwinner,function = "gpio_out";
- allwinner,drive = ;
- allwinner,pull = ;
+ pins = "PH24";
+ function = "gpio_out";
};
i2c_lcd_pins: i2c_lcd_pin@0 {
- allwinner,pins = "PA23", "PA24";
- allwinner,function = "gpio_out";
- allwinner,drive = ;
- allwinner,pull = ;
+ pins = "PA23", "PA24";
+ function = "gpio_out";
+ bias-pull-up;
};
};
diff --git a/arch/arm/dts/sun6i-a31-hummingbird.dts
b/arch/arm/dts/sun6i-a31-hummingbird.dts
index 9a74637f67..ce4f9e9834 100644
--- a/arch/arm/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/dts/sun6i-a31-hummingbird.dts
@@ -47,7 +47,6 @@
#include "sunxi-common-regulators.dtsi"
#include
-#include
/ {
model = "Merrii A31 Hummingbird";
@@ -63,16 +62,98 @@
stdout-path = "serial0:115200n8";
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
+ vga-connector {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <_dac_out>;
+ };
+ };
+ };
+
+ vga-dac {
+ compatible = "dumb-vga-dac";
+ vdd-supply = <_vga_3v3>;
+ #address-cells = <1>;
+
[U-Boot] [PATCH 0/7] ARM: dts: sunxi: Update dts(i) files from
This series is trying to update SoC dtsi and board dts files for Allwinner sun4i, 5i, 6i, 8i-a23/a33/a83t, r40 SoC's from Linux-4.18-rc3 These update is useful for supporting features CLK, RESET, DM_MMC etc Since H3/H5/A64 is already updated with Linux-4.18-rc3, this series use same version to maintain proper compatibility for all SoC platforms syncs. thanks, Jagan. Jagan Teki (7): ARM: dts: sun4i: Update A10 dts(i) files from Linux ARM: dts: sun5i: Update A10s/A13/gr8/r8 dts(i) files from Linux ARM: dts: sun6i: Update A31/A31s dts(i) files from Linux ARM: dts: sun7i: Update A20 dts(i) files from Linux ARM: dts: sun8i: Update A23/A33/r16 dts(i) files from Linux ARM: dts: sun8i: Update A83T dts(i) files from Linux ARM: dts: sun8i: Update R40/V40 dts(i) files from Linux arch/arm/dts/axp209.dtsi | 17 +- arch/arm/dts/axp81x.dtsi | 169 ++ arch/arm/dts/sun4i-a10-a1000.dts | 61 +- arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 23 +- arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts| 37 +- arch/arm/dts/sun4i-a10-cubieboard.dts | 67 +- arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 76 +- arch/arm/dts/sun4i-a10-gemei-g9.dts | 28 +- arch/arm/dts/sun4i-a10-hackberry.dts | 32 +- arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 31 +- arch/arm/dts/sun4i-a10-inet-3f.dts|2 +- arch/arm/dts/sun4i-a10-inet-3w.dts|2 +- arch/arm/dts/sun4i-a10-inet1.dts | 58 +- arch/arm/dts/sun4i-a10-inet97fv2.dts | 41 +- arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 101 +- .../dts/sun4i-a10-itead-iteaduino-plus.dts| 24 +- arch/arm/dts/sun4i-a10-jesurun-q5.dts | 34 +- arch/arm/dts/sun4i-a10-marsboard.dts | 38 +- arch/arm/dts/sun4i-a10-mini-xplus.dts | 16 +- arch/arm/dts/sun4i-a10-mk802.dts | 59 +- arch/arm/dts/sun4i-a10-mk802ii.dts|9 +- arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 75 +- arch/arm/dts/sun4i-a10-pcduino.dts| 47 +- arch/arm/dts/sun4i-a10-pcduino2.dts | 11 - arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 89 +- arch/arm/dts/sun4i-a10.dtsi | 1349 +++ arch/arm/dts/sun5i-a10s-auxtek-t003.dts | 26 +- arch/arm/dts/sun5i-a10s-auxtek-t004.dts | 42 +- arch/arm/dts/sun5i-a10s-mk802.dts | 24 +- arch/arm/dts/sun5i-a10s-olinuxino-micro.dts | 82 +- arch/arm/dts/sun5i-a10s-r7-tv-dongle.dts | 24 +- arch/arm/dts/sun5i-a10s-wobo-i5.dts | 29 +- arch/arm/dts/sun5i-a10s.dtsi | 224 +-- .../dts/sun5i-a13-empire-electronix-d709.dts | 29 +- arch/arm/dts/sun5i-a13-hsg-h702.dts | 29 +- arch/arm/dts/sun5i-a13-inet-98v-rev2.dts | 164 +- arch/arm/dts/sun5i-a13-olinuxino-micro.dts| 44 +- arch/arm/dts/sun5i-a13-olinuxino.dts | 100 +- arch/arm/dts/sun5i-a13-utoo-p66.dts | 49 +- arch/arm/dts/sun5i-a13.dtsi | 268 +-- arch/arm/dts/sun5i-gr8-chip-pro.dts | 16 +- arch/arm/dts/sun5i-gr8.dtsi | 1082 +--- arch/arm/dts/sun5i-r8-chip.dts| 91 +- arch/arm/dts/sun5i-r8.dtsi| 40 - .../dts/sun5i-reference-design-tablet.dtsi| 69 +- arch/arm/dts/sun5i.dtsi | 792 - arch/arm/dts/sun6i-a31-app4-evb1.dts |7 +- arch/arm/dts/sun6i-a31-colombus.dts | 26 +- arch/arm/dts/sun6i-a31-hummingbird.dts| 153 +- arch/arm/dts/sun6i-a31-i7.dts | 82 +- arch/arm/dts/sun6i-a31-m9.dts | 23 +- arch/arm/dts/sun6i-a31-mele-a1000g-quad.dts | 23 +- arch/arm/dts/sun6i-a31.dtsi | 1151 - arch/arm/dts/sun6i-a31s-cs908.dts |2 - arch/arm/dts/sun6i-a31s-primo81.dts | 69 +- arch/arm/dts/sun6i-a31s-sina31s-core.dtsi |1 - arch/arm/dts/sun6i-a31s-sina31s.dts | 77 +- arch/arm/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 154 +- .../sun6i-a31s-yones-toptech-bs1078-v2.dts| 13 +- arch/arm/dts/sun6i-a31s.dtsi |8 + .../dts/sun6i-reference-design-tablet.dtsi| 18 +- arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 32 +- arch/arm/dts/sun7i-a20-bananapi.dts | 106 +- arch/arm/dts/sun7i-a20-bananapro.dts | 73 +- arch/arm/dts/sun7i-a20-cubieboard2.dts| 56 +- arch/arm/dts/sun7i-a20-cubietruck.dts | 84 +- arch/arm/dts/sun7i-a20-hummingbird.dts| 30 +- arch/arm/dts/sun7i-a20-i12-tvbox.dts | 34 +- arch/arm/dts/sun7i-a20-icnova-swac.dts|6 +- arch/arm/dts/sun7i-a20-itead-ibox.dts | 12 +- arch/arm/dts/sun7i-a20-lamobo-r1.dts | 73 +- arch/arm/dts/sun7i-a20-m3.dts | 12 +- arch/arm/dts/sun7i-a20-mk808c.dts | 43 +-
Re: [U-Boot] Pull request: u-boot-sunxi/master
于 2018年8月5日 GMT+08:00 上午2:51:43, Tom Rini 写到: >On Sat, Aug 04, 2018 at 11:18:43PM +0530, Jagan Teki wrote: >> On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: >> > On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: >> >> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini >wrote: >> >> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: >> >> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > wrote: >> >> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini >wrote: >> >> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: >> >> >> >> >> >> >> >>> Hi Tom, >> >> >> >>> >> >> >> >>> Please pull this PR. >> >> >> >>> >> >> >> >>> thanks, >> >> >> >>> Jagan. >> >> >> >>> >> >> >> >>> The following changes since commit >5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: >> >> >> >>> >> >> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) >> >> >> >>> >> >> >> >>> are available in the Git repository at: >> >> >> >>> >> >> >> >>> git://git.denx.de/u-boot-sunxi.git master >> >> >> >>> >> >> >> >>> for you to fetch changes up to >89a897fc4d78e31332e5899e977d8bf3c82abafa: >> >> >> >>> >> >> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support >(2018-07-31 20:50:01 +0530) >> >> >> >>> >> >> >> >> >> >> >> >> For the moment, on hold. pine_h64 doesn't link (see >> >> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet >Andre's >> >> >> >> changes to save some space on aarch64 will get it to fit in, >and I need >> >> >> >> to see if I'm ready to apply them. >> >> >> > >> >> >> > I though of inform the same, but for h6 atf need to use it >from >> >> >> > mainline here all a64 boards seems failing. I didn't >reproduce this >> >> >> > manually. >> >> >> > >> >> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is >non-functional >> >> >> >> >> >> The cause is obvious. The ATF blob is missing from the >environment. >> >> >> If TravisCI is only used to test building, maybe we could just >put an >> >> >> empty bl31.bin there to make it happy. >> >> > >> >> > Please note that the above is NOT the problem. That's the >non-fatal >> >> > warning that your resulting binary won't work as there's no >bl31.bin. >> >> > The problem is: >> >> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will >not fit in region `.sram' >> >> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes >> >> > +make[2]: *** [spl/u-boot-spl] Error 1 >> >> > +make[1]: *** [spl/u-boot-spl] Error 2 >> >> > +make: *** [sub-make] Error 2 >> >> >> >> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 >> > >> > Travis-CI uses gcc-7.3 from kernel.org. >> >> Look like we have size issues wrt gcc versions, Icenowy tried glibc >> variant, 2018.07-3 bleeding edge and it work it seems. can't we >> upgrade Travis-CI to use the same or if not specific for h6? > >I'm testing Andre's series currently and that should resolve this Do you mention the exception handling series? BTW I made a patch to save ~200B, purely in sunxi codepath, simple, easier to review, and may solve the problem more quickly. I have sent the patch, it's named "sunxi: disable Pine A64 model detection code on non-A64 SoCs". >problem. But no, Travis-CI is using the toolchains that buildman >fetches and those are the must-work toolchains. It's the kernel.org >ones that Arnd sets up and are as vendor-neutral as we're going to get. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sunxi: disable Pine A64 model detection code on non-A64 SoCs
The Pine A64 Plus/non-Plus model detection code is now built on all
64-bit ARM SoCs, even if the code cannot be triggered when H5/H6 is in
use.
Disable them when the SoC is not A64 by use #ifdef to wrap them.
On GCC 7.3.1 this makes the size of the function reduces 184 bytes, and
saves a 104 byte strstr() function, then makes SPL on H6 succeed to
build.
Signed-off-by: Icenowy Zheng
---
board/sunxi/board.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 857d5ff010..4fb0ff2529 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -823,13 +823,14 @@ int board_fit_config_name_match(const char *name)
};
/* Differentiate the two Pine64 board DTs by their DRAM size. */
+#ifdef CONFIG_MACH_SUN50I
if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
if ((gd->ram_size > 512 * 1024 * 1024))
return !strstr(name, "plus");
else
return !!strstr(name, "plus");
- } else {
- return strcmp(name, cmp_str);
}
+#endif
+ return strcmp(name, cmp_str);
}
#endif
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
于 2018年8月5日 GMT+08:00 上午2:51:43, Tom Rini 写到: >On Sat, Aug 04, 2018 at 11:18:43PM +0530, Jagan Teki wrote: >> On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: >> > On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: >> >> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini >wrote: >> >> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: >> >> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > wrote: >> >> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini >wrote: >> >> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: >> >> >> >> >> >> >> >>> Hi Tom, >> >> >> >>> >> >> >> >>> Please pull this PR. >> >> >> >>> >> >> >> >>> thanks, >> >> >> >>> Jagan. >> >> >> >>> >> >> >> >>> The following changes since commit >5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: >> >> >> >>> >> >> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) >> >> >> >>> >> >> >> >>> are available in the Git repository at: >> >> >> >>> >> >> >> >>> git://git.denx.de/u-boot-sunxi.git master >> >> >> >>> >> >> >> >>> for you to fetch changes up to >89a897fc4d78e31332e5899e977d8bf3c82abafa: >> >> >> >>> >> >> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support >(2018-07-31 20:50:01 +0530) >> >> >> >>> >> >> >> >> >> >> >> >> For the moment, on hold. pine_h64 doesn't link (see >> >> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet >Andre's >> >> >> >> changes to save some space on aarch64 will get it to fit in, >and I need >> >> >> >> to see if I'm ready to apply them. >> >> >> > >> >> >> > I though of inform the same, but for h6 atf need to use it >from >> >> >> > mainline here all a64 boards seems failing. I didn't >reproduce this >> >> >> > manually. >> >> >> > >> >> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is >non-functional >> >> >> >> >> >> The cause is obvious. The ATF blob is missing from the >environment. >> >> >> If TravisCI is only used to test building, maybe we could just >put an >> >> >> empty bl31.bin there to make it happy. >> >> > >> >> > Please note that the above is NOT the problem. That's the >non-fatal >> >> > warning that your resulting binary won't work as there's no >bl31.bin. >> >> > The problem is: >> >> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will >not fit in region `.sram' >> >> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes >> >> > +make[2]: *** [spl/u-boot-spl] Error 1 >> >> > +make[1]: *** [spl/u-boot-spl] Error 2 >> >> > +make: *** [sub-make] Error 2 >> >> >> >> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 >> > >> > Travis-CI uses gcc-7.3 from kernel.org. >> >> Look like we have size issues wrt gcc versions, Icenowy tried glibc >> variant, 2018.07-3 bleeding edge and it work it seems. can't we >> upgrade Travis-CI to use the same or if not specific for h6? > >I'm testing Andre's series currently and that should resolve this BTW where's this series? >problem. But no, Travis-CI is using the toolchains that buildman >fetches and those are the must-work toolchains. It's the kernel.org >ones that Arnd sets up and are as vendor-neutral as we're going to get. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Sat, Aug 04, 2018 at 11:18:43PM +0530, Jagan Teki wrote: > On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: > > On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: > >> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini wrote: > >> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: > >> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > >> >> wrote: > >> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini wrote: > >> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: > >> >> >> > >> >> >>> Hi Tom, > >> >> >>> > >> >> >>> Please pull this PR. > >> >> >>> > >> >> >>> thanks, > >> >> >>> Jagan. > >> >> >>> > >> >> >>> The following changes since commit > >> >> >>> 5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: > >> >> >>> > >> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) > >> >> >>> > >> >> >>> are available in the Git repository at: > >> >> >>> > >> >> >>> git://git.denx.de/u-boot-sunxi.git master > >> >> >>> > >> >> >>> for you to fetch changes up to > >> >> >>> 89a897fc4d78e31332e5899e977d8bf3c82abafa: > >> >> >>> > >> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support > >> >> >>> (2018-07-31 20:50:01 +0530) > >> >> >>> > >> >> >> > >> >> >> For the moment, on hold. pine_h64 doesn't link (see > >> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet Andre's > >> >> >> changes to save some space on aarch64 will get it to fit in, and I > >> >> >> need > >> >> >> to see if I'm ready to apply them. > >> >> > > >> >> > I though of inform the same, but for h6 atf need to use it from > >> >> > mainline here all a64 boards seems failing. I didn't reproduce this > >> >> > manually. > >> >> > > >> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is > >> >> > non-functional > >> >> > >> >> The cause is obvious. The ATF blob is missing from the environment. > >> >> If TravisCI is only used to test building, maybe we could just put an > >> >> empty bl31.bin there to make it happy. > >> > > >> > Please note that the above is NOT the problem. That's the non-fatal > >> > warning that your resulting binary won't work as there's no bl31.bin. > >> > The problem is: > >> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in > >> > region `.sram' > >> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes > >> > +make[2]: *** [spl/u-boot-spl] Error 1 > >> > +make[1]: *** [spl/u-boot-spl] Error 2 > >> > +make: *** [sub-make] Error 2 > >> > >> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 > > > > Travis-CI uses gcc-7.3 from kernel.org. > > Look like we have size issues wrt gcc versions, Icenowy tried glibc > variant, 2018.07-3 bleeding edge and it work it seems. can't we > upgrade Travis-CI to use the same or if not specific for h6? I'm testing Andre's series currently and that should resolve this problem. But no, Travis-CI is using the toolchains that buildman fetches and those are the must-work toolchains. It's the kernel.org ones that Arnd sets up and are as vendor-neutral as we're going to get. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 2018.09-rc1 breakage on orangepi pc2
> From: Heinrich Schuchardt > Date: Sat, 4 Aug 2018 14:21:17 +0200 > > On 08/03/2018 12:07 AM, Mark Kettenis wrote: > >> Date: Thu, 2 Aug 2018 22:55:23 +0200 (CEST) > >> From: Mark Kettenis > >> > >> I can no longer boot OpenBSD on the orangepi pc2. The kernel faults > >> somewhere in the EFI detection code, almost certainly where it looks > >> through the configuration table entries looking for the ACPI table. > >> I've bisected this resulting in: > >> > >> > >> 4182a129ef735bfd6c54788affe1b649ab85b851 is the first bad commit > >> commit 4182a129ef735bfd6c54788affe1b649ab85b851 > >> Author: Heinrich Schuchardt > >> Date: Thu Jun 28 12:45:32 2018 +0200 > >> > >> efi_loader: allocate configuration table array > >> > >> The system table contains a link to the list of configurations tables. > >> These include the device tree, SMBIOS table, and the ACPI table. > >> > >> This array is currently statically linked. With the patch it is > >> allocated > >> as EFI_RUNTIME_SERVICES_DATA. Due to the structure of the system table > >> we > >> cannot work with a linked list here. > >> > >> Signed-off-by: Heinrich Schuchardt > >> Reviewed-by: Bin Meng > >> Signed-off-by: Alexander Graf > > > > So after this commit, the ConfigurationTable field of the system table > > is no longer translated from a physical address into a virtual address > > when the SerVirtualAddressMap() runtime service gets called. > > > > The way SetVirtualAddressMap() is implemented is actually quite nify. > > It "relocates" the relevant bits by processing the ELF relocations for > > everything that is marked as __efi_runtime_data. This magically > > modifies all the pointers in the system table that reference other > > symbols, such as firmware_vendor, efi_runtime_services and > > efi_conf_table. But since the diff replaces the reference to > > efi_conf_table with a dynamically updated pointer, there no longer is > > a relocation for the tables member. > > > >>From the commit message it isn't abvious what is being fixed. I think > > the commit should be reverted. > > > Hello Mark, > > thanks for pointing out the following requirement from the UEFI spec > that is not correctly implemented: > > "Several fields of the EFI System Table must be converted from physical > pointers to virtual pointers using the ConvertPointer() service. These > fields include FirmwareVendor, RuntimeServices, and ConfigurationTable." Sorry, but that functionality was implemented and it still works for the FirmwareVendor and RuntimeServices fields. Your commit introduced a regression by breaking this functionality for the ConfigurationTable field. This regression should really be fixed before 2018.09 gets released. > I am currently testing a patch for this. Great. Although I still don't understand what your commit is trying to fix. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
于 2018年8月5日 GMT+08:00 上午1:48:43, Jagan Teki 写到: >On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: >> On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: >>> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini wrote: >>> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: >>> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > wrote: >>> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini >wrote: >>> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: >>> >> >> >>> >> >>> Hi Tom, >>> >> >>> >>> >> >>> Please pull this PR. >>> >> >>> >>> >> >>> thanks, >>> >> >>> Jagan. >>> >> >>> >>> >> >>> The following changes since commit >5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: >>> >> >>> >>> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) >>> >> >>> >>> >> >>> are available in the Git repository at: >>> >> >>> >>> >> >>> git://git.denx.de/u-boot-sunxi.git master >>> >> >>> >>> >> >>> for you to fetch changes up to >89a897fc4d78e31332e5899e977d8bf3c82abafa: >>> >> >>> >>> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support >(2018-07-31 20:50:01 +0530) >>> >> >>> >>> >> >> >>> >> >> For the moment, on hold. pine_h64 doesn't link (see >>> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet >Andre's >>> >> >> changes to save some space on aarch64 will get it to fit in, >and I need >>> >> >> to see if I'm ready to apply them. >>> >> > >>> >> > I though of inform the same, but for h6 atf need to use it from >>> >> > mainline here all a64 boards seems failing. I didn't reproduce >this >>> >> > manually. >>> >> > >>> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is >non-functional >>> >> >>> >> The cause is obvious. The ATF blob is missing from the >environment. >>> >> If TravisCI is only used to test building, maybe we could just >put an >>> >> empty bl31.bin there to make it happy. >>> > >>> > Please note that the above is NOT the problem. That's the >non-fatal >>> > warning that your resulting binary won't work as there's no >bl31.bin. >>> > The problem is: >>> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not >fit in region `.sram' >>> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes >>> > +make[2]: *** [spl/u-boot-spl] Error 1 >>> > +make[1]: *** [spl/u-boot-spl] Error 2 >>> > +make: *** [sub-make] Error 2 >>> >>> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 >> >> Travis-CI uses gcc-7.3 from kernel.org. > >Look like we have size issues wrt gcc versions, Icenowy tried glibc >variant, 2018.07-3 bleeding edge and it work it seems. can't we >upgrade Travis-CI to use the same or if not specific for h6? I will soon push a patch that disables Pine A64 plus/non-plus detection code on non-A64 SoCs (clearly these code doesn't apply to H5/H6, as there's no Pine A64/Pine A64+ with H5/H6 :-) ) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
于 2018年8月5日 GMT+08:00 上午1:48:43, Jagan Teki 写到: >On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: >> On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: >>> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini wrote: >>> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: >>> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > wrote: >>> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini >wrote: >>> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: >>> >> >> >>> >> >>> Hi Tom, >>> >> >>> >>> >> >>> Please pull this PR. >>> >> >>> >>> >> >>> thanks, >>> >> >>> Jagan. >>> >> >>> >>> >> >>> The following changes since commit >5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: >>> >> >>> >>> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) >>> >> >>> >>> >> >>> are available in the Git repository at: >>> >> >>> >>> >> >>> git://git.denx.de/u-boot-sunxi.git master >>> >> >>> >>> >> >>> for you to fetch changes up to >89a897fc4d78e31332e5899e977d8bf3c82abafa: >>> >> >>> >>> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support >(2018-07-31 20:50:01 +0530) >>> >> >>> >>> >> >> >>> >> >> For the moment, on hold. pine_h64 doesn't link (see >>> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet >Andre's >>> >> >> changes to save some space on aarch64 will get it to fit in, >and I need >>> >> >> to see if I'm ready to apply them. >>> >> > >>> >> > I though of inform the same, but for h6 atf need to use it from >>> >> > mainline here all a64 boards seems failing. I didn't reproduce >this >>> >> > manually. >>> >> > >>> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is >non-functional >>> >> >>> >> The cause is obvious. The ATF blob is missing from the >environment. >>> >> If TravisCI is only used to test building, maybe we could just >put an >>> >> empty bl31.bin there to make it happy. >>> > >>> > Please note that the above is NOT the problem. That's the >non-fatal >>> > warning that your resulting binary won't work as there's no >bl31.bin. >>> > The problem is: >>> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not >fit in region `.sram' >>> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes >>> > +make[2]: *** [spl/u-boot-spl] Error 1 >>> > +make[1]: *** [spl/u-boot-spl] Error 2 >>> > +make: *** [sub-make] Error 2 >>> >>> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 >> >> Travis-CI uses gcc-7.3 from kernel.org. > >Look like we have size issues wrt gcc versions, Icenowy tried glibc >variant, 2018.07-3 bleeding edge and it work it seems. can't we >upgrade Travis-CI to use the same or if not specific for h6? I have a commit from Vasily that can reduce ~100B of SPL. It can be applied to workaround this, but I don't want to use it so early. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Thu, Aug 2, 2018 at 4:43 PM, Tom Rini wrote: > On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: >> On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini wrote: >> > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: >> >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki >> >> wrote: >> >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini wrote: >> >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: >> >> >> >> >> >>> Hi Tom, >> >> >>> >> >> >>> Please pull this PR. >> >> >>> >> >> >>> thanks, >> >> >>> Jagan. >> >> >>> >> >> >>> The following changes since commit >> >> >>> 5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: >> >> >>> >> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) >> >> >>> >> >> >>> are available in the Git repository at: >> >> >>> >> >> >>> git://git.denx.de/u-boot-sunxi.git master >> >> >>> >> >> >>> for you to fetch changes up to >> >> >>> 89a897fc4d78e31332e5899e977d8bf3c82abafa: >> >> >>> >> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support >> >> >>> (2018-07-31 20:50:01 +0530) >> >> >>> >> >> >> >> >> >> For the moment, on hold. pine_h64 doesn't link (see >> >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet Andre's >> >> >> changes to save some space on aarch64 will get it to fit in, and I need >> >> >> to see if I'm ready to apply them. >> >> > >> >> > I though of inform the same, but for h6 atf need to use it from >> >> > mainline here all a64 boards seems failing. I didn't reproduce this >> >> > manually. >> >> > >> >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is >> >> > non-functional >> >> >> >> The cause is obvious. The ATF blob is missing from the environment. >> >> If TravisCI is only used to test building, maybe we could just put an >> >> empty bl31.bin there to make it happy. >> > >> > Please note that the above is NOT the problem. That's the non-fatal >> > warning that your resulting binary won't work as there's no bl31.bin. >> > The problem is: >> > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in >> > region `.sram' >> > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes >> > +make[2]: *** [spl/u-boot-spl] Error 1 >> > +make[1]: *** [spl/u-boot-spl] Error 2 >> > +make: *** [sub-make] Error 2 >> >> ie what, I'm able to built manually pine_h64 with gcc-6.3.1 > > Travis-CI uses gcc-7.3 from kernel.org. Look like we have size issues wrt gcc versions, Icenowy tried glibc variant, 2018.07-3 bleeding edge and it work it seems. can't we upgrade Travis-CI to use the same or if not specific for h6? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: don't allocate unusable RAM
On 08/04/2018 10:56 AM, Heinrich Schuchardt wrote: > On 08/02/2018 07:00 PM, Stephen Warren wrote: >> On 08/01/2018 11:57 PM, Heinrich Schuchardt wrote: >>> On 08/01/2018 06:17 PM, Stephen Warren wrote: On 08/01/2018 12:07 AM, Heinrich Schuchardt wrote: > On 07/31/2018 09:44 PM, Stephen Warren wrote: >> From: Stephen Warren >> >> Some boards define a maximum usable RAM top that's more restrictive >> than >> the ranges defined by U-Boot's memory bank definitions[1]. In this >> case, >> the unusable RAM isn't mapped in the page tables, and so the EFI code >> must >> not attempt to allocate RAM from outside the usable regions. Fix >> efi_find_free_memory() to detect when max_addr is unconstrained or >> out of >> range, and substitue a valid value. >> > > In this case the board has to call efi_add_memory_map() to mark the > reserved region (cf. board/raspberrypi/rpi/rpi.c) or have to mark the > memory region as reserved in the device tree (see > efi_carve_out_dt_rsv()). > > Please, check if the tegra boards with which you had problems do so. I don't think this makes sense; memory should be managed the same way within U-Boot no matter which part of U-Boot is consuming that memory. Memory regions are currently represented by the content of the memory bank definitions and gd->ram_top. Having different parts of the code define legal RAM usage in different ways is horribly inconsistent. >>> >>> Memory banks and gd->top together cannot reflect unusable memory regions >>> in the middle of the RAM area. >> >> Sure this is possible. For example, a common set of memory banks for >> Tegra is: >> >> bank 0: >> start: 0x08000 >> length: 0x07000 >> limit: 0x0f000 >> bank 1: >> start: 0x1 >> length: 0x08000 >> limit: 0x18000 >> >> gd->ram_top = 0x0f000 >> That is set so that U-Boot itself (not just the UEFI code) doesn't use >> RAM above 4GB due to HW peripherals that can't access such RAM. The RAM >> above 4GB is left in the DRAM banks so that the kernel can use it for >> non-DMA purposes > > Hello Stephen, > > this explanation makes the problem much clearer. Memory usable by the > operating system but not by the firmware cannot be expressed in the > device tree. > > If bank 1 cannot be used by U-Boot but can be used by the operating > system we should mark it as EFI_BOOT_SERVICES_DATA by calling > efi_add_memory_map() in arch/arm/mach-tegra/board2.c. This will indicate > to the operating system that it may use this memory after exiting boot > services and the U-Boot EFI subsystem will not use this region. This > call could be done in dram_init_banksize(). > > Could you give this a try, please. Please revert the patch first, then we can fix this later (I sent the revert as a patch already). I'm leaving on vacation right now, so won't be able to look at this for at least 2 weeks. We need to fix the regression immediately. Equally, EFI shouldn't require boards to provide memory information to U-Boot in a different way than the rest of U-Boot as I mentioned, so even if this WAR works, it doesn't sound scalable across all boards. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 00/13] Allwinner H6 support (w/ SPL)
于 2018年8月5日 GMT+08:00 上午12:36:14, Jagan Teki 写到:
>On Sat, Aug 4, 2018 at 9:36 PM, Icenowy Zheng wrote:
>> 在 2018-07-31二的 11:30 +0530，Jagan Teki写道：
>>> On Sat, Jul 21, 2018 at 1:50 PM, Icenowy Zheng
>>> wrote:
>>> > This patchset trys to add support for Allwinner H6 SoC to U-Boot.
>>> >
>>> > Allwinner H6 is a quite new Allwinner SoC, with several parts
>>> > changed a
>>> > lot (memory map, DRAM controller, CCU, so on). The position which
>>> > SPL
>>> > will be loaded (SRAM A1) also changed to 0x2.
>>> >
>>> > The Pine H64 board support comes with this patchset, as this is
>the
>>> > first H6 board that I can get (being early bird).
>>> >
>>> > Icenowy Zheng (13):
>>> > sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS
>>> > sunxi: add basic memory map definitions of H6 SoC
>>> > sunxi: change RMR64's RVBAR address for H6
>>> > sunxi: change ATF position for H6
>>> > sunxi: add config for SPL at 0x2 on H6
>>> > sunxi: change GIC address on H6
>>> > sunxi: add clock code for H6
>>> > sunxi: use sun6i-style watchdog for H6
>>> > sunxi: add UART0 setup for H6
>>> > sunxi: add MMC support for H6
>>> > sunxi: add DRAM support to H6
>>>
>>> Replaced with v2.1 [3]
>>>
>>> > sunxi: add support for Allwinner H6 SoC
>>> > sunxi: add support for Pine H64 board
>>>
>>> Applied to u-boot-sunxi/master
>>>
>>> [3] https://patchwork.ozlabs.org/patch/947557/
>>
>> I tried to build 89a897fc4d ("board: sun50i: h6: Add OrangePi One
>Plus
>> initial support"), and with GCC 7.3.0 and binutils 2.3.0 I got
>"region
>> `.sram' overflowed by 56 bytes".
>
>Yes, with pine_h64 with 7.3 [1]
>
>aarch64-linux-gnu-ld.bfd: u-boot-spl section `.u_boot_list' will not
>fit in region `.sram'
>aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 16 bytes
>make[1]: *** [spl/u-boot-spl] Error 1
>make: *** [spl/u-boot-spl] Error 2
With 8.2 from bootlin (glibc variant, 2018.07-3 bleeding
edge), I successfully built it for pine h64.
>
>Any inputs?
>
>[1]
>https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: don't allocate unusable RAM
On 08/02/2018 07:00 PM, Stephen Warren wrote: > On 08/01/2018 11:57 PM, Heinrich Schuchardt wrote: >> On 08/01/2018 06:17 PM, Stephen Warren wrote: >>> On 08/01/2018 12:07 AM, Heinrich Schuchardt wrote: On 07/31/2018 09:44 PM, Stephen Warren wrote: > From: Stephen Warren > > Some boards define a maximum usable RAM top that's more restrictive > than > the ranges defined by U-Boot's memory bank definitions[1]. In this > case, > the unusable RAM isn't mapped in the page tables, and so the EFI code > must > not attempt to allocate RAM from outside the usable regions. Fix > efi_find_free_memory() to detect when max_addr is unconstrained or > out of > range, and substitue a valid value. > In this case the board has to call efi_add_memory_map() to mark the reserved region (cf. board/raspberrypi/rpi/rpi.c) or have to mark the memory region as reserved in the device tree (see efi_carve_out_dt_rsv()). Please, check if the tegra boards with which you had problems do so. >>> >>> I don't think this makes sense; memory should be managed the same way >>> within U-Boot no matter which part of U-Boot is consuming that memory. >>> Memory regions are currently represented by the content of the memory >>> bank definitions and gd->ram_top. Having different parts of the code >>> define legal RAM usage in different ways is horribly inconsistent. >> >> Memory banks and gd->top together cannot reflect unusable memory regions >> in the middle of the RAM area. > > Sure this is possible. For example, a common set of memory banks for > Tegra is: > > bank 0: > start: 0x08000 > length: 0x07000 > limit: 0x0f000 > bank 1: > start: 0x1 > length: 0x08000 > limit: 0x18000 > > gd->ram_top = 0x0f000 > That is set so that U-Boot itself (not just the UEFI code) doesn't use > RAM above 4GB due to HW peripherals that can't access such RAM. The RAM > above 4GB is left in the DRAM banks so that the kernel can use it for > non-DMA purposes Hello Stephen, this explanation makes the problem much clearer. Memory usable by the operating system but not by the firmware cannot be expressed in the device tree. If bank 1 cannot be used by U-Boot but can be used by the operating system we should mark it as EFI_BOOT_SERVICES_DATA by calling efi_add_memory_map() in arch/arm/mach-tegra/board2.c. This will indicate to the operating system that it may use this memory after exiting boot services and the U-Boot EFI subsystem will not use this region. This call could be done in dram_init_banksize(). Could you give this a try, please. Best regards Heinrich > > That represents a hole at 0xf000..0x1. > >> To be consistent reflect all information in the device tree and >> calculate gd->ram_top from the device tree information. > > Nothing in U-Boot that I'm aware of gets RAM information from DT. It all > comes from the banks in gd. That's set up by some early low level code > in arch/arm/mach-tegra/board2.c, which at least upstream hard-codes the > size of the RAM gap below 4G rather than getting information from either > DT or the earlier FW loads. So, I'm not sure what DT has to do with this. > >>> At this point, I think the best thing is to revert aa909462d018 >>> "efi_loader: efi_allocate_pages is too restrictive" since it causes a >>> regression on Jetson TX1, and we can work out the correct way to fix all >>> this once the system is working again. >>> >> >> The situation before the patch was really buggy. It is sufficient if you >> get the Jetson device tree right. > > What bugs specifically? Perhaps there's a better way to fix them. > > Anyway, there was agreement in other messages in the thread to revert > the problematic patch to avoid breaking the code while we work on a more > complete solution. That's about all I can do right now since I'm heading > off on vacation for a couple of weeks and would rather we have a working > U-Boot running in the test farm during that time so that any other bugs > that are introduced get caught rather than hidden. I'll send the revert. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 00/13] Allwinner H6 support (w/ SPL)
On Sat, Aug 4, 2018 at 9:36 PM, Icenowy Zheng wrote:
> 在 2018-07-31二的 11:30 +0530，Jagan Teki写道：
>> On Sat, Jul 21, 2018 at 1:50 PM, Icenowy Zheng
>> wrote:
>> > This patchset trys to add support for Allwinner H6 SoC to U-Boot.
>> >
>> > Allwinner H6 is a quite new Allwinner SoC, with several parts
>> > changed a
>> > lot (memory map, DRAM controller, CCU, so on). The position which
>> > SPL
>> > will be loaded (SRAM A1) also changed to 0x2.
>> >
>> > The Pine H64 board support comes with this patchset, as this is the
>> > first H6 board that I can get (being early bird).
>> >
>> > Icenowy Zheng (13):
>> > sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS
>> > sunxi: add basic memory map definitions of H6 SoC
>> > sunxi: change RMR64's RVBAR address for H6
>> > sunxi: change ATF position for H6
>> > sunxi: add config for SPL at 0x2 on H6
>> > sunxi: change GIC address on H6
>> > sunxi: add clock code for H6
>> > sunxi: use sun6i-style watchdog for H6
>> > sunxi: add UART0 setup for H6
>> > sunxi: add MMC support for H6
>> > sunxi: add DRAM support to H6
>>
>> Replaced with v2.1 [3]
>>
>> > sunxi: add support for Allwinner H6 SoC
>> > sunxi: add support for Pine H64 board
>>
>> Applied to u-boot-sunxi/master
>>
>> [3] https://patchwork.ozlabs.org/patch/947557/
>
> I tried to build 89a897fc4d ("board: sun50i: h6: Add OrangePi One Plus
> initial support"), and with GCC 7.3.0 and binutils 2.3.0 I got "region
> `.sram' overflowed by 56 bytes".
Yes, with pine_h64 with 7.3 [1]
aarch64-linux-gnu-ld.bfd: u-boot-spl section `.u_boot_list' will not
fit in region `.sram'
aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 16 bytes
make[1]: *** [spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl] Error 2
Any inputs?
[1]
https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks, Jagan. The following changes since commit a839c3641e4de98981695056eeeb2ec17ba1a4ab: ARM: tegra: align carveout size (2018-08-01 20:06:10 -0400) are available in the Git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 7f25d8179776226a8ecfbaad3d3a88e9acd89f28: arm: sunxi: Allwinner A10 SPI driver (2018-08-03 11:14:08 +0530) Chris Packham (1): spi: kirkwood: add orion-spi compatible string Clément Laigle (1): mtd: add spi flash id s25fl128l Jagan Teki (1): spi: kirkwood: Get drvdata in .ofdata_to_platdata Stefan Mavrodiev (1): arm: sunxi: Allwinner A10 SPI driver drivers/mtd/spi/spi_flash_ids.c | 1 + drivers/spi/Kconfig | 5 + drivers/spi/Makefile| 1 + drivers/spi/kirkwood_spi.c | 16 +- drivers/spi/sun4i_spi.c | 456 5 files changed, 476 insertions(+), 3 deletions(-) create mode 100644 drivers/spi/sun4i_spi.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 00/13] Allwinner H6 support (w/ SPL)
在 2018-07-31二的 11:30 +0530，Jagan Teki写道：
> On Sat, Jul 21, 2018 at 1:50 PM, Icenowy Zheng
> wrote:
> > This patchset trys to add support for Allwinner H6 SoC to U-Boot.
> >
> > Allwinner H6 is a quite new Allwinner SoC, with several parts
> > changed a
> > lot (memory map, DRAM controller, CCU, so on). The position which
> > SPL
> > will be loaded (SRAM A1) also changed to 0x2.
> >
> > The Pine H64 board support comes with this patchset, as this is the
> > first H6 board that I can get (being early bird).
> >
> > Icenowy Zheng (13):
> > sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS
> > sunxi: add basic memory map definitions of H6 SoC
> > sunxi: change RMR64's RVBAR address for H6
> > sunxi: change ATF position for H6
> > sunxi: add config for SPL at 0x2 on H6
> > sunxi: change GIC address on H6
> > sunxi: add clock code for H6
> > sunxi: use sun6i-style watchdog for H6
> > sunxi: add UART0 setup for H6
> > sunxi: add MMC support for H6
> > sunxi: add DRAM support to H6
>
> Replaced with v2.1 [3]
>
> > sunxi: add support for Allwinner H6 SoC
> > sunxi: add support for Pine H64 board
>
> Applied to u-boot-sunxi/master
>
> [3] https://patchwork.ozlabs.org/patch/947557/
I tried to build 89a897fc4d ("board: sun50i: h6: Add OrangePi One Plus
initial support"), and with GCC 7.3.0 and binutils 2.3.0 I got "region
`.sram' overflowed by 56 bytes".
>
> Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] armv5 and OMAP3 Question
On Sat, Aug 04, 2018 at 09:39:12AM -0500, Adam Ford wrote:
> On Sat, Aug 4, 2018 at 6:44 AM Tom Rini wrote:
> >
> > On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
> > > On Fri, Aug 3, 2018 at 10:20 AM Tom Rini wrote:
> > > >
> > > > On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
> > > > > On Fri, Aug 3, 2018 at 10:00 AM Tom Rini wrote:
> > > > > >
> > > > > > On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
> > > > > > > On Tue, Jul 25, 2017 at 11:08 AM Tom Rini
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
> > > > > > > >
> > > > > > > > > The readme file for OMAP indicates that we compile using
> > > > > > > > > armv5 to "to
> > > > > > > > > allow more compilers to work"
> > > > > > > > >
> > > > > > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file
> > > > > > > > > also noting
> > > > > > > > > some special assembly insturctions becuse we use armv5. The
> > > > > > > > > barriers
> > > > > > > > > defined also indicate we're using CP15 instead of the
> > > > > > > > > separate barrier
> > > > > > > > > instructions for armv7 because we're using armv5 instead.
> > > > > > > > >
> > > > > > > > > I just wonder in this day and age when we're noting a GCC
> > > > > > > > > version and
> > > > > > > > > generating warnings based on the GCC warning, do we still
> > > > > > > > > need to
> > > > > > > > > compile as armv5 any more? It seems like "to allow more
> > > > > > > > > compilers to
> > > > > > > > > work" would not really apply any more we're trying to push
> > > > > > > > > newer
> > > > > > > > > versions of GCC.
> > > > > > > >
> > > > > > > > So, these are historical notes that really should be corrected.
> > > > > > > > Initially, when ARMv7 support was added, most people did not
> > > > > > > > have
> > > > > > > > compilers new enough to recognize -march=armv7-a. We still
> > > > > > > > even support
> > > > > > > > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7
> > > > > > > > (the
> > > > > > > > options are any sort of modern gcc, llvm, ancient gcc). When
> > > > > > > > we move to
> > > > > > > > gcc-6 being the oldest gcc supported for ARM we can fixup those
> > > > > > > > comments
> > > > > > > > and logic as well.
> > > > > > >
> > > > > > > My understanding is that we've made the requirement for GCC 6
> > > > > > > now. I
> > > > > > > just pushed a patch which enabled mtune=armv7-a-generic when
> > > > > > > CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit
> > > > > > > on
> > > > > > > omap3_logic. Does it make sense to remove the , -march=armv5 from
> > > > > > > arch/arm/Makefile and or the plain -march=armv7 since
> > > > > > > CONFIG_CPU_V7A
> > > > > > > implies armv-a?
> > > > > >
> > > > > > Yes, we can probably at least drop the v5 portion of that logic. As
> > > > > > noted in the other patch, LLVM and GCC disagree on "armv7" vs
> > > > > > "armv7-a"
> > > > > > as being the appropriate name, or at least did in the past.
> > > > >
> > > > > Can you point me to an example of how to tune armv7 for both GCC and
> > > > > LLVM? I was looking around and I'm not seeing an obvious syntax.
> > > > > I'll do a 2-part patch. One to remove the armv5, and one to enable
> > > > > the armv7 optimization.
> > > >
> > > > In arch/arm/Makefile:
> > > > arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
> > > > $(call cc-option, -march=armv7,
> > > > -march=armv5))
> > > >
> > > > this works in both cases. And doc/README.clang is correct on how to
> > > > build with LLVM on ARM.
> > >
> > > I reset my head to origin/master, but using the following, I am not
> > > able to build omap3_logic with clang on Ubuntu 18.04:
> > >
> > > make HOSTCC=clang omap3_logic
> > > make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
> > > CC="clang -target arm-linux-gnueabi" -j8
> > >
> > > arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT
> > > block
> > > stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
> > > ^
> > > arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT
> > > block
> > > stmiage ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT
> > > block
> > > stmiage ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT
> > > block
> > > stmiage ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT
> > > block
> > > ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go.
> > > ^
> > > arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT
> > > block
> > > stmiane ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT
> > > block
> > > stmiane ip!, {r1, r3, r8, lr}
> > > ^
> > >
Re: [U-Boot] armv5 and OMAP3 Question
On Sat, Aug 4, 2018 at 6:44 AM Tom Rini wrote:
>
> On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
> > On Fri, Aug 3, 2018 at 10:20 AM Tom Rini wrote:
> > >
> > > On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
> > > > On Fri, Aug 3, 2018 at 10:00 AM Tom Rini wrote:
> > > > >
> > > > > On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
> > > > > > On Tue, Jul 25, 2017 at 11:08 AM Tom Rini
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
> > > > > > >
> > > > > > > > The readme file for OMAP indicates that we compile using armv5
> > > > > > > > to "to
> > > > > > > > allow more compilers to work"
> > > > > > > >
> > > > > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also
> > > > > > > > noting
> > > > > > > > some special assembly insturctions becuse we use armv5. The
> > > > > > > > barriers
> > > > > > > > defined also indicate we're using CP15 instead of the separate
> > > > > > > > barrier
> > > > > > > > instructions for armv7 because we're using armv5 instead.
> > > > > > > >
> > > > > > > > I just wonder in this day and age when we're noting a GCC
> > > > > > > > version and
> > > > > > > > generating warnings based on the GCC warning, do we still need
> > > > > > > > to
> > > > > > > > compile as armv5 any more? It seems like "to allow more
> > > > > > > > compilers to
> > > > > > > > work" would not really apply any more we're trying to push newer
> > > > > > > > versions of GCC.
> > > > > > >
> > > > > > > So, these are historical notes that really should be corrected.
> > > > > > > Initially, when ARMv7 support was added, most people did not have
> > > > > > > compilers new enough to recognize -march=armv7-a. We still even
> > > > > > > support
> > > > > > > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the
> > > > > > > options are any sort of modern gcc, llvm, ancient gcc). When we
> > > > > > > move to
> > > > > > > gcc-6 being the oldest gcc supported for ARM we can fixup those
> > > > > > > comments
> > > > > > > and logic as well.
> > > > > >
> > > > > > My understanding is that we've made the requirement for GCC 6 now.
> > > > > > I
> > > > > > just pushed a patch which enabled mtune=armv7-a-generic when
> > > > > > CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on
> > > > > > omap3_logic. Does it make sense to remove the , -march=armv5 from
> > > > > > arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A
> > > > > > implies armv-a?
> > > > >
> > > > > Yes, we can probably at least drop the v5 portion of that logic. As
> > > > > noted in the other patch, LLVM and GCC disagree on "armv7" vs
> > > > > "armv7-a"
> > > > > as being the appropriate name, or at least did in the past.
> > > >
> > > > Can you point me to an example of how to tune armv7 for both GCC and
> > > > LLVM? I was looking around and I'm not seeing an obvious syntax.
> > > > I'll do a 2-part patch. One to remove the armv5, and one to enable
> > > > the armv7 optimization.
> > >
> > > In arch/arm/Makefile:
> > > arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
> > > $(call cc-option, -march=armv7,
> > > -march=armv5))
> > >
> > > this works in both cases. And doc/README.clang is correct on how to
> > > build with LLVM on ARM.
> >
> > I reset my head to origin/master, but using the following, I am not
> > able to build omap3_logic with clang on Ubuntu 18.04:
> >
> > make HOSTCC=clang omap3_logic
> > make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
> > CC="clang -target arm-linux-gnueabi" -j8
> >
> > arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT
> > block
> > stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
> > ^
> > arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT
> > block
> > stmiage ip!, {r1, r3, r8, lr}
> > ^
> > arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT
> > block
> > stmiage ip!, {r1, r3, r8, lr}
> > ^
> > arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT
> > block
> > stmiage ip!, {r1, r3, r8, lr}
> > ^
> > arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT
> > block
> > ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go.
> > ^
> > arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT
> > block
> > stmiane ip!, {r1, r3, r8, lr}
> > ^
> > arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT
> > block
> > stmiane ip!, {r1, r3, r8, lr}
> > ^
> > arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT
> > block
> > stmiane ip!, {r1, r3, r8, lr}
> > ^
> > arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT
> > block
> > stmiane ip!, {r1, r3}
> > ^
> > arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT
> > block
> > strne r1, [ip],
[U-Boot] [PATCH 2/2] sunxi: SPI: reset bus when enabling clock
--- drivers/spi/sun6i_spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/sun6i_spi.c b/drivers/spi/sun6i_spi.c index 3192548e83..3c6a13e40e 100644 --- a/drivers/spi/sun6i_spi.c +++ b/drivers/spi/sun6i_spi.c @@ -215,6 +215,7 @@ static inline void sun6i_spi_enable_clock(void) struct sunxi_ccm_reg *const ccm = (struct sunxi_ccm_reg *const)SUNXI_CCM_BASE; + setbits_le32(>ahb_reset0_cfg, (1 << AHB_RESET_OFFSET_SPI0)); setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_SPI0)); writel((1 << 31), >spi0_clk_cfg); } -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] sunxi: SPI: add AHB gate and reset offsets
---
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index d328df9597..71a1673fa8 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -290,6 +290,8 @@ struct sunxi_ccm_reg {
#define AHB_GATE_OFFSET_USB0 25
#define AHB_GATE_OFFSET_SATA 24
#endif
+#define AHB_GATE_OFFSET_SPI1 21
+#define AHB_GATE_OFFSET_SPI0 20
#define AHB_GATE_OFFSET_MCTL 14
#define AHB_GATE_OFFSET_GMAC 17
#define AHB_GATE_OFFSET_NAND0 13
@@ -436,6 +438,8 @@ struct sunxi_ccm_reg {
#ifdef CONFIG_MACH_SUN8I_R40
#define AHB_RESET_OFFSET_SATA 24
#endif
+#define AHB_RESET_OFFSET_SPI1 21
+#define AHB_RESET_OFFSET_SPI0 20
#define AHB_RESET_OFFSET_GMAC 17
#define AHB_RESET_OFFSET_MCTL 14
#define AHB_RESET_OFFSET_MMC3 11
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] sunxi: SPI: reset bus when enabling clock
Hi all, The sun6i SPI peripheral needs to be reset before it can be used. Add the necessary offset #defines and perform this reset. Applies to the allwinner-spi head on the u-boot-spi tree. Tested on Orange Pi R1 (Allwinner H2+ / sun8i) and successfully booted from SPI Thanks, Signed-off-by: Fahad Sadah Fahad Sadah (2): sunxi: SPI: add AHB gate and reset offsets sunxi: SPI: reset bus when enabling clock arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4 drivers/spi/sun6i_spi.c | 1 + 2 files changed, 5 insertions(+) -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 2018.09-rc1 breakage on orangepi pc2
On 08/03/2018 12:07 AM, Mark Kettenis wrote: >> Date: Thu, 2 Aug 2018 22:55:23 +0200 (CEST) >> From: Mark Kettenis >> >> I can no longer boot OpenBSD on the orangepi pc2. The kernel faults >> somewhere in the EFI detection code, almost certainly where it looks >> through the configuration table entries looking for the ACPI table. >> I've bisected this resulting in: >> >> >> 4182a129ef735bfd6c54788affe1b649ab85b851 is the first bad commit >> commit 4182a129ef735bfd6c54788affe1b649ab85b851 >> Author: Heinrich Schuchardt >> Date: Thu Jun 28 12:45:32 2018 +0200 >> >> efi_loader: allocate configuration table array >> >> The system table contains a link to the list of configurations tables. >> These include the device tree, SMBIOS table, and the ACPI table. >> >> This array is currently statically linked. With the patch it is allocated >> as EFI_RUNTIME_SERVICES_DATA. Due to the structure of the system table we >> cannot work with a linked list here. >> >> Signed-off-by: Heinrich Schuchardt >> Reviewed-by: Bin Meng >> Signed-off-by: Alexander Graf > > So after this commit, the ConfigurationTable field of the system table > is no longer translated from a physical address into a virtual address > when the SerVirtualAddressMap() runtime service gets called. > > The way SetVirtualAddressMap() is implemented is actually quite nify. > It "relocates" the relevant bits by processing the ELF relocations for > everything that is marked as __efi_runtime_data. This magically > modifies all the pointers in the system table that reference other > symbols, such as firmware_vendor, efi_runtime_services and > efi_conf_table. But since the diff replaces the reference to > efi_conf_table with a dynamically updated pointer, there no longer is > a relocation for the tables member. > >>From the commit message it isn't abvious what is being fixed. I think > the commit should be reverted. > Hello Mark, thanks for pointing out the following requirement from the UEFI spec that is not correctly implemented: "Several fields of the EFI System Table must be converted from physical pointers to virtual pointers using the ConvertPointer() service. These fields include FirmwareVendor, RuntimeServices, and ConfigurationTable." The EDK2 implementation is in MdeModulePkg/Core/RuntimeDxe/Runtime.c:352: RuntimeDriverConvertInternalPointer ((VOID **) >ConfigurationTable); I am currently testing a patch for this. @Alex: Relocation still has several todos: - calculate crc32 after updating the system table - provide ConvertPointer() - do not assume U-Boot is the only runtime driver Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] sunxi: SPI: reset bus when enabling clock
Hi all, The sun6i SPI peripheral needs to be reset before it can be used Add the necessary offset #defines and perform this reset Tested on Orange Pi R1 (Allwinner H2+ / sun8i) and successfully booted from SPI Thanks, Signed-off-by: Fahad Sadah Fahad Sadah (2): sunxi: SPI: add AHB gate and reset offsets sunxi: SPI: reset bus when enabling clock arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4 drivers/spi/sun6i_spi.c | 1 + 2 files changed, 5 insertions(+) -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] sunxi: SPI: add AHB gate and reset offsets
---
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index d328df9597..71a1673fa8 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -290,6 +290,8 @@ struct sunxi_ccm_reg {
#define AHB_GATE_OFFSET_USB0 25
#define AHB_GATE_OFFSET_SATA 24
#endif
+#define AHB_GATE_OFFSET_SPI1 21
+#define AHB_GATE_OFFSET_SPI0 20
#define AHB_GATE_OFFSET_MCTL 14
#define AHB_GATE_OFFSET_GMAC 17
#define AHB_GATE_OFFSET_NAND0 13
@@ -436,6 +438,8 @@ struct sunxi_ccm_reg {
#ifdef CONFIG_MACH_SUN8I_R40
#define AHB_RESET_OFFSET_SATA 24
#endif
+#define AHB_RESET_OFFSET_SPI1 21
+#define AHB_RESET_OFFSET_SPI0 20
#define AHB_RESET_OFFSET_GMAC 17
#define AHB_RESET_OFFSET_MCTL 14
#define AHB_RESET_OFFSET_MMC3 11
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: SPI: reset bus when enabling clock
--- drivers/spi/sun6i_spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/sun6i_spi.c b/drivers/spi/sun6i_spi.c index 3192548e83..3c6a13e40e 100644 --- a/drivers/spi/sun6i_spi.c +++ b/drivers/spi/sun6i_spi.c @@ -215,6 +215,7 @@ static inline void sun6i_spi_enable_clock(void) struct sunxi_ccm_reg *const ccm = (struct sunxi_ccm_reg *const)SUNXI_CCM_BASE; + setbits_le32(>ahb_reset0_cfg, (1 << AHB_RESET_OFFSET_SPI0)); setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_SPI0)); writel((1 << 31), >spi0_clk_cfg); } -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] armv5 and OMAP3 Question
On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
> On Fri, Aug 3, 2018 at 10:20 AM Tom Rini wrote:
> >
> > On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
> > > On Fri, Aug 3, 2018 at 10:00 AM Tom Rini wrote:
> > > >
> > > > On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
> > > > > On Tue, Jul 25, 2017 at 11:08 AM Tom Rini wrote:
> > > > > >
> > > > > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
> > > > > >
> > > > > > > The readme file for OMAP indicates that we compile using armv5 to
> > > > > > > "to
> > > > > > > allow more compilers to work"
> > > > > > >
> > > > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also
> > > > > > > noting
> > > > > > > some special assembly insturctions becuse we use armv5. The
> > > > > > > barriers
> > > > > > > defined also indicate we're using CP15 instead of the separate
> > > > > > > barrier
> > > > > > > instructions for armv7 because we're using armv5 instead.
> > > > > > >
> > > > > > > I just wonder in this day and age when we're noting a GCC version
> > > > > > > and
> > > > > > > generating warnings based on the GCC warning, do we still need to
> > > > > > > compile as armv5 any more? It seems like "to allow more
> > > > > > > compilers to
> > > > > > > work" would not really apply any more we're trying to push newer
> > > > > > > versions of GCC.
> > > > > >
> > > > > > So, these are historical notes that really should be corrected.
> > > > > > Initially, when ARMv7 support was added, most people did not have
> > > > > > compilers new enough to recognize -march=armv7-a. We still even
> > > > > > support
> > > > > > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the
> > > > > > options are any sort of modern gcc, llvm, ancient gcc). When we
> > > > > > move to
> > > > > > gcc-6 being the oldest gcc supported for ARM we can fixup those
> > > > > > comments
> > > > > > and logic as well.
> > > > >
> > > > > My understanding is that we've made the requirement for GCC 6 now. I
> > > > > just pushed a patch which enabled mtune=armv7-a-generic when
> > > > > CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on
> > > > > omap3_logic. Does it make sense to remove the , -march=armv5 from
> > > > > arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A
> > > > > implies armv-a?
> > > >
> > > > Yes, we can probably at least drop the v5 portion of that logic. As
> > > > noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a"
> > > > as being the appropriate name, or at least did in the past.
> > >
> > > Can you point me to an example of how to tune armv7 for both GCC and
> > > LLVM? I was looking around and I'm not seeing an obvious syntax.
> > > I'll do a 2-part patch. One to remove the armv5, and one to enable
> > > the armv7 optimization.
> >
> > In arch/arm/Makefile:
> > arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
> > $(call cc-option, -march=armv7,
> > -march=armv5))
> >
> > this works in both cases. And doc/README.clang is correct on how to
> > build with LLVM on ARM.
>
> I reset my head to origin/master, but using the following, I am not
> able to build omap3_logic with clang on Ubuntu 18.04:
>
> make HOSTCC=clang omap3_logic
> make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
> CC="clang -target arm-linux-gnueabi" -j8
>
> arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block
> stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
> ^
> arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block
> stmiage ip!, {r1, r3, r8, lr}
> ^
> arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block
> stmiage ip!, {r1, r3, r8, lr}
> ^
> arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block
> stmiage ip!, {r1, r3, r8, lr}
> ^
> arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block
> ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go.
> ^
> arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block
> stmiane ip!, {r1, r3, r8, lr}
> ^
> arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block
> stmiane ip!, {r1, r3, r8, lr}
> ^
> arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block
> stmiane ip!, {r1, r3, r8, lr}
> ^
> arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT
> block
> stmiane ip!, {r1, r3}
> ^
> arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT
> block
> strne r1, [ip], #4
> ^
> arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT
> block
> strbne r1, [ip], #1
> ^
> arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT
> block
> strbne r1, [ip], #1
> ^
> arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT
> block
> strbne r1, [ip], #1
> ^
>
Re: [U-Boot] armv5 and OMAP3 Question
On Fri, Aug 3, 2018 at 10:20 AM Tom Rini wrote:
>
> On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
> > On Fri, Aug 3, 2018 at 10:00 AM Tom Rini wrote:
> > >
> > > On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
> > > > On Tue, Jul 25, 2017 at 11:08 AM Tom Rini wrote:
> > > > >
> > > > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
> > > > >
> > > > > > The readme file for OMAP indicates that we compile using armv5 to
> > > > > > "to
> > > > > > allow more compilers to work"
> > > > > >
> > > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also
> > > > > > noting
> > > > > > some special assembly insturctions becuse we use armv5. The
> > > > > > barriers
> > > > > > defined also indicate we're using CP15 instead of the separate
> > > > > > barrier
> > > > > > instructions for armv7 because we're using armv5 instead.
> > > > > >
> > > > > > I just wonder in this day and age when we're noting a GCC version
> > > > > > and
> > > > > > generating warnings based on the GCC warning, do we still need to
> > > > > > compile as armv5 any more? It seems like "to allow more compilers
> > > > > > to
> > > > > > work" would not really apply any more we're trying to push newer
> > > > > > versions of GCC.
> > > > >
> > > > > So, these are historical notes that really should be corrected.
> > > > > Initially, when ARMv7 support was added, most people did not have
> > > > > compilers new enough to recognize -march=armv7-a. We still even
> > > > > support
> > > > > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the
> > > > > options are any sort of modern gcc, llvm, ancient gcc). When we move
> > > > > to
> > > > > gcc-6 being the oldest gcc supported for ARM we can fixup those
> > > > > comments
> > > > > and logic as well.
> > > >
> > > > My understanding is that we've made the requirement for GCC 6 now. I
> > > > just pushed a patch which enabled mtune=armv7-a-generic when
> > > > CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on
> > > > omap3_logic. Does it make sense to remove the , -march=armv5 from
> > > > arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A
> > > > implies armv-a?
> > >
> > > Yes, we can probably at least drop the v5 portion of that logic. As
> > > noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a"
> > > as being the appropriate name, or at least did in the past.
> >
> > Can you point me to an example of how to tune armv7 for both GCC and
> > LLVM? I was looking around and I'm not seeing an obvious syntax.
> > I'll do a 2-part patch. One to remove the armv5, and one to enable
> > the armv7 optimization.
>
> In arch/arm/Makefile:
> arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
> $(call cc-option, -march=armv7,
> -march=armv5))
>
> this works in both cases. And doc/README.clang is correct on how to
> build with LLVM on ARM.
I reset my head to origin/master, but using the following, I am not
able to build omap3_logic with clang on Ubuntu 18.04:
make HOSTCC=clang omap3_logic
make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
CC="clang -target arm-linux-gnueabi" -j8
arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block
stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
^
arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block
stmiage ip!, {r1, r3, r8, lr}
^
arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block
stmiage ip!, {r1, r3, r8, lr}
^
arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block
stmiage ip!, {r1, r3, r8, lr}
^
arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block
ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go.
^
arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block
stmiane ip!, {r1, r3, r8, lr}
^
arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block
stmiane ip!, {r1, r3, r8, lr}
^
arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block
stmiane ip!, {r1, r3, r8, lr}
^
arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT block
stmiane ip!, {r1, r3}
^
arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT block
strne r1, [ip], #4
^
arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT block
strbne r1, [ip], #1
^
arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT block
strbne r1, [ip], #1
^
arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT block
strbne r1, [ip], #1
^
arch/arm/lib/memset.S:120:2: error: predicated instructions must be in IT block
strblt r1, [ip], #1 @ 1
^
arch/arm/lib/memset.S:121:2: error: predicated instructions must be in IT block
strble r1, [ip], #1 @ 1
^
scripts/Makefile.build:314: recipe for target 'arch/arm/lib/memset.o' failed
Re: [U-Boot] [PATCH v6 00/27] SPI-NAND support
Hi Boris,
Boris Brezillon wrote on Sat, 4 Aug 2018
10:34:55 +0200:
> On Sat, 4 Aug 2018 09:23:05 +0200
> Miquel Raynal wrote:
>
> > Hi Jagan,
> >
> > Jagan Teki wrote on Fri, 3 Aug 2018
> > 17:38:33 +0530:
> >
> > > On Fri, Aug 3, 2018 at 3:20 PM, Jagan Teki
> > > wrote:
> > > > On Fri, Aug 3, 2018 at 1:57 PM, Miquel Raynal
> > > > wrote:
> > > >> Hi Jagan, Tom,
> > > >>
> > > >> Miquel Raynal wrote on Wed, 1 Aug 2018
> > > >> 10:18:21 +0200:
> > > >>
> > > >>> During the last months, Boris Brezillon shared his work to support
> > > >>> serial flashes within Linux. First, he delivered (and merged) a new
> > > >>> layer called spi-mem. He also initiated in Linux MTD subsystem the
> > > >>> move
> > > >>> of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> > > >>> same time a NAND core that would be shared with all NAND devices.
> > > >>> Then,
> > > >>> he contributed a generic SPI-NAND driver, making use of this NAND
> > > >>> core,
> > > >>> as well as some vendor code to drive a few chips.
> > > >>>
> > > >>> On top of this work, I added an 'mtd' U-Boot command to handle all
> > > >>> sort
> > > >>> of MTD devices. This should become the default command instead of
> > > >>> having
> > > >>> one per flash flavor ('sf', 'nand', 'spi-nand' ?).
> > > >>>
> > > >>> The series has been tested on an Ocelot board PCB123 (VSC7514),
> > > >>> featuring a Macronix SPI NAND chip.
> > > >>>
> > > >>> TL;DR: the series contains:
> > > >>> - A few patches from Linux to resynchronize some areas of the MTD
> > > >>> layer.
> > > >>> - Various fixes and re-organization of the MTD subsystem.
> > > >>> - The introduction of the SPI-mem interface.
> > > >>> - The addition of the generic SPI-NAND driver (and its bindings).
> > > >>> - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> > > >>> - A new 'mtd' command.
> > > >>> - Support for spi-nand devices in mtdparts.
> > > >>>
> > > >>> To test your SPI-NAND device with U-Boot simply follow these lines:
> > > >>>
> > > >>> > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
> > > >>> > setenv mtdids spi-nand0=spi-nand0
> > > >>> > mtdparts # show the spi-nand device partitions
> > > >>> > ubi part bar # create a static UBI volume in the bar
> > > >>> > partition
> > > >>>
> > > >>> Thanks,
> > > >>> Miquèl
> > > >>>
> > > >>> Changes since v5:
> > > >>> -
> > > >>> * Included Boris fixup about the build issues.
> > > >>> * Added Rb/Ab tags from Jagan on patchs 20/21.
> > > >>
> > > >> I can't see a pull request flow on U-Boot ML, I suppose you use a
> > > >> different mean for that purpose.
> > > >>
> > > >> Jagan, is this version OK? Is it part of your PR?
> > > >
> > > > Travis is going on [1], will send PR once all fine.
> > > >
> > > > [1] https://travis-ci.org/openedev/u-boot-amarula/builds/411596788
> > >
> > > There are some build issues, not quite sure whether it relates. please
> > > look into it.
> >
> > Thanks for the reports.
> >
> > >
> > > [2] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596814
> > > [3] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596815
> >
> > Boris supposedly fixed all the build issues related to my changes (I
> > don't think the "missing interrupt parent" in a DTS file is related),
> > please pull his branch [1].
> >
> > The fixes are under the form of fixups if you wanna check them.
> > Otherwise you can just 'rebase -i --autosquash' to automatically squash
> > them with the commit introducing the regression.
>
> One more thing, if you want to make things bisectable patch 6 ("mtd: fix
> build issue with includes") and it's fixup should be squashed in patch 5
> ("mtd: add get/set of_node/flash_node helpers"), because the build
> failure you're fixing in patch 6 is introduced by patch 5.
>
> >
> > [1] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596814
>
> You mean
>
> [1]https://github.com/bbrezillon/u-boot/commits/wip-spi
Oops!
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 00/27] SPI-NAND support
On Sat, 4 Aug 2018 09:23:05 +0200
Miquel Raynal wrote:
> Hi Jagan,
>
> Jagan Teki wrote on Fri, 3 Aug 2018
> 17:38:33 +0530:
>
> > On Fri, Aug 3, 2018 at 3:20 PM, Jagan Teki
> > wrote:
> > > On Fri, Aug 3, 2018 at 1:57 PM, Miquel Raynal
> > > wrote:
> > >> Hi Jagan, Tom,
> > >>
> > >> Miquel Raynal wrote on Wed, 1 Aug 2018
> > >> 10:18:21 +0200:
> > >>
> > >>> During the last months, Boris Brezillon shared his work to support
> > >>> serial flashes within Linux. First, he delivered (and merged) a new
> > >>> layer called spi-mem. He also initiated in Linux MTD subsystem the move
> > >>> of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> > >>> same time a NAND core that would be shared with all NAND devices. Then,
> > >>> he contributed a generic SPI-NAND driver, making use of this NAND core,
> > >>> as well as some vendor code to drive a few chips.
> > >>>
> > >>> On top of this work, I added an 'mtd' U-Boot command to handle all sort
> > >>> of MTD devices. This should become the default command instead of having
> > >>> one per flash flavor ('sf', 'nand', 'spi-nand' ?).
> > >>>
> > >>> The series has been tested on an Ocelot board PCB123 (VSC7514),
> > >>> featuring a Macronix SPI NAND chip.
> > >>>
> > >>> TL;DR: the series contains:
> > >>> - A few patches from Linux to resynchronize some areas of the MTD layer.
> > >>> - Various fixes and re-organization of the MTD subsystem.
> > >>> - The introduction of the SPI-mem interface.
> > >>> - The addition of the generic SPI-NAND driver (and its bindings).
> > >>> - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> > >>> - A new 'mtd' command.
> > >>> - Support for spi-nand devices in mtdparts.
> > >>>
> > >>> To test your SPI-NAND device with U-Boot simply follow these lines:
> > >>>
> > >>> > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
> > >>> > setenv mtdids spi-nand0=spi-nand0
> > >>> > mtdparts # show the spi-nand device partitions
> > >>> > ubi part bar # create a static UBI volume in the bar
> > >>> > partition
> > >>>
> > >>> Thanks,
> > >>> Miquèl
> > >>>
> > >>> Changes since v5:
> > >>> -
> > >>> * Included Boris fixup about the build issues.
> > >>> * Added Rb/Ab tags from Jagan on patchs 20/21.
> > >>
> > >> I can't see a pull request flow on U-Boot ML, I suppose you use a
> > >> different mean for that purpose.
> > >>
> > >> Jagan, is this version OK? Is it part of your PR?
> > >
> > > Travis is going on [1], will send PR once all fine.
> > >
> > > [1] https://travis-ci.org/openedev/u-boot-amarula/builds/411596788
> >
> > There are some build issues, not quite sure whether it relates. please
> > look into it.
>
> Thanks for the reports.
>
> >
> > [2] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596814
> > [3] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596815
>
> Boris supposedly fixed all the build issues related to my changes (I
> don't think the "missing interrupt parent" in a DTS file is related),
> please pull his branch [1].
>
> The fixes are under the form of fixups if you wanna check them.
> Otherwise you can just 'rebase -i --autosquash' to automatically squash
> them with the commit introducing the regression.
One more thing, if you want to make things bisectable patch 6 ("mtd: fix
build issue with includes") and it's fixup should be squashed in patch 5
("mtd: add get/set of_node/flash_node helpers"), because the build
failure you're fixing in patch 6 is introduced by patch 5.
>
> [1] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596814
You mean
[1]https://github.com/bbrezillon/u-boot/commits/wip-spi
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 00/27] SPI-NAND support
Hi Jagan,
Jagan Teki wrote on Fri, 3 Aug 2018
17:38:33 +0530:
> On Fri, Aug 3, 2018 at 3:20 PM, Jagan Teki wrote:
> > On Fri, Aug 3, 2018 at 1:57 PM, Miquel Raynal
> > wrote:
> >> Hi Jagan, Tom,
> >>
> >> Miquel Raynal wrote on Wed, 1 Aug 2018
> >> 10:18:21 +0200:
> >>
> >>> During the last months, Boris Brezillon shared his work to support
> >>> serial flashes within Linux. First, he delivered (and merged) a new
> >>> layer called spi-mem. He also initiated in Linux MTD subsystem the move
> >>> of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> >>> same time a NAND core that would be shared with all NAND devices. Then,
> >>> he contributed a generic SPI-NAND driver, making use of this NAND core,
> >>> as well as some vendor code to drive a few chips.
> >>>
> >>> On top of this work, I added an 'mtd' U-Boot command to handle all sort
> >>> of MTD devices. This should become the default command instead of having
> >>> one per flash flavor ('sf', 'nand', 'spi-nand' ?).
> >>>
> >>> The series has been tested on an Ocelot board PCB123 (VSC7514),
> >>> featuring a Macronix SPI NAND chip.
> >>>
> >>> TL;DR: the series contains:
> >>> - A few patches from Linux to resynchronize some areas of the MTD layer.
> >>> - Various fixes and re-organization of the MTD subsystem.
> >>> - The introduction of the SPI-mem interface.
> >>> - The addition of the generic SPI-NAND driver (and its bindings).
> >>> - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> >>> - A new 'mtd' command.
> >>> - Support for spi-nand devices in mtdparts.
> >>>
> >>> To test your SPI-NAND device with U-Boot simply follow these lines:
> >>>
> >>> > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
> >>> > setenv mtdids spi-nand0=spi-nand0
> >>> > mtdparts # show the spi-nand device partitions
> >>> > ubi part bar # create a static UBI volume in the bar partition
> >>>
> >>> Thanks,
> >>> Miquèl
> >>>
> >>> Changes since v5:
> >>> -
> >>> * Included Boris fixup about the build issues.
> >>> * Added Rb/Ab tags from Jagan on patchs 20/21.
> >>
> >> I can't see a pull request flow on U-Boot ML, I suppose you use a
> >> different mean for that purpose.
> >>
> >> Jagan, is this version OK? Is it part of your PR?
> >
> > Travis is going on [1], will send PR once all fine.
> >
> > [1] https://travis-ci.org/openedev/u-boot-amarula/builds/411596788
>
> There are some build issues, not quite sure whether it relates. please
> look into it.
Thanks for the reports.
>
> [2] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596814
> [3] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596815
Boris supposedly fixed all the build issues related to my changes (I
don't think the "missing interrupt parent" in a DTS file is related),
please pull his branch [1].
The fixes are under the form of fixups if you wanna check them.
Otherwise you can just 'rebase -i --autosquash' to automatically squash
them with the commit introducing the regression.
[1] https://travis-ci.org/openedev/u-boot-amarula/jobs/411596814
Thanks,
Miquèl
--
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
