Re: [U-Boot] ARM64 Allwinner Binary Size

[Mark Kettenis]

> Date: Wed, 20 Dec 2017 08:15:46 +0100
> From: Maxime Ripard 
> 
> On Wed, Dec 20, 2017 at 01:55:51AM +, Andr=E9 Przywara wrote:
> > On 19/12/17 15:24, Maxime Ripard wrote:
> > > On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote:
> > >>> Date: Tue, 19 Dec 2017 14:12:02 +0100
> > >>> From: Maxime Ripard 
> > >>>
> > >>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> >  So even though the actual u-boot.bin for 64-bit boards is still some=
> what
> >  below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> >  the edge. So since v2017.11 u-boot.itb is already too big for the
> >  traditional MMC env location.
> > >>>
> > >>> So I've had a quick look about what could go possibly go away in our
> > >>> current armv8 config (using the pine64+ defconfig). Let me know if
> > >>> some are actually vitals:
> > >>>
> > >>>  - FIT_ENABLE_SHA256_SUPPORT
> > >>>  - CONSOLE_MUX
> > >>>  - CMD_CRC32
> > >>>  - CMD_LZMADEC
> > >>>  - CMD_UNZIP
> > >>>  - CMD_LOADB
> > >>>  - CMD_LOADS
> > >>>  - CMD_MISC (actually implementing the command sleep)
> > >>>  - ISO_PARTITION (yes. For CDROMs.)
> > >>>  - VIDEO_BPP8, VIDEO_BPP16
> > >>>  - VIDEO_ANSI
> > >>>  - SHA256
> > >>>  - LZMA
> > >>>
> > >>> Removing those options make the u-boot.itb binary size going from
> > >>> 516kB to 478kB, making it functional again *and* allowing us to enable
> > >>> the DT overlays that seem way more important than any feature
> > >>> mentionned above (and bumps the size to 483kB).
> > >>
> > >> So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
> > >> console and usb keyboard are present?  Is the usb keyboard used when
> > >> it is plugged in but serial otherwise?
> > >=20
> > > That's actually a very good question, and I don't know, I never used a
> > > USB keyboard with U-Boot.
> > >=20
> > > This is enabled on 7 Allwinner boards, and no one complained so far,
> > > so I would expect to work without that option activated. However, it
> > > doesn't take that much space either, so it's not like we really need
> > > to disable it either.
> >=20
> > Just tested it: without CONSOLE_MUX we don't use video and USB keyboard
> > automatically. It seems to default to serial, "setenv stdout vidconsole"
> > switches over (immediately). This is quite weird behaviour, and probably
> > quite unpleasant for the casual user.
> > With CONSOLE_MUX defined we get what we want: always serial console,
> > plus USB keyboard and HDMI, if connected. Output appears on both, input
> > is accepted from both.
> > So I would very much like to keep it in.
> 
> Sounds like we should even enable it for everyone then.

common/Kconfig has:

config CONSOLE_MUX
bool "Enable console multiplexing"
default y if DM_VIDEO || VIDEO || LCD

so it is already enabled in the cases where it matters.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Wed, Dec 20, 2017 at 01:55:51AM +, André Przywara wrote:
> On 19/12/17 15:24, Maxime Ripard wrote:
> > On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote:
> >>> Date: Tue, 19 Dec 2017 14:12:02 +0100
> >>> From: Maxime Ripard 
> >>>
> >>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
>  So even though the actual u-boot.bin for 64-bit boards is still somewhat
>  below the limit (~480KB), adding the ATF image (~32KB) pushes it over
>  the edge. So since v2017.11 u-boot.itb is already too big for the
>  traditional MMC env location.
> >>>
> >>> So I've had a quick look about what could go possibly go away in our
> >>> current armv8 config (using the pine64+ defconfig). Let me know if
> >>> some are actually vitals:
> >>>
> >>>  - FIT_ENABLE_SHA256_SUPPORT
> >>>  - CONSOLE_MUX
> >>>  - CMD_CRC32
> >>>  - CMD_LZMADEC
> >>>  - CMD_UNZIP
> >>>  - CMD_LOADB
> >>>  - CMD_LOADS
> >>>  - CMD_MISC (actually implementing the command sleep)
> >>>  - ISO_PARTITION (yes. For CDROMs.)
> >>>  - VIDEO_BPP8, VIDEO_BPP16
> >>>  - VIDEO_ANSI
> >>>  - SHA256
> >>>  - LZMA
> >>>
> >>> Removing those options make the u-boot.itb binary size going from
> >>> 516kB to 478kB, making it functional again *and* allowing us to enable
> >>> the DT overlays that seem way more important than any feature
> >>> mentionned above (and bumps the size to 483kB).
> >>
> >> So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
> >> console and usb keyboard are present?  Is the usb keyboard used when
> >> it is plugged in but serial otherwise?
> > 
> > That's actually a very good question, and I don't know, I never used a
> > USB keyboard with U-Boot.
> > 
> > This is enabled on 7 Allwinner boards, and no one complained so far,
> > so I would expect to work without that option activated. However, it
> > doesn't take that much space either, so it's not like we really need
> > to disable it either.
> 
> Just tested it: without CONSOLE_MUX we don't use video and USB keyboard
> automatically. It seems to default to serial, "setenv stdout vidconsole"
> switches over (immediately). This is quite weird behaviour, and probably
> quite unpleasant for the casual user.
> With CONSOLE_MUX defined we get what we want: always serial console,
> plus USB keyboard and HDMI, if connected. Output appears on both, input
> is accepted from both.
> So I would very much like to keep it in.

Sounds like we should even enable it for everyone then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] fs/fat: device not booting since conversion to dir iterators

[Patrick Brünn]

Hi Simon,

>From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>Sent: Dienstag, 19. Dezember 2017 16:42
>Hi Patrick,
>
>On 13 December 2017 at 03:15, Patrick Brünn 
>wrote:
>>>From: Patrick Brünn
>>>Sent: Donnerstag, 30. November 2017 12:22
>>>
>>>Since commit 8eafae209c35932d9a6560809c55ee4641534236
>>>my mx53cx9020_defconfig stopped booting.
>>>...
>>>It seems important to read into do_fat_read_at_block. If I
>>>allocate a temporary buffer and read into that one, I still
>>>can't boot. That seems strange to me as, I couldn't find
>>>any uninitialized access to do_fat_read_at_block anywhere.
>>>
>> I believe I finally tracked it down to the linker.
>>
>> Without accessing do_fat_read_at_block within fat.c, I find
>> .bss. do_fat_read_at_block as "discarded input section" in
>> my u-boot.map
>>
>> With a patch like this:
>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
>> index d16883fa10..8e70fdbc8d 100644
>> --- a/fs/fat/fat.c
>> +++ b/fs/fat/fat.c
>> @@ -1157,6 +1157,7 @@ int fat_opendir(const char *filename, struct
>fs_dir_stream **dirsp)
>> return -ENOMEM;
>> memset(dir, 0, sizeof(*dir));
>>
>> +   if (do_fat_read_at_block[0])
>> +   printf("value doesn't matter, the access is important\n");
>> +
>> ret = fat_itr_root(>itr, >fsdata);
>> if (ret)
>> goto fail_free_dir;
>>
>> The section isn't discarded and my board boots again.
>>
>>
>> Another workaround would be:
>> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
>> index 124b44a337..02f61fcc3c 100644
>> --- a/arch/arm/config.mk
>> +++ b/arch/arm/config.mk
>> @@ -17,7 +17,7 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-
>sections -fdata-sections
>>  CFLAGS_EFI := -fpic -fshort-wchar
>>
>>  LDFLAGS_FINAL += --gc-sections
>> -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
>> +PLATFORM_RELFLAGS += -ffunction-sections \
>>  -fno-common -ffixed-r9
>>  PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
>>$(call cc-option,-mshort-load-bytes,$(call 
>> cc-option,-malignment-traps,))
>>
>> Or a hack like:
>> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
>> index 37d4c605ac..b916cbc733 100644
>> --- a/arch/arm/cpu/u-boot.lds
>> +++ b/arch/arm/cpu/u-boot.lds
>> @@ -219,6 +219,7 @@ SECTIONS
>> }
>>
>> .bss_end __bss_limit (OVERLAY) : {
>> +   KEEP(*(.bss.do_fat_read_at_block));
>> KEEP(*(.__bss_end));
>> }
>>
>> I also tried to mark do_fat_read_at_block as:
>> volatile, __used and/or __attribute__((externally_visible))
>>
>> This doesn't help.
>>
>> Moving it into fat_write.c doesn't help either(with/without static)
>>
>> My toolchain is:
>> ~/u-boot$ arm-linux-gnueabihf-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=arm-linux-gnueabihf-gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/6/lto-
>wrapper
>> Target: arm-linux-gnueabihf
>> Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' --
>with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-
>languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-
>suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --
>without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
>--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-
>libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-
>object --disable-libitm --disable-libquadmath --enable-plugin --enable-
>default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
>--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-
>cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-
>6-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-
>cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
>--disable-libgcj --with-target-system-zlib --enable-objc-gc=auto --enable-
>multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16
>--with-float=hard --with-mode=thumb --enable-checking=release --
>build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-
>gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-
>linux-gnueabihf/include
>> Thread model: posix
>> gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>
>> ~/u-boot$ arm-linux-gnueabihf-ld -v
>> GNU ld (GNU Binutils for Debian) 2.28
>>
>>
>> Does anyone have an idea what else I can try to prevent my linker from
>removing
>> do_fat_read_at_block?
>
>This doesn't seem to be used unless you have enabled CONFIG_FAT_WRITE.
>Have you?
>
>I wonder if the problem is somewhere else, and the presence of this
>buffer is just moving things apart in the data space, and thus masking
>the problem?
>
Yes, I hope I finally found it. Please see the first patch of this series[1].
Don't using that global variable anymore fixes my problem, 

[U-Boot] [PATCH] rockchp: dts: rk3399-evb: support boot from sd-card

[Kever Yang]

Enable sdmmc node in SPL and add it to boot order.

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3399-evb.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index 0e5d8d7..f0567c9 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -17,6 +17,8 @@
 
chosen {
stdout-path = 
+   u-boot,spl-boot-order = \
+   , 
};
 
vdd_center: vdd-center {
@@ -154,6 +156,7 @@
 };
 
  {
+   u-boot,dm-pre-reloc;
bus-width = <4>;
status = "okay";
 };
-- 
1.9.1

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

[U-Boot] [PATCH RESEND v2 3/3] arm64: layerscape: Move CONFIG_HAS_FSL_DR_USB to Kconfig

[Ran Wang]

Rename to USB_EHCI_FSL, use Kconfig to select ehci accordingly.

Signed-off-by: Ran Wang 
---
Change in v2:
None

 drivers/usb/host/Kconfig |  6 ++
 include/configs/ls1012aqds.h | 11 ---
 include/configs/ls1021aqds.h | 11 ---
 include/configs/ls1021atwr.h | 20 
 4 files changed, 6 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c79f866..90b2f78 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -186,6 +186,12 @@ config USB_EHCI_GENERIC
---help---
  Enables support for generic EHCI controller.
 
+config USB_EHCI_FSL
+   bool  "Support for FSL on-chip EHCI USB controller"
+   default n
+   select  CONFIG_EHCI_HCD_INIT_AFTER_RESET
+   ---help---
+ Enables support for the on-chip EHCI controller on FSL chips.
 endif # USB_EHCI_HCD
 
 config USB_OHCI_HCD
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index af5f37c..bf4262a 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -107,17 +107,6 @@
 #define CONFIG_SF_DEFAULT_BUS1
 #define CONFIG_SF_DEFAULT_CS 0
 
-/*
-* USB
-*/
-/* EHCI Support - disbaled by default */
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
 /*  MMC  */
 #ifdef CONFIG_MMC
 #define CONFIG_FSL_ESDHC
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 6669f2f..d088e83 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -394,17 +394,6 @@ unsigned long get_board_ddr_clk(void);
 #endif
 
 /*
- * USB
- */
-/* EHCI Support - disbaled by default */
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
-/*
  * Video
  */
 #ifdef CONFIG_VIDEO_FSL_DCU_FB
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 3db7ef1..15d6638 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -24,26 +24,6 @@
 #define CONFIG_SYS_INIT_RAM_ADDR   OCRAM_BASE_ADDR
 #define CONFIG_SYS_INIT_RAM_SIZE   OCRAM_SIZE
 
-/*
- * USB
- */
-
-/*
- * EHCI Support - disbaled by default as
- * there is no signal coming out of soc on
- * this board for this controller. However,
- * the silicon still has this controller,
- * and anyone can use this controller by
- * taking signals out on their board.
- */
-
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
 #define CONFIG_SYS_CLK_FREQ1
 #define CONFIG_DDR_CLK_FREQ1
 
-- 
2.7.4

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

[U-Boot] [PATCH RESEND v2 2/3] usb: ehci: fsl: Fix some compile warnings.

[Ran Wang]

When enable CONFIG_HAS_FSL_DR_USB, we might encounter below compile
warning, apply this patch can fix it:

drivers/usb/host/ehci-fsl.c:109:4: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
^
drivers/usb/host/ehci-fsl.c:108:9: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  hcor = (struct ehci_hcor *)
 ^
drivers/usb/host/ehci-fsl.c:115:8: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
(u32)hccr, (u32)hcor,
^
include/log.h:131:26: note: in definition of macro 'debug_cond'
printf(pr_fmt(fmt), ##args); \
  ^~~~
drivers/usb/host/ehci-fsl.c:114:2: note: in expansion of macro 'debug'
  debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
  ^
drivers/usb/host/ehci-fsl.c:115:19: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
(u32)hccr, (u32)hcor,
   ^
include/log.h:131:26: note: in definition of macro 'debug_cond'
printf(pr_fmt(fmt), ##args); \
  ^~~~
drivers/usb/host/ehci-fsl.c:114:2: note: in expansion of macro 'debug'
  debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
  ^

Signed-off-by: Ran Wang 
---
Change in v2:
Add compile warning informaion in commit message.

 drivers/usb/host/ehci-fsl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 62c431b..17d1fae 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -106,14 +106,14 @@ static int ehci_fsl_probe(struct udevice *dev)
ehci = (struct usb_ehci *)priv->hcd_base;
hccr = (struct ehci_hccr *)(>caplength);
hcor = (struct ehci_hcor *)
-   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
+   ((void *)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
 
if (ehci_fsl_init(priv, ehci, hccr, hcor) < 0)
return -ENXIO;
 
-   debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
- (u32)hccr, (u32)hcor,
- (u32)HC_LENGTH(ehci_readl(>cr_capbase)));
+   debug("ehci-fsl: init hccr %p and hcor %p hc_length %d\n",
+ (void *)hccr, (void *)hcor,
+ HC_LENGTH(ehci_readl(>cr_capbase)));
 
return ehci_register(dev, hccr, hcor, _ehci_ops, 0, USB_INIT_HOST);
 }
-- 
2.7.4

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

[U-Boot] [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Ran Wang]

Without this propertiy, U-Boot will pop warning of 'USB phy type not
defined' when select CONFIG_HAS_FSL_DR_USB.

Signed-off-by: Ran Wang 
---
Change in v2:
None

 arch/arm/dts/fsl-ls1012a-qds.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi 
b/arch/arm/dts/fsl-ls1012a-qds.dtsi
index dde7134..d17cd99 100644
--- a/arch/arm/dts/fsl-ls1012a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
@@ -121,3 +121,8 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+   phy_type = "ulpi";
+};
-- 
2.7.4

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

[U-Boot] [PATCH v2 3/3] arm64: layerscape: Move CONFIG_HAS_FSL_DR_USB to Kconfig

[Ran Wang]

Rename to USB_EHCI_FSL, use Kconfig to select ehci accordingly.

Signed-off-by: Ran Wang 
---
 drivers/usb/host/Kconfig |  6 ++
 include/configs/ls1012aqds.h | 11 ---
 include/configs/ls1021aqds.h | 11 ---
 include/configs/ls1021atwr.h | 20 
 4 files changed, 6 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c79f866..90b2f78 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -186,6 +186,12 @@ config USB_EHCI_GENERIC
---help---
  Enables support for generic EHCI controller.
 
+config USB_EHCI_FSL
+   bool  "Support for FSL on-chip EHCI USB controller"
+   default n
+   select  CONFIG_EHCI_HCD_INIT_AFTER_RESET
+   ---help---
+ Enables support for the on-chip EHCI controller on FSL chips.
 endif # USB_EHCI_HCD
 
 config USB_OHCI_HCD
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index af5f37c..bf4262a 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -107,17 +107,6 @@
 #define CONFIG_SF_DEFAULT_BUS1
 #define CONFIG_SF_DEFAULT_CS 0
 
-/*
-* USB
-*/
-/* EHCI Support - disbaled by default */
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
 /*  MMC  */
 #ifdef CONFIG_MMC
 #define CONFIG_FSL_ESDHC
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 6669f2f..d088e83 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -394,17 +394,6 @@ unsigned long get_board_ddr_clk(void);
 #endif
 
 /*
- * USB
- */
-/* EHCI Support - disbaled by default */
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
-/*
  * Video
  */
 #ifdef CONFIG_VIDEO_FSL_DCU_FB
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 3db7ef1..15d6638 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -24,26 +24,6 @@
 #define CONFIG_SYS_INIT_RAM_ADDR   OCRAM_BASE_ADDR
 #define CONFIG_SYS_INIT_RAM_SIZE   OCRAM_SIZE
 
-/*
- * USB
- */
-
-/*
- * EHCI Support - disbaled by default as
- * there is no signal coming out of soc on
- * this board for this controller. However,
- * the silicon still has this controller,
- * and anyone can use this controller by
- * taking signals out on their board.
- */
-
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
 #define CONFIG_SYS_CLK_FREQ1
 #define CONFIG_DDR_CLK_FREQ1
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/3] usb: ehci: fsl: Fix some compile warnings.

[Ran Wang]

When enable CONFIG_HAS_FSL_DR_USB, we might encounter below compile
warning, apply this patch can fix it:

drivers/usb/host/ehci-fsl.c:109:4: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
^
drivers/usb/host/ehci-fsl.c:108:9: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  hcor = (struct ehci_hcor *)
 ^
