date:20170113

Hi,

two small patches on top of sunxi/next to enable Ethernet and SPI flash.
Was there any reason the emac node was omitted from the DT patch (as
it is in the OrangePi One DT, which I belive the Zero has copied from)?

Also newer versions of the board seem all to come with SPI flash soldered,
so lets enable the SPL support for that to allow booting without an SD card.
Having the option enabled for boards without a chip doesn't harm, as it
will only be used if the board is actually booted from SPI.
This was quickly tested with ssvb's version of sunxi-fel, which can
write the SPI flash via FEL (USB).

Cheers,
Andre.

Andre Przywara (2):
  sunxi: dts: OrangePi Zero: add Ethernet node
  sunxi: OrangePi Zero: defconfig: enable SPI flash

 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 11 +++
 configs/orangepi_zero_defconfig  |  2 ++
 2 files changed, 13 insertions(+)

-- 
2.8.2

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

[U-Boot] [PATCH 1/2] sunxi: dts: OrangePi Zero: add Ethernet node

The OrangePi Zero can happily use the EMAC along with its integrated
PHY to use Ethernet (for TFTP booting, for instance).
Add the emac node to the board .dts by copying it from the OrangePi One
DT.

Signed-off-by: Andre Przywara 
---
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
index 0989434..20d489c 100644
--- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -99,6 +99,17 @@
status = "okay";
 };
 
+ {
+   phy = <>;
+   phy-mode = "mii";
+   allwinner,use-internal-phy;
+   allwinner,leds-active-low;
+   status = "okay";
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.8.2

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

[U-Boot] [PATCH 2/2] sunxi: OrangePi Zero: defconfig: enable SPI flash

Newer OrangePi Zero boards all come with 16 Mib SPI flash soldered, from
which the board can actually boot from.
Enable the SPL support for the SPI controller and SPI flash to allow
putting the SPL, the DT and U-Boot proper into there. This will let
a board boot without an SD card inserted.
The flash chip can be written with a version of the sunxi-fel tool.

Signed-off-by: Andre Przywara 
---
 configs/orangepi_zero_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig
index 8813927..abb3fcf 100644
--- a/configs/orangepi_zero_defconfig
+++ b/configs/orangepi_zero_defconfig
@@ -13,3 +13,5 @@ CONFIG_SPL=y
 # CONFIG_CMD_FPGA is not set
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_SPL_SPI_SUNXI=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
-- 
2.8.2

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

Re: [U-Boot] Booting kernel/dtb with FIT image

2017-01-13 Thread André Przywara

On 13/01/17 17:13, Nicolas le bayon wrote:
> Hi,
> 
> Here is a problem I presently meet, any help or track to follow would be
> welcome.
> 
> My U-boot (2016.09) loads a kernel and a dtb, and "bootm" all this. This is
> my reference, and this is correctly running.
> 
> From this, I'm trying to implement FIT image management, so I enabled
> CONFIG_FIT.
> 
> On the other side, I constructed the ITS FILE from my kernel and my dtb, as
> described below:
> 
> */dts-v1/;*
> */ {*
> *description = "Simple image with single Linux kernel and FDT blob";*
> *#address-cells = <0x1>;*
> *images {*
> *kernel@1 {*
> *description = "My Linux kernel";*
> *data = /incbin/("./uImage");*

uImage is usually the name of a kernel wrapped into a _legacy U-Boot
image_. Now you are using the new FIT image, so I would use zImage as
the source here instead, otherwise you will have it double wrapped. I
guess U-Boot can't cope with that, also it would be a bit weird.
So copy arch/arm/boot/zImage and use that instead.

Cheers,
Andre.

> *type = "kernel";*
> *arch = "arm";*
> *os = "linux";*
> *compression = "none";*
> *load = <0x40008000>;*
> *entry = <0x40008000>;*
> *hash@1 {*
> *algo = "md5";*
> *};*
> *hash@2 {*
> *algo = "sha1";*
> *};*
> *};*
> *fdt@1 {*
> *description = "My Flattened Device Tree blob";*
> *data = /incbin/("./mydtb.dtb");*
> *type = "flat_dt";*
> *arch = "arm";*
> *compression = "none";*
> *hash@1 {*
> *algo = "md5";*
> *};*
> *hash@2 {*
> *algo = "sha1";*
> *};*
> *};*
> *};*
> */* a notable concept of FIT, configurations */*
> *configurations {*
> *default = "conf@1";*
> *conf@1 {*
> *description = "Boot Linux kernel with FDT blob";*
> *kernel = "kernel@1";*
> *fdt = "fdt@1";*
> *};*
> *};*
> *};*
> 
> I managed to construct the ITB (using the mkimage of my u-boot, in tools
> directory) and to store it on my target.
> 
> I load this ITB at 0x6000 address of memory.
> 
> The "bootm 0x6000" gives the following error: "Ramdisk image is corrupt
> or invalid". Indeed I have no ramdisk. Not what was described in tutorials.
> 
> The "bootm 0x6000 - " gives a better result:
> *## Loading kernel from FIT Image at 6000 ...*
> *   Using 'conf@1' configuration*
> *   Trying 'kernel@1' kernel subimage*
> * Description:  My Linux kernel*
> * Type: Kernel Image*
> * Compression:  uncompressed*
> * Data Start:   0x60e4*
> * Data Size:5568600 Bytes = 5.3 MiB (Note: same size as the
> original file!)*
> * Architecture: ARM*
> * OS:   Linux*
> * Load Address: 0x40008000*
> * Entry Point:  0x40008000*
> * Hash algo:md5*
> * Hash value:   0cccb060e1c4f50e98d8f6c8ed61242e*
> * Hash algo:sha1*
> * Hash value:   f0442dd1b8c4f006b25533c3148df2742fc8a7ad*
> *   Verifying Hash Integrity ... md5+ sha1+ OK*
> *## Loading fdt from FIT Image at 6000 ...*
> *   Using 'conf@1' configuration*
> *   Trying 'fdt@1' fdt subimage*
> * Description:  My Flattened Device Tree blob*
> * Type: Flat Device Tree*
> * Compression:  uncompressed*
> * Data Start:   0x6054fa70*
> * Data Size:55154 Bytes = 53.9 KiB **(Note: same size as the
> original file!)*
> * Architecture: ARM*
> * Hash algo:md5*
> * Hash value:   a201db29486c7c70b707e085d0196fda*
> * Hash algo:sha1*
> * Hash value:   adb751ba04c1aed120a329bb4812a9c8f0bb68a7*
> *   Verifying Hash Integrity ... md5+ sha1+ OK*
> *   Booting using the fdt blob at 0x6054fa70*
> *   Loading Kernel Image ... OK*
> *   Using Device Tree in place at 6054fa70, end 605601e1*
> 
> *Starting kernel ...*
> 
> And unfortunately nothing else after.
> 
> I have the feeling to be in the same conditions, but I do not have the same
> result.
> 
> If you have any idea of what could be wrong, please let me know, it would
> be welcomed.
> Maybe some corrections have been pushed in this domain since v2016.09?
> Thanks in advance.
> 
> Best Regards
> Nicolas
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

[U-Boot] [PATCH] defconfig: Add a config for AM335x High Security EVM

2017-01-13 Thread Andrew F. Davis

Add a new defconfig file for the AM335x High Security EVM. This config
is specific for the case of memory device booting. Memory device booting
is handled separatly from peripheral booting on HS devices as the load
address changes.

This defconfig is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_ISW_ENTRY_ADDR updated for secure images.
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size
CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size

Signed-off-by: Andrew F. Davis 
---
 configs/am335x_hs_evm_defconfig | 62 +
 1 file changed, 62 insertions(+)
 create mode 100644 configs/am335x_hs_evm_defconfig

diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
new file mode 100644
index 00..f8445c3249
--- /dev/null
+++ b/configs/am335x_hs_evm_defconfig
@@ -0,0 +1,62 @@
+CONFIG_ARM=y
+CONFIG_AM33XX=y
+CONFIG_TI_SECURE_DEVICE=y
+# CONFIG_SPL_EXT_SUPPORT is not set
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_TARGET_AM335X_EVM=y
+CONFIG_ISW_ENTRY_ADDR=0x40300350
+CONFIG_SPL_STACK_R_ADDR=0x8200
+# CONFIG_SPL_YMODEM_SUPPORT is not set
+CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_SYS_EXTRA_OPTIONS="NAND"
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_VERSION_VARIABLE=y
+CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_MTD_SUPPORT=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
am335x-bonegreen am335x-icev2"
+# CONFIG_BLK is not set
+CONFIG_DFU_MMC=y
+CONFIG_DFU_NAND=y
+CONFIG_DFU_RAM=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
+# CONFIG_DM_MMC_OPS is not set
+CONFIG_MMC_OMAP_HS=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_DM_ETH=y
+CONFIG_SYS_NS16550=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_MUSB_HOST=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0451
+CONFIG_G_DNL_PRODUCT_NUM=0xd022
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_RSA=y
+CONFIG_SPL_OF_LIBFDT=y
-- 
2.11.0

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

[U-Boot] [PATCH v2] splash: fix splash source flags check

From: "tomas.me...@vaisala.com" 

SPLASH_STORAGE_RAW is defined as 0, so a check against & will
never be true. These flags are never combined so do a check
against == instead.

Signed-off-by: Tomas Melin 
Reviewed-by: Tom Rini 
---

Changes in v2:
- rebased on u-boot-video/master

 common/splash_source.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index 4c64f10..a5eeb3f 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -395,9 +395,9 @@ int splash_source_load(struct splash_location *locations, 
uint size)
if (!splash_location)
return -EINVAL;
 
-   if (splash_location->flags & SPLASH_STORAGE_RAW)
+   if (splash_location->flags == SPLASH_STORAGE_RAW)
return splash_load_raw(splash_location, bmp_load_addr);
-   else if (splash_location->flags & SPLASH_STORAGE_FS)
+   else if (splash_location->flags == SPLASH_STORAGE_FS)
return splash_load_fs(splash_location, bmp_load_addr);
 #ifdef CONFIG_FIT
else if (splash_location->flags == SPLASH_STORAGE_FIT)
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/4] mmc: fsl_esdhc: make GPIO support optional

2017-01-13 Thread york sun