drivers/usb/host/ehci-fsl.c:115:8: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
(u32)hccr, (u32)hcor,
^
include/log.h:131:26: note: in definition of macro 'debug_cond'
printf(pr_fmt(fmt), ##args); \
  ^~~~
drivers/usb/host/ehci-fsl.c:114:2: note: in expansion of macro 'debug'
  debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
  ^
drivers/usb/host/ehci-fsl.c:115:19: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
(u32)hccr, (u32)hcor,
   ^
include/log.h:131:26: note: in definition of macro 'debug_cond'
printf(pr_fmt(fmt), ##args); \
  ^~~~
drivers/usb/host/ehci-fsl.c:114:2: note: in expansion of macro 'debug'
  debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
  ^

Signed-off-by: Ran Wang 
---
 drivers/usb/host/ehci-fsl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 62c431b..17d1fae 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -106,14 +106,14 @@ static int ehci_fsl_probe(struct udevice *dev)
ehci = (struct usb_ehci *)priv->hcd_base;
hccr = (struct ehci_hccr *)(>caplength);
hcor = (struct ehci_hcor *)
-   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
+   ((void *)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
 
if (ehci_fsl_init(priv, ehci, hccr, hcor) < 0)
return -ENXIO;
 
-   debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
- (u32)hccr, (u32)hcor,
- (u32)HC_LENGTH(ehci_readl(>cr_capbase)));
+   debug("ehci-fsl: init hccr %p and hcor %p hc_length %d\n",
+ (void *)hccr, (void *)hcor,
+ HC_LENGTH(ehci_readl(>cr_capbase)));
 
return ehci_register(dev, hccr, hcor, _ehci_ops, 0, USB_INIT_HOST);
 }
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Ran Wang]

Without this propertiy, U-Boot will pop warning of 'USB phy type not
defined' when select CONFIG_HAS_FSL_DR_USB.

Signed-off-by: Ran Wang 
---
 arch/arm/dts/fsl-ls1012a-qds.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi 
b/arch/arm/dts/fsl-ls1012a-qds.dtsi
index dde7134..d17cd99 100644
--- a/arch/arm/dts/fsl-ls1012a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
@@ -121,3 +121,8 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+   phy_type = "ulpi";
+};
-- 
2.7.4

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[André Przywara]

On 19/12/17 15:36, Maxime Ripard wrote:
> On Tue, Dec 19, 2017 at 02:27:57PM +, Andre Przywara wrote:
> Removing those options make the u-boot.itb binary size going from
> 516kB to 478kB, making it functional again *and* allowing us to enable
> the DT overlays that seem way more important than any feature
> mentionned above (and bumps the size to 483kB).

 How important is the raw MMC environment for the ARM64 boards, actually?
 Most of the rationale for the 32-bit side seemed to apply to legacy use
 cases only. Do we have reports/complaints from 64-bit users?
>>>
>>> Pretty much as important as it is on arm I guess. We just have less
>>> history, but the same use cases.
>>>
>>> I'd really like to give at least one release for transition, which
>>> would mean having a schedule like this:
>>>
>>>   - in 2018.01, merge those config removals so that we have least have
>>> something that works quite fast
> 
> So, given the various feedback, the current diff for the pine64 is:
> http://code.bulix.org/t7icrw-243561
> 
> With that, We're at 500kB with the ATF.
> 
> Does it work for everyone here?

Yes, briefly tested with HDMI, USB keyboard, also UEFI boot (just grub).

The only downside is the missing "boot" command. Not a big deal (as one
can always type "run bootmcd"), but quite inconvenient for the casual
user. If one (accidentally) aborts the timeout, just typing "boot" does
the right thing. This add ~450 bytes on my setup, so I wonder if we can
keep it in?

Cheers,
Andre.


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

Re: [U-Boot] ARM64 Allwinner Binary Size

[André Przywara]

On 19/12/17 15:24, Maxime Ripard wrote:
> On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote:
>>> Date: Tue, 19 Dec 2017 14:12:02 +0100
>>> From: Maxime Ripard 
>>>
>>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
 So even though the actual u-boot.bin for 64-bit boards is still somewhat
 below the limit (~480KB), adding the ATF image (~32KB) pushes it over
 the edge. So since v2017.11 u-boot.itb is already too big for the
 traditional MMC env location.
>>>
>>> So I've had a quick look about what could go possibly go away in our
>>> current armv8 config (using the pine64+ defconfig). Let me know if
>>> some are actually vitals:
>>>
>>>  - FIT_ENABLE_SHA256_SUPPORT
>>>  - CONSOLE_MUX
>>>  - CMD_CRC32
>>>  - CMD_LZMADEC
>>>  - CMD_UNZIP
>>>  - CMD_LOADB
>>>  - CMD_LOADS
>>>  - CMD_MISC (actually implementing the command sleep)
>>>  - ISO_PARTITION (yes. For CDROMs.)
>>>  - VIDEO_BPP8, VIDEO_BPP16
>>>  - VIDEO_ANSI
>>>  - SHA256
>>>  - LZMA
>>>
>>> Removing those options make the u-boot.itb binary size going from
>>> 516kB to 478kB, making it functional again *and* allowing us to enable
>>> the DT overlays that seem way more important than any feature
>>> mentionned above (and bumps the size to 483kB).
>>
>> So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
>> console and usb keyboard are present?  Is the usb keyboard used when
>> it is plugged in but serial otherwise?
> 
> That's actually a very good question, and I don't know, I never used a
> USB keyboard with U-Boot.
> 
> This is enabled on 7 Allwinner boards, and no one complained so far,
> so I would expect to work without that option activated. However, it
> doesn't take that much space either, so it's not like we really need
> to disable it either.

Just tested it: without CONSOLE_MUX we don't use video and USB keyboard
automatically. It seems to default to serial, "setenv stdout vidconsole"
switches over (immediately). This is quite weird behaviour, and probably
quite unpleasant for the casual user.
With CONSOLE_MUX defined we get what we want: always serial console,
plus USB keyboard and HDMI, if connected. Output appears on both, input
is accepted from both.
So I would very much like to keep it in.

Cheers,
Andre.

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

Re: [U-Boot] [PATCH 2/3] usb: ehci: fsl: Fix some compile warnings.

[Ran Wang]

Hi Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Tuesday, December 19, 2017 7:17 PM

> 
> On 12/19/2017 08:33 AM, Ran Wang wrote:
> 
> Commit message explaining what "some" means is missing.
> 

OK, will explain it in v2

> > Signed-off-by: Ran Wang 
> > ---
> >  drivers/usb/host/ehci-fsl.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> > index 62c431b..17d1fae 100644
> > --- a/drivers/usb/host/ehci-fsl.c
> > +++ b/drivers/usb/host/ehci-fsl.c
> > @@ -106,14 +106,14 @@ static int ehci_fsl_probe(struct udevice *dev)
> > ehci = (struct usb_ehci *)priv->hcd_base;
> > hccr = (struct ehci_hccr *)(>caplength);
> > hcor = (struct ehci_hcor *)
> > -   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
> > +   ((void *)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
> >
> > if (ehci_fsl_init(priv, ehci, hccr, hcor) < 0)
> > return -ENXIO;
> >
> > -   debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
> > - (u32)hccr, (u32)hcor,
> > - (u32)HC_LENGTH(ehci_readl(>cr_capbase)));
> > +   debug("ehci-fsl: init hccr %p and hcor %p hc_length %d\n",
> > + (void *)hccr, (void *)hcor,
> > + HC_LENGTH(ehci_readl(>cr_capbase)));
> >
> > return ehci_register(dev, hccr, hcor, _ehci_ops, 0,
> > USB_INIT_HOST);  }
> >
> 
> 
Best Regards,
Ran
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/4] ARM: tegra: use CONFIG_SYS_INIT_SP_BSS_OFFSET

[Stephen Warren]

From: Stephen Warren 

Enable CONFIG_SYS_INIT_SP_BSS_OFFSET for all 64-bit Tegra boards. Place
the stack/... 512KiB from the end of the U-Boot binary. This should be
plenty to accommodate the current DTBs (max 64 KiB), early malloc region
(6KiB), stack usage, and plenty of slack, while still not placing it too
far away from the U-Boot binary.

Signed-off-by: Stephen Warren 
---
 arch/arm/mach-tegra/tegra186/Kconfig | 3 +++
 arch/arm/mach-tegra/tegra210/Kconfig | 3 +++
 include/configs/tegra-common.h   | 2 ++
 include/configs/tegra186-common.h| 5 -
 include/configs/tegra210-common.h| 5 -
 5 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-tegra/tegra186/Kconfig 
b/arch/arm/mach-tegra/tegra186/Kconfig
index b2e53b58caf8..479c0955eec6 100644
--- a/arch/arm/mach-tegra/tegra186/Kconfig
+++ b/arch/arm/mach-tegra/tegra186/Kconfig
@@ -21,6 +21,9 @@ endchoice
 config SYS_SOC
default "tegra186"
 
+config SYS_INIT_SP_BSS_OFFSET
+   default 524288
+
 source "board/nvidia/p2771-/Kconfig"
 
 endif
diff --git a/arch/arm/mach-tegra/tegra210/Kconfig 
b/arch/arm/mach-tegra/tegra210/Kconfig
index 3637473051b8..250738aed312 100644
--- a/arch/arm/mach-tegra/tegra210/Kconfig
+++ b/arch/arm/mach-tegra/tegra210/Kconfig
@@ -40,6 +40,9 @@ endchoice
 config SYS_SOC
default "tegra210"
 
+config SYS_INIT_SP_BSS_OFFSET
+   default 524288
+
 source "board/nvidia/e2220-1170/Kconfig"
 source "board/nvidia/p2371-/Kconfig"
 source "board/nvidia/p2371-2180/Kconfig"
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 75e36c0b759d..2d98a6fa64a7 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -78,11 +78,13 @@
 
 #define CONFIG_SYS_BOOTMAPSZ   (256 << 20) /* 256M */
 
+#ifndef CONFIG_ARM64
 #define CONFIG_SYS_INIT_RAM_ADDR   CONFIG_STACKBASE
 #define CONFIG_SYS_INIT_RAM_SIZE   CONFIG_SYS_MALLOC_LEN
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)
+#endif
 
 #ifndef CONFIG_ARM64
 /* Defines for SPL */
diff --git a/include/configs/tegra186-common.h 
b/include/configs/tegra186-common.h
index 495d18555f3f..1c8772a117e4 100644
--- a/include/configs/tegra186-common.h
+++ b/include/configs/tegra186-common.h
@@ -14,11 +14,6 @@
  */
 #define V_NS16550_CLK  40800   /* 408MHz (pllp_out0) */
 
-/*
- * Miscellaneous configurable options
- */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
-
 /*---
  * Physical Memory Map
  */
diff --git a/include/configs/tegra210-common.h 
b/include/configs/tegra210-common.h
index 93c9455e8ff3..35735f3b78e4 100644
--- a/include/configs/tegra210-common.h
+++ b/include/configs/tegra210-common.h
@@ -15,11 +15,6 @@
  */
 #define V_NS16550_CLK  40800   /* 408MHz (pllp_out0) */
 
-/*
- * Miscellaneous configurable options
- */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
-
 /*---
  * Physical Memory Map
  */
-- 
2.15.1

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

[U-Boot] [PATCH 3/4] ARMv8: Allow dynamic early stack pointer

[Stephen Warren]

From: Stephen Warren 

U-Boot typically uses a hard-coded value for the stack pointer before
relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
the initial SP at run-time. This is useful to avoid hard-coding addresses
into U-Boot, so that can be loaded and executed at arbitrary addresses and
thus avoid using arbitrary addresses at runtime. This option's value is
the offset added to &_bss_start in order to calculate the stack pointer.
This offset should be large enough so that the early malloc region, global
data (gd), and early stack usage do not overlap any appended DTB.

Signed-off-by: Stephen Warren 
---
 arch/arm/Kconfig   | 13 +
 arch/arm/lib/crt0_64.S |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f2c35e32c649..93b93c142929 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -19,6 +19,19 @@ config POSITION_INDEPENDENT
  from almost any address. This logic relies on the relocation
  information that is embedded into the binary to support U-Boot
  relocating itself to the top-of-RAM later during execution.
+
+config SYS_INIT_SP_BSS_OFFSET
+   int
+   help
+ U-Boot typically uses a hard-coded value for the stack pointer
+ before relocation. Define this option to instead calculate the
+ initial SP at run-time. This is useful to avoid hard-coding addresses
+ into U-Boot, so that can be loaded and executed at arbitrary
+ addresses and thus avoid using arbitrary addresses at runtime. This
+ option's value is the offset added to &_bss_start in order to
+ calculate the stack pointer. This offset should be large enough so
+ that the early malloc region, global data (gd), and early stack usage
+ do not overlap any appended DTB.
 endif
 
 config STATIC_RELA
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 9cb70552feda..a181283e0fa9 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -73,6 +73,9 @@ ENTRY(_main)
ldr x0, =(CONFIG_TPL_STACK)
 #elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
ldr x0, =(CONFIG_SPL_STACK)
+#elif defined(CONFIG_SYS_INIT_SP_BSS_OFFSET)
+   adr x0, __bss_start
+   add x0, x0, #CONFIG_SYS_INIT_SP_BSS_OFFSET
 #else
ldr x0, =(CONFIG_SYS_INIT_SP_ADDR)
 #endif
-- 
2.15.1

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

[U-Boot] [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL

[Stephen Warren]

From: Stephen Warren 

64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE
when building. Fix the binman .dts file so that it doesn't use undefined
values.

Signed-off-by: Stephen Warren 
---
 arch/arm/dts/tegra-u-boot.dtsi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/tegra-u-boot.dtsi b/arch/arm/dts/tegra-u-boot.dtsi
index cde591c5fca4..4f692ee97572 100644
--- a/arch/arm/dts/tegra-u-boot.dtsi
+++ b/arch/arm/dts/tegra-u-boot.dtsi
@@ -1,5 +1,11 @@
 #include 
 
+#ifdef CONFIG_SPL_TEXT_BASE
+#define U_BOOT_OFFSET (CONFIG_SYS_TEXT_BASE - CONFIG_SPL_TEXT_BASE)
+#else
+#define U_BOOT_OFFSET 0
+#endif
+
 / {
binman {
multiple-images;
@@ -9,8 +15,7 @@
u-boot-spl {
};
u-boot {
-   pos = <(CONFIG_SYS_TEXT_BASE -
-   CONFIG_SPL_TEXT_BASE)>;
+   pos = <(U_BOOT_OFFSET)>;
};
};
 
@@ -21,8 +26,7 @@
u-boot-spl {
};
u-boot {
-   pos = <(CONFIG_SYS_TEXT_BASE -
-   CONFIG_SPL_TEXT_BASE)>;
+   pos = <(U_BOOT_OFFSET)>;
};
};
 
@@ -32,8 +36,7 @@
u-boot-spl {
};
u-boot-nodtb {
-   pos = <(CONFIG_SYS_TEXT_BASE -
-   CONFIG_SPL_TEXT_BASE)>;
+   pos = <(U_BOOT_OFFSET)>;
};
};
};
-- 
2.15.1

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

[U-Boot] [PATCH 2/4] ARM: tegra: remove SPL config for non-SPL SoCs

[Stephen Warren]

From: Stephen Warren 

No 64-bit Tegra uses SPL. Remove various unused definitions from config
headers.

Signed-off-by: Stephen Warren 
---
 include/configs/tegra-common.h| 2 ++
 include/configs/tegra186-common.h | 5 -
 include/configs/tegra210-common.h | 5 -
 3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 3cdd9741b241..75e36c0b759d 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -84,11 +84,13 @@
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)
 
+#ifndef CONFIG_ARM64
 /* Defines for SPL */
 #define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SPL_MAX_FOOTPRINT   (CONFIG_SYS_TEXT_BASE - \
CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
+#endif
 
 /* Misc utility code */
 #define CONFIG_BOUNCE_BUFFER
diff --git a/include/configs/tegra186-common.h 
b/include/configs/tegra186-common.h
index 98e4fc2d252b..495d18555f3f 100644
--- a/include/configs/tegra186-common.h
+++ b/include/configs/tegra186-common.h
@@ -60,9 +60,4 @@
"fdt_addr_r=0x8200\0" \
"ramdisk_addr_r=0x8210\0"
 
-/* Defines for SPL */
-#define CONFIG_SPL_TEXT_BASE   0x80108000
-#define CONFIG_SYS_SPL_MALLOC_START0x8009
-#define CONFIG_SPL_STACK   0x800c
-
 #endif
diff --git a/include/configs/tegra210-common.h 
b/include/configs/tegra210-common.h
index 4c05576a909e..93c9455e8ff3 100644
--- a/include/configs/tegra210-common.h
+++ b/include/configs/tegra210-common.h
@@ -60,11 +60,6 @@
"fdt_addr_r=0x8200\0" \
"ramdisk_addr_r=0x8210\0"
 
-/* Defines for SPL */
-#define CONFIG_SPL_TEXT_BASE   0x80108000
-#define CONFIG_SYS_SPL_MALLOC_START0x8009
-#define CONFIG_SPL_STACK   0x800c
-
 /* For USB EHCI controller */
 #define CONFIG_EHCI_IS_TDI
 #define CONFIG_USB_EHCI_TXFIFO_THRESH  0x10
-- 
2.15.1

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

Re: [U-Boot] Socfpga: configure FPGA to SDRAM interface without reprogramming the FPGA

[Jan Siegmund]

Am 18.12.2017 um 22:05 schrieb Marek Vasut:
> On 12/18/2017 09:44 PM, Jan Siegmund wrote:

Hi Marek,

>> Hi all,
> 
> Hi,
> 
>> Here is another question on the FPGA to SDRAM interface of the Cyclone V SoC.
>> Is is possible to configure the the interface in U-Boot or SPL,
> 
> What is "the interface" ?

I am sorry I did not specify it further. I meant the FPGA-to-HPS SDRAM interface
[2], sometimes called FPGA2SDRAM bridge.

> 
> If you mean DRAM, then yes, the CV/AV do _not_ configure the FPGA in SPL
> at all. They just configure the IOMUX/clock rings, but that's all.
> 

I know the FPGA is not configured in SPL, but does the FPGA need to be
configured in SPL or U-Boot, to use the FPGA-to-HPS SDRAM interface? Would it be
possible to just preset the registers for later configuration?
My preferred usecase would be configuring the registers in the table below in
SPL and configuring the FPGA in Linux, with a design using the FPGA-to-HPS SDRAM
interface.

For example, the last bits in the portcfg register define whether the
FPGA-to-HPS SDRAM interface's protocol is AXI or Avalon MM. The problem is, that
this register can't be written to in U-Boot, even though it is specified as rw
[3]. Can this register just be set by programming the FPGA?