On 01/11/2017 05:39 PM, Y.B. Lu wrote:
> Hi York,
>
> Could you help to merge this patchset if there is no any changes needed?
> Thanks :)
>

It's in my queue.

York

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

Re: [U-Boot] [PATCH] video: cfb_console: fix hang if splashimage file is missing

On Wed, 30 Nov 2016 14:30:59 +0100
Anatolij Gustschin ag...@denx.de wrote:

> If the splash file doesn't exist, the booting stops bricking
> the boards. Check return value of prepare function and stop
> decoding the logo data if splash prepare stage failed.
> 
> Signed-off-by: Anatolij Gustschin 
> ---
>  drivers/video/cfb_console.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

applied to u-boot-video/master.

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

Re: [U-Boot] [PATCH RESEND v2] at91: video: Support driver-model for the HLCD driver

Hi,

On Wed, 11 Jan 2017 10:36:48 +0800
Songjun Wu songjun...@microchip.com wrote:

> Add driver-model support to this driver.
> 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v2:
> - Due to the peripheral clock driver improvement, remove
>   the unneccessary clock calling.
> 
>  drivers/video/Kconfig|   7 +
>  drivers/video/Makefile   |   2 +-
>  drivers/video/atmel_hlcdfb.c | 314 
> ++-
>  3 files changed, 319 insertions(+), 4 deletions(-)

there are many issues with this patch. First it needs re-basing to apply
on current master branch. The U-Boot image linking fails with this patch
applied. You change CONFIG_ATMEL_HLCD to CONFIG_VIDEO_ATMEL_HLCD, but
no board config files in include/config are updated accordingly.

If I update for this option e.g. in at91sam9x5ek.h, the driver doesn't
build. The building also doesn't work when I enable DM support.
Please fix all these issues before resubmitting. Thanks.

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

Re: [U-Boot] Booting kernel/dtb with FIT image

2017-01-13 Thread Jagan Teki

On Fri, Jan 13, 2017 at 6:13 PM, Nicolas le bayon  wrote:
> Hi,
>
> Here is a problem I presently meet, any help or track to follow would be
> welcome.
>
> My U-boot (2016.09) loads a kernel and a dtb, and "bootm" all this. This is
> my reference, and this is correctly running.
>
> From this, I'm trying to implement FIT image management, so I enabled
> CONFIG_FIT.
>
> On the other side, I constructed the ITS FILE from my kernel and my dtb, as
> described below:
>
> */dts-v1/;*
> */ {*
> *description = "Simple image with single Linux kernel and FDT blob";*
> *#address-cells = <0x1>;*
> *images {*
> *kernel@1 {*
> *description = "My Linux kernel";*
> *data = /incbin/("./uImage");*

Usually kernel images can be considered to vmlinux.bin or
vmlinux.bin.gz (if compressed) in its

> *type = "kernel";*
> *arch = "arm";*
> *os = "linux";*
> *compression = "none";*
> *load = <0x40008000>;*
> *entry = <0x40008000>;*
> *hash@1 {*
> *algo = "md5";*
> *};*
> *hash@2 {*
> *algo = "sha1";*
> *};*
> *};*
> *fdt@1 {*
> *description = "My Flattened Device Tree blob";*
> *data = /incbin/("./mydtb.dtb");*
> *type = "flat_dt";*
> *arch = "arm";*
> *compression = "none";*
> *hash@1 {*
> *algo = "md5";*
> *};*
> *hash@2 {*
> *algo = "sha1";*
> *};*
> *};*
> *};*
> */* a notable concept of FIT, configurations */*
> *configurations {*
> *default = "conf@1";*
> *conf@1 {*
> *description = "Boot Linux kernel with FDT blob";*
> *kernel = "kernel@1";*
> *fdt = "fdt@1";*
> *};*
> *};*
> *};*
>
> I managed to construct the ITB (using the mkimage of my u-boot, in tools
> directory) and to store it on my target.
>
> I load this ITB at 0x6000 address of memory.
>
> The "bootm 0x6000" gives the following error: "Ramdisk image is corrupt
> or invalid". Indeed I have no ramdisk. Not what was described in tutorials.

Sorry I didn't see "Ramdisk image" correct on below log, shall I miss?

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
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RESEND] video: bcm2835: add support for reading from the video-mode environment variable

2017-01-13 Thread Stephen Warren

On 01/13/2017 04:48 AM, Brian Masney wrote:

On Thu, Jan 12, 2017 at 11:47:48AM -0700, Stephen Warren wrote:

On 01/12/2017 11:32 AM, Brian Masney wrote:

On Thu, Jan 12, 2017 at 11:02:14AM -0700, Stephen Warren wrote:

On 01/12/2017 01:57 AM, Brian Masney wrote:

The bcm2835 driver polls the monitor and selects the highest resolution
that is available. This patch allows optionally setting the video-mode
environment variable so that a different video resolution can be used.
If the environment variable is not specified, then it will fall back to
using the old behavior of using the maximum allowable resolution.