>> without reprogramming the FPGA? Maybe through the usage of the generated
>> header files from the Quartus synthesis?
>> The SDRAM controller's registers only differ in eight entries in Linux when 
>> the
>> FPGA is programmed or not.
>>
>> +--+-+++
>> | address  |name | programmed | not programmed |
>> +--+-+++
>> | FFC25064 | | 00044003   | 00044FFF   |
>> | FFC25068 | | 2C00   | 2C03   |
>> | FFC2506c | | 00B0   | 00B3   |
>> | FFC25070 | | 0076   | 0076   |
>> | FFC25074 | | 0098   | 0098   |
>> | FFC25078 | | 0005A003   | 0005AFFF   |
>> | FFC2507c | portcfg |    | 003F   |
>> | FFC25080 | fpgaportrst | 01FF   |    |
>> +--+-+++
>>
>> The registers 0xFFC25064-0xFFC25078 don't show up on the HPS' memory map
>> [1], so are they even intended to be configured?
>>
>> Thanks
>>
>>
>>
>> [1]
>> https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577380716.html#sfo1411577380716
>>
> 
> 

Best regards,
Jan

[2]
https://www.altera.com/documentation/sfo1410143707420.html#sfo1411577336440__section_N10012_N1000F_N10001


[3] https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577375739.html
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Mark Kettenis]

> Date: Tue, 19 Dec 2017 16:24:59 +0100
> From: Maxime Ripard 
> 
> On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 19 Dec 2017 14:12:02 +0100
> > > From: Maxime Ripard 
> > > 
> > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > > So even though the actual u-boot.bin for 64-bit boards is still somewhat
> > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > > traditional MMC env location.
> > > 
> > > So I've had a quick look about what could go possibly go away in our
> > > current armv8 config (using the pine64+ defconfig). Let me know if
> > > some are actually vitals:
> > > 
> > >  - FIT_ENABLE_SHA256_SUPPORT
> > >  - CONSOLE_MUX
> > >  - CMD_CRC32
> > >  - CMD_LZMADEC
> > >  - CMD_UNZIP
> > >  - CMD_LOADB
> > >  - CMD_LOADS
> > >  - CMD_MISC (actually implementing the command sleep)
> > >  - ISO_PARTITION (yes. For CDROMs.)
> > >  - VIDEO_BPP8, VIDEO_BPP16
> > >  - VIDEO_ANSI
> > >  - SHA256
> > >  - LZMA
> > > 
> > > Removing those options make the u-boot.itb binary size going from
> > > 516kB to 478kB, making it functional again *and* allowing us to enable
> > > the DT overlays that seem way more important than any feature
> > > mentionned above (and bumps the size to 483kB).
> > 
> > So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
> > console and usb keyboard are present?  Is the usb keyboard used when
> > it is plugged in but serial otherwise?
> 
> That's actually a very good question, and I don't know, I never used a
> USB keyboard with U-Boot.
> 
> This is enabled on 7 Allwinner boards, and no one complained so far,
> so I would expect to work without that option activated. However, it
> doesn't take that much space either, so it's not like we really need
> to disable it either.

I've used it on several board including my Orange Pi PC2.  With this
option enabled, all output from U-Boot and the EFI bootloader is
visible on both serial and hdmi, and I can interact with U-Boot and
the EFI bootloader over serial and using a USB keyboard.

That allows users to interact with U-Boot and/or the EFI bootloader
and configure whether the kernel sould use serial or "glass" console.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On 19 December 2017 at 14:30, Tom Rini  wrote:
> On Tue, Dec 19, 2017 at 02:27:06PM -0700, Simon Glass wrote:
>> Hi Tom,
>>
>> On 19 December 2017 at 14:19, Tom Rini  wrote:
>> >
>> > On Tue, Dec 19, 2017 at 06:30:48AM -0700, Simon Glass wrote:
>> >
>> > > Hi Tom,
>> > >
>> > > Here is the remainder of my queue for u-boot-dm, including the test
>> > > patches that were dropped. If any of the test patches cause a problem
>> > > with your workflow, please let me know. If you would rather hold these
>> > > off until next release that's fine too.
>> >
>> > The problem is that travis doesn't (yet?  I suppose we could add that
>> > into the matrix) run 'make tests' but I do.  And the new binman tests
>> > don't pass, both due to dtc things:
>> > 15:56:55 FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
>>
>> That sounds like you need a newer dtc. I wonder if we should run the
>> one in the U-Boot tree?
>
> Yes, not running the one in the U-Boot tree would be a bug :)

Ah OK. Then that means that the coverage patch needs to be dropped / respun.

>
>> > and utils:
>> > 15:56:58 sh: 1: coverage: not found
>> > 15:56:58 Exception: Error running 'coverage report': 
>>
>> Yes you need the coverage tools:
>>
>> To enable Python test coverage on Debian-type distributions (e.g. Ubuntu):
>>
>>$ sudo apt-get install python-pip python-pytest
>>$ sudo pip install coverage
>
> Is this documented already somewhere?  I can update my docker slaves to
> include python-coverage.

Yes, tools/binman/README

>
> --
> Tom

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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Tue, Dec 19, 2017 at 02:27:06PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On 19 December 2017 at 14:19, Tom Rini  wrote:
> >
> > On Tue, Dec 19, 2017 at 06:30:48AM -0700, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > Here is the remainder of my queue for u-boot-dm, including the test
> > > patches that were dropped. If any of the test patches cause a problem
> > > with your workflow, please let me know. If you would rather hold these
> > > off until next release that's fine too.
> >
> > The problem is that travis doesn't (yet?  I suppose we could add that
> > into the matrix) run 'make tests' but I do.  And the new binman tests
> > don't pass, both due to dtc things:
> > 15:56:55 FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
> 
> That sounds like you need a newer dtc. I wonder if we should run the
> one in the U-Boot tree?

Yes, not running the one in the U-Boot tree would be a bug :)

> > and utils:
> > 15:56:58 sh: 1: coverage: not found
> > 15:56:58 Exception: Error running 'coverage report': 
> 
> Yes you need the coverage tools:
> 
> To enable Python test coverage on Debian-type distributions (e.g. Ubuntu):
> 
>$ sudo apt-get install python-pip python-pytest
>$ sudo pip install coverage

Is this documented already somewhere?  I can update my docker slaves to
include python-coverage.

-- 
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] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On 19 December 2017 at 14:19, Tom Rini  wrote:
>
> On Tue, Dec 19, 2017 at 06:30:48AM -0700, Simon Glass wrote:
>
> > Hi Tom,
> >
> > Here is the remainder of my queue for u-boot-dm, including the test
> > patches that were dropped. If any of the test patches cause a problem
> > with your workflow, please let me know. If you would rather hold these
> > off until next release that's fine too.
>
> The problem is that travis doesn't (yet?  I suppose we could add that
> into the matrix) run 'make tests' but I do.  And the new binman tests
> don't pass, both due to dtc things:
> 15:56:55 FATAL ERROR: Unrecognized check name "unit_address_vs_reg"

That sounds like you need a newer dtc. I wonder if we should run the
one in the U-Boot tree?

> and utils:
> 15:56:58 sh: 1: coverage: not found
> 15:56:58 Exception: Error running 'coverage report': 

Yes you need the coverage tools:

To enable Python test coverage on Debian-type distributions (e.g. Ubuntu):

   $ sudo apt-get install python-pip python-pytest
   $ sudo pip install coverage

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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Tue, Dec 19, 2017 at 06:30:48AM -0700, Simon Glass wrote:

> Hi Tom,
> 
> Here is the remainder of my queue for u-boot-dm, including the test
> patches that were dropped. If any of the test patches cause a problem
> with your workflow, please let me know. If you would rather hold these
> off until next release that's fine too.

The problem is that travis doesn't (yet?  I suppose we could add that
into the matrix) run 'make tests' but I do.  And the new binman tests
don't pass, both due to dtc things:
15:56:55 FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
and utils:
15:56:58 sh: 1: coverage: not found
15:56:58 Exception: Error running 'coverage report': 

-- 
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] efi_loader: Setup logical_partition media information

[Tom Rini]

On Mon, Dec 11, 2017 at 07:22:33PM +0100, Emmanuel Vadot wrote:

> When adding a partition, set the logical_partition member in the media
> structure as mandated by the UEFI spec.
> 
> Signed-off-by: Emmanuel Vadot 
> Reviewed-by: Heinrich Schuchardt 

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] Pull request: u-boot-sunxi/master

[Tom Rini]

On Tue, Dec 19, 2017 at 05:17:21PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks!
> Jagan.
> 
> The following changes since commit b6251db8c3f0de605b4cd6f15a00fc7dd19cda63:
> 
>   Kconfig: Introduce USE_BOOTCOMMAND and migrate BOOTCOMMAND (2017-11-17 
> 16:37:26 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to 23cd00ab2d8c39eaa15257efcba441939ea66fa8:
> 
>   arm64: dts: sun50i: h5: Order nodes in alphabetic for orangepi-prime 
> (2017-12-19 16:26:21 +0530)
> 

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] Pull request: u-boot-spi/master

[Tom Rini]

On Tue, Dec 19, 2017 at 05:54:21PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 16fa2eb95172e63820ee5f3d4052f3362a6de84e:
> 
>   ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx (2017-11-21 
> 08:03:39 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 065592b40b41b11ee66d8ff71a55156bf1b35088:
> 
>   mtd/spi: fix block count for is25lq040b (2017-12-19 17:33:48 +0530)
> 

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

[U-Boot] [PATCH 1/1] efi_loader: correct EFI_BLOCK_IO_PROTOCOL definitions

[Heinrich Schuchardt]

Add the revision constants.
Depending on the revision additional fields are needed in the
media descriptor.
Use efi_uintn_t for number of bytes to read or write.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h | 10 --
 lib/efi_loader/efi_disk.c |  8 
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 502fffed20..0bc24d 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -424,18 +424,24 @@ struct efi_block_io_media
u32 io_align;
u8 pad2[4];
u64 last_block;
+   u64 lowest_aligned_lba;
+   u32 logical_blocks_per_physical_block;
+   u32 optimal_transfer_length_granualarity;
 };
 
+#define EFI_BLOCK_IO_PROTOCOL_REVISION20x00020001
+#define EFI_BLOCK_IO_PROTOCOL_REVISION30x0002001f
+
 struct efi_block_io {
u64 revision;
struct efi_block_io_media *media;
efi_status_t (EFIAPI *reset)(struct efi_block_io *this,
char extended_verification);
efi_status_t (EFIAPI *read_blocks)(struct efi_block_io *this,
-   u32 media_id, u64 lba, unsigned long buffer_size,
+   u32 media_id, u64 lba, efi_uintn_t buffer_size,
void *buffer);
efi_status_t (EFIAPI *write_blocks)(struct efi_block_io *this,
-   u32 media_id, u64 lba, unsigned long buffer_size,
+   u32 media_id, u64 lba, efi_uintn_t buffer_size,
void *buffer);
efi_status_t (EFIAPI *flush_blocks)(struct efi_block_io *this);
 };
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d299fc8dea..c99632ad0c 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -91,7 +91,7 @@ static efi_status_t efi_disk_rw_blocks(struct efi_block_io 
*this,
 }
 
 static efi_status_t EFIAPI efi_disk_read_blocks(struct efi_block_io *this,
-   u32 media_id, u64 lba, unsigned long buffer_size,
+   u32 media_id, u64 lba, efi_uintn_t buffer_size,
void *buffer)
 {
void *real_buffer = buffer;
@@ -112,7 +112,7 @@ static efi_status_t EFIAPI efi_disk_read_blocks(struct 
efi_block_io *this,
real_buffer = efi_bounce_buffer;
 #endif
 
-   EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
+   EFI_ENTRY("%p, %x, %" PRIx64 ", %zx, %p", this, media_id, lba,
  buffer_size, buffer);
 
r = efi_disk_rw_blocks(this, media_id, lba, buffer_size, real_buffer,
@@ -126,7 +126,7 @@ static efi_status_t EFIAPI efi_disk_read_blocks(struct 
efi_block_io *this,
 }
 
 static efi_status_t EFIAPI efi_disk_write_blocks(struct efi_block_io *this,
-   u32 media_id, u64 lba, unsigned long buffer_size,
+   u32 media_id, u64 lba, efi_uintn_t buffer_size,
void *buffer)
 {
void *real_buffer = buffer;
@@ -147,7 +147,7 @@ static efi_status_t EFIAPI efi_disk_write_blocks(struct 
efi_block_io *this,
real_buffer = efi_bounce_buffer;
 #endif
 
-   EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
+   EFI_ENTRY("%p, %x, %" PRIx64 ", %zx, %p", this, media_id, lba,
  buffer_size, buffer);
 
/* Populate bounce buffer if necessary */
-- 
2.15.1

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

[U-Boot] [PATCH] TCP and wget implementation v3

[Duncan Hare]

>I'd like to see the shim and all changes to existing stack as a
>separate patch to make review simpler.

In this patch.

>Also please make TCP and wget into 2 other separate patches.

Yes, following.

> Yes it should... you could have wget "selects" tcp.
Please send a "how to" example.

>> The rationale behind this change is that UDP file transfers elapsed
>> time is twice the sum of network latency x number of pcckets, and
>> TCP file transfer times are about 4x network latency plus data
>> transit time.

>What settings are used in this tftp benchmark for block size? It makes
>a huge difference to the performance.

We use the default blocksize.

We decided on TCP becuse it is probably the best high performance,
reliable protocol available, and the simplicity of the http protocol.

UDP has its place. Relaible fast file transfer is a poor fit for UDP.

We we lookin at a series of patches, or a concurrent set? The
previous patch include all the pvarius change for setting up
integration into u-boot. This patch standing by itself cannot
be integrated. At a minimun it needs the slightly changed
version of ping.

Signed-off-by: Duncan Hare 
---

 include/net.h |  32 ++
 net/net.c | 102
 +++--- 2 files
 changed, 108 insertions(+), 26 deletions(-)

diff --git a/include/net.h b/include/net.h
index 455b48f6c7..d231987e6e 100644
--- a/include/net.h
+++ b/include/net.h
@@ -15,17 +15,26 @@
 #include 
 #include  /* for nton* / ntoh* stuff */
 
-#define DEBUG_LL_STATE 0   /* Link local state machine changes */
-#define DEBUG_DEV_PKT 0/* Packets or info directed to
the device */ -#define DEBUG_NET_PKT 0  /* Packets on
info on the network at large */ +#define DEBUG_LL_STATE  0  /*
Link local state machine changes */ +#define DEBUG_DEV_PKT
0   /* Packets or info directed to the device */ +#define
DEBUG_NET_PKT   0   /* Packets on info on the network at large */
#define DEBUG_INT_STATE 0   /* Internal network state changes */ 
 /*
  * The number of receive packet buffers, and the required
packet buffer
  * alignment in memory.
  *
+ * The nuber of buffers for TCP is used to calculate a static
TCP window
+ * size, becuse TCP window size is a promise to the sending TCP
to be able
+ * to buffer up to the window size of data.
+ * When the sending TCP has a window size of outstanding
unacknowledged
+ * data, the sending TCP will stop sending.
  */
 
+#if defined(CONFIG_TCP)
+#define CONFIG_SYS_RX_ETH_BUFFER 50/* For TCP */
+#endif
+
 #ifdef CONFIG_SYS_RX_ETH_BUFFER
 # define PKTBUFSRX CONFIG_SYS_RX_ETH_BUFFER
 #else
@@ -354,6 +363,8 @@ struct vlan_ethernet_hdr {
 
 #define IPPROTO_ICMP1  /* Internet Control Message
Protocol*/ #define IPPROTO_UDP  17  /* User
Datagram Protocol   */ +#define IPPROTO_TCP
6   /* Transmission Control Protocol*/ +
 
 /*
  * Internet Protocol (IP) header.
@@ -538,7 +549,7 @@ extern int
net_restart_wrap;   /* Tried all network devices */ 
 enum proto_t {
BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS,
SNTP,
-   TFTPSRV, TFTPPUT, LINKLOCAL
+   TFTPSRV, TFTPPUT, LINKLOCAL, WGET
 };
 
 extern charnet_boot_file_name[1024];/* Boot File name */
@@ -596,10 +607,10 @@ int net_set_ether(uchar *xet, const uchar
*dest_ethaddr, uint prot); int net_update_ether(struct ethernet_hdr
*et, uchar *addr, uint prot); 
 /* Set IP header */
-void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr
source); +void net_set_ip_header(uchar *pkt, struct in_addr dest,
struct in_addr source,
+  u16  pkt_len, u8 prot);
 void net_set_udp_header(uchar *pkt, struct in_addr dest, int dport,
-   int sport, int len);
-
+   int sport, int len);
 /**
  * compute_ip_checksum() - Compute IP checksum
  *
@@ -670,9 +681,16 @@ static inline void net_send_packet(uchar *pkt, int
len)
  * @param sport Source UDP port
  * @param payload_len Length of data after the UDP header
  */
+int net_send_ip_packet(uchar *ether, struct in_addr dest, int dport,
int sport,
+  int payload_len, int proto, u8 action, u32
tcp_seq_num,
+  u32 tcp_ack_num);
+
 int net_send_udp_packet(uchar *ether, struct in_addr dest, int dport,
int sport, int payload_len);
 
+int net_send_tcp_packet(int payload_len, int dport, int sport, u8
action,
+   u32 tcp_seq_num, u32 tcp_ack_num);
+
 /* Processes a received packet */
 void net_process_received_packet(uchar *in_packet, int len);
 
diff --git a/net/net.c b/net/net.c
index 4259c9e321..79255c11eb 100644
--- a/net/net.c
+++ b/net/net.c
@@ -107,6 +107,12 @@
 #if defined(CONFIG_CMD_SNTP)
 #include "sntp.h"
 #endif
+#if defined(CONFIG_TCP)
+#include "tcp.h"
+#endif
+#if defined(CONFIG_CMD_WGET)
+#include "wget.h"

Re: [U-Boot] [PATCH] musb: sunxi: Use base address from device tree

[Marek Vasut]

On 12/19/2017 05:04 PM, Chen-Yu Tsai wrote:
> On Tue, Dec 12, 2017 at 11:56 PM, Marek Vasut  wrote:
>> On 12/12/2017 08:24 AM, Chen-Yu Tsai wrote:
>>> Now that the musb sunxi glue driver is completely device model / device
>>> tree driven, we should use the base address from the device tree,
>>> instead of hard-coding it in the source code.
>>>
>>> Fixes: 3a61b080acee ("musb: sunxi: switch to the device model")
>>> Signed-off-by: Chen-Yu Tsai 
>>> ---
>>>  drivers/usb/musb-new/sunxi.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
>>> index 7ee44ea91900..ae6a54118cd1 100644
>>> --- a/drivers/usb/musb-new/sunxi.c
>>> +++ b/drivers/usb/musb-new/sunxi.c
>>> @@ -318,7 +318,7 @@ static int musb_usb_probe(struct udevice *dev)
>>>
>>>  #ifdef CONFIG_USB_MUSB_HOST
>>>   host->host = musb_init_controller(_plat, NULL,
>>> -   (void *)SUNXI_USB0_BASE);
>>> +  dev_read_addr_ptr(dev));
>>
>> What happens if dev_read_addr_ptr() returns some non-standard value?
> 
> You mean like an error value? That would likely be a signal that
> the device tree is broken, like a missing property or invalid value,
> or a corrupt device tree. In all cases I think blowing up should be
> an expected result for a device tree driven driver?

What about handling the errors instead ? :)

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] armv8: ls2085a: Update README file for NAND boot

[York Sun]

On 12/07/2017 02:38 PM, York Sun wrote:
> Update README file to note LS2088A and LS1088A don't support booting
> from NAND flash.
> 
> Signed-off-by: York Sun 
> ---
> 

Applied to fsl-qoriq master.

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

Re: [U-Boot] [PATCH] armv8: ls1046aqds: Adjust IFC timing for NOR flash

[York Sun]

On 12/12/2017 11:41 AM, York Sun wrote:
> Increase setup, assertion and hold time related to chip-select signal.
> Additional delay is needed for the signal to propogate through FPGA.
> This adjustment slightly increase the read and write cycle but has no
> impact on burst read or write.
> 
> Signed-off-by: York Sun 
> ---

Applied to fsl-qoriq master.

York

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

Re: [U-Boot] [PATCH 1/2] armv8: ls2080a: Increase load image len for NAND boot

[York Sun]

On 12/07/2017 02:38 PM, York Sun wrote:
> From: Yuan Yao 
> 
> Again the image size increases and the length needs to be adjusted.
> 
> Signed-off-by: York Sun 
> ---
> 

Fixed author information.Applied to fsl-qoriq master.

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

Re: [U-Boot] [PATCH] musb: sunxi: Use base address from device tree

[Chen-Yu Tsai]

On Tue, Dec 12, 2017 at 11:56 PM, Marek Vasut  wrote:
> On 12/12/2017 08:24 AM, Chen-Yu Tsai wrote:
>> Now that the musb sunxi glue driver is completely device model / device
>> tree driven, we should use the base address from the device tree,
>> instead of hard-coding it in the source code.
>>
>> Fixes: 3a61b080acee ("musb: sunxi: switch to the device model")
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/usb/musb-new/sunxi.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
>> index 7ee44ea91900..ae6a54118cd1 100644
>> --- a/drivers/usb/musb-new/sunxi.c
>> +++ b/drivers/usb/musb-new/sunxi.c
>> @@ -318,7 +318,7 @@ static int musb_usb_probe(struct udevice *dev)
>>
>>  #ifdef CONFIG_USB_MUSB_HOST
>>   host->host = musb_init_controller(_plat, NULL,
>> -   (void *)SUNXI_USB0_BASE);
>> +  dev_read_addr_ptr(dev));
>
> What happens if dev_read_addr_ptr() returns some non-standard value?

You mean like an error value? That would likely be a signal that
the device tree is broken, like a missing property or invalid value,
or a corrupt device tree. In all cases I think blowing up should be
an expected result for a device tree driven driver?

ChenYu

>
>>   if (!host->host)
>>   return -EIO;
>>
>> @@ -326,7 +326,7 @@ static int musb_usb_probe(struct udevice *dev)
>>   if (!ret)
>>   printf("Allwinner mUSB OTG (Host)\n");
>>  #else
>> - ret = musb_register(_plat, NULL, (void *)SUNXI_USB0_BASE);
>> + ret = musb_register(_plat, NULL, dev_read_addr_ptr(dev));
>>   if (!ret)
>>   printf("Allwinner mUSB OTG (Peripheral)\n");
>>  #endif
>>
>
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [v4 2/3] armv8: ls1012ardb: add more board version information

[York Sun]

On 12/07/2017 11:54 PM, Yangbo Lu wrote:
> Add LS1012ARDB RevC/RevC1/RevC2/RevD/RevE information and
> detect it when u-boot starts up.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v4:
>   - Added this patch.

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] [v4 3/3] armv8: ls1012ardb: support hwconfig for eSDHC1 enabling

[York Sun]

On 12/07/2017 11:54 PM, Yangbo Lu wrote:
> I2C reading for DIP switch setting is not reliable for LS1012ARDB
> RevD and later versions. This patch is to add hwconfig support to
> enable/disable eSDHC1 manually for these boards. Also drop 'status'
> fix-up for eSDHC0 and leave it as it is. It shouldn't always be
> fixed up with 'okay'.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - Just used hwconfig() instead of getenv() and hwconfig_f().
> Changes for v3:
>   - only applied hwconfig support for RevD and later versions.
> Changes for v4:
>   - Modified commit message.
>   - reused io variable.
>   - checked CONFIG_HWCONFIG before use it.

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] [v4 1/3] armv8: ls1012ardb: clean up definitions for I2C IO expanders

[York Sun]

On 12/07/2017 11:54 PM, Yangbo Lu wrote:
> This patch is to clean up definitions for I2C IO expanders.
> The value 0x10 of __SW_BOOT_EMU is wrong. It should be 0x2.
> Fixed it in this patch.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v4:
>   - Added this patch.

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] [PATCH] board/ls2080a, ls1088a: Add check for mc-dpl applied in fdt

[York Sun]

On 12/06/2017 09:40 PM, Yogesh Gaur wrote:
> In fdt_fixup_board_enet() perform fdt fixup, fdt_status_okay, only when
> both MC is applied and DPL is deployed.
> Else returns failure, fdt_status_fail().
> 
> This patch add this check for
> - LS2080A/LS2088A boards: in dir ls2080a, ls2080ardb and ls2080aqds
> - LS1088A board: in dir ls1088a
> 
> Signed-off-by: Yogesh Gaur 
> ---

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] [v4 1/2] armv8: ls1043a/ls2080a: check SoC by device ID

[York Sun]

On 12/03/2017 08:37 PM, Wenbin song wrote:
> Check LS1043A/LS2080a by device ID without using personality ID to
> determine revision number. This check applies to all various
> personalities of the same SoC family.
> 
> Signed-off-by: Wenbin Song 
> ---
> Changes for V1:
>   None.
> Changes for v2:
>   Modify the commit message and subject.
>   Add SVR_DEV and IS_SVR_DEV mocros. 
> Changes for V3:
>   None.
> ---

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] [v4 2/2] armv8: layerscape: Discard the needless cpu nodes

[York Sun]

On 12/03/2017 08:37 PM, Wenbin song wrote:
> Using "cpu_pos_mask()" function to detect the real online cpus,
> and discard the needless cpu nodes on kernel dts.
> 
> Signed-off-by: Wenbin Song 
> ---
> Changes for v1:
>   Remove the config option.
>   Use id_to_core() funcation to find the position of core.
> Changes for v2:
>   None.
> Changes for v3:
>   Replace "ls1043a" with "layerscape" on the subject.
> ---

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] [PATCH v3] arm64: ls1012afrdm: Add distro boot support

[York Sun]

On 11/30/2017 03:14 AM, Rajesh Bhagat wrote:
> Include common config_distro_defaults.h and config_distro_bootcmd.h
> for u-boot enviroments to support automatical distro boot which
> scan boot.scr from external storage devices(e.g. SD and USB)
> and execute autoboot script.
> 
> Signed-off-by: Bhaskar Upadhaya 
> Signed-off-by: Rajesh Bhagat 
> ---
> Depends on:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F837811%2F=02%7C01%7Cyork.sun%40nxp.com%7Cf80f6d9cccfc4d9f560908d537e38ac3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636476372779591179=PtWvgIqfSR2plBBgRKwlfOSRI%2F1Ef%2BwDDJWmO%2Bo6las%3D=0
> 
> Changes in v3: 
>  - Rebased to dependency patch

Applied to fsl-qoriq master. Thanks.

York

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

Re: [U-Boot] [PATCH v5] arm64: ls1012ardb: Add distro boot support

[York Sun]

On 11/30/2017 03:14 AM, Rajesh Bhagat wrote:
> Include common config_distro_defaults.h and config_distro_bootcmd.h
> for u-boot enviroments to support automatical distro boot which
> scan boot.scr from external storage devices(e.g. SD and USB)
> and execute autoboot script.
> 
> Signed-off-by: Bhaskar Upadhaya 
> Signed-off-by: Rajesh Bhagat 
> ---
> Depends on:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F837811%2F=02%7C01%7Cyork.sun%40nxp.com%7C75341176bea242f6452a08d537e3874f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636476372724178215=BbyZUv1zKlluIBMOQizA%2FpEuzr7cs8V7s4CXwxJekRA%3D=0
> 
> Changes in v5:
>  - Rebased to dependency patch 
> 

Applied to fsl-qoriq master. Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: ls1088ardb: support force SDHC mode by hwconfig

[York Sun]

On 11/26/2017 11:59 PM, Yangbo Lu wrote:
> The BRDCFG5[SPISDHC] register field of Qixis device is used
> to control SPI and SDHC signal routing.
> 
> 10 = Force SDHC Mode
>   - SPI_CS[0] is routed to CPLD for SDHC_VS use.
>   - SPI_CS[1] is unused.
>   - SPI_CS[2:3] are routed to the TDMRiser slot.
> 
> 11 = Force eMMC Mode
>   - SPI_CS[0:3] are routed to the eMMC card.
> 
> 0X = Auto Mode
>   - If SDHC_CS_B=0 (SDHC card installed): Use SDHC mode
> described above.
>   - Else SDHC_CS_B=1 (no SDHC card installed): Use eMMC
> mode described above.
> 
> In default the hardware uses auto mode, but sometimes we need
> to use force SDHC mode to support SD card hotplug, or SD sleep
> waking up in kernel. This patch is to support force SDHC mode
> by hwconfig.
> 
> Signed-off-by: Yangbo Lu 
> ---

Applied to fsl-qoriq master. Thanks.

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Jagan Teki]

On Tue, Dec 19, 2017 at 9:06 PM, Maxime Ripard
 wrote:
> On Tue, Dec 19, 2017 at 02:27:57PM +, Andre Przywara wrote:
>> >>> Removing those options make the u-boot.itb binary size going from
>> >>> 516kB to 478kB, making it functional again *and* allowing us to enable
>> >>> the DT overlays that seem way more important than any feature
>> >>> mentionned above (and bumps the size to 483kB).
>> >>
>> >> How important is the raw MMC environment for the ARM64 boards, actually?
>> >> Most of the rationale for the 32-bit side seemed to apply to legacy use
>> >> cases only. Do we have reports/complaints from 64-bit users?
>> >
>> > Pretty much as important as it is on arm I guess. We just have less
>> > history, but the same use cases.
>> >
>> > I'd really like to give at least one release for transition, which
>> > would mean having a schedule like this:
>> >
>> >   - in 2018.01, merge those config removals so that we have least have
>> > something that works quite fast
>
> So, given the various feedback, the current diff for the pine64 is:
> http://code.bulix.org/t7icrw-243561
>
> With that, We're at 500kB with the ATF.
>
> Does it work for everyone here?

496KB for a64-olinuxino, nanopi-a64
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 04:36:13PM +0100, Maxime Ripard wrote:
> On Tue, Dec 19, 2017 at 02:27:57PM +, Andre Przywara wrote:
> > >>> Removing those options make the u-boot.itb binary size going from
> > >>> 516kB to 478kB, making it functional again *and* allowing us to enable
> > >>> the DT overlays that seem way more important than any feature
> > >>> mentionned above (and bumps the size to 483kB).
> > >>
> > >> How important is the raw MMC environment for the ARM64 boards, actually?
> > >> Most of the rationale for the 32-bit side seemed to apply to legacy use
> > >> cases only. Do we have reports/complaints from 64-bit users?
> > > 
> > > Pretty much as important as it is on arm I guess. We just have less
> > > history, but the same use cases.
> > > 
> > > I'd really like to give at least one release for transition, which
> > > would mean having a schedule like this:
> > > 
> > >   - in 2018.01, merge those config removals so that we have least have
> > > something that works quite fast
> 
> So, given the various feedback, the current diff for the pine64 is:
> http://code.bulix.org/t7icrw-243561
> 
> With that, We're at 500kB with the ATF.
> 
> Does it work for everyone here?

Works for me, 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] How to re-use the driver data for pre-reloc in post-reloc driver

[Simon Glass]

+Tom, Wolfgang, Masahiro

Hi Kever,

On 12 December 2017 at 21:35, Kever Yang  wrote:
> Hi Simon,
>
> This is not the topic about disable the relocate feature in U-Boot
> proper.
>
> My target is re-use kernel dtb in U-Boot and U-Boot can work properly even
> if
> some of dts node in kernel is broken.
> - U-Boot mark a set of driver as u-boot,dm-pre-reloc, suppose to able to get
>into U-Boot shell with them. dram, syscon, serial, clock, pinctrl, emmc,
> and etc.
> In this case we can always make U-Boot works and get into shell.
> - When relocate, I would like to read dtb from kernel and use it for U-Boot
> driver.
> In this case, we can get periph driver setting for different board from
> kernel dtb,
> what we need most are: power/pmic, display, charger, input key and etc.
>
> The problem is, the dm architecture now always init all the driver from dtb
> after relocate,
> If anything missin in kernel dtb, the U-Boot hang there. What I met now in
> rockchip
> kernel(same in different SoCs) is:
> - no stdout in chosen, we use cmdline instead;
> - debug uart node not enabled; we may use ttyFIQ driver instead of uart
> driver for it.
> - no alias for emmc/sd, which is much in U-Boot;
> - compaptible for syscon may different, kernel may use "syscon",
> "simple-mfd" only,
> but U-Boot need "rockchip,rk3228-grf" for GRF and "rockchip,rk3228-PMU"
> for PMU and etc.
> Of cause I can update kernel source, but as you can see we are not able to
> cover all the case
> because kernel may have different use with U-Boot.

One option is to fix up the kernel DT using code, e.g. in the
fix_fdt() function.

Another is to fix the Linux DT. I think the above could all be fixed
without complaints from Linux. Could you try that? We should use
exactly the same DT for Linux and U-Boot. Even the u-boot,dm-* should
be able to be sent upstream, based on my understanding of a discussion
at ELCE.

>
> If we do not need to re-init all the driver after relocate, or re-use the
> driver data,
> then we can have a robust U-Boot only depends on U-Boot dtb with
> dm-pre-reloc,
> and we can have a good compatibility U-Boot with kernel dtb support for
> different board/periph.
> Then U-Boot focus on SoC support, kernel focus on all kinds of board/periph
> support,
> U-Boot need to sync periph driver from kernel, so that if kernel works then
> U-Boot also works, developers
> do not need to develop one for kernel and one for U-Boot.
>
> Could you help to make a demo patch about how to re-use the driver-data of
> pre-reloc to post-reloc?

I don't think this is a good way to solve the problem. Masahiro has
suggested that we eliminate pre-relocatiom U-Boot when using SPL, so
in this case we would not have the ability to use a separate DT for
pre-relocation and post-relocation U-Boot.

As to your goal of avoiding device re-init, Masahiro's idea (if
implemented) would avoid the need to re-init (SPL would still do it
but that is a separate program).

That said, I will see if I can come up with a patch to allow access to
driver data from a previous driver-model data structure. I worry that
it would be a bit fiddly though.

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

Re: [U-Boot] [RFC] Design of UEFI drivers

[Simon Glass]

Hi Heinrich,

On 12 December 2017 at 12:57, Heinrich Schuchardt  wrote:
> 2a92080d8c4 [PATCH] efi_loader: add file/filesys support
> implemented the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
>
> Unfortunately it assumes that the available media are constant.
>
> iPXE offers the possibility to attach iSCSI targets. On the handle for
> the attached target the EFI_BLOCK_IO_PROTOCOL and the
> EFI_DEVICE_PATH_PROTOCOL are installed.
>
> Afterwards the ConnectController boot service is called to connect
> drivers to the iSCSI target. This relates to the following statement in
> the UEFI spec:
>
> The firmware automatically creates handles for any block device that
> supports the following file system formats:
> - FAT12
> - FAT16
> - FAT32

Doesn't it have to probe the device to do this? Can this be done in a
lazy fashion, or must it be done up front?

>
> iPXE expects that the driver for the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
> gets installed to a child handle representing the partitions of the
> attached iSCSI target.
>
> So I think we have to rewrite the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
> implementation as an UEFI driver. The driver handle shall implement the
> EFI_DRIVER_BINDING_PROTOCOL. For each attached disk we shall call the
> ConnectController boot service. It will call the supported() service for
> the driver binding protocol and in case of success the start() service.
> The driver will in turn install the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on
> the block io device.
>
> The same pattern could be applied to the simple
> EFI_SIMPLE_NETWORK_PROTOCOL and the EFI_GRAPHICS_OUTPUT_PROTOCOL.
>
> I now wonder what would be the best design. Should we have a uclass
> comprising all UEFI drivers? This would allow generating the UEFI driver
> handles by iterating the members of the uclass.

One idea is to attach a UEFI device (in a UEFI uclass) to each U-Boot
device that supports UEFI, as a child. Then you can iterate through
the uclass and find all the UEFI devices, plus you can look at the
parent device to get information about it.

That would also help to make UEFI support more consistent with driver model.

>
> Looking forward to your ideas.
>
> Best regards
>
> Heinrich

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

Re: [U-Boot] [PATCH 1/2] disk: part: scan the disk if the part_type is unknow

[Simon Glass]

Hi Kever,

On 13 December 2017 at 23:39, Kever Yang  wrote:
> We can get the new part table when we write a new partition table to
> a blank disk with this patch, or else we have to reset the board
> to get new partition table.
>
> Signed-off-by: Kever Yang 
> ---
>
>  disk/part.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)

How are you writing the partition table? I wonder if we should rescan
then? Or should we have a flag indicating when we have to scan again?

With your patch, it would not be possible to change the partition type
(e.g. from FAT to EXT4), right?

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

Re: [U-Boot] [ANN] U-Boot v2018.01-rc1 released

[Simon Glass]

Hi Tom,