This patch is needed to fix an issue booting an upstream Linux kernel
on a Raspberry Pi 2 with a Pi Top screen. Previously, the bcm2835 would
select the 1366x768 resolution (which is a supported resolution),
however the screen would be unreadable. (See
https://www.flickr.com/photos/masneyb/30942037416/ for picture). Using
this patch, the resolution 1024x768 can be selected and is readable on
the screen.

Doesn't this mean that the RPi firmware is reporting the wrong resolution?
If so, isn't the correct fix to get an updated firmware that reports the
correct resolution, rather than patching each piece of SW to ignore the
FW-reported resolution? Or, if this is caused by incorrect EDID in the Pi
Top, then fix the EDID EEPROM on that.

Perhaps there are other use-cases for using a non-default resolution, but to
support that, you'd need to make a call into the FW to request and configure
that non-default resolution, not just ignore what resolution the FW
programmed.

Hi Stephen,
The Pi Top screen works correctly with the 1366x768 resolution when
booting the 4.4 kernel provided by the Raspberry Pi foundation in
stock Raspbian (no u-boot). (There are no outside provided drivers from
Pi Top.) When booting with u-boot, I can't use the 1366x768 resolution,
even when setting the resolution manually using my patch. When auto
detection is in place, u-boot correctly detects the 1366x768 resolution
according to debugging messages that I see on the serial console.
1024x768 is the highest resolution that I can get a working display with
the Pi Top and u-boot. I also tried changing the display depth.

I tried booting u-boot using the latest Raspberry Pi firmware and the
older firmware provided with the Raspbian 4.4 kernel. In both cases, the
screen correctly displays the rainbow square at the top left when the
GPU is booting, but then the screen becomes garbled when it gets to
u-boot and the bcm2835 code sets the resolution.

I tried going through the Pi Top vendor for help but didn't get very
far with them. I'm open to other suggestions to try.

Is the bad image that you get static/fixed, or does it move about randomly?

If it's static/fixed, I wonder if the issue is with the memory pitch
calculation. What value does bcm2835_pitch have without your patch? (and
with your patch, I think it's uninitialized?).

I wonder if you round the value of bcm2835_pitch up to a multiple of 256 (or
something like that), then perhaps the issue may be solved? If you change
the pitch value, and you notice the angle of the diagonal edges in the image
change, the issue is almost certainly related to this pitch value.

I can't recall how the mainline kernel driver works now. If it also uses the
property mailbox to configure the display, and you're just using the dumb
simplefb driver, perhaps you can compare the memory layout parameters the
kernel uses when it's working to what U-Boot uses when it's not working.

The image is fixed. I can see when the Linux Kernel boots and the
console messages scroll across the screen.

Without my patch, u-boot detects the screen resolution as 1366x768 with
a pitch of 5504. With my patch, 1024x768 uses a pitch of 2048.

I reverted my u-boot patch and tried hard coding the pitch to the values
5376, 5632, 2048, 4096, and 6144 with no success. Once I read what the
pitch value does, I also tried 5464 (1366 x 4 (for 32bpp)) and 2732.

Is this related?

https://www.riscosopen.org/forum/forums/4/topics/6400?posts_per_page=25_per_page_change=Change

(See "I think I've just fixed that")

https://www.riscosopen.org/viewer/revisions/logs?ident=1471703957-443671.html

(See the diff in the BCMVideo file)

Another thing to try might be to remove the SET_* operations from
U-Boot's property mailbox calls (I think the FW always initializes video
out anyway, so U-Boot doesn't need to set anything up), and simply
invoke the relevant GET_* operations to query where the buffer is and
its size. IIRC I didn't do that because you can only query certain
information as a side-effect of asking the FW to allocate a frame-buffer
though (i.e. the info comes back in a SET_xxx/ALLOCATE_xxx response
message, but there's no GET_xxx to query the data without modifying the
configuration or re-allocating anything).

___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] Booting kernel/dtb with FIT image

2017-01-13 Thread Nicolas le bayon

Hi,

Here is a problem I presently meet, any help or track to follow would be
welcome.

My U-boot (2016.09) loads a kernel and a dtb, and "bootm" all this. This is
my reference, and this is correctly running.

>From this, I'm trying to implement FIT image management, so I enabled
CONFIG_FIT.

On the other side, I constructed the ITS FILE from my kernel and my dtb, as
described below:

*/dts-v1/;*
*/ {*
*description = "Simple image with single Linux kernel and FDT blob";*
*#address-cells = <0x1>;*
*images {*
*kernel@1 {*
*description = "My Linux kernel";*
*data = /incbin/("./uImage");*
*type = "kernel";*
*arch = "arm";*
*os = "linux";*
*compression = "none";*
*load = <0x40008000>;*
*entry = <0x40008000>;*
*hash@1 {*
*algo = "md5";*
*};*
*hash@2 {*
*algo = "sha1";*
*};*
*};*
*fdt@1 {*
*description = "My Flattened Device Tree blob";*
*data = /incbin/("./mydtb.dtb");*
*type = "flat_dt";*
*arch = "arm";*
*compression = "none";*
*hash@1 {*
*algo = "md5";*
*};*
*hash@2 {*
*algo = "sha1";*
*};*
*};*
*};*
*/* a notable concept of FIT, configurations */*
*configurations {*
*default = "conf@1";*
*conf@1 {*
*description = "Boot Linux kernel with FDT blob";*
*kernel = "kernel@1";*
*fdt = "fdt@1";*
*};*
*};*
*};*

I managed to construct the ITB (using the mkimage of my u-boot, in tools
directory) and to store it on my target.

I load this ITB at 0x6000 address of memory.

The "bootm 0x6000" gives the following error: "Ramdisk image is corrupt
or invalid". Indeed I have no ramdisk. Not what was described in tutorials.

The "bootm 0x6000 - " gives a better result:
*## Loading kernel from FIT Image at 6000 ...*
*   Using 'conf@1' configuration*
*   Trying 'kernel@1' kernel subimage*
* Description:  My Linux kernel*
* Type: Kernel Image*
* Compression:  uncompressed*
* Data Start:   0x60e4*
* Data Size:5568600 Bytes = 5.3 MiB (Note: same size as the
original file!)*
* Architecture: ARM*
* OS:   Linux*
* Load Address: 0x40008000*
* Entry Point:  0x40008000*
* Hash algo:md5*
* Hash value:   0cccb060e1c4f50e98d8f6c8ed61242e*
* Hash algo:sha1*
* Hash value:   f0442dd1b8c4f006b25533c3148df2742fc8a7ad*
*   Verifying Hash Integrity ... md5+ sha1+ OK*
*## Loading fdt from FIT Image at 6000 ...*
*   Using 'conf@1' configuration*
*   Trying 'fdt@1' fdt subimage*
* Description:  My Flattened Device Tree blob*
* Type: Flat Device Tree*
* Compression:  uncompressed*
* Data Start:   0x6054fa70*
* Data Size:55154 Bytes = 53.9 KiB **(Note: same size as the
original file!)*
* Architecture: ARM*
* Hash algo:md5*
* Hash value:   a201db29486c7c70b707e085d0196fda*
* Hash algo:sha1*
* Hash value:   adb751ba04c1aed120a329bb4812a9c8f0bb68a7*
*   Verifying Hash Integrity ... md5+ sha1+ OK*
*   Booting using the fdt blob at 0x6054fa70*
*   Loading Kernel Image ... OK*
*   Using Device Tree in place at 6054fa70, end 605601e1*

*Starting kernel ...*

And unfortunately nothing else after.

I have the feeling to be in the same conditions, but I do not have the same
result.

If you have any idea of what could be wrong, please let me know, it would
be welcomed.
Maybe some corrections have been pushed in this domain since v2016.09?
Thanks in advance.

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

Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

2017-01-13 Thread Ryan Harkin

On 13 January 2017 at 14:19, Mark Rutland  wrote:
> On Thu, Jan 12, 2017 at 01:47:32PM +, Ryan Harkin wrote:
>> On 12 January 2017 at 12:25, Mark Rutland  wrote:
>> > On Tue, Jan 10, 2017 at 06:50:19PM +, Jon Medhurst (Tixy) wrote:
>> >> On Tue, 2017-01-10 at 18:34 +, Mark Rutland wrote:
>> >> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
>> >> > simply adding new descriptions, so a DTB from a year ago should work
>> >> > just fine with mainline (modulo the Juno PCI window issue, which was a
>> >> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
>> >> > equivalent functionality.
>
>> > The key point is that it is possible to provide a baseline DTB that is
>> > good enough for most users, and will work with future kernels.
>> >
>> > We're unlikely to get to a state where DTBs are perfect and complete
>> > from day one. We can have something that remains usable.
>>
>> I hope it stays that way. Most of my users are either on 3.18 or 4.4.
>> And they are incompatible with each other w.r.t. DTBs to the point
>> where one won't even post a banner message with the other's DTB.
>
> Interesting. Just to check, do you mean v3.19? There was no upstream
> Juno DT in v3.18.
>
> Unfortunately, I can't spot any DT changes between v3.19 and v4.4 that
> would obviously break compatibility such that serial wouldn't work.
>
> If you have those kernels && DTBs to hand, are you able to take a look
> if passing "earlycon=pl011,0x7ff8"?
>
> I know that the ARM Software linux repo shipped a broken DT, along with
> some kernel modifications which bodge around that (specifically, they
> exposed a broken MMIO timer as functional). IIRC, Poking that would
> bring down the kernel, before the serial wa up.
>
> Is your v3.18 DT the old ARM Software repo's Juno DT?
>

I don't have any of the data points any more, but it wasn't due to the
ARMLT tree, which tends to be stable/reliable. It was mostly debian vs
upstream.


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

Re: [U-Boot] [PATCH v5 2/2] splash: add support for loading splash from a FIT image

On Fri, 13 Jan 2017 13:20:14 +0200
Tomas Melin tomas.me...@vaisala.com wrote:

> Enable support for loading a splash image from within a FIT image.
> The image is assumed to be generated with mkimage -E flag to hold
> the data external to the FIT.
> 
> Signed-off-by: Tomas Melin 
> ---
> 
> Changes in v5:
> - Change two debug() statements to use printf(), update printed error msg 
> 
> Changes in v4:
> - Added missing changelog
> 
> Changes in v3:
> - Add documentation to README.splashprepare
> - Change printf() to debug()
> - Coding style fixes
> 
> Changes in v2:
> - Add helper functions to image-fit.c for getting required FIT data fields
> - Add comments
> 
>  common/image-fit.c   | 48 
>  common/splash_source.c   | 72 
> +++-
>  doc/README.splashprepare | 15 ++
>  include/image.h  |  4 +++
>  include/splash.h |  5 ++--
>  5 files changed, 136 insertions(+), 8 deletions(-)

applied to u-boot-video/master. Thanks!

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

Re: [U-Boot] [PATCH v5 1/2] splash: sort include files

On Fri, 13 Jan 2017 13:20:13 +0200
Tomas Melin tomas.me...@vaisala.com wrote:

> Sort include files in accordance to U-Boot coding style.
> 
> Signed-off-by: Tomas Melin 
> ---
> 
> Changes in v5:
> - None
> 
> Changes in v4:
> - Added missing changelog
> 
> Changes in v3:
> - Change patch order so that include sort patch comes prior to adding
>   new include
> 
> Changes in v2:
> - Add separate patch for sorting include files
> 
>  common/splash_source.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)

applied to u-boot-video/master. Thanks!

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

Re: [U-Boot] Using 'gitdm' to generate U-Boot release statistics

2017-01-13 Thread Wolfgang Denk

Hi,

In message <20170113120449.9bc2b100...@atlas.denx.de> I wrote:
> 
> To avoid such requests in the future and to make the information
> easier available and the whole process more transparent, I decided to
> move my so far local git repository to our public git server, see [1].
> 
> The configuration used for the U-Boot statistics is in the "u-boot"
> branch.

Here is the missing link:

[1] git://git.denx.de/gitdm
http://git.denx.de/gitdm.git


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/2] splash: add support for loading splash from a FIT image

2017-01-13 Thread Igor Grinberg

On 01/13/17 13:20, Tomas Melin wrote:
> Enable support for loading a splash image from within a FIT image.
> The image is assumed to be generated with mkimage -E flag to hold
> the data external to the FIT.
> 
> Signed-off-by: Tomas Melin 

Acked-by: Igor Grinberg 

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

Re: [U-Boot] [RESEND] video: bcm2835: add support for reading from the video-mode environment variable

2017-01-13 Thread Peter Robinson