On 7 December 2017 at 06:16, Tom Rini  wrote:
> On Thu, Dec 07, 2017 at 04:49:49AM -0700, Simon Glass wrote:
>> Hi Tom,
>>
>> On 4 December 2017 at 16:33, Tom Rini  wrote:
>> > Hey all,
>> >
>> > So it's release day and I've put up v2018.01-rc1.  The merge window is
>> > now closed and I've updated git and the tarballs are also up now.
>> >
>> > I think my patch queue is in OK shape currently, but I need to
>> > pick up a few series once I've had a chance to test them more, and I
>> > expect a new EFI PR to come along soon too.  Once again, I'm going to
>> > otherwise try and be pretty strict about what goes in, and more so as
>> > time goes on.  I will follow the usual rule of an -rc every other Monday
>> > and we're looking at release on Jan 8th, 2018.
>> >
>> > Thanks all!
>>
>> I have some patches that are marked as accepted but there was no email
>> and I don't see them in mainline. For example this one:
>>
>> http://patchwork.ozlabs.org/patch/841455/
>
> Ooops, thanks!  I had put them in a bundle to test, saw that it caused
> 'make tests' to fail without (I assume) some other series you had, and
> moved it over to you.  But I forgot to remove from the bundle, so I then
> accidentally moved them to me/Accepted.  Fixed now.  Thanks!

OK I've applied these in now that the previous pull request has cleared.

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

Re: [U-Boot] fs/fat: device not booting since conversion to dir iterators

[Simon Glass]

Hi Patrick,

On 13 December 2017 at 03:15, Patrick Brünn  wrote:
>>From: Patrick Brünn
>>Sent: Donnerstag, 30. November 2017 12:22
>>
>>Since commit 8eafae209c35932d9a6560809c55ee4641534236
>>my mx53cx9020_defconfig stopped booting.
>>...
>>It seems important to read into do_fat_read_at_block. If I
>>allocate a temporary buffer and read into that one, I still
>>can't boot. That seems strange to me as, I couldn't find
>>any uninitialized access to do_fat_read_at_block anywhere.
>>
> I believe I finally tracked it down to the linker.
>
> Without accessing do_fat_read_at_block within fat.c, I find
> .bss. do_fat_read_at_block as "discarded input section" in
> my u-boot.map
>
> With a patch like this:
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index d16883fa10..8e70fdbc8d 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -1157,6 +1157,7 @@ int fat_opendir(const char *filename, struct 
> fs_dir_stream **dirsp)
> return -ENOMEM;
> memset(dir, 0, sizeof(*dir));
>
> +   if (do_fat_read_at_block[0])
> +   printf("value doesn't matter, the access is important\n");
> +
> ret = fat_itr_root(>itr, >fsdata);
> if (ret)
> goto fail_free_dir;
>
> The section isn't discarded and my board boots again.
>
>
> Another workaround would be:
> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> index 124b44a337..02f61fcc3c 100644
> --- a/arch/arm/config.mk
> +++ b/arch/arm/config.mk
> @@ -17,7 +17,7 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections 
> -fdata-sections
>  CFLAGS_EFI := -fpic -fshort-wchar
>
>  LDFLAGS_FINAL += --gc-sections
> -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
> +PLATFORM_RELFLAGS += -ffunction-sections \
>  -fno-common -ffixed-r9
>  PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
>$(call cc-option,-mshort-load-bytes,$(call 
> cc-option,-malignment-traps,))
>
> Or a hack like:
> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
> index 37d4c605ac..b916cbc733 100644
> --- a/arch/arm/cpu/u-boot.lds
> +++ b/arch/arm/cpu/u-boot.lds
> @@ -219,6 +219,7 @@ SECTIONS
> }
>
> .bss_end __bss_limit (OVERLAY) : {
> +   KEEP(*(.bss.do_fat_read_at_block));
> KEEP(*(.__bss_end));
> }
>
> I also tried to mark do_fat_read_at_block as:
> volatile, __used and/or __attribute__((externally_visible))
>
> This doesn't help.
>
> Moving it into fat_write.c doesn't help either(with/without static)
>
> My toolchain is:
> ~/u-boot$ arm-linux-gnueabihf-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-linux-gnueabihf-gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/6/lto-wrapper
> Target: arm-linux-gnueabihf
> Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' 
> --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-6 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm 
> --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross/jre 
> --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-cross 
> --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --disable-libgcj --with-target-system-zlib --enable-objc-gc=auto 
> --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a 
> --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- 
> --includedir=/usr/arm-linux-gnueabihf/include
> Thread model: posix
> gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>
> ~/u-boot$ arm-linux-gnueabihf-ld -v
> GNU ld (GNU Binutils for Debian) 2.28
>
>
> Does anyone have an idea what else I can try to prevent my linker from 
> removing
> do_fat_read_at_block?

This doesn't seem to be used unless you have enabled CONFIG_FAT_WRITE. Have you?

I wonder if the problem is somewhere else, and the presence of this
buffer is just moving things apart in the data space, and thus masking
the problem?

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

Re: [U-Boot] [PATCH 1/1] dm: fix typo falback

[Simon Glass]

On 17 December 2017 at 10:19, Heinrich Schuchardt  wrote:
> %s/falback/fallback/g
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/dm/uclass.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH] musb: sunxi: Use base address from device tree

[Simon Glass]

On 12 December 2017 at 00:24, Chen-Yu Tsai  wrote:
> Now that the musb sunxi glue driver is completely device model / device
> tree driven, we should use the base address from the device tree,
> instead of hard-coding it in the source code.
>
> Fixes: 3a61b080acee ("musb: sunxi: switch to the device model")
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/usb/musb-new/sunxi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH] power: tps65910: replace error() by pr_err()

[Simon Glass]

On 18 December 2017 at 07:38, Felix Brack  wrote:
> The patch replaces the former error() by the new pr_err().
> This makes the TPS65910 driver conform to Masahiro's patch
> 'treewide:replace with error() with pr_err()' introduced
> October 2017.
>
> Signed-off-by: Felix Brack 
> ---
>
>  drivers/power/pmic/pmic_tps65910_dm.c| 4 ++--
>  drivers/power/regulator/tps65910_regulator.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH] BCM283x ALT5 function for JTAG pins

[Simon Glass]

On 18 December 2017 at 01:13,   wrote:
> From: Henry Zhang 
>
> BCM2835 ARM Peripherals doc shows gpio pins 4, 5, 6, 12 and 13 carry altenate
> function, ALT5 for ARM JTAG
>
> Signed-off-by: Henry Zhang 
> ---
>  arch/arm/dts/bcm283x.dtsi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [RESEND PATCH 2/2] configs: stm32f746-disco: enable MMC related flags

[Simon Glass]

On 12 December 2017 at 02:15,   wrote:
> From: Patrice Chotard 
>
> STM32F469-disco embeds an arm_pl180 mmc IP, so
> enable CMD_MMC, DM_MMC and ARM_PL180_MMCI flags.
>
> Also enables all filesystem command related flags :
>   _ CMD_EXT2
>   _ CMD_EXT4
>   _ CMD_FAT
>   _ CMD_FS_GENERIC
>   _ CMD_GPT
>   _ CMD_BOOTZ
>
> Signed-off-by: Patrice Chotard 
> ---
>  configs/stm32f746-disco_defconfig | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)

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

Re: [U-Boot] Swig now required to build U-Boot?

[Simon Glass]

Hi Tom,

On 11 December 2017 at 18:51, Tom Rini  wrote:
> On Fri, Dec 08, 2017 at 04:16:41PM -0800, Sergey Kubushyn wrote:
>> On Fri, 8 Dec 2017, Simon Glass wrote:
>>
>> >Hi Stephen,
>> >
>> >On 8 December 2017 at 16:28, Stephen Warren  wrote:
>> >>Simon,
>> >>
>> >>Is it expected that the latest u-boot-dm.git master branch now requires
>> >>swig? All the non-sandbox builds on my test systems are failing:
>> >>
>> >>  CHK include/config/uboot.release
>> >>  CHK include/generated/timestamp_autogenerated.h
>> >>  GEN ./Makefile
>> >>  UPD include/generated/timestamp_autogenerated.h
>> >>  CHK include/config.h
>> >>  CFG u-boot.cfg
>> >>  SHIPPED scripts/dtc/pylibfdt/libfdt.i
>> >>  PYMOD   scripts/dtc/pylibfdt/_libfdt.so
>> >>unable to execute 'swig': No such file or directory
>> >>error: command 'swig' failed with exit status 1
>> >>make[4]: *** [scripts/dtc/pylibfdt/_libfdt.so] Error 1
>> >>make[3]: *** [scripts/dtc/pylibfdt] Error 2
>> >>make[2]: *** [scripts/dtc] Error 2
>> >>make[1]: *** [scripts] Error 2
>> >>make[1]: *** Waiting for unfinished jobs
>> >
>> >Yes, unless we have a very recent libfdt on the system (and even then
>> >I'm not sure that it is picked up). We need swig to build pylibfdt
>> >which is needed for binman.
>>
>> Err, would it be long before we need Java/Eclipse/Maven/younameit to just
>> build U-Boot?
>
> There is a fine line to be walked here.  On the flip side, do we want to
> have to depend on N little external tools to put together a functional
> image?  We can use binman to avoid some subset of that.  That said,
> Simon, are we only building binman related stuff when we need binman in
> the end?  Thanks!

Sorry I missed this question but answered it on another thread. Yes we
are only building pylibfdt when it is needed. It is controlled by
CONFIG_PYLIBFDT which is enabled when binman or dtoc are needed.

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

Re: [U-Boot] [RESEND PATCH 1/2] ARM: DTS: stm32: add MMC nodes for stm32f746-disco and stm32f769-disco

[Simon Glass]

On 12 December 2017 at 02:14,   wrote:
> From: Patrice Chotard 
>
> Add DT nodes to enable ARM_PL180_MMCI IP support for STM32F746
> and STM32F769 discovery boards
>
> There is a hardware issue on these boards, it misses a pullup on the GPIO line
> used as card detect to allow correct SD card detection.
> As workaround, cd-gpios property is not present in DT.
> So SD card is always considered present in the slot.
>
> Signed-off-by: Christophe Priouzeau 
> Signed-off-by: Patrice Chotard 
> ---
>  arch/arm/dts/stm32f746-disco.dts| 12 
>  arch/arm/dts/stm32f746.dtsi | 85 
> +
>  arch/arm/dts/stm32f769-disco.dts| 12 
>  include/dt-bindings/pinctrl/stm32f746-pinfunc.h | 19 +-
>  4 files changed, 127 insertions(+), 1 deletion(-)

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 02:27:57PM +, Andre Przywara wrote:
> >>> Removing those options make the u-boot.itb binary size going from
> >>> 516kB to 478kB, making it functional again *and* allowing us to enable
> >>> the DT overlays that seem way more important than any feature
> >>> mentionned above (and bumps the size to 483kB).
> >>
> >> How important is the raw MMC environment for the ARM64 boards, actually?
> >> Most of the rationale for the 32-bit side seemed to apply to legacy use
> >> cases only. Do we have reports/complaints from 64-bit users?
> > 
> > Pretty much as important as it is on arm I guess. We just have less
> > history, but the same use cases.
> > 
> > I'd really like to give at least one release for transition, which
> > would mean having a schedule like this:
> > 
> >   - in 2018.01, merge those config removals so that we have least have
> > something that works quite fast

So, given the various feedback, the current diff for the pine64 is:
http://code.bulix.org/t7icrw-243561

With that, We're at 500kB with the ATF.

Does it work for everyone here?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH] sunxi: imply CONFIG_OF_LIBFDT_OVERLAY

[Andre Heider]

On 19/12/17 13:51, Maxime Ripard wrote:

On Tue, Dec 19, 2017 at 05:12:00PM +0530, Jagan Teki wrote:

On Wed, Dec 13, 2017 at 2:16 PM, Andre Heider  wrote:

fdt overlay support is useful for all sunxi boards, enable per default
and remove it from sunxi defconfigs.

Signed-off-by: Andre Heider 
---

Hi,

there're way too many sunxi boards so I'm not 100% sure this is the best
approach...

Are there boards where enabling this is definitely not desired?

Thanks,
Andre

  arch/arm/Kconfig   | 1 +
  configs/CHIP_defconfig | 1 -
  configs/CHIP_pro_defconfig | 1 -
  3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73909952d0..25847b3aa1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -715,6 +715,7 @@ config ARCH_SUNXI
 select USE_TINY_PRINTF
 imply CMD_GPT
 imply FAT_WRITE
+   imply OF_LIBFDT_OVERLAY


It's increasing u-boot.itb size to 512KB (which is 508K earlier) and
in either case the size moves on env side where env start 0x88000
(504KB)


Right, so maybe we can make that conditional to ARM?

Maxime



From the 'we're out of space' thread:
...
> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
> overlay support, we're at 500kB.
>
> Again, tight, but under the limit.
...

If I understood correctly the issue will be solved without any requiring 
changes to this patch.

Let me know if that is not the case.

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote:
> > Date: Tue, 19 Dec 2017 14:12:02 +0100
> > From: Maxime Ripard 
> > 
> > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > So even though the actual u-boot.bin for 64-bit boards is still somewhat
> > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > traditional MMC env location.
> > 
> > So I've had a quick look about what could go possibly go away in our
> > current armv8 config (using the pine64+ defconfig). Let me know if
> > some are actually vitals:
> > 
> >  - FIT_ENABLE_SHA256_SUPPORT
> >  - CONSOLE_MUX
> >  - CMD_CRC32
> >  - CMD_LZMADEC
> >  - CMD_UNZIP
> >  - CMD_LOADB
> >  - CMD_LOADS
> >  - CMD_MISC (actually implementing the command sleep)
> >  - ISO_PARTITION (yes. For CDROMs.)
> >  - VIDEO_BPP8, VIDEO_BPP16
> >  - VIDEO_ANSI
> >  - SHA256
> >  - LZMA
> > 
> > Removing those options make the u-boot.itb binary size going from
> > 516kB to 478kB, making it functional again *and* allowing us to enable
> > the DT overlays that seem way more important than any feature
> > mentionned above (and bumps the size to 483kB).
> 
> So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
> console and usb keyboard are present?  Is the usb keyboard used when
> it is plugged in but serial otherwise?

That's actually a very good question, and I don't know, I never used a
USB keyboard with U-Boot.

This is enabled on 7 Allwinner boards, and no one complained so far,
so I would expect to work without that option activated. However, it
doesn't take that much space either, so it's not like we really need
to disable it either.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH] am335x_hs_evm: Trim options in SPL to reduce binary size

[Tom Rini]

On Tue, Dec 19, 2017 at 08:54:25AM -0600, Andrew F. Davis wrote:
> On 12/16/2017 10:04 PM, Tom Rini wrote:
> > The am335x_hs_evm runs into size constraint problems at times with
> > various toolchains as changes come in due to the config have a large
> > number of options in SPL (to showcase what is possible) while also
> > having rather constrained binary limits.  Gain some of this room back by
> > lowering the loglevel, disabling HW partition support and switching over
> > to the tiny FIT image support.
> > 
> > Cc: Andrew F. Davis 
> > Signed-off-by: Tom Rini 
> > ---
> > I'd really appreciate a run-time test of this patch if at all possible
> > as I'm a little worried about TINY_FIT being incompatible with all of
> > the security options.  Thanks!
> > ---
> >  configs/am335x_hs_evm_defconfig | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/configs/am335x_hs_evm_defconfig 
> > b/configs/am335x_hs_evm_defconfig
> > index 48b0e8583997..8eb304686dc7 100644
> > --- a/configs/am335x_hs_evm_defconfig
> > +++ b/configs/am335x_hs_evm_defconfig
> > @@ -13,10 +13,12 @@ CONFIG_ANDROID_BOOT_IMAGE=y
> >  CONFIG_FIT_IMAGE_POST_PROCESS=y
> >  CONFIG_SPL_LOAD_FIT=y
> >  CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
> > +CONFIG_LOGLEVEL=3
> >  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> >  CONFIG_VERSION_VARIABLE=y
> >  CONFIG_ARCH_MISC_INIT=y
> >  CONFIG_SPL=y
> > +CONFIG_SPL_FIT_IMAGE_TINY=y
> >  # CONFIG_SPL_ENV_SUPPORT is not set
> >  # CONFIG_SPL_EXT_SUPPORT is not set
> >  CONFIG_SPL_MTD_SUPPORT=y
> > @@ -37,6 +39,7 @@ CONFIG_DFU_RAM=y
> >  CONFIG_DM_I2C=y
> >  CONFIG_MISC=y
> >  CONFIG_DM_MMC=y
> > +# CONFIG_MMC_HW_PARTITIONING is not set
> 
> I haven't gotten around to testing the FIT_IMAGE_TINY stuff yet, but
> conceptually I have a much bigger problem with this part.
> 
> Sacrificing functionality to allow continued SPL bloat is just wrong.
> 
> Whatever caused SPL to grow should be re-worked or the author should
> have also made some optimization elsewhere to offset this. Now I'll have
> to go hunt for more optimizations somewhere so I can get all my features
> back here :(

FWIW, I don't think there was any functionality (aside from switching to
FIT_IMAGE_TINY, but if that supports everything needed in this
use-case...) that was removed exactly.  But I see your point too.
Jean-Jacques, was there anything else that could have been made
configurable in your MMC work, that wasn't?  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] [PATCH] am335x_hs_evm: Trim options in SPL to reduce binary size

[Andrew F. Davis]

On 12/16/2017 10:04 PM, Tom Rini wrote:
> The am335x_hs_evm runs into size constraint problems at times with
> various toolchains as changes come in due to the config have a large
> number of options in SPL (to showcase what is possible) while also
> having rather constrained binary limits.  Gain some of this room back by
> lowering the loglevel, disabling HW partition support and switching over
> to the tiny FIT image support.
> 
> Cc: Andrew F. Davis 
> Signed-off-by: Tom Rini 
> ---
> I'd really appreciate a run-time test of this patch if at all possible
> as I'm a little worried about TINY_FIT being incompatible with all of
> the security options.  Thanks!
> ---
>  configs/am335x_hs_evm_defconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
> index 48b0e8583997..8eb304686dc7 100644
> --- a/configs/am335x_hs_evm_defconfig
> +++ b/configs/am335x_hs_evm_defconfig
> @@ -13,10 +13,12 @@ CONFIG_ANDROID_BOOT_IMAGE=y
>  CONFIG_FIT_IMAGE_POST_PROCESS=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
> +CONFIG_LOGLEVEL=3
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_VERSION_VARIABLE=y
>  CONFIG_ARCH_MISC_INIT=y
>  CONFIG_SPL=y
> +CONFIG_SPL_FIT_IMAGE_TINY=y
>  # CONFIG_SPL_ENV_SUPPORT is not set
>  # CONFIG_SPL_EXT_SUPPORT is not set
>  CONFIG_SPL_MTD_SUPPORT=y
> @@ -37,6 +39,7 @@ CONFIG_DFU_RAM=y
>  CONFIG_DM_I2C=y
>  CONFIG_MISC=y
>  CONFIG_DM_MMC=y
> +# CONFIG_MMC_HW_PARTITIONING is not set

I haven't gotten around to testing the FIT_IMAGE_TINY stuff yet, but
conceptually I have a much bigger problem with this part.

Sacrificing functionality to allow continued SPL bloat is just wrong.

Whatever caused SPL to grow should be re-worked or the author should
have also made some optimization elsewhere to offset this. Now I'll have
to go hunt for more optimizations somewhere so I can get all my features
back here :(

>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
>  CONFIG_NAND_OMAP_GPMC_PREFETCH=y
> @@ -61,5 +64,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0451
>  CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
>  CONFIG_USB_GADGET_DOWNLOAD=y
>  CONFIG_USB_ETHER=y
> +CONFIG_SPL_TINY_MEMSET=y
>  CONFIG_RSA=y
>  CONFIG_LZO=y
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 10:41:23PM +0800, Chen-Yu Tsai wrote:
> > All these trimming(if it fits) seems to be nice for now, but what if
> > once driver-model MMC, reset, pinctrl, clk, regulator are IN?

I guess a better question would be: what are we doing to fix an issue
we had in a release already and will destroy the binary as soon as
someone does a saveenv?

> > of-course we can't do anything with SPL size because of SRAM
> > constraints, but U-Boot proper size? why can't we increase the u-boot
> > partition size?
> 
> That is a really big if, given no one is actively working on it.
> I reckon we deal with it when someone starts having patches merged. :)

+1.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Chen-Yu Tsai]

On Tue, Dec 19, 2017 at 10:38 PM, Jagan Teki  wrote:
> On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara  
> wrote:
>> Hi Maxime,
>>
>> On 19/12/17 14:20, Maxime Ripard wrote:
>>> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote:
 Hi Maxime,

 thanks for having a look!

 On 19/12/17 13:12, Maxime Ripard wrote:
> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
>> So even though the actual u-boot.bin for 64-bit boards is still somewhat
>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
>> the edge. So since v2017.11 u-boot.itb is already too big for the
>> traditional MMC env location.
>
> So I've had a quick look about what could go possibly go away in our
> current armv8 config (using the pine64+ defconfig). Let me know if
> some are actually vitals:
>
>  - FIT_ENABLE_SHA256_SUPPORT
>  - CONSOLE_MUX
>  - CMD_CRC32
>  - CMD_LZMADEC
>  - CMD_UNZIP
>  - CMD_LOADB
>  - CMD_LOADS
>  - CMD_MISC (actually implementing the command sleep)
>  - ISO_PARTITION (yes. For CDROMs.)

 As Alex mentioned, this is needed for some installer images, which come
 as ISOs. So if possible, we should keep this in.
>>>
>>> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
>>> overlay support, we're at 500kB.
>>>
>>> Again, tight, but under the limit.
>>
>> Phew! ;-)
>>
>>>
>  - VIDEO_BPP8, VIDEO_BPP16
>  - VIDEO_ANSI
>  - SHA256
>  - LZMA

 From just looking at the names I am fine with the rest gone. But let me
 test tonight if there are any side effects.

 Some of them seem useful, but I would leave enabling them to the actual
 users. If someone needs it, they can enable them and loose the raw MMC
 environment. I think this is a fair trade-off.
>>>
>>> Yes, that's my view too.
>>>
> Removing those options make the u-boot.itb binary size going from
> 516kB to 478kB, making it functional again *and* allowing us to enable
> the DT overlays that seem way more important than any feature
> mentionned above (and bumps the size to 483kB).

 How important is the raw MMC environment for the ARM64 boards, actually?
 Most of the rationale for the 32-bit side seemed to apply to legacy use
 cases only. Do we have reports/complaints from 64-bit users?
>>>
>>> Pretty much as important as it is on arm I guess. We just have less
>>> history, but the same use cases.
>>>
>>> I'd really like to give at least one release for transition, which
>>> would mean having a schedule like this:
>>>
>>>   - in 2018.01, merge those config removals so that we have least have
>>> something that works quite fast
>>>
>>>   - in 2018.03, merge the multiple environment patches. We seem to
>>> have reached a consensus here, so I'm not really concerned that we
>>> will have it merged.
>>>
>>>   - in 2018.05, if needed, remove the raw MMC options and complete the
>>> transition to FAT.
>>
>> That sounds very reasonable to me, thanks for writing this down!
>>
>> This gives us an only intermediate shortage of features for defconfig.
>>
>> We should encourage everyone who builds (and ships) firmware right now
>> to drop MMC env support already, if they tinker with the .config anyway.
>> That is, if there is no legacy usage to be concerned about.
>
> All these trimming(if it fits) seems to be nice for now, but what if
> once driver-model MMC, reset, pinctrl, clk, regulator are IN?
> of-course we can't do anything with SPL size because of SRAM
> constraints, but U-Boot proper size? why can't we increase the u-boot
> partition size?

That is a really big if, given no one is actively working on it.
I reckon we deal with it when someone starts having patches merged. :)

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi,

On 19/12/17 14:38, Jagan Teki wrote:
> On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara  
> wrote:
>> Hi Maxime,
>>
>> On 19/12/17 14:20, Maxime Ripard wrote:
>>> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote:
 Hi Maxime,

 thanks for having a look!

 On 19/12/17 13:12, Maxime Ripard wrote:
> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
>> So even though the actual u-boot.bin for 64-bit boards is still somewhat
>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
>> the edge. So since v2017.11 u-boot.itb is already too big for the
>> traditional MMC env location.
>
> So I've had a quick look about what could go possibly go away in our
> current armv8 config (using the pine64+ defconfig). Let me know if
> some are actually vitals:
>
>  - FIT_ENABLE_SHA256_SUPPORT
>  - CONSOLE_MUX
>  - CMD_CRC32
>  - CMD_LZMADEC
>  - CMD_UNZIP
>  - CMD_LOADB
>  - CMD_LOADS
>  - CMD_MISC (actually implementing the command sleep)
>  - ISO_PARTITION (yes. For CDROMs.)

 As Alex mentioned, this is needed for some installer images, which come
 as ISOs. So if possible, we should keep this in.
>>>
>>> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
>>> overlay support, we're at 500kB.
>>>
>>> Again, tight, but under the limit.
>>
>> Phew! ;-)
>>
>>>
>  - VIDEO_BPP8, VIDEO_BPP16
>  - VIDEO_ANSI
>  - SHA256
>  - LZMA

 From just looking at the names I am fine with the rest gone. But let me
 test tonight if there are any side effects.

 Some of them seem useful, but I would leave enabling them to the actual
 users. If someone needs it, they can enable them and loose the raw MMC
 environment. I think this is a fair trade-off.
>>>
>>> Yes, that's my view too.
>>>
> Removing those options make the u-boot.itb binary size going from
> 516kB to 478kB, making it functional again *and* allowing us to enable
> the DT overlays that seem way more important than any feature
> mentionned above (and bumps the size to 483kB).

 How important is the raw MMC environment for the ARM64 boards, actually?
 Most of the rationale for the 32-bit side seemed to apply to legacy use
 cases only. Do we have reports/complaints from 64-bit users?
>>>
>>> Pretty much as important as it is on arm I guess. We just have less
>>> history, but the same use cases.
>>>
>>> I'd really like to give at least one release for transition, which
>>> would mean having a schedule like this:
>>>
>>>   - in 2018.01, merge those config removals so that we have least have
>>> something that works quite fast
>>>
>>>   - in 2018.03, merge the multiple environment patches. We seem to
>>> have reached a consensus here, so I'm not really concerned that we
>>> will have it merged.
>>>
>>>   - in 2018.05, if needed, remove the raw MMC options and complete the
>>> transition to FAT.
>>
>> That sounds very reasonable to me, thanks for writing this down!
>>
>> This gives us an only intermediate shortage of features for defconfig.
>>
>> We should encourage everyone who builds (and ships) firmware right now
>> to drop MMC env support already, if they tinker with the .config anyway.
>> That is, if there is no legacy usage to be concerned about.
> 
> All these trimming(if it fits) seems to be nice for now, but what if
> once driver-model MMC, reset, pinctrl, clk, regulator are IN?

But that is what all of this is about? At the moment we can't go beyond
504K because the raw MMC U-Boot environment lives there on the SD card.
But with Maxime's plan for 2018.05, this will be gone and we should have
about 984KB (1MB - 40K).

Cheers,
Andre.

> of-course we can't do anything with SPL size because of SRAM
> constraints, but U-Boot proper size? why can't we increase the u-boot
> partition size?
> 
> thanks!
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Jagan Teki]

On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara  wrote:
> Hi Maxime,
>
> On 19/12/17 14:20, Maxime Ripard wrote:
>> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote:
>>> Hi Maxime,
>>>
>>> thanks for having a look!
>>>
>>> On 19/12/17 13:12, Maxime Ripard wrote:
 On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> So even though the actual u-boot.bin for 64-bit boards is still somewhat
> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> the edge. So since v2017.11 u-boot.itb is already too big for the
> traditional MMC env location.

 So I've had a quick look about what could go possibly go away in our
 current armv8 config (using the pine64+ defconfig). Let me know if
 some are actually vitals:

  - FIT_ENABLE_SHA256_SUPPORT
  - CONSOLE_MUX
  - CMD_CRC32
  - CMD_LZMADEC
  - CMD_UNZIP
  - CMD_LOADB
  - CMD_LOADS
  - CMD_MISC (actually implementing the command sleep)
  - ISO_PARTITION (yes. For CDROMs.)
>>>
>>> As Alex mentioned, this is needed for some installer images, which come
>>> as ISOs. So if possible, we should keep this in.
>>
>> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
>> overlay support, we're at 500kB.
>>
>> Again, tight, but under the limit.
>
> Phew! ;-)
>
>>
  - VIDEO_BPP8, VIDEO_BPP16
  - VIDEO_ANSI
  - SHA256
  - LZMA
>>>
>>> From just looking at the names I am fine with the rest gone. But let me
>>> test tonight if there are any side effects.
>>>
>>> Some of them seem useful, but I would leave enabling them to the actual
>>> users. If someone needs it, they can enable them and loose the raw MMC
>>> environment. I think this is a fair trade-off.
>>
>> Yes, that's my view too.
>>
 Removing those options make the u-boot.itb binary size going from
 516kB to 478kB, making it functional again *and* allowing us to enable
 the DT overlays that seem way more important than any feature
 mentionned above (and bumps the size to 483kB).
>>>
>>> How important is the raw MMC environment for the ARM64 boards, actually?
>>> Most of the rationale for the 32-bit side seemed to apply to legacy use
>>> cases only. Do we have reports/complaints from 64-bit users?
>>
>> Pretty much as important as it is on arm I guess. We just have less
>> history, but the same use cases.
>>
>> I'd really like to give at least one release for transition, which
>> would mean having a schedule like this:
>>
>>   - in 2018.01, merge those config removals so that we have least have
>> something that works quite fast
>>
>>   - in 2018.03, merge the multiple environment patches. We seem to
>> have reached a consensus here, so I'm not really concerned that we
>> will have it merged.
>>
>>   - in 2018.05, if needed, remove the raw MMC options and complete the
>> transition to FAT.
>
> That sounds very reasonable to me, thanks for writing this down!
>
> This gives us an only intermediate shortage of features for defconfig.
>
> We should encourage everyone who builds (and ships) firmware right now
> to drop MMC env support already, if they tinker with the .config anyway.
> That is, if there is no legacy usage to be concerned about.

All these trimming(if it fits) seems to be nice for now, but what if
once driver-model MMC, reset, pinctrl, clk, regulator are IN?
of-course we can't do anything with SPL size because of SRAM
constraints, but U-Boot proper size? why can't we increase the u-boot
partition size?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi Maxime,

On 19/12/17 14:20, Maxime Ripard wrote:
> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote:
>> Hi Maxime,
>>
>> thanks for having a look!
>>
>> On 19/12/17 13:12, Maxime Ripard wrote:
>>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
 So even though the actual u-boot.bin for 64-bit boards is still somewhat
 below the limit (~480KB), adding the ATF image (~32KB) pushes it over
 the edge. So since v2017.11 u-boot.itb is already too big for the
 traditional MMC env location.
>>>
>>> So I've had a quick look about what could go possibly go away in our
>>> current armv8 config (using the pine64+ defconfig). Let me know if
>>> some are actually vitals:
>>>
>>>  - FIT_ENABLE_SHA256_SUPPORT
>>>  - CONSOLE_MUX
>>>  - CMD_CRC32
>>>  - CMD_LZMADEC
>>>  - CMD_UNZIP
>>>  - CMD_LOADB
>>>  - CMD_LOADS
>>>  - CMD_MISC (actually implementing the command sleep)
>>>  - ISO_PARTITION (yes. For CDROMs.)
>>
>> As Alex mentioned, this is needed for some installer images, which come
>> as ISOs. So if possible, we should keep this in.
> 
> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
> overlay support, we're at 500kB.
> 
> Again, tight, but under the limit.

Phew! ;-)

> 
>>>  - VIDEO_BPP8, VIDEO_BPP16
>>>  - VIDEO_ANSI
>>>  - SHA256
>>>  - LZMA
>>
>> From just looking at the names I am fine with the rest gone. But let me
>> test tonight if there are any side effects.
>>
>> Some of them seem useful, but I would leave enabling them to the actual
>> users. If someone needs it, they can enable them and loose the raw MMC
>> environment. I think this is a fair trade-off.
> 
> Yes, that's my view too.
> 
>>> Removing those options make the u-boot.itb binary size going from
>>> 516kB to 478kB, making it functional again *and* allowing us to enable
>>> the DT overlays that seem way more important than any feature
>>> mentionned above (and bumps the size to 483kB).
>>
>> How important is the raw MMC environment for the ARM64 boards, actually?
>> Most of the rationale for the 32-bit side seemed to apply to legacy use
>> cases only. Do we have reports/complaints from 64-bit users?
> 
> Pretty much as important as it is on arm I guess. We just have less
> history, but the same use cases.
> 
> I'd really like to give at least one release for transition, which
> would mean having a schedule like this:
> 
>   - in 2018.01, merge those config removals so that we have least have
> something that works quite fast
> 
>   - in 2018.03, merge the multiple environment patches. We seem to
> have reached a consensus here, so I'm not really concerned that we
> will have it merged.
> 
>   - in 2018.05, if needed, remove the raw MMC options and complete the
> transition to FAT.

That sounds very reasonable to me, thanks for writing this down!

This gives us an only intermediate shortage of features for defconfig.

We should encourage everyone who builds (and ships) firmware right now
to drop MMC env support already, if they tinker with the .config anyway.
That is, if there is no legacy usage to be concerned about.

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 02:22:59PM +, Andre Przywara wrote:
> Hi,
> 
> On 19/12/17 14:20, Tom Rini wrote:
> > On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote:
> >> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote:
> >>> On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
>  1;5002;0c
>  On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> >> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> >>> So even though the actual u-boot.bin for 64-bit boards is still 
> >>> somewhat
> >>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> >>> the edge. So since v2017.11 u-boot.itb is already too big for the
> >>> traditional MMC env location.
> >>
> >> So I've had a quick look about what could go possibly go away in our
> >> current armv8 config (using the pine64+ defconfig). Let me know if
> >> some are actually vitals:
> >>
> >>  - FIT_ENABLE_SHA256_SUPPORT
> >>  - CONSOLE_MUX
> >>  - CMD_CRC32
> >>  - CMD_LZMADEC
> >>  - CMD_UNZIP
> >>  - CMD_LOADB
> >>  - CMD_LOADS
> >>  - CMD_MISC (actually implementing the command sleep)
> >>  - ISO_PARTITION (yes. For CDROMs.)
> >>  - VIDEO_BPP8, VIDEO_BPP16
> >>  - VIDEO_ANSI
> >>  - SHA256
> >>  - LZMA
> >>
> >> Removing those options make the u-boot.itb binary size going from
> >> 516kB to 478kB, making it functional again *and* allowing us to enable
> >> the DT overlays that seem way more important than any feature
> >> mentionned above (and bumps the size to 483kB).
> >
> > You want to keep sha256 support in FIT images, we only have dropping
> > that allowed for some very odd use-cases.  And while I don't have a
> > strong opinion about unzip, lzma is one of the valid/likelu compressions
> > for an Image (and aside, I, or someone, needs to look into having
> > 'booti' recognize various compression algorithms and automatically
> > decompress them) so I don't think we should get rid of that.
> 
>  So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
>  499kB. Still tight, but it fits.
> >>>
> >>> Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?
> >>
> >> And we're at 498kB now! :)
> >>
> >> Is CMD_ELF useful as well?
> > 
> > That's a good question.  In 32bit land, that's how you're going to
> > launch FreeRTOS and proprietary apps and so forth.  I don't know if for
> > aarch64 people will still be doing ELF applications or UEFI applications
> > for all of this.
> 
> Eventually we will be, but for now (and the *defconfig*) I think it's
> fine to drop it. If we stick to Maxime's plan, we can get it back in 6
> months or so.

If we have to, we have to.  But I am weary of dropping and then
re-adding functionality like that as you never know what version some
company/vendor/etc is going to pick up and run with.  If we can't keep
the limit without dropping ELF, well, then we can't.

-- 
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] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi,

On 19/12/17 14:20, Tom Rini wrote:
> On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote:
>> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote:
>>> On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
 1;5002;0c
 On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
>>> So even though the actual u-boot.bin for 64-bit boards is still somewhat
>>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
>>> the edge. So since v2017.11 u-boot.itb is already too big for the
>>> traditional MMC env location.
>>
>> So I've had a quick look about what could go possibly go away in our
>> current armv8 config (using the pine64+ defconfig). Let me know if
>> some are actually vitals:
>>
>>  - FIT_ENABLE_SHA256_SUPPORT
>>  - CONSOLE_MUX
>>  - CMD_CRC32
>>  - CMD_LZMADEC
>>  - CMD_UNZIP
>>  - CMD_LOADB
>>  - CMD_LOADS
>>  - CMD_MISC (actually implementing the command sleep)
>>  - ISO_PARTITION (yes. For CDROMs.)
>>  - VIDEO_BPP8, VIDEO_BPP16
>>  - VIDEO_ANSI
>>  - SHA256
>>  - LZMA
>>
>> Removing those options make the u-boot.itb binary size going from
>> 516kB to 478kB, making it functional again *and* allowing us to enable
>> the DT overlays that seem way more important than any feature
>> mentionned above (and bumps the size to 483kB).
>
> You want to keep sha256 support in FIT images, we only have dropping
> that allowed for some very odd use-cases.  And while I don't have a
> strong opinion about unzip, lzma is one of the valid/likelu compressions
> for an Image (and aside, I, or someone, needs to look into having
> 'booti' recognize various compression algorithms and automatically
> decompress them) so I don't think we should get rid of that.

 So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
 499kB. Still tight, but it fits.