On Fri, Jan 13, 2017 at 11:48 AM, Brian Masney  wrote:
> On Thu, Jan 12, 2017 at 11:47:48AM -0700, Stephen Warren wrote:
>> On 01/12/2017 11:32 AM, Brian Masney wrote:
>> > On Thu, Jan 12, 2017 at 11:02:14AM -0700, Stephen Warren wrote:
>> > > On 01/12/2017 01:57 AM, Brian Masney wrote:
>> > > > The bcm2835 driver polls the monitor and selects the highest resolution
>> > > > that is available. This patch allows optionally setting the video-mode
>> > > > environment variable so that a different video resolution can be used.
>> > > > If the environment variable is not specified, then it will fall back to
>> > > > using the old behavior of using the maximum allowable resolution.
>> > > >
>> > > > This patch is needed to fix an issue booting an upstream Linux kernel
>> > > > on a Raspberry Pi 2 with a Pi Top screen. Previously, the bcm2835 would
>> > > > select the 1366x768 resolution (which is a supported resolution),
>> > > > however the screen would be unreadable. (See
>> > > > https://www.flickr.com/photos/masneyb/30942037416/ for picture). Using
>> > > > this patch, the resolution 1024x768 can be selected and is readable on
>> > > > the screen.
>> > >
>> > > Doesn't this mean that the RPi firmware is reporting the wrong 
>> > > resolution?
>> > > If so, isn't the correct fix to get an updated firmware that reports the
>> > > correct resolution, rather than patching each piece of SW to ignore the
>> > > FW-reported resolution? Or, if this is caused by incorrect EDID in the Pi
>> > > Top, then fix the EDID EEPROM on that.
>> > >
>> > > Perhaps there are other use-cases for using a non-default resolution, 
>> > > but to
>> > > support that, you'd need to make a call into the FW to request and 
>> > > configure
>> > > that non-default resolution, not just ignore what resolution the FW
>> > > programmed.
>> >
>> > Hi Stephen,
>> >The Pi Top screen works correctly with the 1366x768 resolution when
>> > booting the 4.4 kernel provided by the Raspberry Pi foundation in
>> > stock Raspbian (no u-boot). (There are no outside provided drivers from
>> > Pi Top.) When booting with u-boot, I can't use the 1366x768 resolution,
>> > even when setting the resolution manually using my patch. When auto
>> > detection is in place, u-boot correctly detects the 1366x768 resolution
>> > according to debugging messages that I see on the serial console.
>> > 1024x768 is the highest resolution that I can get a working display with
>> > the Pi Top and u-boot. I also tried changing the display depth.
>> >
>> >I tried booting u-boot using the latest Raspberry Pi firmware and the
>> > older firmware provided with the Raspbian 4.4 kernel. In both cases, the
>> > screen correctly displays the rainbow square at the top left when the
>> > GPU is booting, but then the screen becomes garbled when it gets to
>> > u-boot and the bcm2835 code sets the resolution.
>> >
>> >I tried going through the Pi Top vendor for help but didn't get very
>> > far with them. I'm open to other suggestions to try.
>>
>> Is the bad image that you get static/fixed, or does it move about randomly?
>>
>> If it's static/fixed, I wonder if the issue is with the memory pitch
>> calculation. What value does bcm2835_pitch have without your patch? (and
>> with your patch, I think it's uninitialized?).
>>
>> I wonder if you round the value of bcm2835_pitch up to a multiple of 256 (or
>> something like that), then perhaps the issue may be solved? If you change
>> the pitch value, and you notice the angle of the diagonal edges in the image
>> change, the issue is almost certainly related to this pitch value.
>>
>> I can't recall how the mainline kernel driver works now. If it also uses the
>> property mailbox to configure the display, and you're just using the dumb
>> simplefb driver, perhaps you can compare the memory layout parameters the
>> kernel uses when it's working to what U-Boot uses when it's not working.
>
> The image is fixed. I can see when the Linux Kernel boots and the
> console messages scroll across the screen.
>
> Without my patch, u-boot detects the screen resolution as 1366x768 with
> a pitch of 5504. With my patch, 1024x768 uses a pitch of 2048.
>
> I reverted my u-boot patch and tried hard coding the pitch to the values
> 5376, 5632, 2048, 4096, and 6144 with no success. Once I read what the
> pitch value does, I also tried 5464 (1366 x 4 (for 32bpp)) and 2732.
>
> I don't see a utility to dump the pitch value from the property mailbox.

Not sure if this has anything of use: https://github.com/anholt/vc4-gpu-tools
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

For 64-bit kernel, there is a warning about x1-x3 nonzero in violation
of boot protocol. x3 should be reset to zero before jumping to the
kernel.

This patch will adjust the parameters to transfer and make sure x3 is
zero.

Signed-off-by: Alison Wang 
---
 arch/arm/cpu/armv8/transition.S | 44 +
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
index adb9f35..06b6664 100644
--- a/arch/arm/cpu/armv8/transition.S
+++ b/arch/arm/cpu/armv8/transition.S
@@ -26,9 +26,27 @@ ENTRY(armv8_switch_to_el2)
 * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
  * When running in EL2 now, jump to the
 * address saved in x3.
+*
+* For 64-bit kernel, there is a warning about
+* x1-x3 nonzero in violation of boot protocol.
+* x3 should be reset to zero before jumping to
+* the kernel. Use x4 instead of x3 as parameter.
 */
-   br x3
-1: armv8_switch_to_el2_m x3, x4, x5
+   mov x4, x3
+   mov x3, #0
+   br x4
+1:
+   /*
+* For 64-bit kernel, there is a warning about
+* x1-x3 nonzero in violation of boot protocol.
+* x3 should be reset to zero before jumping to
+* the kernel. Use x4, x5, x6 instead of x3, x4,
+* x5 as parameters.
+*/
+   mov x5, x4
+   mov x4, x3
+   mov x3, #0
+   armv8_switch_to_el2_m x4, x5, x6
 ENDPROC(armv8_switch_to_el2)
 
 ENTRY(armv8_switch_to_el1)
@@ -36,9 +54,27 @@ ENTRY(armv8_switch_to_el1)
 0:
/* x3 is kernel entry point. When running in EL1
 * now, jump to the address saved in x3.
+*
+* For 64-bit kernel, there is a warning about
+* x1-x3 nonzero in violation of boot protocol.
+* x3 should be reset to zero before jumping to
+* the kernel. Use x4 instead of x3 as parameter.
+*/
+   mov x4, x3
+   mov x3, #0
+   br x4
+1:
+   /*
+* For 64-bit kernel, there is a warning about
+* x1-x3 nonzero in violation of boot protocol.
+* x3 should be reset to zero before jumping to
+* the kernel. Use x4, x5, x6 instead of x3, x4,
+* x5 as parameters.
 */
-   br x3
-1: armv8_switch_to_el1_m x3, x4, x5
+   mov x5, x4
+   mov x4, x3
+   mov x3, #0
+   armv8_switch_to_el1_m x4, x5, x6
 ENDPROC(armv8_switch_to_el1)
 
 WEAK(armv8_el2_to_aarch32)
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

2017-01-13 Thread Mark Rutland

On Thu, Jan 12, 2017 at 01:47:32PM +, Ryan Harkin wrote:
> On 12 January 2017 at 12:25, Mark Rutland  wrote:
> > On Tue, Jan 10, 2017 at 06:50:19PM +, Jon Medhurst (Tixy) wrote:
> >> On Tue, 2017-01-10 at 18:34 +, Mark Rutland wrote:
> >> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
> >> > simply adding new descriptions, so a DTB from a year ago should work
> >> > just fine with mainline (modulo the Juno PCI window issue, which was a
> >> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
> >> > equivalent functionality.

> > The key point is that it is possible to provide a baseline DTB that is
> > good enough for most users, and will work with future kernels.
> >
> > We're unlikely to get to a state where DTBs are perfect and complete
> > from day one. We can have something that remains usable.
> 
> I hope it stays that way. Most of my users are either on 3.18 or 4.4.
> And they are incompatible with each other w.r.t. DTBs to the point
> where one won't even post a banner message with the other's DTB.

Interesting. Just to check, do you mean v3.19? There was no upstream
Juno DT in v3.18.

Unfortunately, I can't spot any DT changes between v3.19 and v4.4 that
would obviously break compatibility such that serial wouldn't work.

If you have those kernels && DTBs to hand, are you able to take a look
if passing "earlycon=pl011,0x7ff8"?

I know that the ARM Software linux repo shipped a broken DT, along with
some kernel modifications which bodge around that (specifically, they
exposed a broken MMIO timer as functional). IIRC, Poking that would
bring down the kernel, before the serial wa up.

Is your v3.18 DT the old ARM Software repo's Juno DT?

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

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

2017-01-13 Thread Tom Rini

On Thu, Jan 12, 2017 at 07:18:57PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> This includes rockchip Ethernet support and various other minor fixes/changes.
> 
> 
> The following changes since commit 4386feb73da7946fc79b55c4fa41c6dd66dcb2e2:
> 
>   SPL: Adjust more debug prints for ulong entry_point (2017-01-11
> 10:45:48 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git
> 
> for you to fetch changes up to 35a05761a1aebc857e73bec7d9e72a7f84cd96ba:
> 
>   rockchip: Drop Ethernet from the TODO (2017-01-11 20:24:19 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

> > Am 13.01.2017 um 08:50 schrieb Alison Wang :
> >
> > For 64-bit kernel, there is a warning about x1-x3 nonzero in
> violation
> > of boot protocol. x3 should be reset to zero before jumping to the
> > kernel.
> >
> > This patch will adjust the parameters to transfer and make sure x3 is
> > zero.
> >
> > Signed-off-by: Alison Wang 
> 
> If x3 is part of the boot protocol, please treat it as function
> argument rather than hard code it to 0.
> 
[Alison Wang] I think x3 need to set to 0. Refer to the codes for the warning 
in kernel,

if (boot_args[1] || boot_args[2] || boot_args[3]) {
pr_err("WARNING: x1-x3 nonzero in violation of boot protocol:\n"
"\tx1: %016llx\n\tx2: %016llx\n\tx3: %016llx\n"
"This indicates a broken bootloader or old kernel\n",
boot_args[1], boot_args[2], boot_args[3]);
}
> 
> > ---
> > arch/arm/cpu/armv8/transition.S | 44
> > +
> > 1 file changed, 40 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/transition.S
> > b/arch/arm/cpu/armv8/transition.S index adb9f35..06b6664 100644
> > --- a/arch/arm/cpu/armv8/transition.S
> > +++ b/arch/arm/cpu/armv8/transition.S
> > @@ -26,9 +26,27 @@ ENTRY(armv8_switch_to_el2)
> > * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
> >  * When running in EL2 now, jump to the
> > * address saved in x3.
> > + *
> > + * For 64-bit kernel, there is a warning about
> > + * x1-x3 nonzero in violation of boot protocol.
> > + * x3 should be reset to zero before jumping to
> > + * the kernel. Use x4 instead of x3 as parameter.
> > */
> > -br x3
> > -1:armv8_switch_to_el2_m x3, x4, x5
> > +mov x4, x3
> > +mov x3, #0
> > +br x4
> > +1:
> > +/*
> > + * For 64-bit kernel, there is a warning about
> > + * x1-x3 nonzero in violation of boot protocol.
> > + * x3 should be reset to zero before jumping to
> > + * the kernel. Use x4, x5, x6 instead of x3, x4,
> > + * x5 as parameters.
> > + */
> > +mov x5, x4
> > +mov x4, x3
> > +mov x3, #0
> > +armv8_switch_to_el2_m x4, x5, x6
> > ENDPROC(armv8_switch_to_el2)
> >
> > ENTRY(armv8_switch_to_el1)
> > @@ -36,9 +54,27 @@ ENTRY(armv8_switch_to_el1)
> > 0:
> >/* x3 is kernel entry point. When running in EL1
> > * now, jump to the address saved in x3.
> > + *
> > + * For 64-bit kernel, there is a warning about
> > + * x1-x3 nonzero in violation of boot protocol.
> > + * x3 should be reset to zero before jumping to
> > + * the kernel. Use x4 instead of x3 as parameter.
> > + */
> > +mov x4, x3
> > +mov x3, #0
> > +br x4
> > +1:
> > +/*
> > + * For 64-bit kernel, there is a warning about
> > + * x1-x3 nonzero in violation of boot protocol.
> > + * x3 should be reset to zero before jumping to
> > + * the kernel. Use x4, x5, x6 instead of x3, x4,
> > + * x5 as parameters.
> > */
> > -br x3
> > -1:armv8_switch_to_el1_m x3, x4, x5
> > +mov x5, x4
> > +mov x4, x3
> > +mov x3, #0
> > +armv8_switch_to_el1_m x4, x5, x6
> > ENDPROC(armv8_switch_to_el1)
> >
> > WEAK(armv8_el2_to_aarch32)
> > --
> > 2.1.0.27.g96db324
> >

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

Re: [U-Boot] [PATCH] zynq/board.c: Add support for qspiboot and nandboot

2017-01-13 Thread Mike Looijmans

Ah, missed that. I noticed that "run $modeboot" didn't work for QSPI in the 
2017.1 tag, hadn't seen that one yet.


On 13-01-17 14:18, Michal Simek wrote:

Hi,

On 13.1.2017 14:04, Mike Looijmans wrote:

The Zynq can also boot from QSPI or NAND, and environment scripting
uses "qspiboot" and "nandboot" already. Add these to the board init
routines so that modeboot is properly set to one of these values when
the mode bits indicate so.

Signed-off-by: Mike Looijmans 
---
 board/xilinx/zynq/board.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 5cd9bbf..cf80302 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -85,9 +85,15 @@ int board_init(void)
 int board_late_init(void)
 {
switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) {
+   case ZYNQ_BM_QSPI:
+   setenv("modeboot", "qspiboot");
+   break;
case ZYNQ_BM_NOR:
setenv("modeboot", "norboot");
break;
+   case ZYNQ_BM_NAND:
+   setenv("modeboot", "nandboot");
+   break;
case ZYNQ_BM_SD:
setenv("modeboot", "sdboot");
break;



The same patch was merged some days ago. Please check latest master branch.

Thanks,
Michal





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [U-Boot] [PATCH] zynq/board.c: Add support for qspiboot and nandboot

2017-01-13 Thread Michal Simek

Hi,

On 13.1.2017 14:04, Mike Looijmans wrote:
> The Zynq can also boot from QSPI or NAND, and environment scripting
> uses "qspiboot" and "nandboot" already. Add these to the board init
> routines so that modeboot is properly set to one of these values when
> the mode bits indicate so.
> 
> Signed-off-by: Mike Looijmans 
> ---
>  board/xilinx/zynq/board.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
> index 5cd9bbf..cf80302 100644
> --- a/board/xilinx/zynq/board.c
> +++ b/board/xilinx/zynq/board.c
> @@ -85,9 +85,15 @@ int board_init(void)
>  int board_late_init(void)
>  {
>   switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) {
> + case ZYNQ_BM_QSPI:
> + setenv("modeboot", "qspiboot");
> + break;
>   case ZYNQ_BM_NOR:
>   setenv("modeboot", "norboot");
>   break;
> + case ZYNQ_BM_NAND:
> + setenv("modeboot", "nandboot");
> + break;
>   case ZYNQ_BM_SD:
>   setenv("modeboot", "sdboot");
>   break;
> 

The same patch was merged some days ago. Please check latest master branch.

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

[U-Boot] [PATCH] zynq/board.c: Add support for qspiboot and nandboot

2017-01-13 Thread Mike Looijmans

The Zynq can also boot from QSPI or NAND, and environment scripting
uses "qspiboot" and "nandboot" already. Add these to the board init
routines so that modeboot is properly set to one of these values when
the mode bits indicate so.

Signed-off-by: Mike Looijmans 
---
 board/xilinx/zynq/board.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 5cd9bbf..cf80302 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -85,9 +85,15 @@ int board_init(void)
 int board_late_init(void)
 {
switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) {
+   case ZYNQ_BM_QSPI:
+   setenv("modeboot", "qspiboot");
+   break;
case ZYNQ_BM_NOR:
setenv("modeboot", "norboot");
break;
+   case ZYNQ_BM_NAND:
+   setenv("modeboot", "nandboot");
+   break;
case ZYNQ_BM_SD:
setenv("modeboot", "sdboot");
break;
-- 
1.9.1

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

Re: [U-Boot] [U-Boot, v3, 3/3] armv8: ls1012a: define esdhc_status_fixup for RDB board

2017-01-13 Thread Y.B. Lu

> -Original Message-
> From: york sun
> Sent: Friday, January 13, 2017 1:09 AM
> To: Y.B. Lu; u-boot@lists.denx.de
> Subject: Re: [U-Boot, v3, 3/3] armv8: ls1012a: define esdhc_status_fixup
> for RDB board
> 
> On 12/07/2016 07:42 PM, Yangbo Lu wrote:
> > On LS1012ARDB board, three dual 1:4 mux/demux devices drive the SDHC2
> > signals to eMMC, SDIO wifi, SPI and Ardiuno shield. Only when we
> > select eMMC and SDIO wifi, the SDHC2 could be used. Otherwise, the
> > command inhibit bits of eSDHC2_PRSSTAT register will never release.
> > This would cause below continious error messages in linux since it
> > uses polling mode to detect card.
> > "mmc1: Controller never released inhibit bit(s)."
> > "mmc1: Controller never released inhibit bit(s)."
> > "mmc1: Controller never released inhibit bit(s)."
> > This patch is to define esdhc_status_fixup function for RDB to disable
> > SDHC2 status if no SDIO wifi or eMMC is selected.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v2:
> > - Added this patch
> > Changes for v3:
> > - Fixed checkpatch issue
> > ---
> >  board/freescale/ls1012ardb/ls1012ardb.c | 39
> > +
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/board/freescale/ls1012ardb/ls1012ardb.c
> > b/board/freescale/ls1012ardb/ls1012ardb.c
> > index 778434d..708e0a1 100644
> > --- a/board/freescale/ls1012ardb/ls1012ardb.c
> > +++ b/board/freescale/ls1012ardb/ls1012ardb.c
> > @@ -113,6 +113,45 @@ int board_init(void)
> > return 0;
> >  }
> >
> > +int esdhc_status_fixup(void *blob, const char *compat) {
> > +   char esdhc0_path[] = "/soc/esdhc@156";
> > +   char esdhc1_path[] = "/soc/esdhc@158";
> > +   u8 io = 0;
> > +   u8 mux_sdhc2;
> > +
> > +   do_fixup_by_path(blob, esdhc0_path, "status", "okay",
> > +sizeof("okay"), 1);
> > +
> > +   /* Initialize i2c early for serial flash bank information */
> > +   i2c_set_bus_num(0);
> 
> What do you mean "early" in the comment? This function is called after
> I2C is initialized.
> 

[Lu Yangbo-B47093] Sorry, it's really confusing comment. I will remove it.

> > +
> > +   /*
> > +* The I2C IO-expander for mux select is used to control the muxing
> > +* of various onboard interfaces.
> > +*
> > +* IO1[3:2] indicates SDHC2 interface demultiplexer select lines.
> > +*  00 - SDIO wifi
> > +*  01 - GPIO (to Arduino)
> > +*  10 - eMMC Memory
> > +*  11 - SPI
> > +*/
> > +   if (i2c_read(I2C_MUX_IO1_ADDR, 0, 1, , 1) < 0) {
> > +   printf("Error reading i2c boot information!\n");
> > +   return 0; /* Don't want to hang() on this error */
> 
> In case of this error, do you want to "disable" esdhc1?

[Lu Yangbo-B47093] If error occurs here, I just used return to let kernel dts 
decide to use it or not.

> 
> > +   }
> > +
> > +   mux_sdhc2 = (io & 0x0c) >> 2;
> > +   /* Enable SDHC2 only when use SDIO wifi and eMMC */
> > +   if (mux_sdhc2 == 2 || mux_sdhc2 == 0)
> > +   do_fixup_by_path(blob, esdhc1_path, "status", "okay",
> > +sizeof("okay"), 1);
> > +   else
> > +   do_fixup_by_path(blob, esdhc1_path, "status", "disabled",
> > +sizeof("disabled"), 1);
> > +   return 0;
> > +}
> > +
> >  int ft_board_setup(void *blob, bd_t *bd)  {
> > arch_fixup_fdt(blob);
> >
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Using 'gitdm' to generate U-Boot release statistics

2017-01-13 Thread Wolfgang Denk

Hi all,

people have repeatedly asked me how I generate the U-Boot release
statistics, or if they can use the tools to generate similar data for
other projects, etc.

To avoid such requests in the future and to make the information
easier available and the whole process more transparent, I decided to
move my so far local git repository to our public git server, see [1].

The configuration used for the U-Boot statistics is in the "u-boot"
branch.

Please note that I re-sync from time to time against Jonathan Corbet's
original gitdm repository, and then I usually rebase "u-boot" against
the new master (keeping a copy of the old branch, for example as in
the "u-boot-2016-11-22" branch).

To generate the release statistics for U-Boot I use a command like
this:

-> cd ~/git/gitdm
-> ( cd /home/git/u-boot ; git log -p -M v2016.11..v2017.01 ) | \
./gitdm -u -s -a -o /tmp/results -h /tmp/results.html

Hope this helps.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv7 2/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 MSI node

2017-01-13 Thread Zhiqiang Hou

From: Wenbin Song 

The default MSI node in kernel tree is for LS1043A rev1.0 silicon, if
rev1.1 silicon used, need to fixup the MSI node to match it.

Signed-off-by: Wenbin Song 
Signed-off-by: Mingkai Hu 
Signed-off-by: Hou Zhiqiang 
---
v7:
 - Use a new MSI node on rev1.1.

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |   3 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 153 ++
 2 files changed, 156 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index cb24ce7..0941bf8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -172,4 +172,7 @@ config HAS_FEATURE_GIC64K_ALIGN
bool
default y if ARCH_LS1043A
 
+config HAS_FEATURE_ENHANCED_MSI
+   bool
+   default y if ARCH_LS1043A
 endmenu
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f289172..3b87579 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -194,6 +194,157 @@ static void fdt_fixup_gic(void *blob)
 }
 #endif
 
+#ifdef CONFIG_HAS_FEATURE_ENHANCED_MSI
+static int _fdt_fixup_msi_node(void *blob, const char *name,
+ int irq_0, int irq_1, int rev)
+{
+   int err, offset, len;
+   u32 tmp[4][3];
+   void *p;
+
+   offset = fdt_path_offset(blob, name);
+   if (offset < 0) {
+   printf("WARNING: fdt_path_offset can't find path %s: %s\n",
+  name, fdt_strerror(offset));
+   return 0;
+   }
+
+   /*fixup the property of interrupts*/
+
+   tmp[0][0] = cpu_to_fdt32(0x0);
+   tmp[0][1] = cpu_to_fdt32(irq_0);
+   tmp[0][2] = cpu_to_fdt32(0x4);
+
+   if (rev > REV1_0) {
+   tmp[1][0] = cpu_to_fdt32(0x0);
+   tmp[1][1] = cpu_to_fdt32(irq_1);
+   tmp[1][2] = cpu_to_fdt32(0x4);
+   tmp[2][0] = cpu_to_fdt32(0x0);
+   tmp[2][1] = cpu_to_fdt32(irq_1 + 1);
+   tmp[2][2] = cpu_to_fdt32(0x4);
+   tmp[3][0] = cpu_to_fdt32(0x0);
+   tmp[3][1] = cpu_to_fdt32(irq_1 + 2);
+   tmp[3][2] = cpu_to_fdt32(0x4);
+   len = sizeof(tmp);
+   } else {
+   len = sizeof(tmp[0]);
+   }
+
+   err = fdt_setprop(blob, offset, "interrupts", tmp, len);
+   if (err < 0) {
+   printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
+  "interrupts", name, fdt_strerror(err));
+   return 0;
+   }
+
+   /*fixup the property of reg*/
+   p = (char *)fdt_getprop(blob, offset, "reg", );
+   if (!p) {
+   printf("WARNING: fdt_getprop can't get %s from node %s\n",
+  "reg", name);
+   return 0;
+   }
+
+   memcpy((char *)tmp, p, len);
+
+   if (rev > REV1_0)
+   *((u32 *)tmp + 3) = cpu_to_fdt32(0x1000);
+   else
+   *((u32 *)tmp + 3) = cpu_to_fdt32(0x8);
+
+   err = fdt_setprop(blob, offset, "reg", tmp, len);
+   if (err < 0) {
+   printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
+  "reg", name, fdt_strerror(err));
+   return 0;
+   }
+
+   /*fixup the property of compatible*/
+   if (rev > REV1_0)
+   err = fdt_setprop_string(blob, offset, "compatible",
+"fsl,ls1043a-v1.1-msi");
+   else
+   err = fdt_setprop_string(blob, offset, "compatible",
+"fsl,ls1043a-msi");
+   if (err < 0) {
+   printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
+  "compatible", name, fdt_strerror(err));
+   return 0;
+   }
+
+   return 1;
+}
+
+static int _fdt_fixup_pci_msi(void *blob, const char *name, int rev)
+{
+   int offset, len, err;
+   void *p;
+   int val;
+   u32 tmp[4][8];
+
+   offset = fdt_path_offset(blob, name);
+   if (offset < 0) {
+   printf("WARNING: fdt_path_offset can't find path %s: %s\n",
+  name, fdt_strerror(offset));
+   return 0;
+   }
+
+   p = (char *)fdt_getprop(blob, offset, "interrupt-map", );
+   if (!p || len != sizeof(tmp)) {
+   printf("WARNING: fdt_getprop can't get %s from node %s\n",
+  "interrupt-map", name);
+   return 0;
+   }
+
+   memcpy((char *)tmp, p, len);
+
+   val = fdt32_to_cpu(tmp[0][6]);
+   if (rev > REV1_0) {
+   tmp[1][6] = cpu_to_fdt32(val + 1);
+   tmp[2][6] = cpu_to_fdt32(val + 2);
+   tmp[3][6] = cpu_to_fdt32(val + 3);
+   } else {
+   tmp[1][6] = cpu_to_fdt32(val);
+

Re: [U-Boot] [RESEND] video: bcm2835: add support for reading from the video-mode environment variable

2017-01-13 Thread Brian Masney

On Thu, Jan 12, 2017 at 11:47:48AM -0700, Stephen Warren wrote:
> On 01/12/2017 11:32 AM, Brian Masney wrote:
> > On Thu, Jan 12, 2017 at 11:02:14AM -0700, Stephen Warren wrote:
> > > On 01/12/2017 01:57 AM, Brian Masney wrote:
> > > > The bcm2835 driver polls the monitor and selects the highest resolution
> > > > that is available. This patch allows optionally setting the video-mode
> > > > environment variable so that a different video resolution can be used.
> > > > If the environment variable is not specified, then it will fall back to
> > > > using the old behavior of using the maximum allowable resolution.
> > > > 
> > > > This patch is needed to fix an issue booting an upstream Linux kernel
> > > > on a Raspberry Pi 2 with a Pi Top screen. Previously, the bcm2835 would
> > > > select the 1366x768 resolution (which is a supported resolution),
> > > > however the screen would be unreadable. (See
> > > > https://www.flickr.com/photos/masneyb/30942037416/ for picture). Using
> > > > this patch, the resolution 1024x768 can be selected and is readable on
> > > > the screen.
> > > 
> > > Doesn't this mean that the RPi firmware is reporting the wrong resolution?
> > > If so, isn't the correct fix to get an updated firmware that reports the
> > > correct resolution, rather than patching each piece of SW to ignore the
> > > FW-reported resolution? Or, if this is caused by incorrect EDID in the Pi
> > > Top, then fix the EDID EEPROM on that.
> > > 
> > > Perhaps there are other use-cases for using a non-default resolution, but 
> > > to
> > > support that, you'd need to make a call into the FW to request and 
> > > configure
> > > that non-default resolution, not just ignore what resolution the FW
> > > programmed.
> > 
> > Hi Stephen,
> >The Pi Top screen works correctly with the 1366x768 resolution when
> > booting the 4.4 kernel provided by the Raspberry Pi foundation in
> > stock Raspbian (no u-boot). (There are no outside provided drivers from
> > Pi Top.) When booting with u-boot, I can't use the 1366x768 resolution,
> > even when setting the resolution manually using my patch. When auto
> > detection is in place, u-boot correctly detects the 1366x768 resolution
> > according to debugging messages that I see on the serial console.
> > 1024x768 is the highest resolution that I can get a working display with
> > the Pi Top and u-boot. I also tried changing the display depth.
> > 
> >I tried booting u-boot using the latest Raspberry Pi firmware and the
> > older firmware provided with the Raspbian 4.4 kernel. In both cases, the
> > screen correctly displays the rainbow square at the top left when the
> > GPU is booting, but then the screen becomes garbled when it gets to
> > u-boot and the bcm2835 code sets the resolution.
> > 
> >I tried going through the Pi Top vendor for help but didn't get very
> > far with them. I'm open to other suggestions to try.
> 
> Is the bad image that you get static/fixed, or does it move about randomly?
> 
> If it's static/fixed, I wonder if the issue is with the memory pitch
> calculation. What value does bcm2835_pitch have without your patch? (and
> with your patch, I think it's uninitialized?).
> 
> I wonder if you round the value of bcm2835_pitch up to a multiple of 256 (or
> something like that), then perhaps the issue may be solved? If you change
> the pitch value, and you notice the angle of the diagonal edges in the image
> change, the issue is almost certainly related to this pitch value.
> 
> I can't recall how the mainline kernel driver works now. If it also uses the
> property mailbox to configure the display, and you're just using the dumb
> simplefb driver, perhaps you can compare the memory layout parameters the
> kernel uses when it's working to what U-Boot uses when it's not working.

The image is fixed. I can see when the Linux Kernel boots and the
console messages scroll across the screen.

Without my patch, u-boot detects the screen resolution as 1366x768 with
a pitch of 5504. With my patch, 1024x768 uses a pitch of 2048.

I reverted my u-boot patch and tried hard coding the pitch to the values
5376, 5632, 2048, 4096, and 6144 with no success. Once I read what the
pitch value does, I also tried 5464 (1366 x 4 (for 32bpp)) and 2732.

I don't see a utility to dump the pitch value from the property mailbox.
I see this
https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes and
will have to look at it tonight (I'm in GMT-05). In the mean time, I
dumped the EDID information with the Pi Top booted using Raspbian's
4.4.21 kernel:

# tvservice -d edid-raw
# edidparser edid-raw

HDMI:EDID version 1.3, 0 extensions, screen size 29x17 cm
HDMI:EDID features - videodef 0x80 !standby !suspend !active off; colour
encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred
format is native; does not support GTF
HDMI:EDID ignored unknown descriptor tag 0x0
HDMI:EDID found monitor ascii descriptor tag 0xfe
HDMI:EDID found monitor ascii

[U-Boot] [PATCHv7 1/2] armv8/ls1043a: fixup GIC offset for ls1043a rev1

2017-01-13 Thread Zhiqiang Hou

From: Wenbin Song 

The LS1043A rev1.1 silicon supports two types of GIC offset: 4K
alignment and 64K alignment. The bit SCFG_GIC400_ALIGN[GIC_ADDR_BIT]
is used to choose which offset will be used.

The LS1043A rev1.0 silicon only supports the CIG offset with 4K
alignment.

If GIC_ADDR_BIT bit is set, 4K alignment is used, or else 64K alignment
is used. 64K alignment is the default setting.

Overriding the weak smp_kick_all_cpus, the new impletment is able to
detect GIC offset.

The default GIC offset in kernel device tree is using 4K alignment, it
need to be fixed if 64K alignment is detected.

Signed-off-by: Wenbin Song 
Signed-off-by: Mingkai Hu 
Signed-off-by: Hou Zhiqiang 
---
V7:
 - Use the full SVR to check if a Soc needs the fix.
 - Use 4K alignment as the default alignment. 

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  4 ++
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 64 ++
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   | 55 +--
 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 24 
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  3 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  1 +
 6 files changed, 146 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index cc0dc88..cb24ce7 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -168,4 +168,8 @@ config SYS_FSL_DDR4
help
  Enable Freescale DDR4 controller.
 
+config HAS_FEATURE_GIC64K_ALIGN
+   bool
+   default y if ARCH_LS1043A
+
 endmenu
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index c10ccf9..f289172 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -133,6 +133,67 @@ void fsl_fdt_disable_usb(void *blob)
}
 }
 
+#ifdef CONFIG_HAS_FEATURE_GIC64K_ALIGN
+static void fdt_fixup_gic(void *blob)
+{
+   int offset, err;
+   u64 reg[8];
+   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+   unsigned int val;
+   struct ccsr_scfg __iomem *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+   int align_64k = 0;
+
+   val = gur_in32(>svr);
+
+   if (SVR_SOC_VER(val) != SVR_LS1043A) {
+   align_64k = 1;
+   } else if (SVR_REV(val) != REV1_0) {
+   val = scfg_in32(>gic_align) & (0x01 << GIC_ADDR_BIT);
+   if (!val)
+   align_64k = 1;
+   }
+
+   offset = fdt_subnode_offset(blob, 0, "interrupt-controller@140");
+   if (offset < 0) {
+   printf("WARNING: fdt_subnode_offset can't find node %s: %s\n",
+  "interrupt-controller@140", fdt_strerror(offset));
+   return;
+   }
+
+   /* Fixup gic node align with 64K */
+   if (align_64k) {
+   reg[0] = cpu_to_fdt64(GICD_BASE_64K);
+   reg[1] = cpu_to_fdt64(GICD_SIZE_64K);
+   reg[2] = cpu_to_fdt64(GICC_BASE_64K);
+   reg[3] = cpu_to_fdt64(GICC_SIZE_64K);
+   reg[4] = cpu_to_fdt64(GICH_BASE_64K);
+   reg[5] = cpu_to_fdt64(GICH_SIZE_64K);
+   reg[6] = cpu_to_fdt64(GICV_BASE_64K);
+   reg[7] = cpu_to_fdt64(GICV_SIZE_64K);
+   } else {
+   /* Fixup gic node align with default */
+   reg[0] = cpu_to_fdt64(GICD_BASE);
+   reg[1] = cpu_to_fdt64(GICD_SIZE);
+   reg[2] = cpu_to_fdt64(GICC_BASE);
+   reg[3] = cpu_to_fdt64(GICC_SIZE);
+   reg[4] = cpu_to_fdt64(GICH_BASE);
+   reg[5] = cpu_to_fdt64(GICH_SIZE);
+   reg[6] = cpu_to_fdt64(GICV_BASE);
+   reg[7] = cpu_to_fdt64(GICV_SIZE);
+   }
+
+   err = fdt_setprop(blob, offset, "reg", reg, sizeof(reg));
+   if (err < 0) {
+   printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
+  "reg", "interrupt-controller@140",
+  fdt_strerror(err));
+   return;
+   }
+
+   return;
+}
+#endif
+
 void ft_cpu_setup(void *blob, bd_t *bd)
 {
 #ifdef CONFIG_FSL_LSCH2
@@ -177,4 +238,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #endif
fsl_fdt_disable_usb(blob);
 
+#ifdef CONFIG_HAS_FEATURE_GIC64K_ALIGN
+   fdt_fixup_gic(blob);
+#endif
 }
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 72f2c11..67c9636 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -19,6 +19,53 @@
 #endif
 #include 
 
+/* Get GIC offset
+* For LS1043a rev1.0, GIC base address align with 4k.
+* For LS1043a rev1.1, if DCFG_GIC400_ALIGN[GIC_ADDR_BIT]
+* is set, GIC base address align with 4K, or

[U-Boot] [PATCH v5 1/2] splash: sort include files

2017-01-13 Thread Tomas Melin

Sort include files in accordance to U-Boot coding style.

Signed-off-by: Tomas Melin 
---

Changes in v5:
- None

Changes in v4:
- Added missing changelog

Changes in v3:
- Change patch order so that include sort patch comes prior to adding
  new include

Changes in v2:
- Add separate patch for sorting include files

 common/splash_source.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index 230b2db..5f6e961 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -7,15 +7,16 @@
  */
 
 #include 
-#include 
+#include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5 2/2] splash: add support for loading splash from a FIT image

2017-01-13 Thread Tomas Melin

Enable support for loading a splash image from within a FIT image.
The image is assumed to be generated with mkimage -E flag to hold
the data external to the FIT.

Signed-off-by: Tomas Melin 
---

Changes in v5:
- Change two debug() statements to use printf(), update printed error msg 

Changes in v4:
- Added missing changelog

Changes in v3:
- Add documentation to README.splashprepare
- Change printf() to debug()
- Coding style fixes

Changes in v2:
- Add helper functions to image-fit.c for getting required FIT data fields
- Add comments

 common/image-fit.c   | 48 
 common/splash_source.c   | 72 +++-
 doc/README.splashprepare | 15 ++
 include/image.h  |  4 +++
 include/splash.h |  5 ++--
 5 files changed, 136 insertions(+), 8 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 77dc011..2bc536c 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -777,6 +777,54 @@ int fit_image_get_data(const void *fit, int noffset,
 }
 
 /**
+ * Get 'data-offset' property from a given image node.
+ *
+ * @fit: pointer to the FIT image header
+ * @noffset: component image node offset
+ * @data_offset: holds the data-offset property
+ *
+ * returns:
+ * 0, on success
+ * -ENOENT if the property could not be found
+ */
+int fit_image_get_data_offset(const void *fit, int noffset, int *data_offset)
+{
+   const fdt32_t *val;
+
+   val = fdt_getprop(fit, noffset, FIT_DATA_OFFSET_PROP, NULL);
+   if (!val)
+   return -ENOENT;
+
+   *data_offset = fdt32_to_cpu(*val);
+
+   return 0;
+}
+
+/**
+ * Get 'data-size' property from a given image node.
+ *
+ * @fit: pointer to the FIT image header
+ * @noffset: component image node offset
+ * @data_size: holds the data-size property
+ *
+ * returns:
+ * 0, on success
+ * -ENOENT if the property could not be found
+ */
+int fit_image_get_data_size(const void *fit, int noffset, int *data_size)
+{
+   const fdt32_t *val;
+
+   val = fdt_getprop(fit, noffset, FIT_DATA_SIZE_PROP, NULL);
+   if (!val)
+   return -ENOENT;
+
+   *data_size = fdt32_to_cpu(*val);
+
+   return 0;
+}
+
+/**
  * fit_image_hash_get_algo - get hash algorithm name
  * @fit: pointer to the FIT format image header
  * @noffset: hash node offset
diff --git a/common/splash_source.c b/common/splash_source.c
index 5f6e961..4c64f10 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -296,6 +297,72 @@ static struct splash_location *select_splash_location(
return NULL;
 }
 
+#ifdef CONFIG_FIT
+static int splash_load_fit(struct splash_location *location, u32 bmp_load_addr)
+{
+   int res;
+   int node_offset;
+   int splash_offset;
+   int splash_size;
+   struct image_header *img_header;
+   const u32 *fit_header;
+   u32 fit_size;
+   const size_t header_size = sizeof(struct image_header);
+
+   /* Read in image header */
+   res = splash_storage_read_raw(location, bmp_load_addr, header_size);
+   if (res < 0)
+   return res;
+
+   img_header = (struct image_header *)bmp_load_addr;
+   fit_size = fdt_totalsize(img_header);
+
+   /* Read in entire FIT */
+   fit_header = (const u32 *)(bmp_load_addr + header_size);
+   res = splash_storage_read_raw(location, (u32)fit_header, fit_size);
+   if (res < 0)
+   return res;
+
+   res = fit_check_format(fit_header);
+   if (!res) {
+   debug("Could not find valid FIT image\n");
+   return -EINVAL;
+   }
+
+   node_offset = fit_image_get_node(fit_header, location->name);
+   if (node_offset < 0) {
+   debug("Could not find splash image '%s' in FIT\n",
+ location->name);
+   return -ENOENT;
+   }
+
+   res = fit_image_get_data_offset(fit_header, node_offset,
+   _offset);
+   if (res < 0) {
+   printf("Failed to load splash image (err=%d)\n", res);
+   return res;
+   }
+
+   res = fit_image_get_data_size(fit_header, node_offset, _size);
+   if (res < 0) {
+   printf("Failed to load splash image (err=%d)\n", res);
+   return res;
+   }
+
+   /* Align data offset to 4-byte boundrary */
+   fit_size = fdt_totalsize(fit_header);
+   fit_size = (fit_size + 3) & ~3;
+
+   /* Read in the splash data */
+   location->offset = (location->offset + fit_size + splash_offset);
+   res = splash_storage_read_raw(location, bmp_load_addr , splash_size);
+   if (res < 0)
+   return res;
+
+   return 0;
+}
+#endif /* CONFIG_FIT */
+
 /**
  * splash_source_load - load splash image from a supported location.
  *
@@ -332,6

Re: [U-Boot] [PATCH v3] disk: convert to Kconfig

2017-01-13 Thread Patrick DELAUNAY

> Subject: Re: [PATCH v3] disk: convert to Kconfig
> 
> >
> > >
> > > First, thanks for doing all of this, I think it's just about ready to 
> > > apply so:
> > >
> > > Reviewed-by: Tom Rini 
> > >
> > > But that said, I'm going to re-run the sync as there's still a few
> > > places where we enable $X in the defconfig file as it wasn't setting
> > > DISTRO_DEFAULTS before, but is now (am335x* and making
> > > EFI_PARTITIONS default y if TEGRA).  But I'll fix that up in-place
> > > so you don't have to re-submit the giant thing.  Thanks!
> > >
> > > --
> > > Tom
> >
> > Hi Tom
> >
> > I see that your patch is now merged and integrated in v2017.01
> > (https://patchwork.ozlabs.org/patch/700546/),
> > do you need some re-submit of my giant patch for the next merge
> windows ?
> > or you can handle it my simple merge ?
> 
> So, I took some attempts at merging this.  The problem is that as the changes
> exist today it's not size-neutral which means that some of the changes aren't
> quite right.  Do you have the time to look at making sure it's size neutral?
> Thanks!

Hi Tom,

I will take some time (in background) to merge my patch on v2017.01 to be sure 
it is neutral .

If I have a better result I will push it again on top of v2017.01 next week.

Patrick

> --
> Tom


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

Re: [U-Boot] [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

2017-01-13 Thread Alexander Graf


On 01/13/2017 10:36 AM, Alison Wang wrote:

On 01/13/2017 09:23 AM, Alison Wang wrote:

Am 13.01.2017 um 08:50 schrieb Alison Wang :

For 64-bit kernel, there is a warning about x1-x3 nonzero in

violation

of boot protocol. x3 should be reset to zero before jumping to the
kernel.

This patch will adjust the parameters to transfer and make sure x3
is zero.

Signed-off-by: Alison Wang 

If x3 is part of the boot protocol, please treat it as function
argument rather than hard code it to 0.


[Alison Wang] I think x3 need to set to 0. Refer to the codes for the
warning in kernel,

  if (boot_args[1] || boot_args[2] || boot_args[3]) {
  pr_err("WARNING: x1-x3 nonzero in violation of boot

protocol:\n"
"\tx1: %016llx\n\tx2: %016llx\n\tx3: %016llx\n"

  "This indicates a broken bootloader or old

kernel\n",

  boot_args[1], boot_args[2], boot_args[3]);
  }

Yes, that merely means that the kernel doesn't take 3 arguments, it
takes 4. Today args[1..3] have to be 0, but I don't want to iron that
out in u-boot code.

So in pseudo-code, what we do today is we call

entry(dt_addr, 0, 0);

and instead we should be calling

entry(dt_addr, 0, 0, 0);

So in U-Boot code that means we should change the prototype for our
switch function from

void armv8_switch_to_el2(u64 args, u64 mach_nr, u64 fdt_addr,
   u64 entry_point, u64 es_flag);

to

void armv8_switch_to_el2(u64 args, u64 mach_nr, u64 fdt_addr,
   u64 arg4, u64 entry_point, u64 es_flag);

and adapt the macros accordingly to use x5/x6 instead of x4/5.


[Alison Wang] I understand your meaning. Actually, I thought that method too. 
Well, my concern is that there are more changes. Not only armv8_switch_to_el2 
and armv8_switch_to_el1, all the places calling them need to change too. It may 
cause more problems. With this concern, I choose a simple way to fix this issue 
before.


I think there'll be enough people testing Linux boot :), let's try to 
fix it properly right away.



Alex

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

Re: [U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image

2017-01-13 Thread Tomas Melin

Hi Igor, Simon,

On 12/26/2016 09:24 AM, Igor Grinberg wrote:
> Hi Tomas,
> 
> Sorry for the late response...
> 
> On 12/20/16 07:29, Tomas Melin wrote:
>> Hi Igor, Simon,
>>
>> On 12/15/2016 11:08 AM, Igor Grinberg wrote:
>>> Hi Tomas,
>>>
>>> On 12/14/16 16:23, Tomas Melin wrote:
 Hi Simon, Igor,

 On 12/14/2016 02:53 PM, Igor Grinberg wrote:
> On 12/13/16 22:29, Simon Glass wrote:
>
> I think two above debug() are very legitimate - no need to shout if 
> no FIT image
> or no splash in it...
>
>> + res = fit_image_get_data_offset(fit_header, node_offset,
>> + _offset);
>> + if (res < 0) {
>> + debug("Could not find 'data-offset' property in 
>> FIT\n");
>> + return res;
>> + }
>> +
>> + res = fit_image_get_data_size(fit_header, node_offset, 
>> _size);
>> + if (res < 0) {
>> + debug("Could not find 'data-size' property in FIT\n");
>> + return res;
>> + }
>
> Now regarding these two, I'm not sure.
> Since we have found a valid FIT and also a node with a correct splash 
> name,
> probably the intent is that we show the splash, right?
> But in the two above checks, we find inconsistencies that do not 
> allow us to
> show the splash - meaning the FIT is not actually good (am I right 
> here?).
> So may be we should report it to the 'user' and allow correcting the 
> FIT?
> Otherwise, it is impossible to debug the image w/o a debug version of 
> U-Boot...
> Do I make sense, or do I miss something?

 Yes that makes some sense, but the problem is that then you are
 including error messages always which would never happen in a working
 system (i.e. it just bloats the code).
>>>
>>> Unless, there a kind of corruption or a user mistake and then that same
>>> user can't even understand what happened because we do not help him with
>>> an error message.
>>> You cannot know that these error messages will never happen...
>>> This is a generic code which can be used by a wide variety of platforms 
>>> -
>>> I don't think you can foresee all the possible use cases.
>>>
>>> We are talking about several tens of bytes vs. usability.
>>> If there is an error, it should be stated as such. It should not just
>>> exit silently...
>>
>> I agree with that, there should definitely be an error printed. It
>> should say something like 'Failed to load splash screen (err=-4)' or
>> something like that. The error number should provide some clues and
>> people can dig in.
>
> Great idea!

 splash_load_fit() currently fails silently but still reports the error in
 the return value. And this function is used so that board.c calls 
 splash_source_load()->splash_load_fit().
 The board function call will get notified of the error value as provided
 by the return value for splash_load_fit(). In our board implementation 
 that is 
 actually exactly how it is done, the board function call checks the return
 value and prints ("Failed to load splash screen image, error: %d\n", ret)
 in case there was and error.

 IMHO this is quite good behaviour as is, leaving it up to the 
 implementation
 in the board.c if there should be a error message or not (and if it should 
 bloat the code with another printf or not).
>>>
>>> Well, yes this makes sense if you care to do the work in the board code.
>>> Although, I would expect that sometime this code will be called from
>>> a generic board independent place (e.g. init array, etc.).
>>
>> I don't have a strong opinion, even if I do prefer the current version.
>> Please let me know if patch this still needs changes. 
> 
> Well, I can see two courses this patch can take:
> 1) We merge it as-is and any additional board uses the splash_load_fit() will
>copy/paste the error handling from your board, or generalizes it and 
> patches
>both boards.
> 2) We make a more generic approach (e.g. print error messages in the common 
> code)
>and any new user (board or common call) will not need to handle the errors,
>but just use the call.
> 
> Either one is good with me.

I'll update the patch to use printf:s for the latter statements (as discussed 
above.), I will send out a new version shortly.

Thanks,
Tomas 

> 
> Have a great holidays everyone!
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 26/26] sunxi: A64: add 32-bit SPL support

Hi,

On 13/01/17 02:19, Simon Glass wrote:
> Hi Andre,
> 
> On 2 January 2017 at 04:48, Andre Przywara  wrote:
>> When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't
>> use the more compact Thumb2 encoding, which only exists for AArch32
>> code. This makes the SPL rather big, up to a point where any code
>> additions or even a different compiler may easily exceed the 32KB limit
>> that the Allwinner BROM imposes.
>> Introduce a separate, mostly generic sun50i-a64 configuration, which
>> defines the CPU_V7 symbol and thus will create a 32-bit binary using
>> the memory-saving Thumb2 encoding.
>> This should only be used for the SPL, the U-Boot proper should still be
>> using the existing 64-bit configuration. The SPL code can switch to
>> AArch64 if needed, so a 32-bit SPL can be combined with a 64-bit U-Boot
>> proper to eventually launch arm64 kernels.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  board/sunxi/Kconfig| 14 --
>>  configs/pine64_plus_defconfig  |  2 +-
>>  configs/sun50i_spl32_defconfig | 10 ++
>>  3 files changed, 23 insertions(+), 3 deletions(-)
>>  create mode 100644 configs/sun50i_spl32_defconfig
> 
> Following up on the previous discussion, I take it that one on problem
> is that U-Boot does not support building SPL with one toolchain and
> U-Boot proper with another?

Yes. For the time being I have a script [1] that first configures and
compiles everything with an ARM cross compiler, then repeats this with
an aarch64 cross compiler. Then I combine the 32-bit SPL and the 64-bit
U-Boot proper.

While we are at it: I didn't find a Makefile target to just compile the
SPL (or just U-Boot proper), is that worth looking at? Or can we somehow
influence Kconfig options on the command line to achieve that on that level?

> Re wanting to build SPL either as 32-bit or 64-bit, could this be a
> Kconfig option perhaps?

Sounds like a direction worth to investigate.
In the moment we have two separate defconfig files, because CPU_V7 and
ARM64 are actually mutually exclusive, which is really a pain and the
main reason that part wasn't merged.

> Anyway, if this is what we have for now, fine. But I'd like to see at
> least a TODO suggesting a better solution.

So yes, the series was now merged omitting the 32-bit SPL part, which is
really optional. For the time being we seem to get away with only
64-bit, but I will definitely revisit this after having handled the
higher priority patches in my queue.

Cheers,
Andre.

[1] http://pastebin.com/kH7u2h7M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

> On 01/13/2017 09:23 AM, Alison Wang wrote:
> >>> Am 13.01.2017 um 08:50 schrieb Alison Wang :
> >>>
> >>> For 64-bit kernel, there is a warning about x1-x3 nonzero in
> >> violation
> >>> of boot protocol. x3 should be reset to zero before jumping to the
> >>> kernel.
> >>>
> >>> This patch will adjust the parameters to transfer and make sure x3
> >>> is zero.
> >>>
> >>> Signed-off-by: Alison Wang 
> >> If x3 is part of the boot protocol, please treat it as function
> >> argument rather than hard code it to 0.
> >>
> > [Alison Wang] I think x3 need to set to 0. Refer to the codes for the
> > warning in kernel,
> >
> >  if (boot_args[1] || boot_args[2] || boot_args[3]) {
> >  pr_err("WARNING: x1-x3 nonzero in violation of boot
> protocol:\n"
> >
> "\tx1: %016llx\n\tx2: %016llx\n\tx3: %016llx\n"
> >  "This indicates a broken bootloader or old
> kernel\n",
> >  boot_args[1], boot_args[2], boot_args[3]);
> >  }
> 
> Yes, that merely means that the kernel doesn't take 3 arguments, it
> takes 4. Today args[1..3] have to be 0, but I don't want to iron that
> out in u-boot code.
> 
> So in pseudo-code, what we do today is we call
> 
>entry(dt_addr, 0, 0);
> 
> and instead we should be calling
> 
>entry(dt_addr, 0, 0, 0);
> 
> So in U-Boot code that means we should change the prototype for our
> switch function from
> 
> void armv8_switch_to_el2(u64 args, u64 mach_nr, u64 fdt_addr,
>   u64 entry_point, u64 es_flag);
> 
> to
> 
> void armv8_switch_to_el2(u64 args, u64 mach_nr, u64 fdt_addr,
>   u64 arg4, u64 entry_point, u64 es_flag);
> 
> and adapt the macros accordingly to use x5/x6 instead of x4/5.
> 
[Alison Wang] I understand your meaning. Actually, I thought that method too. 
Well, my concern is that there are more changes. Not only armv8_switch_to_el2 
and armv8_switch_to_el1, all the places calling them need to change too. It may 
cause more problems. With this concern, I choose a simple way to fix this issue 
before.


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

Re: [U-Boot] u-boot

2017-01-13 Thread Michal Simek

Hi,

please subscribe here.
http://lists.denx.de/mailman/listinfo/u-boot

Thanks,
Michal

On 12.1.2017 17:45, adam.da...@stfc.ac.uk wrote:
> Hi,
> 
> Just starting out looking at u-boot for a project using Xilinx Zynq zc7020 
> chip on an Enclustra module
> 
> Please add me to the mailing list
> 
> Many thanks
> 
> Regards
> 
> Adam Davis MEng
> R65, G.15
> Application Engineering Group
> Science & Technology Facilities Council,
> Rutherford Appleton Laboratory,
> Chilton,
> Didcot,
> Oxon,
> OX11 0QX
> TE : 01235 821900
> EX : 6700
> EM : adam.da...@stfc.ac.uk
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero issue