>>>
>>> Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?
>>
>> And we're at 498kB now! :)
>>
>> Is CMD_ELF useful as well?
> 
> That's a good question.  In 32bit land, that's how you're going to
> launch FreeRTOS and proprietary apps and so forth.  I don't know if for
> aarch64 people will still be doing ELF applications or UEFI applications
> for all of this.

Eventually we will be, but for now (and the *defconfig*) I think it's
fine to drop it. If we stick to Maxime's plan, we can get it back in 6
months or so.

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote:
> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote:
> > On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
> > > 1;5002;0c
> > > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> > > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> > > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > > > > So even though the actual u-boot.bin for 64-bit boards is still 
> > > > > > somewhat
> > > > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it 
> > > > > > over
> > > > > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > > > > traditional MMC env location.
> > > > > 
> > > > > So I've had a quick look about what could go possibly go away in our
> > > > > current armv8 config (using the pine64+ defconfig). Let me know if
> > > > > some are actually vitals:
> > > > > 
> > > > >  - FIT_ENABLE_SHA256_SUPPORT
> > > > >  - CONSOLE_MUX
> > > > >  - CMD_CRC32
> > > > >  - CMD_LZMADEC
> > > > >  - CMD_UNZIP
> > > > >  - CMD_LOADB
> > > > >  - CMD_LOADS
> > > > >  - CMD_MISC (actually implementing the command sleep)
> > > > >  - ISO_PARTITION (yes. For CDROMs.)
> > > > >  - VIDEO_BPP8, VIDEO_BPP16
> > > > >  - VIDEO_ANSI
> > > > >  - SHA256
> > > > >  - LZMA
> > > > > 
> > > > > Removing those options make the u-boot.itb binary size going from
> > > > > 516kB to 478kB, making it functional again *and* allowing us to enable
> > > > > the DT overlays that seem way more important than any feature
> > > > > mentionned above (and bumps the size to 483kB).
> > > > 
> > > > You want to keep sha256 support in FIT images, we only have dropping
> > > > that allowed for some very odd use-cases.  And while I don't have a
> > > > strong opinion about unzip, lzma is one of the valid/likelu compressions
> > > > for an Image (and aside, I, or someone, needs to look into having
> > > > 'booti' recognize various compression algorithms and automatically
> > > > decompress them) so I don't think we should get rid of that.
> > > 
> > > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
> > > 499kB. Still tight, but it fits.
> > 
> > Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?
> 
> And we're at 498kB now! :)
> 
> Is CMD_ELF useful as well?

That's a good question.  In 32bit land, that's how you're going to
launch FreeRTOS and proprietary apps and so forth.  I don't know if for
aarch64 people will still be doing ELF applications or UEFI applications
for all of this.

-- 
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] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote:
> Hi Maxime,
> 
> thanks for having a look!
> 
> On 19/12/17 13:12, Maxime Ripard wrote:
> > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> >> So even though the actual u-boot.bin for 64-bit boards is still somewhat
> >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> >> the edge. So since v2017.11 u-boot.itb is already too big for the
> >> traditional MMC env location.
> > 
> > So I've had a quick look about what could go possibly go away in our
> > current armv8 config (using the pine64+ defconfig). Let me know if
> > some are actually vitals:
> > 
> >  - FIT_ENABLE_SHA256_SUPPORT
> >  - CONSOLE_MUX
> >  - CMD_CRC32
> >  - CMD_LZMADEC
> >  - CMD_UNZIP
> >  - CMD_LOADB
> >  - CMD_LOADS
> >  - CMD_MISC (actually implementing the command sleep)
> >  - ISO_PARTITION (yes. For CDROMs.)
> 
> As Alex mentioned, this is needed for some installer images, which come
> as ISOs. So if possible, we should keep this in.

So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
overlay support, we're at 500kB.

Again, tight, but under the limit.

> >  - VIDEO_BPP8, VIDEO_BPP16
> >  - VIDEO_ANSI
> >  - SHA256
> >  - LZMA
> 
> From just looking at the names I am fine with the rest gone. But let me
> test tonight if there are any side effects.
> 
> Some of them seem useful, but I would leave enabling them to the actual
> users. If someone needs it, they can enable them and loose the raw MMC
> environment. I think this is a fair trade-off.

Yes, that's my view too.

> > Removing those options make the u-boot.itb binary size going from
> > 516kB to 478kB, making it functional again *and* allowing us to enable
> > the DT overlays that seem way more important than any feature
> > mentionned above (and bumps the size to 483kB).
> 
> How important is the raw MMC environment for the ARM64 boards, actually?
> Most of the rationale for the 32-bit side seemed to apply to legacy use
> cases only. Do we have reports/complaints from 64-bit users?

Pretty much as important as it is on arm I guess. We just have less
history, but the same use cases.

I'd really like to give at least one release for transition, which
would mean having a schedule like this:

  - in 2018.01, merge those config removals so that we have least have
something that works quite fast

  - in 2018.03, merge the multiple environment patches. We seem to
have reached a consensus here, so I'm not really concerned that we
will have it merged.

  - in 2018.05, if needed, remove the raw MMC options and complete the
transition to FAT.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi,

On 19/12/17 13:51, Mark Kettenis wrote:
>> From: Andre Przywara 
>> Date: Tue, 19 Dec 2017 13:38:59 +
>>
>> Hi Maxime,
>>
>> thanks for having a look!
>>
>> On 19/12/17 13:12, Maxime Ripard wrote:
>>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
 So even though the actual u-boot.bin for 64-bit boards is still somewhat
 below the limit (~480KB), adding the ATF image (~32KB) pushes it over
 the edge. So since v2017.11 u-boot.itb is already too big for the
 traditional MMC env location.
>>>
>>> So I've had a quick look about what could go possibly go away in our
>>> current armv8 config (using the pine64+ defconfig). Let me know if
>>> some are actually vitals:
>>>
>>>  - FIT_ENABLE_SHA256_SUPPORT
>>>  - CONSOLE_MUX
>>>  - CMD_CRC32
>>>  - CMD_LZMADEC
>>>  - CMD_UNZIP
>>>  - CMD_LOADB
>>>  - CMD_LOADS
>>>  - CMD_MISC (actually implementing the command sleep)
>>>  - ISO_PARTITION (yes. For CDROMs.)
>>
>> As Alex mentioned, this is needed for some installer images, which come
>> as ISOs. So if possible, we should keep this in.
>>
>>>  - VIDEO_BPP8, VIDEO_BPP16
>>>  - VIDEO_ANSI
>>>  - SHA256
>>>  - LZMA
>>
>> From just looking at the names I am fine with the rest gone. But let me
>> test tonight if there are any side effects.
>>
>> Some of them seem useful, but I would leave enabling them to the actual
>> users. If someone needs it, they can enable them and loose the raw MMC
>> environment. I think this is a fair trade-off.
>>
>>> Removing those options make the u-boot.itb binary size going from
>>> 516kB to 478kB, making it functional again *and* allowing us to enable
>>> the DT overlays that seem way more important than any feature
>>> mentionned above (and bumps the size to 483kB).
>>
>> How important is the raw MMC environment for the ARM64 boards, actually?
>> Most of the rationale for the 32-bit side seemed to apply to legacy use
>> cases only. Do we have reports/complaints from 64-bit users?
> 
> For me/us (OpenBSD) the environment is still important.  I have many
> setups where U-Boot lives on a uSD card but the installed OS lives on
> a USB device.  In that scenario I set boot_targets to boot the EFI
> bootloader and OS off the USB disk.  This is very helpfull for testing
> new versions of U-Boot as I can simply swap the uSD card.  But for
> some setups this is essential as OpenBSD doesn't support the SD/MCC
> controller on all ARM hardware yet (but we do support it on
> Allwinner).

I see, but I wasn't arguing for dropping the environment altogether,
more for supporting FAT environments *only*.
So how important is preserving existing environments over a firmware
update in your scenario? I think this is the killer question here, isn't
it? I'm inclined to just drop raw MMC environment support from sunxi64
boards and then enjoy the ~450KB more worth of code, until we hit the
first MB boundary.
I have builds with all (DDR3) A64 board DTs in the binary [1], which
would be larger than 504K anyway.

Cheers,
Andre.

[1] https://github.com/apritzel/pine64/commit/ee12bea43
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 02:28:03PM +0100, Alexander Graf wrote:
> On 12/19/2017 02:12 PM, Maxime Ripard wrote:
> >   - VIDEO_BPP8, VIDEO_BPP16
> >   - VIDEO_ANSI
> >   - SHA256
> >   - LZMA
> > 
> > Removing those options make the u-boot.itb binary size going from
> > 516kB to 478kB, making it functional again *and* allowing us to enable
> > the DT overlays that seem way more important than any feature
> > mentionned above (and bumps the size to 483kB).
> > 
> > Let me know what you think,
> 
> Out of the ones above, only ISO_PARTITION is the one I would definitely care
> about; please don't remove that one ;)

Well, I guess you're never done with the 90s ;)

And who knows, maybe it'll be hype again in a few years :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote:
> On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
> > 1;5002;0c
> > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > > > So even though the actual u-boot.bin for 64-bit boards is still 
> > > > > somewhat
> > > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > > > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > > > traditional MMC env location.
> > > > 
> > > > So I've had a quick look about what could go possibly go away in our
> > > > current armv8 config (using the pine64+ defconfig). Let me know if
> > > > some are actually vitals:
> > > > 
> > > >  - FIT_ENABLE_SHA256_SUPPORT
> > > >  - CONSOLE_MUX
> > > >  - CMD_CRC32
> > > >  - CMD_LZMADEC
> > > >  - CMD_UNZIP
> > > >  - CMD_LOADB
> > > >  - CMD_LOADS
> > > >  - CMD_MISC (actually implementing the command sleep)
> > > >  - ISO_PARTITION (yes. For CDROMs.)
> > > >  - VIDEO_BPP8, VIDEO_BPP16
> > > >  - VIDEO_ANSI
> > > >  - SHA256
> > > >  - LZMA
> > > > 
> > > > Removing those options make the u-boot.itb binary size going from
> > > > 516kB to 478kB, making it functional again *and* allowing us to enable
> > > > the DT overlays that seem way more important than any feature
> > > > mentionned above (and bumps the size to 483kB).
> > > 
> > > You want to keep sha256 support in FIT images, we only have dropping
> > > that allowed for some very odd use-cases.  And while I don't have a
> > > strong opinion about unzip, lzma is one of the valid/likelu compressions
> > > for an Image (and aside, I, or someone, needs to look into having
> > > 'booti' recognize various compression algorithms and automatically
> > > decompress them) so I don't think we should get rid of that.
> > 
> > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
> > 499kB. Still tight, but it fits.
> 
> Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?

And we're at 498kB now! :)

Is CMD_ELF useful as well?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Mark Kettenis]

> From: Andre Przywara 
> Date: Tue, 19 Dec 2017 13:38:59 +
> 
> Hi Maxime,
> 
> thanks for having a look!
> 
> On 19/12/17 13:12, Maxime Ripard wrote:
> > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> >> So even though the actual u-boot.bin for 64-bit boards is still somewhat
> >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> >> the edge. So since v2017.11 u-boot.itb is already too big for the
> >> traditional MMC env location.
> > 
> > So I've had a quick look about what could go possibly go away in our
> > current armv8 config (using the pine64+ defconfig). Let me know if
> > some are actually vitals:
> > 
> >  - FIT_ENABLE_SHA256_SUPPORT
> >  - CONSOLE_MUX
> >  - CMD_CRC32
> >  - CMD_LZMADEC
> >  - CMD_UNZIP
> >  - CMD_LOADB
> >  - CMD_LOADS
> >  - CMD_MISC (actually implementing the command sleep)
> >  - ISO_PARTITION (yes. For CDROMs.)
> 
> As Alex mentioned, this is needed for some installer images, which come
> as ISOs. So if possible, we should keep this in.
> 
> >  - VIDEO_BPP8, VIDEO_BPP16
> >  - VIDEO_ANSI
> >  - SHA256
> >  - LZMA
> 
> From just looking at the names I am fine with the rest gone. But let me
> test tonight if there are any side effects.
> 
> Some of them seem useful, but I would leave enabling them to the actual
> users. If someone needs it, they can enable them and loose the raw MMC
> environment. I think this is a fair trade-off.
> 
> > Removing those options make the u-boot.itb binary size going from
> > 516kB to 478kB, making it functional again *and* allowing us to enable
> > the DT overlays that seem way more important than any feature
> > mentionned above (and bumps the size to 483kB).
> 
> How important is the raw MMC environment for the ARM64 boards, actually?
> Most of the rationale for the 32-bit side seemed to apply to legacy use
> cases only. Do we have reports/complaints from 64-bit users?

For me/us (OpenBSD) the environment is still important.  I have many
setups where U-Boot lives on a uSD card but the installed OS lives on
a USB device.  In that scenario I set boot_targets to boot the EFI
bootloader and OS off the USB disk.  This is very helpfull for testing
new versions of U-Boot as I can simply swap the uSD card.  But for
some setups this is essential as OpenBSD doesn't support the SD/MCC
controller on all ARM hardware yet (but we do support it on
Allwinner).

Cheers,

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Mark Kettenis]

> Date: Tue, 19 Dec 2017 14:12:02 +0100
> From: Maxime Ripard 
> 
> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > So even though the actual u-boot.bin for 64-bit boards is still somewhat
> > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > the edge. So since v2017.11 u-boot.itb is already too big for the
> > traditional MMC env location.
> 
> So I've had a quick look about what could go possibly go away in our
> current armv8 config (using the pine64+ defconfig). Let me know if
> some are actually vitals:
> 
>  - FIT_ENABLE_SHA256_SUPPORT
>  - CONSOLE_MUX
>  - CMD_CRC32
>  - CMD_LZMADEC
>  - CMD_UNZIP
>  - CMD_LOADB
>  - CMD_LOADS
>  - CMD_MISC (actually implementing the command sleep)
>  - ISO_PARTITION (yes. For CDROMs.)
>  - VIDEO_BPP8, VIDEO_BPP16
>  - VIDEO_ANSI
>  - SHA256
>  - LZMA
> 
> Removing those options make the u-boot.itb binary size going from
> 516kB to 478kB, making it functional again *and* allowing us to enable
> the DT overlays that seem way more important than any feature
> mentionned above (and bumps the size to 483kB).

So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
console and usb keyboard are present?  Is the usb keyboard used when
it is plugged in but serial otherwise?

In any case, this would be just a stopgap measure for 2018.01 wouldn't
it?  We really have to move to the FAT-based environment or just bite
the bullet and move the location of the environment.  Personally I
don't cutsomize my environment beyond setting boot_targets.  So losing
my old settings upon upgrade is not a big issue for me.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi Maxime,

thanks for having a look!

On 19/12/17 13:12, Maxime Ripard wrote:
> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
>> So even though the actual u-boot.bin for 64-bit boards is still somewhat
>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
>> the edge. So since v2017.11 u-boot.itb is already too big for the
>> traditional MMC env location.
> 
> So I've had a quick look about what could go possibly go away in our
> current armv8 config (using the pine64+ defconfig). Let me know if
> some are actually vitals:
> 
>  - FIT_ENABLE_SHA256_SUPPORT
>  - CONSOLE_MUX
>  - CMD_CRC32
>  - CMD_LZMADEC
>  - CMD_UNZIP
>  - CMD_LOADB
>  - CMD_LOADS
>  - CMD_MISC (actually implementing the command sleep)
>  - ISO_PARTITION (yes. For CDROMs.)

As Alex mentioned, this is needed for some installer images, which come
as ISOs. So if possible, we should keep this in.

>  - VIDEO_BPP8, VIDEO_BPP16
>  - VIDEO_ANSI
>  - SHA256
>  - LZMA

From just looking at the names I am fine with the rest gone. But let me
test tonight if there are any side effects.

Some of them seem useful, but I would leave enabling them to the actual
users. If someone needs it, they can enable them and loose the raw MMC
environment. I think this is a fair trade-off.

> Removing those options make the u-boot.itb binary size going from
> 516kB to 478kB, making it functional again *and* allowing us to enable
> the DT overlays that seem way more important than any feature
> mentionned above (and bumps the size to 483kB).

How important is the raw MMC environment for the ARM64 boards, actually?
Most of the rationale for the 32-bit side seemed to apply to legacy use
cases only. Do we have reports/complaints from 64-bit users?

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 02:28:03PM +0100, Alexander Graf wrote:
> On 12/19/2017 02:12 PM, Maxime Ripard wrote:
> >On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> >>So even though the actual u-boot.bin for 64-bit boards is still somewhat
> >>below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> >>the edge. So since v2017.11 u-boot.itb is already too big for the
> >>traditional MMC env location.
> >So I've had a quick look about what could go possibly go away in our
> >current armv8 config (using the pine64+ defconfig). Let me know if
> >some are actually vitals:
> >
> >  - FIT_ENABLE_SHA256_SUPPORT
> >  - CONSOLE_MUX
> >  - CMD_CRC32
> 
> We use this in travis tests, but since no Allwinner systems are present
> there, I guess we don't care.

Note that tests that require CMD_CRC32 should be marked as such too.

-- 
Tom


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

[U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

Here is the remainder of my queue for u-boot-dm, including the test
patches that were dropped. If any of the test patches cause a problem
with your workflow, please let me know. If you would rather hold these
off until next release that's fine too.

I have had to leave out the live-tree translation patch due to it
breaking Jetson-TX1. It looks like you are tracking that:

http://patchwork.ozlabs.org/patch/849881/

It would be good to get that in if we can once we have a respin.

Travis build here (I'm running another now):

https://travis-ci.org/sglass68/u-boot/builds/318440976


The following changes since commit 9da71fc83a38e9dbf71240b3e548f6b37417764a:

  Prepare v2018.01-rc2 (2017-12-18 20:55:17 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to a1626e99b5d00f7d99469dc30b6201ab69d4d5bd:

  armv8: secure firmware: fix incorrect unit address in node name
(2017-12-18 21:25:57 -0700)


Andre Przywara (7):
  doc: FIT image: fix incorrect description of DT node unit address
  doc: FIT image: fix incorrect examples of DT node unit address
  doc: fix incorrect usage of DT node unit address
  fix incorrect usage of DT node unit address in comments
  sunxi: arm64: correct usage of DT node address in FIT generation
  tools: fix incorrect usage of DT node unit address
  armv8: secure firmware: fix incorrect unit address in node name

Prabhakar Kushwaha (3):
  common: Fix-up MAC addr in dts by fetching env variable serially
  arm: Add support of updating dts before fix-up
  boards: ls1046ardb: disable unavailable "ethernet" node in dts

Simon Glass (6):
  test: Run binman tests
  test: Run patman tests
  test: Run buildman tests
  test: Run dtoc tests
  travis.yml: Run tests for tools
  binman: Run code coverage tests

 .travis.yml|  15 
 README |   9 ++
 .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon |  16 ++--
 arch/arm/cpu/armv8/sec_firmware.c  |   2 +-
 arch/arm/lib/bootm-fdt.c   |  12 +++
 board/freescale/ls1046ardb/eth.c   |  51 +++
 board/sunxi/mksunxi_fit_atf.sh |  16 ++--
 common/fdt_support.c   |  25 +-
 common/image-fit.c |  16 ++--
 common/image-sig.c |   2 +-
 doc/README.uniphier|  36 
 doc/chromium/chromebook_jerry.its  |  16 ++--
 doc/chromium/nyan-big.its  |  16 ++--
 doc/uImage.FIT/beaglebone_vboot.txt|  84 -
 doc/uImage.FIT/command_syntax_extensions.txt   |  42 -
 doc/uImage.FIT/howto.txt   |  52 +--
 doc/uImage.FIT/kernel.its  |  28 +++---
 doc/uImage.FIT/kernel_fdt.its  |  20 ++---
 doc/uImage.FIT/multi-with-fpga.its |  28 +++---
 doc/uImage.FIT/multi-with-loadables.its|  40 -
 doc/uImage.FIT/multi.its   |  54 +--
 doc/uImage.FIT/multi_spl.its   |  14 +--
 doc/uImage.FIT/overlay-fdt-boot.txt|  78 
 doc/uImage.FIT/sign-configs.its|  18 ++--
 doc/uImage.FIT/sign-images.its |  16 ++--
 doc/uImage.FIT/signature.txt   | 100 ++---
 doc/uImage.FIT/source_file_format.txt  |  26 +++---
 doc/uImage.FIT/update3.its |  12 +--
 doc/uImage.FIT/update_uboot.its|   4 +-
 doc/uImage.FIT/x86-fit-boot.txt|  10 +--
 include/configs/ls1046ardb.h   |   2 +
 include/fdt_support.h  |   3 +
 include/image.h|  26 +++---
 test/run   |  13 +++
 tools/fit_image.c  |  24 ++---
 tools/image-host.c |  10 +--
 36 files changed, 529 insertions(+), 407 deletions(-)

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
> 1;5002;0c
> On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > > So even though the actual u-boot.bin for 64-bit boards is still somewhat
> > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > > traditional MMC env location.
> > > 
> > > So I've had a quick look about what could go possibly go away in our
> > > current armv8 config (using the pine64+ defconfig). Let me know if
> > > some are actually vitals:
> > > 
> > >  - FIT_ENABLE_SHA256_SUPPORT
> > >  - CONSOLE_MUX
> > >  - CMD_CRC32
> > >  - CMD_LZMADEC
> > >  - CMD_UNZIP
> > >  - CMD_LOADB
> > >  - CMD_LOADS
> > >  - CMD_MISC (actually implementing the command sleep)
> > >  - ISO_PARTITION (yes. For CDROMs.)
> > >  - VIDEO_BPP8, VIDEO_BPP16
> > >  - VIDEO_ANSI
> > >  - SHA256
> > >  - LZMA
> > > 
> > > Removing those options make the u-boot.itb binary size going from
> > > 516kB to 478kB, making it functional again *and* allowing us to enable
> > > the DT overlays that seem way more important than any feature
> > > mentionned above (and bumps the size to 483kB).
> > 
> > You want to keep sha256 support in FIT images, we only have dropping
> > that allowed for some very odd use-cases.  And while I don't have a
> > strong opinion about unzip, lzma is one of the valid/likelu compressions
> > for an Image (and aside, I, or someone, needs to look into having
> > 'booti' recognize various compression algorithms and automatically
> > decompress them) so I don't think we should get rid of that.
> 
> So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
> 499kB. Still tight, but it fits.

Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?

-- 
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] ARM64 Allwinner Binary Size

[Alexander Graf]

On 12/19/2017 02:12 PM, Maxime Ripard wrote:

On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:

So even though the actual u-boot.bin for 64-bit boards is still somewhat
below the limit (~480KB), adding the ATF image (~32KB) pushes it over
the edge. So since v2017.11 u-boot.itb is already too big for the
traditional MMC env location.

So I've had a quick look about what could go possibly go away in our
current armv8 config (using the pine64+ defconfig). Let me know if
some are actually vitals:

  - FIT_ENABLE_SHA256_SUPPORT
  - CONSOLE_MUX
  - CMD_CRC32


We use this in travis tests, but since no Allwinner systems are present 
there, I guess we don't care.



  - CMD_LZMADEC
  - CMD_UNZIP
  - CMD_LOADB
  - CMD_LOADS
  - CMD_MISC (actually implementing the command sleep)
  - ISO_PARTITION (yes. For CDROMs.)


This one is needed to boot openSUSE or SLES images, since they come as 
.iso with el torito (which then gets booted using distro + bootefi).



  - VIDEO_BPP8, VIDEO_BPP16
  - VIDEO_ANSI
  - SHA256
  - LZMA

Removing those options make the u-boot.itb binary size going from
516kB to 478kB, making it functional again *and* allowing us to enable
the DT overlays that seem way more important than any feature
mentionned above (and bumps the size to 483kB).

Let me know what you think,


Out of the ones above, only ISO_PARTITION is the one I would definitely 
care about; please don't remove that one ;)



Alex

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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

1;5002;0c
On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > So even though the actual u-boot.bin for 64-bit boards is still somewhat
> > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > traditional MMC env location.
> > 
> > So I've had a quick look about what could go possibly go away in our
> > current armv8 config (using the pine64+ defconfig). Let me know if
> > some are actually vitals:
> > 
> >  - FIT_ENABLE_SHA256_SUPPORT
> >  - CONSOLE_MUX
> >  - CMD_CRC32
> >  - CMD_LZMADEC
> >  - CMD_UNZIP
> >  - CMD_LOADB
> >  - CMD_LOADS
> >  - CMD_MISC (actually implementing the command sleep)
> >  - ISO_PARTITION (yes. For CDROMs.)
> >  - VIDEO_BPP8, VIDEO_BPP16
> >  - VIDEO_ANSI
> >  - SHA256
> >  - LZMA
> > 
> > Removing those options make the u-boot.itb binary size going from
> > 516kB to 478kB, making it functional again *and* allowing us to enable
> > the DT overlays that seem way more important than any feature
> > mentionned above (and bumps the size to 483kB).
> 
> You want to keep sha256 support in FIT images, we only have dropping
> that allowed for some very odd use-cases.  And while I don't have a
> strong opinion about unzip, lzma is one of the valid/likelu compressions
> for an Image (and aside, I, or someone, needs to look into having
> 'booti' recognize various compression algorithms and automatically
> decompress them) so I don't think we should get rid of that.

So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
499kB. Still tight, but it fits.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 2/3][v3] arm: Add support of updating dts before fix-up

[Simon Glass]

On 12 December 2017 at 10:56, York Sun  wrote:
> On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote:
>> "ethernet" node fix-up for device tree happens before Linux boot.
>>
>> There can be requirement of updating "ethernet" node even before
>> fix-up. So, add support of updating "ethernet" node.
>>
>> Signed-off-by: Prabhakar Kushwaha 
>> ---
>> Changes for v2: Sending as it is
>> Changes for v2: Sending as it is
>>
>
> Reviewed-by: York Sun 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] [v3] boards: ls1046ardb: disable unavailable "ethernet" node in dts

[Simon Glass]

On 12 December 2017 at 10:56, York Sun  wrote:
> On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote:
>> Linux device tree contains "ethernet" node for all possible
>> interface supported by SoC i.e. LS1046A.
>>
>> It is not necessary for a SerDes protocol to support all possible
>> interface. So disable unavailable "ethernet" node in device tree.
>>
>> Also, enable FDT_SEQ_MACADDR_FROM_ENV to fetch MAC address
>> sequentially from environment variables
>>
>> Signed-off-by: Prabhakar Kushwaha 
>> ---
>> Changes for v2: Sending as it is
>> Changes for v3: updated ethernet node for disable
>>
>
> Reviewed-by: York Sun 
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/7] test: Run buildman tests

[Simon Glass]

On 26 November 2017 at 20:25, Simon Glass  wrote:
> Update the test script to run the buildman tests also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  test/run | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH v2 2/7] test: Run binman tests

[Simon Glass]

On 26 November 2017 at 20:25, Simon Glass  wrote:
> Update the test script to run the binman tests also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Adjust PYTHONPATH for new locations
>
>  test/run | 3 +++
>  1 file changed, 3 insertions(+)

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

Re: [U-Boot] [PATCH v2 5/7] test: Run dtoc tests

[Simon Glass]

On 26 November 2017 at 20:25, Simon Glass  wrote:
> Update the test script to run the dtoc tests also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Adjust PYTHONPATH for new locations
>
>  test/run | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH v2 3/7] test: Run patman tests

[Simon Glass]

On 26 November 2017 at 20:25, Simon Glass  wrote:
> Update the test script to run the patman tests also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  test/run | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH 1/3][v3] common: Fix-up MAC addr in dts by fetching env variable serially

[Simon Glass]

On 12 December 2017 at 10:56, York Sun  wrote:
> On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote:
>> The MAC addresses get fixed in the device tree for "ethernet" nodes
>> is by using trailing number behind "ethernet" found in "/aliases".
>> It may not be necessary for the "ethernet" nodes to be sequential.
>> There can be gaps in between or any node disabled
>>
>> So provide a support to fetch MAC addr sequentially from env
>> and apply them to "ethernet" nodes in the order they appear in
>> device tree only if "ethernet" is not "disabled"
>>
>> Signed-off-by: Prabhakar Kushwaha 
>> ---
>> Changes for v2: Updated description and README
>> Changes for v3: sending as it is
>>
>
> Reviewed-by: York Sun 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/7] doc: FIT image: fix incorrect examples of DT node unit address

[Simon Glass]

On 18 December 2017 at 21:24, Simon Glass  wrote:
> On 3 December 2017 at 19:05, Andre Przywara  wrote:
>> The DT spec demands a unit-address of a node name to match the "reg"
>> property in that node. Newer dtc versions will throw warnings if this is
>> not the case.
>> Fix all occurences in the FIT image example files where this was not
>> observed, to not give bad examples to the reader.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  doc/uImage.FIT/kernel.its   | 28 -
>>  doc/uImage.FIT/kernel_fdt.its   | 20 ++--
>>  doc/uImage.FIT/multi-with-fpga.its  | 28 -
>>  doc/uImage.FIT/multi-with-loadables.its | 40 
>>  doc/uImage.FIT/multi.its| 54 
>> -
>>  doc/uImage.FIT/multi_spl.its| 14 -
>>  doc/uImage.FIT/sign-configs.its | 18 +--
>>  doc/uImage.FIT/sign-images.its  | 16 +-
>>  doc/uImage.FIT/update3.its  | 12 
>>  doc/uImage.FIT/update_uboot.its |  4 +--
>>  10 files changed, 117 insertions(+), 117 deletions(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] doc: FIT image: fix incorrect description of DT node unit address

[Simon Glass]

On 18 December 2017 at 21:24, Simon Glass  wrote:
> On 3 December 2017 at 19:05, Andre Przywara  wrote:
>> The DT spec demands a unit-address in a node name to match the "reg"
>> property in that node. Newer dtc versions will throw warnings if this is
>> not the case.
>> Fix all occurences in the FIT image documentation files where this was not
>> observed, to not give bad examples to the reader.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  doc/uImage.FIT/beaglebone_vboot.txt  |  84 +++---
>>  doc/uImage.FIT/command_syntax_extensions.txt |  42 +--
>>  doc/uImage.FIT/howto.txt |  52 +++---
>>  doc/uImage.FIT/overlay-fdt-boot.txt  |  78 ++---
>>  doc/uImage.FIT/signature.txt | 100 
>> +--
>>  doc/uImage.FIT/source_file_format.txt|  26 +++
>>  doc/uImage.FIT/x86-fit-boot.txt  |  10 +--
>>  7 files changed, 196 insertions(+), 196 deletions(-)
>>
>
> Reviewed-by: Simon Glass 
>
> I'm not hugely keen on the inconsistency of kernel vs. hash@1, but I
> suppose it does not matter.

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > So even though the actual u-boot.bin for 64-bit boards is still somewhat
> > below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > the edge. So since v2017.11 u-boot.itb is already too big for the
> > traditional MMC env location.
> 
> So I've had a quick look about what could go possibly go away in our
> current armv8 config (using the pine64+ defconfig). Let me know if
> some are actually vitals:
> 
>  - FIT_ENABLE_SHA256_SUPPORT
>  - CONSOLE_MUX
>  - CMD_CRC32
>  - CMD_LZMADEC
>  - CMD_UNZIP
>  - CMD_LOADB
>  - CMD_LOADS
>  - CMD_MISC (actually implementing the command sleep)
>  - ISO_PARTITION (yes. For CDROMs.)
>  - VIDEO_BPP8, VIDEO_BPP16
>  - VIDEO_ANSI
>  - SHA256
>  - LZMA
> 
> Removing those options make the u-boot.itb binary size going from
> 516kB to 478kB, making it functional again *and* allowing us to enable
> the DT overlays that seem way more important than any feature
> mentionned above (and bumps the size to 483kB).

You want to keep sha256 support in FIT images, we only have dropping
that allowed for some very odd use-cases.  And while I don't have a
strong opinion about unzip, lzma is one of the valid/likelu compressions
for an Image (and aside, I, or someone, needs to look into having
'booti' recognize various compression algorithms and automatically
decompress them) so I don't think we should get rid of that.

-- 
Tom


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

[U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> So even though the actual u-boot.bin for 64-bit boards is still somewhat
> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> the edge. So since v2017.11 u-boot.itb is already too big for the
> traditional MMC env location.

So I've had a quick look about what could go possibly go away in our
current armv8 config (using the pine64+ defconfig). Let me know if
some are actually vitals:

 - FIT_ENABLE_SHA256_SUPPORT
 - CONSOLE_MUX
 - CMD_CRC32
 - CMD_LZMADEC
 - CMD_UNZIP
 - CMD_LOADB
 - CMD_LOADS
 - CMD_MISC (actually implementing the command sleep)
 - ISO_PARTITION (yes. For CDROMs.)
 - VIDEO_BPP8, VIDEO_BPP16
 - VIDEO_ANSI
 - SHA256
 - LZMA

Removing those options make the u-boot.itb binary size going from
516kB to 478kB, making it functional again *and* allowing us to enable
the DT overlays that seem way more important than any feature
mentionned above (and bumps the size to 483kB).

Let me know what you think,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v2 6/7] travis.yml: Run tests for tools

[sjg]

Run tests for the Python tools used by U-Boot.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 .travis.yml | 15 +++
 1 file changed, 15 insertions(+)

Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/7] binman: Run code coverage tests

[sjg]

Binman has 100% test coverage for the code as it is at present. To
encourage it to stay that way, run the code-coverage test as part of the
normal U-Boot tests.

This is RFC because it requires the Python code coverage tools to be
available.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Drop patches already applied
- Run tests with travis-ci also
- Drop RFC tag from patch for binman code-coverage tests

 test/run | 7 +++
 1 file changed, 7 insertions(+)

Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 7/7] armv8: secure firmware: fix incorrect unit address in node name

[sjg]

Hi Andre,

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Remove the unit address from the config node name when U-Boot deals with
> secure firmware FIT images.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/sec_firmware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

After this series, what remains to be converted?

- Simon

Applied to u-boot-dm thanks!
Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] fix incorrect usage of DT node unit address in comments

[sjg]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in the tree where node names were mentioned in
> comments, to not give bad examples to the reader.
>
> Signed-off-by: Andre Przywara 
> ---
>  common/image-fit.c | 16 
>  common/image-sig.c |  2 +-
>  include/image.h| 26 +-
>  tools/image-host.c | 10 +-
>  4 files changed, 27 insertions(+), 27 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] sunxi: arm64: correct usage of DT node address in FIT generation

[sjg]

Hi Simon,

thanks for going through this!

On 19/12/17 04:24, Simon Glass wrote:
> Hi Andre,
>
> On 3 December 2017 at 19:05, Andre Przywara  wrote:
>> The DT spec demands a unit-address in a node name to match the "reg"
>> property in that node. Newer dtc versions will throw warnings if this is
>> not the case.
>> Adjust the FIT build script for 64-bit Allwinner boards to remove the
>> bogus addresses from the node names and avoid the warnings.
>> This avoids a warning with recent versions of the dtc tool.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  board/sunxi/mksunxi_fit_atf.sh | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] sunxi: arm64: correct usage of DT node address in FIT generation

[sjg]

Hi Simon,

thanks for going through this!

On 19/12/17 04:24, Simon Glass wrote:
> Hi Andre,
>
> On 3 December 2017 at 19:05, Andre Przywara  wrote:
>> The DT spec demands a unit-address in a node name to match the "reg"
>> property in that node. Newer dtc versions will throw warnings if this is
>> not the case.
>> Adjust the FIT build script for 64-bit Allwinner boards to remove the
>> bogus addresses from the node names and avoid the warnings.
>> This avoids a warning with recent versions of the dtc tool.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  board/sunxi/mksunxi_fit_atf.sh | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
Applied to u-boot-dm thanks!
Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] tools: fix incorrect usage of DT node unit address

[sjg]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Correct the generated unit names when U-Boot's mkimage creates a FIT
> image.
>
> Signed-off-by: Andre Przywara 
> ---
>  tools/fit_image.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm thanks!
Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] doc: fix incorrect usage of DT node unit address

[sjg]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in various documentation files where this was not
> observed, to not give bad examples to the reader.
>
> Signed-off-by: Andre Przywara 
> ---
>  .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 16 +-
>  doc/README.uniphier| 36 
> +++---
>  doc/chromium/chromebook_jerry.its  | 16 +-
>  doc/chromium/nyan-big.its  | 16 +-
>  4 files changed, 42 insertions(+), 42 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot