Re: [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program
> Am 11.11.2016 um 17:17 schrieb Simon Glass : > > Hi Alex, > >> On 7 November 2016 at 09:32, Alexander Graf wrote: >> >> >>> On 07/11/2016 10:46, Simon Glass wrote: >>> >>> Hi Alex, >>> On 19 October 2016 at 01:09, Alexander Graf wrote: > On 18/10/2016 22:37, Simon Glass wrote: > > Hi Alex, > >> On 18 October 2016 at 01:14, Alexander Graf wrote: >> >>> On 10/18/2016 04:29 AM, Simon Glass wrote: >>> >>> >>> It is useful to have a basic sanity check for EFI loader support. Add >>> a >>> 'bootefi hello' command which loads HelloWord.efi and runs it under >>> U-Boot. >>> >>> Signed-off-by: Simon Glass >>> --- >>> >>> Changes in v3: >>> - Include a link to the program instead of adding it to the tree >> >> >> >> So, uh, where is the link? > > > I put it in the README (see the arm patch). > >> >> I'm really not convinced this command buys us anything yet. I do agree >> that >> we want automated testing - but can't we get that using QEMU and a >> downloadable image file that we pass in as disk and have the distro >> boot do >> its magic? > > > That seems very heavyweight as a sanity check, although I agree it is > useful. It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok. >>> >>> >>> I don't think I understand what you mean by 'image file'. Is it >>> something other than the .efi file? Do you mean a disk image? >> >> >> Yes. For reasonable test coverage, we should also verify that the distro >> defaults wrote a sane boot script that automatically searches for a default >> EFI binary in /efi/boot/bootx86.efi on the first partition of all devices >> and runs it. >> >> So if we just provide an SD card image or hard disk image to QEMU which >> contains a hello world .efi binary as that default boot file, we don't only >> test whether the "bootefi" command works, but also whether the distro boot >> script works. > > That's right. > >> >>> > Here I am just making sure that EFI programs can start, print output > and exit. It is a test that we can easily run without a lot of > overhead, much less than a full distro boot. Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are). >>> >>> >>> You are talking about a functional test, something that tests things >>> end to end. I prefer to at least start with a smaller test. Granted it >>> takes a little more work but it means there are fewer things to hunt >>> through when something goes wrong. >> >> >> Yes, I personally find unit tests terribly annoying and unproductive and >> functional tests very helpful :). And in this case, the effort to write it >> is about the same for both, just that the functional test actually tells you >> that things work or don't work at the end of the day. >> >> With a code base like U-Boot, a simple functional test like the above plus >> git bisect should get you to an offending patch very quickly. > > This is not a unit test - in fact the EFI stuff has no unit tests. I > suppose if we are trying to find a name this is a small functional > test since it exercises the general functionality. > > I am much keener on small tests than large ones for finding simple > bugs. Of course you can generally bisect to find a bug, but the more > layers of software you need to look for the harder this is. > > We could definitely use a pytest which checks an EFI boot into an > image, but I don't think this obviates the need for a smaller targeted > test like this one. I think arguing over this is moot :). More tests is usually a good thing, so whoever gets to write them gets to push them ;). As long as the licenses are sound at least. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Hi all,
Hi Marek, On 11.11.2016 14:33, Marek Vasut wrote: > On 11/11/2016 11:18 PM, Stefan Agner wrote: >> From: Stefan Agner >> >> >> This cleans up the SPL USB Gadget Kconfig and Makfile a bit. The >> first two patches are actual fixes and we might consider to add >> them for the v2016.11 release. The third one adds a new config >> option for cleaner structure. I plan to add another USB function >> with SPL support which is the reason I looked into this... >> >> Build tested mainly with >> dra7xx_evm_defconfig (for CONFIG_SPL_DFU_SUPPORT) >> and >> am335x_evm_usbspl_defconfig (for CONFIG_SPL_USBETH_SUPPORT) I am sorry, it seems I can't handle patman on friday afternoon :-) Will try to do better next time. > There are multiple issues: > 1) Would be nice if the cover letter had real Subject > 2) It's build tested on two boards, people test such disruptive changes > using buildman on at least a few architectures (arm/mips/ppc are the > usual suspects) The changes are not that disruptive as they might seem, but sure, one never knows... Note that the two boards were carefully selected: They are the _only_ ones which actually select the changed configuration options Actually dra7xx_evm_defconfig does not even select CONFIG_SPL_DFU_SUPPORT, but git log/mailing list history tells me that this is the board where that configuration has been developed with... > 3) It is not acceptable as fixes for 2016.11 because it doesn't seems it > was ever boot tested I don't have any of the two boards :-( Lukasz, if you could help me out here on the dra7xx_evm I would be glad. > 4) Please send To: U-Boot list > 5) Please cull the CC list, it's horrible Ok, I thought that was desirable, since it is the default when using patman... -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Hi all,
On 11/11/2016 11:18 PM, Stefan Agner wrote: > From: Stefan Agner > > > This cleans up the SPL USB Gadget Kconfig and Makfile a bit. The > first two patches are actual fixes and we might consider to add > them for the v2016.11 release. The third one adds a new config > option for cleaner structure. I plan to add another USB function > with SPL support which is the reason I looked into this... > > Build tested mainly with > dra7xx_evm_defconfig (for CONFIG_SPL_DFU_SUPPORT) > and > am335x_evm_usbspl_defconfig (for CONFIG_SPL_USBETH_SUPPORT) There are multiple issues: 1) Would be nice if the cover letter had real Subject 2) It's build tested on two boards, people test such disruptive changes using buildman on at least a few architectures (arm/mips/ppc are the usual suspects) 3) It is not acceptable as fixes for 2016.11 because it doesn't seems it was ever boot tested 4) Please send To: U-Boot list 5) Please cull the CC list, it's horrible -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] spl: dfu: move DFU Kconfig to SPL Kconfig
From: Stefan Agner
The DFU Kconfig menu entries should be part of the SPL
Kconfig file. Also avoid using the top level Makefile by
moving the config dependent build artifacts to the driver/
and driver/usb/gadget/ Makfiles.
With that, DFU can be built again in SPL if
CONFIG_SPL_DFU_SUPPORT is enabled.
Fixes: 6ad6102246d8 ("usb:gadget: Disallow DFU in SPL for now")
Signed-off-by: Stefan Agner
---
Tom, I checked size for am335x_evm_usbspl_defconfig, it stays
fine with this patch.
Kconfig | 27 ---
common/spl/Kconfig | 26 ++
drivers/Makefile | 4
drivers/usb/gadget/Makefile | 8 ++--
include/configs/dra7xx_evm.h | 1 -
scripts/Makefile.spl | 4
6 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/Kconfig b/Kconfig
index 1263d0b..a759e4d 100644
--- a/Kconfig
+++ b/Kconfig
@@ -291,33 +291,6 @@ config FIT_IMAGE_POST_PROCESS
injected into the FIT creation (i.e. the blobs would have been pre-
processed before being added to the FIT image).
-config SPL_DFU_SUPPORT
- bool "Enable SPL with DFU to load binaries to memory device"
- depends on USB
- help
- Currently the SPL does not have capability to load the
- binaries or boot images to boot devices like ram,eMMC,SPI,etc.
- This feature enables the DFU (Device Firmware Upgarde) in SPL with
- RAM memory device support. The ROM code will load and execute
- the SPL built with dfu. The user can load binaries (u-boot/kernel) to
- selected device partition from host-pc using dfu-utils.
- This feature will be useful to flash the binaries to factory
- or bare-metal boards using USB interface.
-
-choice
- bool "DFU device selection"
- depends on SPL_DFU_SUPPORT
-
-config SPL_DFU_RAM
- bool "RAM device"
- depends on SPL_DFU_SUPPORT
- help
-select RAM/DDR memory device for loading binary images
-(u-boot/kernel) to the selected device partition using
-DFU and execute the u-boot/kernel from RAM.
-
-endchoice
-
config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index bb99f1f..54bcba3 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -497,6 +497,32 @@ config SPL_USB_SUPPORT
config options. This enables loading from USB using a configured
device.
+config SPL_DFU_SUPPORT
+ bool "Support DFU (Device Firmware Upgarde)"
+ depends on SPL
+ select SPL_HASH_SUPPORT
+ help
+ This feature enables the DFU (Device Firmware Upgarde) in SPL with
+ RAM memory device support. The ROM code will load and execute
+ the SPL built with dfu. The user can load binaries (u-boot/kernel) to
+ selected device partition from host-pc using dfu-utils.
+ This feature is useful to flash the binaries to factory or bare-metal
+ boards using USB interface.
+
+choice
+ bool "DFU device selection"
+ depends on SPL_DFU_SUPPORT
+
+config SPL_DFU_RAM
+ bool "RAM device"
+ depends on SPL_DFU_SUPPORT
+ help
+select RAM/DDR memory device for loading binary images
+(u-boot/kernel) to the selected device partition using
+DFU and execute the u-boot/kernel from RAM.
+
+endchoice
+
config SPL_WATCHDOG_SUPPORT
bool "Support watchdog drivers"
depends on SPL
diff --git a/drivers/Makefile b/drivers/Makefile
index 761d0b3..38885eb 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -34,6 +34,10 @@ obj-$(CONFIG_SPL_ETH_SUPPORT) += net/phy/
obj-$(CONFIG_SPL_USBETH_SUPPORT) += net/phy/
obj-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += usb/musb-new/
obj-$(CONFIG_SPL_USBETH_SUPPORT) += usb/gadget/
+obj-$(CONFIG_SPL_DFU_SUPPORT) += usb/gadget/
+obj-$(CONFIG_SPL_DFU_SUPPORT) += usb/gadget/udc/
+obj-$(CONFIG_SPL_DFU_SUPPORT) += dfu/
+obj-$(CONFIG_SPL_DFU_SUPPORT) += usb/dwc3/
obj-$(CONFIG_SPL_WATCHDOG_SUPPORT) += watchdog/
obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += usb/host/
obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index acc9964..5b18e8c 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -8,6 +8,10 @@
obj-$(CONFIG_USB_GADGET) += epautoconf.o config.o usbstring.o
obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o
+ifdef CONFIG_SPL_BUILD
+obj-$(CONFIG_SPL_DFU_SUPPORT) += f_dfu.o
+endif
+
# new USB gadget layer dependencies
ifdef CONFIG_USB_GADGET
obj-$(CONFIG_USB_GADGET_AT91) += at91_udc.o
@@ -18,13 +22,13 @@ obj-$(CONFIG_USB_GADGET_DWC2_OTG_PHY) += dwc2_udc_otg_phy.o
obj-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
obj-$(CONFIG_CI_UDC) += ci_udc.o
obj-$(CONFIG_USB_GADGET_DOWNLOAD) += g_dnl.o
-obj-$(CONFIG_USB_FUNCTION_THOR) += f_thor.o
ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_US
[U-Boot] [PATCH 3/3] spl: add USB Gadget config option
From: Stefan Agner Introduce USB Gadget config option. This allows to combine Makefile entries for SPL_USBETH_SUPPORT and SPL_DFU_SUPPORT. Signed-off-by: Stefan Agner --- common/spl/Kconfig | 31 +++ configs/am335x_evm_usbspl_defconfig | 1 + drivers/Makefile| 7 +++ drivers/usb/gadget/Makefile | 3 ++- 4 files changed, 25 insertions(+), 17 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 54bcba3..7d0aec0 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -465,17 +465,6 @@ config SPL_SPI_SUPPORT enable SPI drivers that are needed for other purposes also, such as a SPI PMIC. -config SPL_USBETH_SUPPORT - bool "Support USB Ethernet drivers" - depends on SPL - help - Enable access to the USB network subsystem and associated - drivers in SPL. This permits SPL to load U-Boot over a - USB-connected Ethernet link (such as a USB Ethernet dongle) rather - than from an onboard peripheral. Environment support is required - since the network stack uses a number of environment variables. - See also SPL_NET_SUPPORT and SPL_ETH_SUPPORT. - config SPL_USB_HOST_SUPPORT bool "Support USB host drivers" depends on SPL @@ -497,9 +486,27 @@ config SPL_USB_SUPPORT config options. This enables loading from USB using a configured device. +config SPL_USB_GADGET_SUPPORT + bool "Suppport USB Gadget drivers" + depends on SPL + help + Enable USB Gadget API which allows to enable USB device functions + in SPL. + +config SPL_USBETH_SUPPORT + bool "Support USB Ethernet drivers" + depends on SPL_GADGET_SUPPORT + help + Enable access to the USB network subsystem and associated + drivers in SPL. This permits SPL to load U-Boot over a + USB-connected Ethernet link (such as a USB Ethernet dongle) rather + than from an onboard peripheral. Environment support is required + since the network stack uses a number of environment variables. + See also SPL_NET_SUPPORT and SPL_ETH_SUPPORT. + config SPL_DFU_SUPPORT bool "Support DFU (Device Firmware Upgarde)" - depends on SPL + depends on SPL_GADGET_SUPPORT select SPL_HASH_SUPPORT help This feature enables the DFU (Device Firmware Upgarde) in SPL with diff --git a/configs/am335x_evm_usbspl_defconfig b/configs/am335x_evm_usbspl_defconfig index 8c28e28..fdb6f77 100644 --- a/configs/am335x_evm_usbspl_defconfig +++ b/configs/am335x_evm_usbspl_defconfig @@ -12,6 +12,7 @@ CONFIG_SPL_MTD_SUPPORT=y CONFIG_SPL_MUSB_NEW_SUPPORT=y CONFIG_SPL_NET_SUPPORT=y CONFIG_SPL_OS_BOOT=y +CONFIG_SPL_GADGET_SUPPORT=y CONFIG_SPL_USBETH_SUPPORT=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/drivers/Makefile b/drivers/Makefile index 38885eb..2f8f333 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -33,11 +33,10 @@ obj-$(CONFIG_SPL_ETH_SUPPORT) += net/ obj-$(CONFIG_SPL_ETH_SUPPORT) += net/phy/ obj-$(CONFIG_SPL_USBETH_SUPPORT) += net/phy/ obj-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += usb/musb-new/ -obj-$(CONFIG_SPL_USBETH_SUPPORT) += usb/gadget/ -obj-$(CONFIG_SPL_DFU_SUPPORT) += usb/gadget/ -obj-$(CONFIG_SPL_DFU_SUPPORT) += usb/gadget/udc/ +obj-$(CONFIG_USB_DWC3) += usb/dwc3/ +obj-$(CONFIG_SPL_USB_GADGET_SUPPORT) += usb/gadget/ +obj-$(CONFIG_SPL_USB_GADGET_SUPPORT) += usb/gadget/udc/ obj-$(CONFIG_SPL_DFU_SUPPORT) += dfu/ -obj-$(CONFIG_SPL_DFU_SUPPORT) += usb/dwc3/ obj-$(CONFIG_SPL_WATCHDOG_SUPPORT) += watchdog/ obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += usb/host/ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/ diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 5b18e8c..0fbbb7c 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_USB_GADGET) += epautoconf.o config.o usbstring.o obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o ifdef CONFIG_SPL_BUILD +obj-$(CONFIG_SPL_USB_GADGET_SUPPORT) += g_dnl.o obj-$(CONFIG_SPL_DFU_SUPPORT) += f_dfu.o endif @@ -21,8 +22,8 @@ obj-$(CONFIG_USB_GADGET_DWC2_OTG) += dwc2_udc_otg.o obj-$(CONFIG_USB_GADGET_DWC2_OTG_PHY) += dwc2_udc_otg_phy.o obj-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o obj-$(CONFIG_CI_UDC) += ci_udc.o -obj-$(CONFIG_USB_GADGET_DOWNLOAD) += g_dnl.o ifndef CONFIG_SPL_BUILD +obj-$(CONFIG_USB_GADGET_DOWNLOAD) += g_dnl.o obj-$(CONFIG_USB_FUNCTION_THOR) += f_thor.o obj-$(CONFIG_USB_FUNCTION_DFU) += f_dfu.o obj-$(CONFIG_USB_FUNCTION_MASS_STORAGE) += f_mass_storage.o -- 2.10.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] spl: add RAM boot device only if it is actually defined
From: Stefan Agner
Some devices (e.g. dra7xx) support loading to RAM using DFU without
having direct boot from RAM support. Make sure the linker list
does not contain BOOT_DEVICE_RAM if CONFIG_SPL_RAM_SUPPORT is not
enabled.
Fixes: 98136b2f26fa ("spl: Convert spl_ram_load_image() to use linker list")
Signed-off-by: Stefan Agner
---
common/spl/spl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index bdb165a..63e8215 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -220,7 +220,9 @@ static int spl_ram_load_image(struct spl_image_info
*spl_image,
return 0;
}
+#if defined(CONFIG_SPL_RAM_SUPPORT)
SPL_LOAD_IMAGE_METHOD(0, BOOT_DEVICE_RAM, spl_ram_load_image);
+#endif
#if defined(CONFIG_SPL_DFU_SUPPORT)
SPL_LOAD_IMAGE_METHOD(0, BOOT_DEVICE_DFU, spl_ram_load_image);
#endif
--
2.10.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Hi all,
From: Stefan Agner This cleans up the SPL USB Gadget Kconfig and Makfile a bit. The first two patches are actual fixes and we might consider to add them for the v2016.11 release. The third one adds a new config option for cleaner structure. I plan to add another USB function with SPL support which is the reason I looked into this... Build tested mainly with dra7xx_evm_defconfig (for CONFIG_SPL_DFU_SUPPORT) and am335x_evm_usbspl_defconfig (for CONFIG_SPL_USBETH_SUPPORT) -- Stefan Stefan Agner (3): spl: add RAM boot device only if it is actually defined spl: dfu: move DFU Kconfig to SPL Kconfig spl: add USB Gadget config option Kconfig | 27 -- common/spl/Kconfig | 55 + common/spl/spl.c| 2 ++ configs/am335x_evm_usbspl_defconfig | 1 + drivers/Makefile| 5 +++- drivers/usb/gadget/Makefile | 9 -- include/configs/dra7xx_evm.h| 1 - scripts/Makefile.spl| 4 --- 8 files changed, 58 insertions(+), 46 deletions(-) -- 2.10.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sunxi board: why MMC dev are swapped ?
Adding hans to the recipient list Maxime On Fri, Nov 11, 2016 at 07:33:43PM +0100, Mylene Josserand wrote: > Hi everyone, > > > I am currently using FEL and Fastboot to flash a sunxi-device with SPL and > u-boot. > > > In my board, I have two MMC devices: a MMC slot and an eMMC. > > My use-case is to flash an empty device. I want to use FEL to boot a u-boot > and then, use fastboot to flash u-boot into eMMC. > > When I am using an u-boot via FEL, the eMMC is configured as MMC1. To be > able to flash u-boot on it, I need to set CONFIG_FASTBOOT_FLASH_MMC_DEV to > 1. Thanks to that, the flashboot command is working fine. > But when I am booting on my fresh u-boot from eMMC, it is now configured as > MMC0 and not MMC1 anymore. > > It produces some problems in my case as I configured the > CONFIG_FASTBOOT_FLASH_MMC_DEV to 1 so I can not use fastboot anymore to > flash the eMMC (as, now, fastboot is trying to flash u-boot on my MMC slot > and not my eMMC). This is clearly not what I wanted to. I would like to use > fastboot to flash the same MMC device: eMMC. > > This issue is located in this part of the code: > http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=53656383d512199338dcdc1d4fdc4f7f939c9b61;hb=HEAD#l377 > > Do you know why sunxi boards have this behavior ? Why this MMC device's swap > is implemented ? > > Thank you in advance for your help, > > Best regards, > > -- > Mylène Josserand, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- 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 http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] rsa: Verify RSA padding programatically
Simon, So I looked into this more after you asked this, and it looks very platform dependent. I tested on two builds: sandbox and a version of x86-common. The before/after for sandbox image was 5486016-5486800(+784). The before/after for my x86 build was 3306100-3305908(-192). So memory saving is anywhere from a few bytes to actually more space. But the big motivation is the next two patches depend on this change. Thanks, Andrew On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass wrote: > On 8 November 2016 at 11:53, aduda wrote: >> From: Andrew Duda >> >> Padding verification was done against static SHA/RSA pair arrays which >> take up a lot of static memory, are mostly 0xff, and cannot be reused >> for additional SHA/RSA pairings. The padding can be easily computed >> according to PKCS#1v2.1 as: >> >> EM = 0x00 || 0x01 || PS || 0x00 || T >> >> where PS is (emLen - tLen - 3) octets of 0xff and T is DER encoding >> of the hash. >> >> Store DER prefix in checksum_algo and create rsa_verify_padding >> function to handle verification of a message for any SHA/RSA pairing. >> >> Signed-off-by: Andrew Duda >> Signed-off-by: aduda >> --- >> >> common/image-sig.c| 9 ++-- >> include/image.h | 3 +- >> include/u-boot/rsa-checksum.h | 4 -- >> include/u-boot/sha1.h | 3 ++ >> include/u-boot/sha256.h | 3 ++ >> lib/rsa/rsa-checksum.c| 121 >> -- >> lib/rsa/rsa-verify.c | 38 - >> lib/sha1.c| 5 ++ >> lib/sha256.c | 6 +++ >> 9 files changed, 61 insertions(+), 131 deletions(-) > > Reviewed-by: Simon Glass > > How much memory does this save? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] rsa: cosmetic: rename pad_len to key_len
Simon,
padded_len could work. I decided to go with key_len to be more
RSA-independent since I have been dealing with ECDSA primarily. More
specifically, ECDSA has no notion of padding or padded_len, but it
does have a notion of key_len. And in RSA, I believe the padded_len is
the same as the key_len. So the name key_len name would be applicable
to both RSA and ECDSA. Granted, only RSA is currently supported in
u-boot so I wouldn't have much of a problem updating this to
padded_len.
(sorry for the duplicate Simon)
Thanks,
Andrew
On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass wrote:
> Hi,
>
> On 8 November 2016 at 11:53, aduda wrote:
>> From: Andrew Duda
>>
>> checksum_algo's pad_len field isn't actually used to store the length of
>> the padding but the total length of the RSA key (msg_len + pad_len)
>
> Perhaps it should be padded_key_len or padded_len?
>
>>
>> Signed-off-by: Andrew Duda
>> Signed-off-by: aduda
>> ---
>>
>> include/image.h | 2 +-
>> lib/rsa/rsa-verify.c | 6 +++---
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/image.h b/include/image.h
>> index 2b1296c..bfe10a0 100644
>> --- a/include/image.h
>> +++ b/include/image.h
>> @@ -1070,7 +1070,7 @@ struct image_region {
>> struct checksum_algo {
>> const char *name;
>> const int checksum_len;
>> - const int pad_len;
>> + const int key_len;
>> #if IMAGE_ENABLE_SIGN
>> const EVP_MD *(*calculate_sign)(void);
>> #endif
>> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
>> index 442b769..5418f59 100644
>> --- a/lib/rsa/rsa-verify.c
>> +++ b/lib/rsa/rsa-verify.c
>> @@ -84,7 +84,7 @@ static int rsa_verify_key(struct key_prop *prop, const
>> uint8_t *sig,
>> }
>>
>> padding = algo->rsa_padding;
>> - pad_len = algo->pad_len - algo->checksum_len;
>> + pad_len = algo->key_len - algo->checksum_len;
>>
>> /* Check pkcs1.5 padding bytes. */
>> if (memcmp(buf, padding, pad_len)) {
>> @@ -160,7 +160,7 @@ int rsa_verify(struct image_sign_info *info,
>> {
>> const void *blob = info->fdt_blob;
>> /* Reserve memory for maximum checksum-length */
>> - uint8_t hash[info->algo->checksum->pad_len];
>> + uint8_t hash[info->algo->checksum->key_len];
>> int ndepth, noffset;
>> int sig_node, node;
>> char name[100];
>> @@ -171,7 +171,7 @@ int rsa_verify(struct image_sign_info *info,
>> * rsa-signature-length
>> */
>> if (info->algo->checksum->checksum_len >
>> - info->algo->checksum->pad_len) {
>> + info->algo->checksum->key_len) {
>> debug("%s: invlaid checksum-algorithm %s for %s\n",
>> __func__, info->algo->checksum->name,
>> info->algo->name);
>> return -EINVAL;
>> --
>> 2.10.2
>>
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 26/27] ARM64: zynqmp: Add clocks for LPDDMA
> -Original Message-
> From: Michal Simek [mailto:mon...@monstr.eu] On Behalf Of Michal Simek
> Sent: November 11, 2016 05:42
> To: u-boot@lists.denx.de
> Cc: Appana Durga Kedareswara Rao ; Naga Sureshkumar
> Relli ; Bharat Kumar Gogada ;
> Hyun Kwon ; Albert Aribaud
> ; Soren Brinkmann ; Filip
> Drazic
> Subject: [PATCH 26/27] ARM64: zynqmp: Add clocks for LPDDMA
>
> From: Kedareswara rao Appana
>
> Zynqmp DMA driver expects two clocks (main clock and apb clock)
> For LPDDMA channels the two clocks are missing in the
> Dma node resulting probe failure.
>
> xilinx-zynqmp-dma ffa8.dma: main clock not found.
> xilinx-zynqmp-dma ffa8.dma: Probing channel failed
> xilinx-zynqmp-dma: probe of ffa8.dma failed with error -2
>
> This patch fixes this issue.
>
> Signed-off-by: Kedareswara rao Appana
> Signed-off-by: Michal Simek
> ---
>
> arch/arm/dts/zynqmp.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
> index aeeccbf9e9d0..5b4fe0962e05 100644
> --- a/arch/arm/dts/zynqmp.dtsi
> +++ b/arch/arm/dts/zynqmp.dtsi
> @@ -428,6 +428,7 @@
> lpd_dma_chan1: dma@ffa8 {
> status = "disabled";
> compatible = "xlnx,zynqmp-dma-1.0";
> + clock-names = "clk_main", "clk_apb";
> reg = <0x0 0xffa8 0x0 0x1000>;
> interrupt-parent = <&gic>;
> interrupts = <0 77 4>;
Am I missing something? Adding 'clock-names' without 'clocks' doesn't seem
right.
Sören
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sunxi board: why MMC dev are swapped ?
Hi everyone, I am currently using FEL and Fastboot to flash a sunxi-device with SPL and u-boot. In my board, I have two MMC devices: a MMC slot and an eMMC. My use-case is to flash an empty device. I want to use FEL to boot a u-boot and then, use fastboot to flash u-boot into eMMC. When I am using an u-boot via FEL, the eMMC is configured as MMC1. To be able to flash u-boot on it, I need to set CONFIG_FASTBOOT_FLASH_MMC_DEV to 1. Thanks to that, the flashboot command is working fine. But when I am booting on my fresh u-boot from eMMC, it is now configured as MMC0 and not MMC1 anymore. It produces some problems in my case as I configured the CONFIG_FASTBOOT_FLASH_MMC_DEV to 1 so I can not use fastboot anymore to flash the eMMC (as, now, fastboot is trying to flash u-boot on my MMC slot and not my eMMC). This is clearly not what I wanted to. I would like to use fastboot to flash the same MMC device: eMMC. This issue is located in this part of the code: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=53656383d512199338dcdc1d4fdc4f7f939c9b61;hb=HEAD#l377 Do you know why sunxi boards have this behavior ? Why this MMC device's swap is implemented ? Thank you in advance for your help, Best regards, -- Mylène Josserand, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 4/9] w1: Add 1-Wire gpio driver
On Thu, Nov 10, 2016 at 02:35:46PM +0100, Michal Simek wrote:
> On 8.11.2016 11:19, Maxime Ripard wrote:
> > Add a bus driver for bitbanging a 1-Wire bus over a GPIO.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/w1/Kconfig | 6 ++-
> > drivers/w1/Makefile | 1 +-
> > drivers/w1/w1-gpio.c | 160 -
> > 3 files changed, 167 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/w1/w1-gpio.c
> >
> > diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
> > index 0c056b4c06a9..ccc3ae15db86 100644
> > --- a/drivers/w1/Kconfig
> > +++ b/drivers/w1/Kconfig
> > @@ -12,6 +12,12 @@ config W1
> >
> > if W1
> >
> > +config W1_GPIO
> > + bool "Enable 1-Wire GPIO bitbanging"
> > + depends on DM_GPIO
> > + help
> > + Emulate a 1-Wire bus using a GPIO.
> > +
> > endif
> >
> > endmenu
> > diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
> > index 26820fa209e1..7fd8697f8419 100644
> > --- a/drivers/w1/Makefile
> > +++ b/drivers/w1/Makefile
> > @@ -1,2 +1,3 @@
> > obj-$(CONFIG_W1) += w1-uclass.o
> >
> > +obj-$(CONFIG_W1_GPIO) += w1-gpio.o
> > diff --git a/drivers/w1/w1-gpio.c b/drivers/w1/w1-gpio.c
> > new file mode 100644
> > index ..091849162533
> > --- /dev/null
> > +++ b/drivers/w1/w1-gpio.c
> > @@ -0,0 +1,160 @@
> > +/*
> > + * Copyright (c) 2015 Free Electrons
> > + * Copyright (c) 2015 NextThing Co
> > + *
> > + * Maxime Ripard
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +
> > +#define W1_TIMING_A6
> > +#define W1_TIMING_B64
> > +#define W1_TIMING_C60
> > +#define W1_TIMING_D10
> > +#define W1_TIMING_E9
> > +#define W1_TIMING_F55
> > +#define W1_TIMING_G0
> > +#define W1_TIMING_H480
> > +#define W1_TIMING_I70
> > +#define W1_TIMING_J410
> > +
> > +struct w1_gpio_pdata {
> > + struct gpio_descgpio;
> > + u64 search_id;
> > +};
> > +
> > +static bool w1_gpio_read_bit(struct udevice *dev)
> > +{
> > + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> > + int val;
> > +
> > + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_OUT);
> > + udelay(W1_TIMING_A);
> > +
> > + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_IN);
> > + udelay(W1_TIMING_E);
> > +
> > + val = dm_gpio_get_value(&pdata->gpio);
> > + udelay(W1_TIMING_F);
> > +
> > + return val;
> > +}
> > +
> > +static u8 w1_gpio_read_byte(struct udevice *dev)
> > +{
> > + int i;
> > + u8 ret = 0;
> > +
> > + for (i = 0; i < 8; ++i)
> > + ret |= (w1_gpio_read_bit(dev) ? 1 : 0) << i;
> > +
> > + return ret;
> > +}
> > +
> > +static void w1_gpio_write_bit(struct udevice *dev, bool bit)
> > +{
> > + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> > +
> > + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_OUT);
> > +
> > + bit ? udelay(W1_TIMING_A) : udelay(W1_TIMING_C);
> > +
> > + dm_gpio_set_value(&pdata->gpio, 1);
> > +
> > + bit ? udelay(W1_TIMING_B) : udelay(W1_TIMING_D);
> > +}
> > +
> > +static void w1_gpio_write_byte(struct udevice *dev, u8 byte)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < 8; ++i)
> > + w1_gpio_write_bit(dev, (byte >> i) & 0x1);
> > +}
> > +
> > +static bool w1_gpio_reset(struct udevice *dev)
> > +{
> > + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> > + int val;
> > +
> > + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
> > + udelay(W1_TIMING_G);
> > +
> > + dm_gpio_set_value(&pdata->gpio, 0);
> > + udelay(W1_TIMING_H);
> > +
> > + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_IN);
> > + udelay(W1_TIMING_I);
> > +
> > + val = dm_gpio_get_value(&pdata->gpio);
> > + udelay(W1_TIMING_J);
> > +
> > + return val;
> > +}
> > +
> > +static u8 w1_gpio_triplet(struct udevice *dev, bool bdir)
> > +{
> > + u8 id_bit = w1_gpio_read_bit(dev);
> > + u8 comp_bit = w1_gpio_read_bit(dev);
> > + u8 retval;
> > +
> > + if (id_bit && comp_bit)
> > + return 0x03; /* error */
> > +
> > + if (!id_bit && !comp_bit) {
> > + /* Both bits are valid, take the direction given */
> > + retval = bdir ? 0x04 : 0;
> > + } else {
> > + /* Only one bit is valid, take that direction */
> > + bdir = id_bit;
> > + retval = id_bit ? 0x05 : 0x02;
> > + }
> > +
> > + w1_gpio_write_bit(dev, bdir);
> > + return retval;
> > +}
> > +
> > +
> > +static const struct w1_ops w1_gpio_ops = {
> > + .read_byte = w1_gpio_read_byte,
> > + .reset = w1_gpio_reset,
> > + .triplet= w1_gpio_triplet,
> > + .write_byte = w1_gpio_write_byte,
> > +};
> > +
> > +static int w1_gpio_ofdata_to_platdata(struct udevice *dev)
> > +{
> > + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> > + int ret;
> > +
> > + ret = gpio_request_by_name(dev, "gpios"
Re: [U-Boot] [PATCH 3/3] test/py: Create tests for ext4 and fat testing on sandbox
Hi,
On 5 November 2016 at 10:45, Stefan Brüns wrote:
>
> The following checks are currently implemented:
> 1. listing a directory
> 2. verifying size of a file
> 3. veryfying md5sum for a file region
> 4. reading the beginning of a file
>
> Signed-off-by: Stefan Brüns
> ---
> test/py/tests/test_fs.py | 298
> +++
> 1 file changed, 298 insertions(+)
> create mode 100644 test/py/tests/test_fs.py
>
> diff --git a/test/py/tests/test_fs.py b/test/py/tests/test_fs.py
> new file mode 100644
> index 000..5ac91e4
> --- /dev/null
> +++ b/test/py/tests/test_fs.py
> @@ -0,0 +1,298 @@
> +# Copyright (c) 2016, Stefan Bruens
> +#
> +# SPDX-License-Identifier: GPL-2.0
> +
> +# Test U-Boot's filesystem implementations
Can you add a few details here about what this tests?
> +
> +import hashlib
> +import pytest
> +import os
> +import random
> +import re
> +import u_boot_utils as util
> +
> +
> +mkfs_opts = {
> + "fat" :'-t vfat',
> + "ext4" : '-t ext4 -F',
Can you please use a single quote unless you can't? That is the style
used in U-Boot.
> +}
> +
> +fs_commands = {
> + "fat" : {
> + 'listcmd' : 'ls',
> + 'readcmd' : 'load',
> + 'sizecmd' : 'size',
> + 'writecmd' : 'size',
> + },
> + "ext4" : {
> + 'listcmd' : 'ls',
> + 'readcmd' : 'load',
> + 'sizecmd' : 'size',
> + 'writecmd' : 'size',
> + },
> +}
> +
> +cmd_parameters = {
> + "hostfs" : {
> + 'prefix': 'host ',
> + 'interface' : 'hostfs -',
> + },
> + "generic" : {
> + 'prefix': '',
> + 'interface' : 'host 0:0',
> + },
> +}
> +
> +files = {
> +"empty.file" : [(0, 0)],
> +"1MB.file" : [(0, 1e6)],
> +"1MB.sparse.file" : [(1e6-1, 1e6)],
> +}
> +# "2_5GB.sparse.file" : [(0, 1e6), (1e9, 1e9+1e6), (2.5e9-1e6, 2.5e9)],
What is that line for?
> +
> +@pytest.fixture(scope="session")
> +def prereq_commands():
> +from distutils.spawn import find_executable
Why not import this at the top of the file?
> +for command in ["mkfs", "mount", "umount"]:
> +if find_executable(command) is None:
> +pytest.skip('Filesystem tests, "{0}" not in
> PATH'.format(command))
> +
> +class FsImage:
> +def __init__(self, fstype, imagename, mountpath):
Please add comments as to what these params are.
> +self.fstype = fstype
> +self.imagename = imagename
> +self.mountpath = mountpath
> +self.md5s = {}
> +with open(self.imagename, 'w') as fd:
> +fd.truncate(0)
> +fd.seek(3e9)
> +fd.write(bytes([0]))
> +
> +def mkfs(self, log):
> +mkfsopts = mkfs_opts.get(self.fstype)
> +util.run_and_log(log,
> +'mkfs {0} {1}'.format(mkfsopts, self.imagename))
> +
> +def create_file(self, log, filename):
Please add a short comment on each non-function describing what it
does and what the args are (and return value if any).
> +md5sums = []
> +with open(self.mountpath + "/" + filename, 'w') as fd:
I think this is better as os.path.join(self.mountpath, filename)
> +for stride in files[filename]:
> +length = int(stride[1] - stride[0])
> +data = bytearray(random.getrandbits(8) for _ in
> xrange(length))
> +md5 = hashlib.md5(data).hexdigest()
> +md5sums.append(md5)
> +log.info("{0}: write {1} bytes @ {2} : {3}".format(
> +filename, int(stride[1] - stride[0]),
> +int(stride[0]), md5))
> +fd.seek(stride[0])
> +fd.write(data);
> +self.md5s[filename] = md5sums
> +
> +def create_files(self, log):
> +with log.section("Create initial files"):
> +for filename in files:
> +self.create_file(log, filename)
> +log.info("Created test files in {0}".format(self.mountpath))
> +util.run_and_log(log, 'ls -la {0}'.format(self.mountpath))
> +util.run_and_log(log, 'sync {0}'.format(self.mountpath))
> +
> +def mount(self, log):
> +if not os.path.exists(self.mountpath):
> +os.mkdir(self.mountpath)
> +log.info("Mounting {0} at {1}".format(self.imagename,
> self.mountpath))
> +if self.fstype == "ext4":
> +cmd = 'sudo -n mount -o loop,rw {0} {1}'.format(self.imagename,
> self.mountpath)
> +else:
> +cmd = 'sudo -n mount -o loop,rw,umask=000 {0}
> {1}'.format(self.imagename, self.mountpath)
> +util.run_and_log(log, cmd)
> +if self.fstype == "ext4":
> +cmd = 'sudo -n chmod og+rw {0}'.format(self.mountpath)
> +return util.run_and_log(log, cmd)
> +
> +def unmount(self, log):
> +log.info("Unmounting
Re: [U-Boot] xhci USB controller driver for x86 board
On 11/10/2016 07:21 AM, Stefan Roese wrote:
> Hi Chi,
>
> On 10.11.2016 03:16, Kever Yang wrote:
>> Hi Chi,
>>
>> On 11/10/2016 12:51 AM, Ding, ChiX wrote:
>>> Hi there
>>> I'm having problem getting USB 3.0 controller working properly on the
>>> Intel Denverton x86 board.
>>> First I tried to use xhci driver, but there doesn't seem to be any
>>> xhci driver or generic driver for x86
>>> I only found the following
>>> xhci-exynos5.c: { .compatible = "samsung,exynos5250-xhci" },
>>> xhci-mvebu.c: { .compatible = "marvell,armada3700-xhci" },
>>> xhci-rockchip.c: { .compatible = "rockchip,rk3399-xhci" },
>>
>> The xhci.c and xhci-dwc3.c in U-Boot is generic driver, but you may need
>> one driver for x86,
>> this is very like what kernel did, so you can reference to how kernel
>> enable the x86 dwc3.
>
> Please take a look at this patch:
>
> https://patchwork.ozlabs.org/patch/649489/
>
> You do not need to change anything in the dts with this patch. Only
> enable the correct Kconfig options for your board.
>
> I've been able to enable xHCI support on BayTrail with this. But as
> mentioned in the commit text, this still had some problems on my
> board. Unfortunately I've not had the time to dig into it in the
> meantime. It should be a good starting point for you. Perhaps it
> even works for you out-of-the-box.
>
> Marek, could you perhaps queue this patch for the next merge
> window? It has a Reviewed-by from Simon.
Sure, done.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support
Hi Maxime,
On Tue, Nov 8, 2016 at 2:19 AM, Maxime Ripard
wrote:
> Add a driver for the Maxim DS2431 1-Wire EEPROM
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/eeprom/Kconfig | 6 ++
> drivers/eeprom/Makefile | 1 +
> drivers/eeprom/ds2431.c | 38 ++
> 3 files changed, 45 insertions(+), 0 deletions(-)
> create mode 100644 drivers/eeprom/ds2431.c
>
> diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
> index 8dc597a8d894..98bbd67ba579 100644
> --- a/drivers/eeprom/Kconfig
> +++ b/drivers/eeprom/Kconfig
> @@ -12,6 +12,12 @@ config EEPROM
>
> if EEPROM
>
> +config EEPROM_DS2431
> + bool "Enable Maxim DS2431 EEPROM support"
> + depends on W1
> + help
> + Maxim DS2431 1-Wire EEPROM support
> +
> endif
>
> endmenu
> diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
> index 147dba5ec4b8..93dae0bf5d6d 100644
> --- a/drivers/eeprom/Makefile
> +++ b/drivers/eeprom/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_EEPROM) += eeprom-uclass.o
>
> +obj-$(CONFIG_EEPROM_DS2431) += ds2431.o
> diff --git a/drivers/eeprom/ds2431.c b/drivers/eeprom/ds2431.c
> new file mode 100644
> index ..84c1a126c339
> --- /dev/null
> +++ b/drivers/eeprom/ds2431.c
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (c) 2015 Free Electrons
> + * Copyright (c) 2015 NextThing Co
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define W1_F2D_READ_EEPROM 0xf0
> +
> +static int ds2431_read_buf(struct udevice *dev, unsigned offset,
> + u8 *buf, unsigned count)
> +{
> + w1_reset_select(dev);
> +
> + w1_write_byte(dev, W1_F2D_READ_EEPROM);
> + w1_write_byte(dev, offset & 0xff);
> + w1_write_byte(dev, offset >> 8);
> +
> + return w1_read_buf(dev, buf, count);
> +}
> +
> +static const struct eeprom_ops ds2431_ops = {
> + .read_buf = ds2431_read_buf,
> +};
> +
> +U_BOOT_DRIVER(ds2431) = {
> + .name = "ds2431",
> + .id = UCLASS_EEPROM,
> + .ops= &ds2431_ops,
Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?
> +};
> +
> +U_BOOT_W1_DEVICE(ds2431, W1_FAMILY_DS2431);
> --
> git-series 0.8.11
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Cheers,
Moritz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 5/9] EEPROM: Add an EEPROM uclass
Hi Maxime, On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass wrote: > Hi Maxime, > > On 8 November 2016 at 03:19, Maxime Ripard > wrote: >> We might want to access data stored onto EEPROMs. Create a framework to >> provide a consistent API. > > We have UCLASS_I2C_EEPROM. Can we unify these? If not, please add a > sandbox driver and test. I've been working on something very similar (the API looks the same obviously, since the ops are pretty trivial, modulo function names) In my opinion it should be working as follows: UCLASS_EEPROM \... I2C_EEPROM \SPI_EEPROM (AT25) I also have some code to make the CMD_EEPROM stuff work, I'll submit a follow up patch, once we agreed on how the UCLASS_EEPROM looks like. Cheers, Moritz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] imx7: SPI: add suport for SPI flash in mikroBUS slot
Enable the escpi3 nets attached to the mikroBUS slot
on the i.MX7 Sabre evalution board. Also enble the SPI flash
commands to work with the "flash click" board.
This is V2 of this patch with changes recommended by the maintainer
CC: Jagan Teki
---
Changes for v2:
- moved CONFIG_SPI_FLASH_EON conffiguration item from header
file to defconfig
Changes for v3:
- updated comment to match code
---
board/freescale/mx7dsabresd/mx7dsabresd.c | 24
configs/mx7dsabresd_secure_defconfig | 3 +++
include/configs/mx7dsabresd.h | 3 +++
3 files changed, 30 insertions(+)
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index b936544..6ccdd4b 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -50,6 +50,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_SLOW | PAD_CTL_HYS)
+#define SPI_PAD_CTRL \
+ (PAD_CTL_HYS | PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_FAST)
+
#define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
#ifdef CONFIG_SYS_I2C_MXC
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
@@ -68,6 +71,23 @@ static struct i2c_pads_info i2c_pad_info1 = {
};
#endif
+static iomux_v3_cfg_t const ecspi3_pads[] = {
+MX7D_PAD_SAI2_RX_DATA__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_SYNC__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_BCLK__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_DATA__GPIO6_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+int board_spi_cs_gpio(unsigned bus, unsigned cs)
+{
+ return (bus == 2 && cs == 0) ? (IMX_GPIO_NR(6, 22)) : -1;
+}
+
+static void setup_spi(void)
+{
+ imx_iomux_v3_setup_multiple_pads(ecspi3_pads,
ARRAY_SIZE(ecspi3_pads));
+}
+
int dram_init(void)
{
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -553,6 +573,10 @@ int board_init(void)
board_qspi_init();
#endif
+#ifdef CONFIG_MXC_SPI
+ setup_spi();
+#endif
+
return 0;
}
diff --git a/configs/mx7dsabresd_secure_defconfig
b/configs/mx7dsabresd_secure_defconfig
index 126ce31..ef93522 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -45,3 +45,6 @@ CONFIG_G_DNL_MANUFACTURER="FSL"
CONFIG_G_DNL_VENDOR_NUM=0x0525
CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
CONFIG_OF_LIBFDT=y
+CONFIG_SPI_FLASH=y
+CONFIG_CMD_SF=y
+CONFIG_SPI_FLASH_EON=y
diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
index 360a5e0..ca5f9db 100644
--- a/include/configs/mx7dsabresd.h
+++ b/include/configs/mx7dsabresd.h
@@ -201,6 +201,9 @@
#define CONFIG_ENV_SIZESZ_8K
#define CONFIG_ENV_IS_IN_MMC
+/* MXC SPI driver support */
+#define CONFIG_MXC_SPI
+
/*
* If want to use nand, define CONFIG_NAND_MXS and rework board
* to support nand, since emmc has pin conflicts with nand
--
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/2] ARM: zynq: Remove DTC 1.2 warnings
On Fri, Nov 11, 2016 at 06:32:15PM +0100, Michal Simek wrote: > Hi, > > 2016-11-11 17:04 GMT+01:00 Tom Rini : > > > On Fri, Nov 11, 2016 at 01:26:05PM +0100, Michal Simek wrote: > > > > > DTC 1.2 reports these warnings: > > > Warning (unit_address_vs_reg): Node /memory has a reg or ranges > > > property, but no unit name > > > Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property, > > > but no unit name > > > Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name, > > > but no reg property > > > > > > This patch is fixing them. > > > > > > Signed-off-by: Michal Simek > > > > Have you addressed these in Linux as well? > > Going to do so next week. > Both should be in sync. Agreed. I'd prefer to pull them in via Linux but at least once they're on their way into the right tree for upstream we can bring them in here as well (as I want to ensure future re-syncs are easy). 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 1/2] ARM: zynq: Remove DTC 1.2 warnings
Hi, 2016-11-11 17:04 GMT+01:00 Tom Rini : > On Fri, Nov 11, 2016 at 01:26:05PM +0100, Michal Simek wrote: > > > DTC 1.2 reports these warnings: > > Warning (unit_address_vs_reg): Node /memory has a reg or ranges > > property, but no unit name > > Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property, > > but no unit name > > Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name, > > but no reg property > > > > This patch is fixing them. > > > > Signed-off-by: Michal Simek > > Have you addressed these in Linux as well? > > Going to do so next week. Both should be in sync. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] rpi: passthrough of the firmware provided FDT blob
On 11/11/2016 03:59 AM, Cédric Schieli wrote:
Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].
If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.
This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob
There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:
fdt addr ${fdt_addr}
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}
Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
Acked-by: Stephen Warren
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] arm: add save_boot_params for ARM1176
On 11/11/2016 03:59 AM, Cédric Schieli wrote: Implement a hook to allow boards to save boot-time CPU state for later use. When U-Boot is chain-loaded by another bootloader, CPU registers may contain useful information such as system configuration information. This feature mirrors the equivalent ARMv7 feature. Acked-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection
On Wed, Nov 09, 2016 at 03:10:18PM +0100, Maxime Ripard wrote: > Hi Tom, > > On Tue, Nov 08, 2016 at 10:44:18PM -0500, Tom Rini wrote: > > On Tue, Nov 08, 2016 at 11:19:20AM +0100, Maxime Ripard wrote: > > > > [snip] > > > I think the biggest drawback at the moment is that we maintain a list of > > > DIPs and the actions needed directly into the C code, which will make it > > > quite hard to customise for end users and tedious to maintain in the long > > > term. I couldn't really get my head around a better solution, so feel free > > > to suggest alternative approaches. > > > > A thought I had after reading over 8/9 in the series was, could we try > > something like: > > - In C, loop over everything in w1 and set environment variables based > > on each thing we find. > > - In a CONFIG_PREBOOT load a U-Boot shell script in that will look for > > the right env variables to be set for a given DIP and then do whatever > > is needed to load in the overlay. > > > > Does that make sense? > > I thought about an environment-based solution too, but I was pretty > worried about its scalability. But I guesse that's also the easiest > thing to modify by end-users. Yeah, I share that concern too. But it's also the "easy" one in terms of debug and test too. > However, we have basically, three things to do (so far) > 1) Modify the U-Boot environment before the display is initialized > 2) Modify the kernel command line > 3) Apply an overlay > > I think CONFIG_PREBOOT is too late for 1, because the display is > already initialized, and too early for 2 and 3, because the command > line and DT will probably be set / loaded at bootcmd time. Something I honestly wonder about at times is, would it not be better to optimize the default case such that the kernel is up and dealing with the display ASAP? If we go from power-on to Kernel is up and has thrown something on-screen in a few seconds, do we really need a complex solution so that it's up 1 or 2 seconds sooner? > I think we can decouple 1 and 2 from 3, since doing 2 too early is not > an issue, because we might have boards that require to load some > overlay but wouldn't need to make environment modifications (like an > MMC DIP), or the other way around (even though I fail to see a use > case for that at the moment). OK. > So we're left with basically two things: > - Do a bunch of modifications in the environment early > - And apply the overlay very late (basically right before booting > the kernel) > > So we could do something like having an environment script called > dip---setup called when a DIP is detected (if it exists), > and keep the DT overlay logic in its current form. > > What do you think? I think that might work. I think we really want to avoid having modify U-Boot to add a new DIP, so if we can move things to the point of "Here's your DIP and here's a link to the file you install $here on your board and it just works" we'll be in a good spot. -- 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 v8 0/3] armv8: Support loading 32-bit OS in AArch32 execution state
On 11/11/2016 05:58 AM, Ryan Harkin wrote: > Hi Alison, > > On 10 November 2016 at 02:49, Alison Wang wrote: >> This series is to support loading a 32-bit OS, the execution state will >> change from AArch64 to AArch32 when jumping to kernel. The architecture >> information will be got through checking FIT image, then U-Boot will load >> 32-bit OS or 64-bit OS automatically. >> >> Spin-table method is used for secondary cores to load 32-bit OS. >> The architecture information will be got through checking FIT image and >> saved in the os_arch element of spin-table, then the secondary cores will >> check os_arch and jump to 32-bit OS or 64-bit OS automatically. >> >> PSCI method can also be used for secondary cores to load 32-bit OS. >> As PSCI and secure monitor firmware framework are enabled, loading 32-bit OS >> is supported in such case. The default target exception level returned to >> U-Boot is EL2, so the corresponding work to switch to AArch32 EL2 and jump >> to 32-bit OS are done in U-Boot and secure firmware together. >> >> --- >> Changes in v8: >> - Fix the issue when U-Boot is running in EL2 or EL1. > > Thanks for sticking with this. Great news: it works for my setup. > > I tested booting an arm64 kernel on FVP Foundation and AEMv8 modes and > on Juno R0, R1 and R2. I also tested and Versatile Express TC2 can > still load it's Aarch32 kernel. > > I didn't test running an Aarch32 kernel or any of the new > functionality on my ARMv8 platforms. > > But I checked and the patches are bisect-able on my ARMv8 platforms. > > Tested-by: Ryan Harkin > Great! Thanks to Ryan and Alison to work this out. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] rsa: Verify RSA padding programatically
On 8 November 2016 at 11:53, aduda wrote: > From: Andrew Duda > > Padding verification was done against static SHA/RSA pair arrays which > take up a lot of static memory, are mostly 0xff, and cannot be reused > for additional SHA/RSA pairings. The padding can be easily computed > according to PKCS#1v2.1 as: > > EM = 0x00 || 0x01 || PS || 0x00 || T > > where PS is (emLen - tLen - 3) octets of 0xff and T is DER encoding > of the hash. > > Store DER prefix in checksum_algo and create rsa_verify_padding > function to handle verification of a message for any SHA/RSA pairing. > > Signed-off-by: Andrew Duda > Signed-off-by: aduda > --- > > common/image-sig.c| 9 ++-- > include/image.h | 3 +- > include/u-boot/rsa-checksum.h | 4 -- > include/u-boot/sha1.h | 3 ++ > include/u-boot/sha256.h | 3 ++ > lib/rsa/rsa-checksum.c| 121 > -- > lib/rsa/rsa-verify.c | 38 - > lib/sha1.c| 5 ++ > lib/sha256.c | 6 +++ > 9 files changed, 61 insertions(+), 131 deletions(-) Reviewed-by: Simon Glass How much memory does this save? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] sunxi: Add support for the CHIP Pro
On Thu, Nov 10, 2016 at 12:57:09PM +0100, Heiko Schocher wrote: > Hello Maxime, > > Am 09.11.2016 um 15:44 schrieb Maxime Ripard: > >Hi Heiko, > > > >On Wed, Nov 09, 2016 at 08:47:12AM +0100, Heiko Schocher wrote: > >>Am 08.11.2016 um 17:21 schrieb Maxime Ripard: > >>>The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an > >>>AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND. > >>> > >>>Since the first Allwinner device coming whit an SLC NAND that doesn't have > >>>the shortcomings (and breakages) the MLC NAND has, we can finally enable > >>>the NAND support on a board by default. > >>> > >>>This is the occasion to introduce a bunch of additions needed imo to be > >>>able to come up with a sane NAND support for our users. > >>> > >>>The biggest pain point is that the BROM uses a different ECC and randomizer > >>>configuration than for the rest of the NAND. In order to lessen the number > >>>of bitflips, you also need to pad with random data the SPL image. > >>> > >>>Since it's quite tedious to do right (and most users won't be able to > >>>figure it out) and since if it is not done right, it will eventually turn > >>>into an unusable system (which is bad UX), we think that the best solution > >>>is to generate an SPL image that already embeds all this. We'll possible > >>>have to do the same thing for the U-Boot image (at least for the random > >>>padding) on MLC NANDs. > >>> > >>>The only drawback from that is that you need to flash it raw, instead of > >>>using the usual nand write, but it's just a different command, nothing > >>>major anyway. > >>> > >>>In order to flash it, from a device switched in FEL, on your host: > >>>sunxi-fel spl spl/sunxi-spl.bin > >>>sunxi-fel write 0x4a00 u-boot-dtb.bin > >>>sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin > >>>sunxi-fel exe 0x4a00 > >>> > >>>And on the board, once u-boot is running (assuming the NAND is already > >>>erased): > >>> > >>>nand write.raw.noverify 0x4300 0 40 > >>>nand write.raw.noverify 0x4300 0x40 40 > >>> > >>>nand write 0x4a00 0x80 0xc > >>> > >>>I also encountered some weird bug in the private libgcc that prevents > >>>U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that. > >> > >>What was the problem? > > > >It has been reported here: > >http://lists.denx.de/pipermail/u-boot/2016-August/264513.html > > Hmm.. could not find, what was the real problem ... And since it's another area we're just borrowing kernel code for, it'd be good to figure out what odd corner-case is going wrong somewhere and what the fix is. -- 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 4/7] tools: sunxi: Add spl image builder
On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote: > This program generates raw SPL images that can be flashed on the NAND with > the ECC and randomizer properly set up. > > Signed-off-by: Maxime Ripard [snip] > +++ b/tools/sunxi-spl-image-builder.c > @@ -0,0 +1,1113 @@ > +/* > + * Generic binary BCH encoding/decoding library OK, but this is also lib/bch.c and re-using lib/ code for tools is a normal best practice. I'd suggest re-factoring this code in sunxi-tools sot that it too borrows lib/bch.c from the kernel (and can re-sync bugfixes if needed). 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] sata: fix sata command not being executed bug
Hi Tang,
On 9 November 2016 at 02:37, wrote:
> From: Tang Yuantian
>
> Variable sata_curr_device is used to indicate if
> there is a available sata disk on board.
>
> Previously, sata_curr_device is set in sata_initialize().
> Now, sata_initialize() is separated from other sata commands.
> Accordingly, sata_curr_device is removed from sata_initialize() too.
> This caused sata_curr_device never gets a chance to be set.
> If it can't be set a proper value, other sata command will never get
> a change to execute.
>
> This patch sets variable sata_curr_device properly.
>
> Signed-off-by: Tang Yuantian
> ---
> cmd/sata.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
Does this fix commit d97dc8a0 - if so can you please add a 'Fixes:' tag?
>
> diff --git a/cmd/sata.c b/cmd/sata.c
> index d18b523..71c785f 100644
> --- a/cmd/sata.c
> +++ b/cmd/sata.c
> @@ -20,6 +20,7 @@ static int sata_curr_device = -1;
> static int do_sata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
> int rc = 0;
> + int i;
>
> if (argc == 2 && strcmp(argv[1], "stop") == 0)
> return sata_stop();
> @@ -32,9 +33,15 @@ static int do_sata(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> }
>
> /* If the user has not yet run `sata init`, do it now */
> - if (sata_curr_device == -1)
> - if (sata_initialize())
> - return 1;
> + if (sata_curr_device == -1) {
> + rc = sata_initialize();
> + for (i = 0; i < CONFIG_SYS_SATA_MAX_DEVICE; i++) {
> + if (sata_dev_desc[i].lba > 0)
> + sata_curr_device = i;
> + }
> + if (sata_curr_device == -1)
> + return -1;
Can this code go in its own function?
> + }
>
> switch (argc) {
> case 0:
> --
> 2.1.0.27.g96db324
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 03/15] dm: pci: remove pci_bus_to_hose(0) calling
Hi, On 10 November 2016 at 03:58, Zhiqiang Hou wrote: > From: Minghuan Lian > > There may be multiple PCIe controllers in a SoC. > It is not correct that always calling pci_bus_to_hose(0) to get > the first PCIe controller for the PCIe device connected other > controllers. We just remove this calling because hose always point > the correct PCIe controller. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V2: > - No change > > drivers/pci/pci_common.c | 10 -- > 1 file changed, 10 deletions(-) So is 'hose' always a root PCI controller now? If so, can you comment these in the header? I'm a bit confused by this We should perhaps move the regions[] array into its own struct separate from pci_controller. > > diff --git a/drivers/pci/pci_common.c b/drivers/pci/pci_common.c > index 1755914..448e814 100644 > --- a/drivers/pci/pci_common.c > +++ b/drivers/pci/pci_common.c > @@ -181,11 +181,6 @@ phys_addr_t pci_hose_bus_to_phys(struct pci_controller > *hose, > return phys_addr; > } > > -#ifdef CONFIG_DM_PCI > - /* The root controller has the region information */ > - hose = pci_bus_to_hose(0); > -#endif > - > /* > * if PCI_REGION_MEM is set we do a two pass search with preference > * on matches that don't have PCI_REGION_SYS_MEMORY set > @@ -248,11 +243,6 @@ pci_addr_t pci_hose_phys_to_bus(struct pci_controller > *hose, > return bus_addr; > } > > -#ifdef CONFIG_DM_PCI > - /* The root controller has the region information */ > - hose = pci_bus_to_hose(0); > -#endif > - > /* > * if PCI_REGION_MEM is set we do a two pass search with preference > * on matches that don't have PCI_REGION_SYS_MEMORY set > -- > 2.1.0.27.g96db324 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] tools: Add tool to add crc8 to a mac address
Hi Olliver, (is it one l or two?)
On 8 November 2016 at 08:54, Olliver Schinagl wrote:
> This patch adds a little tool that takes a generic MAC address and
> generates a CRC byte for it. The output is the full MAC address without
> any separators, ready written into an EEPROM.
>
> Signed-off-by: Olliver Schinagl
> ---
> tools/.gitignore| 1 +
> tools/Makefile | 4
> tools/gen_ethaddr_crc.c | 52
> +
> 3 files changed, 57 insertions(+)
> create mode 100644 tools/gen_ethaddr_crc.c
>
> diff --git a/tools/.gitignore b/tools/.gitignore
> index cb1e722..0d1f076 100644
> --- a/tools/.gitignore
> +++ b/tools/.gitignore
> @@ -6,6 +6,7 @@
> /fit_check_sign
> /fit_info
> /gen_eth_addr
> +/gen_ethaddr_crc
> /ifdtool
> /img2srec
> /kwboot
> diff --git a/tools/Makefile b/tools/Makefile
> index 06afdb0..4879ded 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -43,6 +43,10 @@ envcrc-objs := envcrc.o lib/crc32.o common/env_embedded.o
> lib/sha1.o
> hostprogs-$(CONFIG_CMD_NET) += gen_eth_addr
> HOSTCFLAGS_gen_eth_addr.o := -pedantic
>
> +hostprogs-$(CONFIG_CMD_NET) += gen_ethaddr_crc
> +gen_ethaddr_crc-objs := gen_ethaddr_crc.o lib/crc8.o
> +HOSTCFLAGS_gen_ethaddr_crc.o := -pedantic
> +
> hostprogs-$(CONFIG_CMD_LOADS) += img2srec
> HOSTCFLAGS_img2srec.o := -pedantic
>
> diff --git a/tools/gen_ethaddr_crc.c b/tools/gen_ethaddr_crc.c
> new file mode 100644
> index 000..9b5bdb0
> --- /dev/null
> +++ b/tools/gen_ethaddr_crc.c
> @@ -0,0 +1,52 @@
> +/*
> + * (C) Copyright 2016
> + * Olliver Schinagl
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ARP_HLEN 6 /* Length of hardware address */
Is there no #define for this in standard headers?
> +
> +int main(int argc, char *argv[])
> +{
> + uint_fast8_t i;
> + uint8_t mac_addr[ARP_HLEN + 1] = { 0x00 };
Why do you need to init it?
> +
> + if (argc < 2) {
> + puts("Please supply a MAC address.");
How about a usage() function which gives generic help as well?
> + return -1;
> + }
> +
> + if (!((strlen(argv[1]) == 12) || (strlen(argv[1]) == 17))) {
> + puts("Please supply a valid MAC address with optionaly\n"
optionally. But do you mean 'Please supply a valid MAC address with
optional - or : separators?'
> +"dashes (-) or colons (:) as seperators.");
separators.
> + return -1;
> + }
> +
> + i = 0;
> + while (*argv[1] != '\0') {
How about putting this code in a separate function:
int process_mac(const char *max)
so you don't have to access argv[1] all the time. Also you can return
1 instead of -1 from main() on error.
> + char nibble[2] = { 0x00, '\n' }; /* for strtol */
> +
> + nibble[0] = *argv[1]++;
> + if (isxdigit(nibble[0])) {
> + if (isupper(nibble[0]))
> + nibble[0] = tolower(nibble[0]);
> + mac_addr[i >> 1] |= strtol(nibble, NULL, 16) << ((i %
> 2) ? 0 : 4) & ((i % 2) ? 0x0f : 0xf0);
How about a nibble_to_hex() function here? This is strange-looking
code. I'm wondering what you are trying to do.
> + i++;
> + }
> + }
> + mac_addr[ARP_HLEN] = crc8(0, mac_addr, ARP_HLEN);
I suggest putting this in a separate variable...
> +
> + for (i = 0; i < ARP_HLEN + 1; i++)
> + printf("%.2x", mac_addr[i]);
> + putchar('\n');
and here: printf("%.2x\n", crc)
> +
> + return 0;
> +}
> --
> 2.10.2
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip USB driver
On 9 November 2016 at 00:33, Kever Yang wrote: > Hi Simon, > > I have send patch for rk3036 kylin and rk3288 PopMetal to enable the usb > host, > both have test with U-Disk, you can enable usb host for other boards with > reference > to my patches if you want. Thanks - I just went through and reviewed them. I think we need a proper USB driver. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 09/15] pci: layerscape: add pci driver based on DM
On 10 November 2016 at 03:58, Zhiqiang Hou wrote: > From: Minghuan Lian > > There are more than five kinds of Layerscape SoCs. unfortunately, > PCIe controller of each SoC is a little bit different. In order > to avoid too many macro definitions, the patch addes a new > implementation of PCIe driver based on DM. PCIe dts node is > used to describe the difference. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V2: > - Rebased the driver against the latest code. > > drivers/pci/Kconfig | 8 + > drivers/pci/pcie_layerscape.c | 761 > ++ > 2 files changed, 769 insertions(+) Reviewed-by: Simon Glass So far as I understand it - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: ns16550: Fix Debug UART initialization for AM335x
Hi, On 10 November 2016 at 04:00, Jacob Siverskog wrote: > Fixed the init sequence in debug_uart_init() to match the one in > NS16550_init(). Without this I was unable to get debug UART working on > AM335x. Based on a patch by Vasili Galka. > > Signed-off-by: Jacob Siverskog > --- > drivers/serial/ns16550.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > index 6e9b946..40fe246 100644 > --- a/drivers/serial/ns16550.c > +++ b/drivers/serial/ns16550.c > @@ -262,6 +262,11 @@ static inline void _debug_uart_init(void) > baud_divisor = ns16550_calc_divisor(com_port, CONFIG_DEBUG_UART_CLOCK, > CONFIG_BAUDRATE); > serial_dout(&com_port->ier, CONFIG_SYS_NS16550_IER); > +#if defined(CONFIG_OMAP) || defined(CONFIG_AM33XX) || \ > + defined(CONFIG_TI81XX) || defined(CONFIG_AM43XX) > + serial_dout(&com_port->mdr1, 0x7); /* mode select reset > TL16C750*/ > +#endif This is generic code so we cannot have arch-specific #ifdefs here. You could pass in a flags or tweaks value perhaps? That would need a change to the function signature. > + > serial_dout(&com_port->mcr, UART_MCRVAL); > serial_dout(&com_port->fcr, UART_FCRVAL); > > @@ -269,6 +274,14 @@ static inline void _debug_uart_init(void) > serial_dout(&com_port->dll, baud_divisor & 0xff); > serial_dout(&com_port->dlm, (baud_divisor >> 8) & 0xff); > serial_dout(&com_port->lcr, UART_LCRVAL); > + > +#if defined(CONFIG_OMAP) || \ > + defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX) || \ > + defined(CONFIG_TI81XX) || defined(CONFIG_AM43XX) > + > + /* /16 is proper to hit 115200 with 48MHz */ > + serial_dout(&com_port->mdr1, 0); > +#endif /* CONFIG_OMAP */ > } > > static inline void _debug_uart_putc(int ch) > -- > 2.10.2 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] board: popmetal: enable the usb host port power in board init
Hi Kever, On 9 November 2016 at 00:30, Kever Yang wrote: > Enable the usb host port 5V power by enable the fix regulator. > The PopMetal board have a on board FE1.1 usb 2.0 hub which connect to > the usb host port, we need to de-assert its reset pin at the same time. This should go in a USB driver. > > Signed-off-by: Kever Yang > --- > > board/chipspark/popmetal_rk3288/popmetal-rk3288.c | 31 > +++ > 1 file changed, 31 insertions(+) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 02/15] dm: pci: return the real controller in pci_bus_to_hose()
On 10 November 2016 at 03:58, Zhiqiang Hou wrote: > From: Minghuan Lian > > for the legacy PCI driver, the function pci_bus_to_hose() returns > the real PCIe controller. To keep consistency, this function is > changed to return the PCIe controller pointer of the root bus > instead of the current PCIe bus. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V2: > - No change > > drivers/pci/pci_compat.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] config: popmetal: enable the USB host controller and function
On 9 November 2016 at 00:30, Kever Yang wrote: > RK3288 using the dwc2 USB host controller, enable it and other usb host > funtion like storage and ether. > > Signed-off-by: Kever Yang > --- > > configs/popmetal-rk3288_defconfig | 3 +++ > include/configs/rk3288_common.h | 7 +++ > 2 files changed, 10 insertions(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dts: popmetal: add usb host power supply node
On 9 November 2016 at 00:30, Kever Yang wrote: > The popmetal board using a HOST_VBUS_DRV gpio signal to control the > USB host port 5V power, add a fix regulator and pinctrl for it, and > enable the USB host1 controller at the same time. > > Signed-off-by: Kever Yang > --- > > arch/arm/dts/rk3288-popmetal.dtsi | 22 ++ > 1 file changed, 22 insertions(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] image: Add crypto_algo struct for RSA info
On 8 November 2016 at 11:53, aduda wrote: > From: Andrew Duda > > Cut down on the repetition of algorithm information by defining separate > checksum and crypto structs. image_sig_algos are now simply pairs of > unique checksum and crypto algos. > > Signed-off-by: Andrew Duda > Signed-off-by: aduda > --- > > common/image-sig.c | 46 +++--- > include/image.h | 9 +++-- > lib/rsa/rsa-verify.c | 19 +++ > tools/image-host.c | 9 + > 4 files changed, 46 insertions(+), 37 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] image: Combine image_sig_algo with image_sign_info
On 8 November 2016 at 11:53, aduda wrote: > From: Andrew Duda > > Remove the need to explicitly add SHA/RSA pairings. Invalid SHA/RSA > pairings will still fail on verify operations when the hash length is > longer than the key length. > > Follow the same naming scheme "checksum,crytpo" without explicitly > defining the string. > > Indirectly adds support for "sha1,rsa4096" signing/verification. > > Signed-off-by: Andrew Duda > Signed-off-by: aduda > --- > > common/image-sig.c | 57 > > include/image.h | 24 -- > lib/rsa/rsa-sign.c | 4 ++-- > lib/rsa/rsa-verify.c | 14 ++--- > tools/image-host.c | 16 --- > 5 files changed, 61 insertions(+), 54 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] tools: Allow crc8 to be used
On 8 November 2016 at 08:54, Olliver Schinagl wrote: > This patch enables crc8 to be used from within the tools directory using > u-boot/crc.h. > > Signed-off-by: Olliver Schinagl > Reviewed-by: Joe Hershberger > --- > include/u-boot/crc.h | 3 +++ > tools/Makefile | 1 + > 2 files changed, 4 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] rsa: cosmetic: rename pad_len to key_len
Hi,
On 8 November 2016 at 11:53, aduda wrote:
> From: Andrew Duda
>
> checksum_algo's pad_len field isn't actually used to store the length of
> the padding but the total length of the RSA key (msg_len + pad_len)
Perhaps it should be padded_key_len or padded_len?
>
> Signed-off-by: Andrew Duda
> Signed-off-by: aduda
> ---
>
> include/image.h | 2 +-
> lib/rsa/rsa-verify.c | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/image.h b/include/image.h
> index 2b1296c..bfe10a0 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1070,7 +1070,7 @@ struct image_region {
> struct checksum_algo {
> const char *name;
> const int checksum_len;
> - const int pad_len;
> + const int key_len;
> #if IMAGE_ENABLE_SIGN
> const EVP_MD *(*calculate_sign)(void);
> #endif
> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> index 442b769..5418f59 100644
> --- a/lib/rsa/rsa-verify.c
> +++ b/lib/rsa/rsa-verify.c
> @@ -84,7 +84,7 @@ static int rsa_verify_key(struct key_prop *prop, const
> uint8_t *sig,
> }
>
> padding = algo->rsa_padding;
> - pad_len = algo->pad_len - algo->checksum_len;
> + pad_len = algo->key_len - algo->checksum_len;
>
> /* Check pkcs1.5 padding bytes. */
> if (memcmp(buf, padding, pad_len)) {
> @@ -160,7 +160,7 @@ int rsa_verify(struct image_sign_info *info,
> {
> const void *blob = info->fdt_blob;
> /* Reserve memory for maximum checksum-length */
> - uint8_t hash[info->algo->checksum->pad_len];
> + uint8_t hash[info->algo->checksum->key_len];
> int ndepth, noffset;
> int sig_node, node;
> char name[100];
> @@ -171,7 +171,7 @@ int rsa_verify(struct image_sign_info *info,
> * rsa-signature-length
> */
> if (info->algo->checksum->checksum_len >
> - info->algo->checksum->pad_len) {
> + info->algo->checksum->key_len) {
> debug("%s: invlaid checksum-algorithm %s for %s\n",
> __func__, info->algo->checksum->name, info->algo->name);
> return -EINVAL;
> --
> 2.10.2
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 5/9] EEPROM: Add an EEPROM uclass
Hi Maxime,
On 8 November 2016 at 03:19, Maxime Ripard
wrote:
> We might want to access data stored onto EEPROMs. Create a framework to
> provide a consistent API.
We have UCLASS_I2C_EEPROM. Can we unify these? If not, please add a
sandbox driver and test.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/Kconfig| 2 +-
> drivers/Makefile | 1 +-
> drivers/eeprom/Kconfig | 17 ++-
> drivers/eeprom/Makefile| 2 +-
> drivers/eeprom/eeprom-uclass.c | 57 +++-
> include/dm/uclass-id.h | 1 +-
> include/eeprom.h | 21 +-
> 7 files changed, 101 insertions(+), 0 deletions(-)
> create mode 100644 drivers/eeprom/Kconfig
> create mode 100644 drivers/eeprom/Makefile
> create mode 100644 drivers/eeprom/eeprom-uclass.c
> create mode 100644 include/eeprom.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 74194b0d6f7f..e518752eae1a 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -20,6 +20,8 @@ source "drivers/dfu/Kconfig"
>
> source "drivers/dma/Kconfig"
>
> +source "drivers/eeprom/Kconfig"
> +
> source "drivers/fpga/Kconfig"
>
> source "drivers/gpio/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 543c43bb0d23..c8f285f66bb3 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -64,6 +64,7 @@ obj-y += block/
> obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/
> obj-$(CONFIG_CPU) += cpu/
> obj-y += crypto/
> +obj-y += eeprom/
> obj-$(CONFIG_FPGA) += fpga/
> obj-y += hwmon/
> obj-y += misc/
> diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
> new file mode 100644
> index ..8dc597a8d894
> --- /dev/null
> +++ b/drivers/eeprom/Kconfig
> @@ -0,0 +1,17 @@
> +#
> +# EEPROM subsystem configuration
> +#
> +
> +menu "EEPROM support"
> +
> +config EEPROM
> + bool "Enable EEPROM support"
> + depends on DM
> + help
> + Support for the EEPROMs
Please expand this a bit.
> +
> +if EEPROM
> +
> +endif
> +
> +endmenu
> diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
> new file mode 100644
> index ..147dba5ec4b8
> --- /dev/null
> +++ b/drivers/eeprom/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_EEPROM) += eeprom-uclass.o
> +
> diff --git a/drivers/eeprom/eeprom-uclass.c b/drivers/eeprom/eeprom-uclass.c
> new file mode 100644
> index ..020b0087d22c
> --- /dev/null
> +++ b/drivers/eeprom/eeprom-uclass.c
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (c) 2015 Free Electrons
> + * Copyright (c) 2015 NextThing Co.
> + *
> + * Maxime Ripard
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +int eeprom_read_buf(struct udevice *dev, unsigned offset,
> + u8 *buf, unsigned count)
> +{
> + const struct eeprom_ops *ops = device_get_ops(dev);
> +
> + if (!ops->read_buf)
> + return -ENOSYS;
> +
> + return ops->read_buf(dev, offset, buf, count);
> +}
> +
> +
> +UCLASS_DRIVER(eeprom) = {
> + .name = "eeprom",
> + .id = UCLASS_EEPROM,
> +};
> +
> +int eeprom_dm_init(void)
> +{
> + struct udevice *bus;
> + struct uclass *uc;
> + int ret;
> +
> + ret = uclass_get(UCLASS_EEPROM, &uc);
> + if (ret)
> + return ret;
> +
> + uclass_foreach_dev(bus, uc) {
> + ret = device_probe(bus);
> + if (ret == -ENODEV) { /* No such device. */
> + printf("EEPROM not available.\n");
debug()?
> + continue;
> + }
> +
> + if (ret) { /* Other error. */
> + printf("EEPROM probe failed, error %d\n", ret);
debug()?
> + continue;
> + }
> + }
> +
> + return 0;
> +}
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index b88adcbe802f..909a32404259 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -83,6 +83,7 @@ enum uclass_id {
> UCLASS_VIDEO_BRIDGE,/* Video bridge, e.g. DisplayPort to LVDS */
> UCLASS_VIDEO_CONSOLE, /* Text console driver for video device */
> UCLASS_W1, /* Dallas 1-Wire bus */
> + UCLASS_EEPROM, /* EEPROM */
Please put this in alpha order.
>
> UCLASS_COUNT,
> UCLASS_INVALID = -1,
> diff --git a/include/eeprom.h b/include/eeprom.h
> new file mode 100644
> index ..648c8606c35a
> --- /dev/null
> +++ b/include/eeprom.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (c) 2015 Free Electrons
> + * Copyright (c) 2015 NextThing Co
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef __EEPROM_H
> +#define __EEPROM_H
> +
> +#include
You can use a 'struct udevice *' forward decl instead.
> +
> +struct eeprom_ops {
Please add comments
> + int (*read_buf)(struct udevice *dev, unsigne
Re: [U-Boot] [PATCH RESEND 7/9] video: Allow board hook before video init
Hi Maxime,
On 8 November 2016 at 03:19, Maxime Ripard
wrote:
> Some boards might need to some additional setup right before initialising
> the video console.
>
> Add some hook to allow that.
Instead of this, can you use driver model (UCLASS_VIDEO)?
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/video/cfb_console.c | 9 +
> 1 file changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
> index c0b1b8dc17e2..724ae16c5a9b 100644
> --- a/drivers/video/cfb_console.c
> +++ b/drivers/video/cfb_console.c
> @@ -2119,6 +2119,11 @@ __weak int board_video_skip(void)
> return 0;
> }
>
> +__weak int board_video_pre_init(void)
> +{
> + return 0;
> +}
> +
> int drv_video_init(void)
> {
> struct stdio_dev console_dev;
> @@ -2129,6 +2134,10 @@ int drv_video_init(void)
> if (board_video_skip())
> return 0;
>
> + /* Allow the board to setup a few things */
> + if (board_video_pre_init())
> + return 0;
> +
> /* Init video chip - returns with framebuffer cleared */
> if (cfg_video_init() == -1)
> return 0;
> --
> git-series 0.8.11
Regards,
SImon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program
Hi Alex, On 7 November 2016 at 09:32, Alexander Graf wrote: > > > On 07/11/2016 10:46, Simon Glass wrote: >> >> Hi Alex, >> >> On 19 October 2016 at 01:09, Alexander Graf wrote: >>> >>> >>> >>> On 18/10/2016 22:37, Simon Glass wrote: Hi Alex, On 18 October 2016 at 01:14, Alexander Graf wrote: > > On 10/18/2016 04:29 AM, Simon Glass wrote: >> >> >> It is useful to have a basic sanity check for EFI loader support. Add >> a >> 'bootefi hello' command which loads HelloWord.efi and runs it under >> U-Boot. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v3: >> - Include a link to the program instead of adding it to the tree > > > > So, uh, where is the link? I put it in the README (see the arm patch). > > I'm really not convinced this command buys us anything yet. I do agree > that > we want automated testing - but can't we get that using QEMU and a > downloadable image file that we pass in as disk and have the distro > boot do > its magic? That seems very heavyweight as a sanity check, although I agree it is useful. >>> >>> >>> It's not really much more heavy weight. The "image file" could simply >>> contain your hello world binary. But with this we don't just verify >>> whether "bootefi" works, but also whether the default boot path works ok. >> >> >> I don't think I understand what you mean by 'image file'. Is it >> something other than the .efi file? Do you mean a disk image? > > > Yes. For reasonable test coverage, we should also verify that the distro > defaults wrote a sane boot script that automatically searches for a default > EFI binary in /efi/boot/bootx86.efi on the first partition of all devices > and runs it. > > So if we just provide an SD card image or hard disk image to QEMU which > contains a hello world .efi binary as that default boot file, we don't only > test whether the "bootefi" command works, but also whether the distro boot > script works. That's right. > >> >>> Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot. >>> >>> >>> Again, I don't think it's much more overhead and I do believe it gives >>> us much cleaner separation between responsibilities of code (tests go >>> where tests are). >> >> >> You are talking about a functional test, something that tests things >> end to end. I prefer to at least start with a smaller test. Granted it >> takes a little more work but it means there are fewer things to hunt >> through when something goes wrong. > > > Yes, I personally find unit tests terribly annoying and unproductive and > functional tests very helpful :). And in this case, the effort to write it > is about the same for both, just that the functional test actually tells you > that things work or don't work at the end of the day. > > With a code base like U-Boot, a simple functional test like the above plus > git bisect should get you to an offending patch very quickly. This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality. I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is. We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] w1: Add 1-Wire gpio driver
Hi Maxime,
On 8 November 2016 at 03:06, Maxime Ripard
wrote:
> Add a bus driver for bitbanging a 1-Wire bus over a GPIO.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/w1/Kconfig | 6 ++-
> drivers/w1/Makefile | 1 +-
> drivers/w1/w1-gpio.c | 160 -
> 3 files changed, 167 insertions(+), 0 deletions(-)
> create mode 100644 drivers/w1/w1-gpio.c
>
> diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
> index 0c056b4c06a9..ccc3ae15db86 100644
> --- a/drivers/w1/Kconfig
> +++ b/drivers/w1/Kconfig
> @@ -12,6 +12,12 @@ config W1
>
> if W1
>
> +config W1_GPIO
> + bool "Enable 1-Wire GPIO bitbanging"
> + depends on DM_GPIO
> + help
> + Emulate a 1-Wire bus using a GPIO.
Any more details? How many GPIOs? Any particular chips that are supported?
> +
> endif
>
> endmenu
> diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
> index 26820fa209e1..7fd8697f8419 100644
> --- a/drivers/w1/Makefile
> +++ b/drivers/w1/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_W1) += w1-uclass.o
>
> +obj-$(CONFIG_W1_GPIO) += w1-gpio.o
> diff --git a/drivers/w1/w1-gpio.c b/drivers/w1/w1-gpio.c
> new file mode 100644
> index ..091849162533
> --- /dev/null
> +++ b/drivers/w1/w1-gpio.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (c) 2015 Free Electrons
> + * Copyright (c) 2015 NextThing Co
> + *
> + * Maxime Ripard
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +
> +#define W1_TIMING_A6
> +#define W1_TIMING_B64
> +#define W1_TIMING_C60
> +#define W1_TIMING_D10
> +#define W1_TIMING_E9
> +#define W1_TIMING_F55
> +#define W1_TIMING_G0
> +#define W1_TIMING_H480
> +#define W1_TIMING_I70
> +#define W1_TIMING_J410
What do these mean? Perhaps add a _US suffix?
> +
> +struct w1_gpio_pdata {
> + struct gpio_descgpio;
> + u64 search_id;
> +};
> +
> +static bool w1_gpio_read_bit(struct udevice *dev)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> + int val;
> +
> + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_OUT);
Error checks here?
> + udelay(W1_TIMING_A);
> +
> + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_IN);
> + udelay(W1_TIMING_E);
> +
> + val = dm_gpio_get_value(&pdata->gpio);
> + udelay(W1_TIMING_F);
> +
> + return val;
> +}
> +
> +static u8 w1_gpio_read_byte(struct udevice *dev)
> +{
> + int i;
> + u8 ret = 0;
> +
> + for (i = 0; i < 8; ++i)
> + ret |= (w1_gpio_read_bit(dev) ? 1 : 0) << i;
> +
> + return ret;
> +}
> +
> +static void w1_gpio_write_bit(struct udevice *dev, bool bit)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> +
> + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_OUT);
> +
> + bit ? udelay(W1_TIMING_A) : udelay(W1_TIMING_C);
Can you convert this and below to if/else?
> +
> + dm_gpio_set_value(&pdata->gpio, 1);
> +
> + bit ? udelay(W1_TIMING_B) : udelay(W1_TIMING_D);
> +}
> +
> +static void w1_gpio_write_byte(struct udevice *dev, u8 byte)
> +{
> + int i;
> +
> + for (i = 0; i < 8; ++i)
> + w1_gpio_write_bit(dev, (byte >> i) & 0x1);
> +}
> +
> +static bool w1_gpio_reset(struct udevice *dev)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> + int val;
> +
> + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_OUT |
> GPIOD_IS_OUT_ACTIVE);
> + udelay(W1_TIMING_G);
> +
> + dm_gpio_set_value(&pdata->gpio, 0);
> + udelay(W1_TIMING_H);
> +
> + dm_gpio_set_dir_flags(&pdata->gpio, GPIOD_IS_IN);
> + udelay(W1_TIMING_I);
> +
> + val = dm_gpio_get_value(&pdata->gpio);
> + udelay(W1_TIMING_J);
> +
> + return val;
> +}
> +
> +static u8 w1_gpio_triplet(struct udevice *dev, bool bdir)
> +{
> + u8 id_bit = w1_gpio_read_bit(dev);
> + u8 comp_bit = w1_gpio_read_bit(dev);
> + u8 retval;
> +
> + if (id_bit && comp_bit)
> + return 0x03; /* error */
> +
> + if (!id_bit && !comp_bit) {
> + /* Both bits are valid, take the direction given */
> + retval = bdir ? 0x04 : 0;
> + } else {
> + /* Only one bit is valid, take that direction */
> + bdir = id_bit;
> + retval = id_bit ? 0x05 : 0x02;
Can you use enums / #defines for these magic values?
> + }
> +
> + w1_gpio_write_bit(dev, bdir);
> + return retval;
> +}
> +
> +
> +static const struct w1_ops w1_gpio_ops = {
> + .read_byte = w1_gpio_read_byte,
> + .reset = w1_gpio_reset,
> + .triplet= w1_gpio_triplet,
> + .write_byte = w1_gpio_write_byte,
> +};
> +
> +static int w1_gpio_ofdata_to_platdata(struct udevice *dev)
This should probably go in probe() since it actually probes the GPIOs.
> +{
> + struct w1_g
Re: [U-Boot] [PATCH 4/4] rk3036: enable the vbus regulator when borad_init
Hi Kever,
On 8 November 2016 at 03:13, Kever Yang wrote:
> enable the vbus for usb host in board_init().
Note 'borad_init' typo in subject.
>
> Signed-off-by: Kever Yang
> ---
>
> arch/arm/mach-rockchip/rk3036-board.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3036-board.c
> b/arch/arm/mach-rockchip/rk3036-board.c
> index bf2b268..90d3d33 100644
> --- a/arch/arm/mach-rockchip/rk3036-board.c
> +++ b/arch/arm/mach-rockchip/rk3036-board.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -57,7 +58,26 @@ int board_late_init(void)
>
> int board_init(void)
> {
> + int ret;
> + struct udevice *regulator;
> +
> + ret = regulator_get_by_platname("vcc5v0_host", ®ulator);
Can this be done in the USB driver? Then you might be able to use
device_get_supply_regulator().
In fact it looks like board_usb_init() should move into a driver.
> + if (ret) {
> + printf("%s vcc5v0_host init fail! ret %d\n", __func__, ret);
> + goto out;
> + }
> +
> + ret = regulator_set_enable(regulator, true);
> + if (ret) {
> + printf("%s vcc5v0-host enable fail!\n", __func__);
> + goto out;
> + }
> +
> return 0;
> +out:
> + printf("%s board ini error %x\n", __func__, ret);
> +
> + return ret;
> }
>
> int dram_init(void)
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] w1: Add 1-Wire uclass
Hi Maxime,
On 8 November 2016 at 03:06, Maxime Ripard
wrote:
> We might want to use 1-Wire devices connected on boards such as EEPROMs in
> U-Boot.
>
> Provide a framework to be able to do that.
Also please can you add a sandbox driver and a test for this uclass.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/Kconfig| 2 +-
> drivers/Makefile | 1 +-
> drivers/w1/Kconfig | 17 +++-
> drivers/w1/Makefile| 2 +-
> drivers/w1/w1-uclass.c | 259 ++-
> include/dm/uclass-id.h | 1 +-
> include/w1.h | 47 -
> 7 files changed, 329 insertions(+), 0 deletions(-)
> create mode 100644 drivers/w1/Kconfig
> create mode 100644 drivers/w1/Makefile
> create mode 100644 drivers/w1/w1-uclass.c
> create mode 100644 include/w1.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index e8c9e0a32626..74194b0d6f7f 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -84,6 +84,8 @@ source "drivers/usb/Kconfig"
>
> source "drivers/video/Kconfig"
>
> +source "drivers/w1/Kconfig"
> +
> source "drivers/watchdog/Kconfig"
>
> config PHYS_TO_BUS
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 761d0b3e85b4..543c43bb0d23 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -91,6 +91,7 @@ obj-y += input/
> obj-y += soc/
> obj-$(CONFIG_REMOTEPROC) += remoteproc/
> obj-y += thermal/
> +obj-y += w1/
>
> obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
> endif
> diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
> new file mode 100644
> index ..0c056b4c06a9
> --- /dev/null
> +++ b/drivers/w1/Kconfig
> @@ -0,0 +1,17 @@
> +#
> +# W1 subsystem configuration
> +#
> +
> +menu "1-Wire support"
> +
> +config W1
> + bool "Enable 1-Wire controllers support"
> + depends on DM
> + help
> + Support for the Dallas 1-Wire bus.
Can you add more explanation of what this is and what support is provided?
> +
> +if W1
> +
> +endif
> +
> +endmenu
> diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
> new file mode 100644
> index ..26820fa209e1
> --- /dev/null
> +++ b/drivers/w1/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_W1) += w1-uclass.o
> +
> diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
> new file mode 100644
> index ..f9224746806c
> --- /dev/null
> +++ b/drivers/w1/w1-uclass.c
> @@ -0,0 +1,259 @@
> +/*
> + * Copyright (c) 2015 Free Electrons
> + * Copyright (c) 2015 NextThing Co.
> + *
> + * Maxime Ripard
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define W1_MATCH_ROM 0x55
> +#define W1_SKIP_ROM0xcc
> +#define W1_SEARCH 0xf0
> +
> +struct w1_bus {
> + u64 search_id;
> +};
> +
> +struct w1_device {
> + u64 id;
> +};
> +
> +static int w1_new_device(struct udevice *bus, u64 id)
Please add function comment - i.e. what this does, args.
> +{
> + struct w1_driver_entry *start, *entry;
> + int n_ents, ret = -ENODEV;
> + u8 family = id & 0xff;
> +
> + debug("%s: Detected new device 0x%llx (family 0x%x)\n",
> + bus->name, id, family);
> +
> + start = ll_entry_start(struct w1_driver_entry, w1_driver_entry);
> + n_ents = ll_entry_count(struct w1_driver_entry, w1_driver_entry);
> +
> + for (entry = start; entry != start + n_ents; entry++) {
> + const struct driver *drv;
> + struct w1_device *w1;
> + struct udevice *dev;
> +
> + if (entry->family != family)
> + continue;
> +
> + drv = entry->driver;
> + ret = device_bind(bus, drv, drv->name, NULL, -1,
> + &dev);
> + if (ret)
> + goto error;
> +
> + debug("%s: Match found: %s\n", __func__, drv->name);
> +
> + w1 = dev_get_parent_platdata(dev);
> + w1->id = id;
> +
> + return 0;
> + }
> +
> +error:
> + debug("%s: No matches found: error %d\n", __func__, ret);
> + return ret;
> +}
> +
> +static int w1_enumerate(struct udevice *bus)
Please add function comment - i.e. what this does, args.
> +{
> + const struct w1_ops *ops = device_get_ops(bus);
> + struct w1_bus *w1 = dev_get_uclass_priv(bus);
> + u64 last_rn, rn = w1->search_id, tmp64;
> + bool last_device = false;
> + int search_bit, desc_bit = 64;
> + int last_zero = -1;
> + u8 triplet_ret = 0;
> + int i;
> +
> + if (!ops->reset || !ops->write_byte || !ops->triplet)
> + return -ENOSYS;
> +
> + while ( !last_device ) {
> + last_rn = rn;
> + rn = 0;
> +
> + /*
> +* Reset bus and all 1-wire device state machines
> +* so they can respond to our requests.
> +*
> +* Return 0 - dev
Re: [U-Boot] [PATCH 3/4] dts: arm: rk3036: add usb vbus node
On 8 November 2016 at 03:13, Kever Yang wrote: > add fix regulator node for usb vbus power control. > > Signed-off-by: Kever Yang > --- > > arch/arm/dts/rk3036-sdk.dts | 37 + > 1 file changed, 33 insertions(+), 4 deletions(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] config: rk3036: enable fix regulator
On 8 November 2016 at 03:13, Kever Yang wrote: > usb host vbus power is using gpio fix regulator, enable it. > > Signed-off-by: Kever Yang > --- > > configs/kylin-rk3036_defconfig | 1 + > 1 file changed, 1 insertion(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] config: rk3036: enable configs for USB HOST
Hi Kever, On 8 November 2016 at 03:13, Kever Yang wrote: > rk3036 using dwc2 usb controller, need enable relate configs for it. > > Signed-off-by: Kever Yang > --- > > configs/kylin-rk3036_defconfig | 3 +++ > include/configs/rk3036_common.h | 7 +++ > 2 files changed, 10 insertions(+) Acked-by: Simon Glass Are these added in the right order? Did you use 'make savedefconfig' afterwards? > > diff --git a/configs/kylin-rk3036_defconfig b/configs/kylin-rk3036_defconfig > index 424cdab..5a8b85a 100644 > --- a/configs/kylin-rk3036_defconfig > +++ b/configs/kylin-rk3036_defconfig > @@ -36,3 +36,6 @@ CONFIG_RAM=y > CONFIG_SYSRESET=y > CONFIG_CMD_DHRYSTONE=y > CONFIG_ERRNO_STR=y > +CONFIG_CMD_USB=y > +CONFIG_USB=y > +CONFIG_USB_STORAGE=y > diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h > index 4eef3f8..92be29e 100644 > --- a/include/configs/rk3036_common.h > +++ b/include/configs/rk3036_common.h > @@ -79,6 +79,13 @@ > #define CONFIG_G_DNL_VENDOR_NUM0x2207 > #define CONFIG_G_DNL_PRODUCT_NUM 0x310a > > +/* usb host */ > +#ifdef CONFIG_CMD_USB > +#define CONFIG_USB_DWC2 > +#define CONFIG_USB_HOST_ETHER > +#define CONFIG_USB_ETHER_SMSC95XX > +#define CONFIG_USB_ETHER_ASIX > +#endif > #define ENV_MEM_LAYOUT_SETTINGS \ > "scriptaddr=0x6000\0" \ > "pxefile_addr_r=0x6010\0" \ > -- > 1.9.1 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] cmd: pci: add option to parse and display BAR information
Hi,
On 6 November 2016 at 07:31, wrote:
> From: Yehuda Yitschak
>
> Currently the PCI command only allows to see the BAR register
> values but not the size and actual base address.
> This little extension parses the BAR registers and displays
> the base, size and type of each BAR.
>
> Signed-off-by: Yehuda Yitschak
> ---
> cmd/pci.c | 95
> +++
> 1 file changed, 95 insertions(+)
Reviewed-by: Simon Glass
>
> diff --git a/cmd/pci.c b/cmd/pci.c
> index 2f4978a..51eb536 100644
> --- a/cmd/pci.c
> +++ b/cmd/pci.c
> @@ -92,6 +92,96 @@ static void pci_show_regs(pci_dev_t dev, struct
> pci_reg_info *regs)
> }
> #endif
>
> +#ifdef CONFIG_DM_PCI
> +int pci_bar_show(struct udevice *dev)
> +#else
> +int pci_bar_show(pci_dev_t dev)
> +#endif
> +{
> + u8 header_type;
> + int bar_cnt, bar_id, is_64, is_io, mem_type;
> + u32 base_low, base_high;
> + u32 size_low, size_high;
> + u64 base, size;
> + u32 reg_addr;
> + int prefetchable;
> +
> +#ifdef CONFIG_DM_PCI
I think you can implement only the DM_PCI case, since we are trying to
move everything to DM_PCI.
> + dm_pci_read_config8(dev, PCI_HEADER_TYPE, &header_type);
> +#else
> + pci_read_config_byte(dev, PCI_HEADER_TYPE, &header_type);
> +#endif
> +
> + if (header_type == PCI_HEADER_TYPE_CARDBUS) {
> + printf("CardBus doesn't support BARs\n");
> + return -1;
-ENOSYS perhaps. This is -EPERM which seems wrong.
> + }
> +
> + bar_cnt = (header_type == PCI_HEADER_TYPE_NORMAL) ? 6 : 2;
> +
> + printf("ID BaseSizeWidth Type\n");
> +
> printf("--\n");
> +
> + bar_id = 0;
> + reg_addr = PCI_BASE_ADDRESS_0;
> + while (bar_cnt) {
> +#ifdef CONFIG_DM_PCI
> + dm_pci_read_config32(dev, reg_addr, &base_low);
> + dm_pci_write_config32(dev, reg_addr, 0x);
Suggest lower-case hex.
> + dm_pci_read_config32(dev, reg_addr, &size_low);
> + dm_pci_write_config32(dev, reg_addr, base_low);
> +#else
> + pci_read_config_dword(dev, reg_addr, &base_low);
> + pci_write_config_dword(dev, reg_addr, 0x);
> + pci_read_config_dword(dev, reg_addr, &size_low);
> + pci_write_config_dword(dev, reg_addr, base_low);
> +#endif
> + reg_addr += 4;
> +
> + base = base_low & ~0xF;
> + size = size_low & ~0xF;
> + base_high = 0x0;
> + size_high = 0x;
> + is_64 = 0;
> + prefetchable = base_low & PCI_BASE_ADDRESS_MEM_PREFETCH;
> + is_io = base_low & PCI_BASE_ADDRESS_SPACE_IO;
> + mem_type = base_low & PCI_BASE_ADDRESS_MEM_TYPE_MASK;
> +
> + if (mem_type == PCI_BASE_ADDRESS_MEM_TYPE_64) {
> +#ifdef CONFIG_DM_PCI
> + dm_pci_read_config32(dev, reg_addr, &base_high);
> + dm_pci_write_config32(dev, reg_addr, 0x);
> + dm_pci_read_config32(dev, reg_addr, &size_high);
> + dm_pci_write_config32(dev, reg_addr, base_high);
> +#else
> + pci_read_config_dword(dev, reg_addr, &base_high);
> + pci_write_config_dword(dev, reg_addr, 0x);
> + pci_read_config_dword(dev, reg_addr, &size_high);
> + pci_write_config_dword(dev, reg_addr, base_high);
> +#endif
> + bar_cnt--;
> + reg_addr += 4;
> + is_64 = 1;
> + }
> +
> + base = base | ((u64)base_high << 32);
> + size = size | ((u64)size_high << 32);
> +
> + if ((!is_64 && size_low) || (is_64 && size)) {
> + size = ~size + 1;
> + printf(" %d 0x%016llx 0x%016llx %d %s %s\n",
Can we drop the the address values? It is implied in U-Boot. If not,
let's use %#x.
> + bar_id, base, size, is_64 ? 64 : 32,
> + is_io ? "I/O" : "MEM",
> + prefetchable ? "Prefetchable" : "");
Check with sandbox, this gives a warning:
cmd/pci.c: In function ‘pci_bar_show’:
cmd/pci.c:175:11: warning: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 3 has type ‘u64’ [-Wformat=]
prefetchable ? "Prefetchable" : "");
^
cmd/pci.c:175:11: warning: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 4 has type ‘u64’ [-Wformat=]
> + }
> +
> + bar_id++;
> + bar_cnt--;
> + }
> +
> + return 0;
> +}
> +
> static struct pci_reg_info regs_start[] = {
> { "vendor ID", PCI_SIZE_16, PCI_VEN
Re: [U-Boot] [PATCH] api: Use hashtable function for API_env_enum
Hi,
On 5 November 2016 at 15:27, Emmanuel Vadot wrote:
>
> Since the env is an hashtable, use the hashtable function for the API_ENV_ENUM
> api call.
Can you please explain why in your commit message?
>
> Signed-off-by: Emmanuel Vadot
> ---
> api/api.c | 60 +++-
> 1 file changed, 31 insertions(+), 29 deletions(-)
>
> diff --git a/api/api.c b/api/api.c
> index 8a1433a..c368511 100644
> --- a/api/api.c
> +++ b/api/api.c
> @@ -495,45 +495,47 @@ static int API_env_set(va_list ap)
> */
> static int API_env_enum(va_list ap)
> {
> - int i, n;
> - char *last, **next;
> + int i, buflen;
> + char *last, **next, *s;
> + ENTRY *match, search;
> + static char *var;
>
> last = (char *)va_arg(ap, unsigned long);
>
> if ((next = (char **)va_arg(ap, uintptr_t)) == NULL)
> return API_EINVAL;
>
> - if (last == NULL)
> - /* start over */
> - *next = ((char *)env_get_addr(0));
> - else {
> - *next = last;
> -
> - for (i = 0; env_get_char(i) != '\0'; i = n + 1) {
> - for (n = i; env_get_char(n) != '\0'; ++n) {
> - if (n >= CONFIG_ENV_SIZE) {
> - /* XXX shouldn't we set *next =
> NULL?? */
> - return 0;
> - }
> - }
> -
> - if (envmatch((uchar *)last, i) < 0)
> - continue;
> -
> - /* try to get next name */
> - i = n + 1;
> - if (env_get_char(i) == '\0') {
> - /* no more left */
> - *next = NULL;
> - return 0;
> - }
> -
> - *next = ((char *)env_get_addr(i));
> - return 0;
> + if (last == NULL) {
> + var = NULL;
> + i = 0;
> + } else {
> + var = strdup(last);
Need to check for failure here.
> + s = strchr(var, '=');
> + if (s != NULL)
> + *s = 0;
> + search.key = var;
> + i = hsearch_r(search, FIND, &match, &env_htab, 0);
> + if (i == 0) {
> + i = API_EINVAL;
> + goto done;
> }
> }
>
> + /* match the next entry after i */
> + i = hmatch_r("", i, &match, &env_htab);
> + if (i == 0)
> + goto done;
> + buflen = strlen(match->key) + strlen(match->data) + 2;
> + var = realloc(var, buflen);
> + snprintf(var, buflen, "%s=%s", match->key, match->data);
> + *next = var;
> return 0;
> +
> +done:
> + free(var);
> + var = NULL;
> + *next = NULL;
> + return i;
> }
>
> /*
> --
> 2.9.2
>
Regards,
SImon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: evb-rk3399: enable PWM_ROCKCHIP
On 7 November 2016 at 01:30, Kever Yang wrote: > PWM_ROCKCHIP need to enable for PWM regulator, this config > is missing during rebase and new patch set in previous submission. > > Signed-off-by: Kever Yang > --- > > configs/evb-rk3399_defconfig | 1 + > 1 file changed, 1 insertion(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] evb-rk3399: deduced the dram node size when space reserved
On 7 November 2016 at 02:40, Andreas Färber wrote: > Am 07.11.2016 um 09:30 schrieb Kever Yang: >> The size dram node need to be deduced by the same amount of reserved space. >> >> > > Reported-by: Andreas Färber > >> Signed-off-by: Kever Yang > > Reviewed-by: Andreas Färber Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot overlaps BSS and initrd on arm64
On Tue, Nov 08, 2016 at 11:50:19PM +, Will Deacon wrote: > On Tue, Nov 08, 2016 at 02:47:30PM -0500, Tom Rini wrote: > > On Tue, Nov 08, 2016 at 07:34:34PM +, Will Deacon wrote: > > > On Tue, Nov 08, 2016 at 01:04:40PM -0500, Tom Rini wrote: > > > > On Tue, Nov 08, 2016 at 06:01:42PM +, Will Deacon wrote: > > > > > On Tue, Nov 08, 2016 at 12:51:44PM -0500, Tom Rini wrote: > > > > > > On Tue, Nov 08, 2016 at 09:41:13AM -0800, Dmitry Vyukov wrote: > > > > > > > Hello, > > > > > > > > > > > > > > We've got a boot problem on arm64 devices. Here is boot log: > > > > > > > https://storage.kernelci.org/mainline/v4.9-rc4/arm64-defconfig+CONFIG_KASAN=y/lab-baylibre-seattle/boot-juno-r2.txt > > > > > > > https://kernelci.org/boot/id/581ece5a59b514e448f03bd7/ > > > > > > > > > > > > > > Here is some debugging that Andrey and Mark did: > > > > > > > > > > > > > > On Tue, Nov 8, 2016 at 2:00 AM, Andrey Ryabinin wrote: > > > > > > > > I've looked at juno-r2: > > > > > > > > https://kernelci.org/boot/id/581ece5a59b514e448f03bd7/ > > > > > > > > So we have > > > > > > > > Dtb address 0x81f0 > > > > > > > > Load address 0x8000 > > > > > > > > Which gives us 31Mb for kernel. > > > > > > > > > > > > > > > > It says that Kernel image is 24.62 MiB, but that's without BSS. > > > > > > > > If bss is big enough it might overwrite dtb. > > > > > > > > And indeed, build details - > > > > > > > > https://kernelci.org/build/id/581e850959b514e564f03bdc/ > > > > > > > > shows that bss is 8.5 Mb which is enough to overlap with dtb. > > > > > > > > > > > > > > On Tue, Nov 8, 2016 at 3:21 AM, Mark Rutland wrote: > > > > > > > > FWIW, since v3.17 we've had an image_size field in the arm64 > > > > > > > > Image > > > > > > > > header which describes the "real" size of the Image, BSS > > > > > > > > included. See > > > > > > > > [1,2]. > > > > > > > > It should be possible to modify U-Boot to use that to > > > > > > > > automatically > > > > > > > > place the DTB and initrd at non-clashing locations (or at least > > > > > > > > to > > > > > > > > expose the value somehow). > > > > > > > > I had assumed U-Boot already did that, but it doesn't seem to > > > > > > > > be the > > > > > > > > case. > > > > > > > > > > > > Yes, we've supported the image_size field since v2016.07 and that > > > > > > board > > > > > > is running v2016.01. Unfortunately the booting.txt changes that > > > > > > added > > > > > > the image_size field weren't publicized widely so we didn't see it > > > > > > until > > > > > > someone else ran into the problem you're describing. > > > > > > > > > > Hmm, that's a good point. If you like, I could add something to that > > > > > file > > > > > asking for all changes to CC the u-boot list? We should probably do > > > > > the > > > > > same for edk2. > > > > > > > > That would be nice, sure. I was even thinking that something like the > > > > cross-distro or boot-architecture lists that linaro runs would have had > > > > this info go by as well. Thanks! > > > > > > D'oh, the u-boot list seems to be subscriber-only, so I'm not going to > > > make > > > a whole lot of friends if I ask kernel devs to add it to cc. > > > > Ah yes. So boot-architecture is probably best. > > This list: https://lists.linaro.org/pipermail/boot-architecture/ ? > > I was about to point out that there have only been 11 posts there in the last > four months, but then I saw the "2015" part :/ Yeah, it's not a highly active list. It feels like it's the appropriate list for such things, but, eh. We did almost right last time, I just didn't follow up and looking at when changes went mainline. -- 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 0/4] config: Add FreeBSD kconfig options
On Mon, Nov 07, 2016 at 09:34:27AM +0100, Emmanuel Vadot wrote: > This series of patches add the needed bits for booting the FreeBSD > loader. > FreeBSD loader needs the U-Boot API and dache disabled for it to run so > add kconfig options for them. > Also add some some boot command that locate and run the FreeBSD loader > if found. > > Emmanuel Vadot (4): > kconfig: Add API kconfig file > kconfig: arm: Add SYS_DCACHE_OFF option > kconfig: Add a FREEBSD option > distro_bootcmd: Add command to run FreeBSD > > Kconfig | 2 ++ > api/Kconfig | 9 + > arch/arm/Kconfig| 6 ++ > common/Kconfig | 9 + > include/config_distro_bootcmd.h | 32 This is a good first start. But I think there's a few things that need tweaking. First, we don't want to globally turn off dcache, but it does need to be migrated to Kconfig (so we know if it's enabled or not). Second, we should instead use CMD_CACHE and the 'dcache' command to disable dcache prior to running the FreeBSD loader. Then we make sure that the generic distro feature has CMD_CACHE if !SYS_DCACHE_OFF (and !SYS_ICACHE_OFF). 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 v3 5/5] ARMv8: LS1043A: Enable LS1043A default PSCI support
On Mon, Nov 07, 2016 at 12:13:54PM +0800, macro.wav...@gmail.com wrote: > From: Hongbo Zhang > > A most basic PSCI implementation with only one psci_version is added for > LS1043A, this can verify the generic PSCI framework, and more platform > specific > implementation will be added later. > > Signed-off-by: Hongbo Zhang Reviewed-by: Tom Rini -- 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 v3 4/5] ARMv8: Setup PSCI memory and device tree
On Mon, Nov 07, 2016 at 12:13:53PM +0800, macro.wav...@gmail.com wrote: > From: Hongbo Zhang > > The newly added ARMv8 PSCI needs to be initialized, be copied or reserved in > right place, this patch does all the setup steps. > > Signed-off-by: Hongbo Zhang Reviewed-by: Tom Rini -- 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 v3 3/5] ARMv8: Add basic PSCI framework
On Mon, Nov 07, 2016 at 12:13:52PM +0800, macro.wav...@gmail.com wrote: > From: Hongbo Zhang > > This patch introduces a generic ARMv8 PSCI framework, with all functions > returning a dummy ARM_PSCI_RET_NI (Not Implemented), then it is up to each > platform to implement their own functions based on this framework. > > Signed-off-by: Hongbo Zhang Reviewed-by: Tom Rini -- 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] board: am335x/mux: Do not hang when encountering a bad EEPROM
On Tue, Nov 08, 2016 at 08:48:44PM -0800, Alexandru Gagniuc wrote: > In most cases, the SPL and u-boot.img will be on the same boot media. > Since the SPL was loaded by the boot rom, the pinmux will already have > been configured for this media. This, the board will still be able to > boot successfully, or at least reach the u-boot console, where more > recovery options are available. > > I've encountered this on a beaglebone black with a corrupted EEPROM. > Removing this check allowed the board to boot successfully. I've also > seen this on EVM-based boards with an unprogrammed EEPROM. On those > boards, for some reason there were no UART messages. This made it look > as if the SOC was dead. > > Remove the hang(), as it is not a fatal error. Also reformat the error > message to be clearer as to the cause. The original message made it > appear as if the wrong binary was being loaded. > > Signed-off-by: Alexandru Gagniuc Reviewed-by: Tom Rini -- 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 1/2] ARM: zynq: Remove DTC 1.2 warnings
On Fri, Nov 11, 2016 at 01:26:05PM +0100, Michal Simek wrote: > DTC 1.2 reports these warnings: > Warning (unit_address_vs_reg): Node /memory has a reg or ranges > property, but no unit name > Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property, > but no unit name > Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name, > but no reg property > > This patch is fixing them. > > Signed-off-by: Michal Simek Have you addressed these in Linux as well? -- 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 v3 2/2] spi: ti_qspi: Fix baudrate divider calculation
On Sat, Nov 5, 2016 at 4:05 PM, Vignesh R wrote: > Fix the divider calculation logic to choose a value so that the > resulting baudrate is either equal to or closest possible baudrate less > than the requested value. While at that, cleanup ti_spi_set_speed(). > > Signed-off-by: Vignesh R Applied to u-boot-spi/master 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] [PATCH v3 1/2] ARM: dts: dra7xx: Update spi-max-frequency for qspi slave node
On Sat, Nov 5, 2016 at 4:05 PM, Vignesh R wrote: > Update the spi-max-frequency property of m25p80 flash slave to match > that of TI QSPI controller node, so that QSPI operations happen at > maximum supported frequency of 76.8MHz. > > Signed-off-by: Vignesh R > Reviewed-by: Jagan Teki Applied to u-boot-spi/master 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] [PATCH v8 0/3] armv8: Support loading 32-bit OS in AArch32 execution state
Hi Alison, On 10 November 2016 at 02:49, Alison Wang wrote: > This series is to support loading a 32-bit OS, the execution state will > change from AArch64 to AArch32 when jumping to kernel. The architecture > information will be got through checking FIT image, then U-Boot will load > 32-bit OS or 64-bit OS automatically. > > Spin-table method is used for secondary cores to load 32-bit OS. > The architecture information will be got through checking FIT image and saved > in the os_arch element of spin-table, then the secondary cores will check > os_arch and jump to 32-bit OS or 64-bit OS automatically. > > PSCI method can also be used for secondary cores to load 32-bit OS. > As PSCI and secure monitor firmware framework are enabled, loading 32-bit OS > is supported in such case. The default target exception level returned to > U-Boot is EL2, so the corresponding work to switch to AArch32 EL2 and jump to > 32-bit OS are done in U-Boot and secure firmware together. > > --- > Changes in v8: > - Fix the issue when U-Boot is running in EL2 or EL1. Thanks for sticking with this. Great news: it works for my setup. I tested booting an arm64 kernel on FVP Foundation and AEMv8 modes and on Juno R0, R1 and R2. I also tested and Versatile Express TC2 can still load it's Aarch32 kernel. I didn't test running an Aarch32 kernel or any of the new functionality on my ARMv8 platforms. But I checked and the patches are bisect-able on my ARMv8 platforms. Tested-by: Ryan Harkin > - Support loading 32-bit OS with PSCI enabled. > > Changes in v7: > - Move the call for armv8_switch_to_el2_m into the first patch. > > Changes in v6: > - Modified armv8_switch_to_el1(). It will always jump to ep when switching to > AArch64 or AArch32 modes. > - Make other platforms compatible with the new armv8_switch_to_el2() and > armv8_switch_to_el1(). > - Make secondary_switch_to_el1() always jump to ep when switching to AArch64 > or AArch32 modes. > > Changes in v5: > - Modified armv8_switch_to_el2(). It will always jump to ep when switching to > AArch64 or AArch32 modes. > - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 > or AArch32 modes. > > Changes in v4: > - Correct config ARM64_SUPPORT_AARCH32. > - Omit arch and ftaddr arguments. > - Rename "xreg5" to "tmp". > - Use xxx_RES1 to combine all RES1 fields in xxx register. > - Use an immediate cmp directly. > - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32. > > Changes in v3: > - Comments the functions and the arguments. > - Rename the real parameters. > - Use the macros instead of the magic values. > - Remove the redundant codes. > - Clean up all of the mess in boot_jump_linux(). > - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't > support AArch32 state. > - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m. > > Changes in v2: > - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used > to switch to AArch64 EL2 or AArch32 Hyp. > - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used > to switch to AArch64 EL1 or AArch32 SVC. > - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m. > > > Alison Wang (3): > armv8: Support loading 32-bit OS in AArch32 execution state > armv8: fsl-layerscape: SMP support for loading 32-bit OS > armv8: fsl-layerscape: Support loading 32-bit OS with PSCI enabled > > arch/arm/Kconfig | 6 > arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 61 > +-- > arch/arm/cpu/armv8/fsl-layerscape/mp.c| 10 ++ > arch/arm/cpu/armv8/sec_firmware_asm.S | 23 > arch/arm/cpu/armv8/start.S| 8 + > arch/arm/cpu/armv8/transition.S | 35 ++ > arch/arm/include/asm/arch-fsl-layerscape/mp.h | 6 > arch/arm/include/asm/macro.h | 176 > -- > arch/arm/include/asm/system.h | 121 > -- > arch/arm/lib/bootm.c | 45 --- > arch/arm/mach-rmobile/lowlevel_init_gen3.S| 9 - > common/image-fit.c| 19 +- > 12 files changed, 451 insertions(+), 68 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 27/27] ARM64: zynqmp: Adding prefetchable memory space to pcie
From: Bharat Kumar Gogada Adding prefetchable memory space to pcie device tree node. Shifting configuration space to 64-bit address space. Removing pcie device tree node from amba as it requires size-cells=<2> in order to access 64-bit address space. Signed-off-by: Bharat Kumar Gogada Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 5b4fe0962e05..ab5c243c61d3 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -665,9 +665,10 @@ msi-parent = <&pcie>; reg = <0x0 0xfd0e 0x0 0x1000>, <0x0 0xfd48 0x0 0x1000>, - <0x0 0xe000 0x0 0x100>; + <0x80 0x 0x0 0x100>; reg-names = "breg", "pcireg", "cfg"; - ranges = <0x0200 0x 0xe100 0x 0xe100 0 0x0f00>; + ranges = <0x0200 0x 0xe000 0x 0xe000 0x 0x1000 /* non-prefetchable memory */ + 0x4300 0x0006 0x 0x0006 0x 0x0002 0x>;/* prefetchable memory */ interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>, <0x0 0x0 0x0 0x2 &pcie_intc 0x2>, -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 26/27] ARM64: zynqmp: Add clocks for LPDDMA
From: Kedareswara rao Appana
Zynqmp DMA driver expects two clocks (main clock and apb clock)
For LPDDMA channels the two clocks are missing in the
Dma node resulting probe failure.
xilinx-zynqmp-dma ffa8.dma: main clock not found.
xilinx-zynqmp-dma ffa8.dma: Probing channel failed
xilinx-zynqmp-dma: probe of ffa8.dma failed with error -2
This patch fixes this issue.
Signed-off-by: Kedareswara rao Appana
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index aeeccbf9e9d0..5b4fe0962e05 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -428,6 +428,7 @@
lpd_dma_chan1: dma@ffa8 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffa8 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 77 4>;
@@ -440,6 +441,7 @@
lpd_dma_chan2: dma@ffa9 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffa9 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 78 4>;
@@ -452,6 +454,7 @@
lpd_dma_chan3: dma@ffaa {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffaa 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 79 4>;
@@ -464,6 +467,7 @@
lpd_dma_chan4: dma@ffab {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffab 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 80 4>;
@@ -476,6 +480,7 @@
lpd_dma_chan5: dma@ffac {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffac 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 81 4>;
@@ -488,6 +493,7 @@
lpd_dma_chan6: dma@ffad {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffad 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 82 4>;
@@ -500,6 +506,7 @@
lpd_dma_chan7: dma@ffae {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffae 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 83 4>;
@@ -512,6 +519,7 @@
lpd_dma_chan8: dma@ffaf {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
+ clock-names = "clk_main", "clk_apb";
reg = <0x0 0xffaf 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 84 4>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 25/27] ARM64: zynqmp: Add description for LPDDMA channel usage
From: Kedareswara rao Appana
LPDDMA default allows only secured access.
inorder to enable these dma channels,
one should ensure that it allows non secure access.
This patch updates the same.
Reported-by: Sai Pavan Boddu
Signed-off-by: Kedareswara rao Appana
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index f67238e89725..aeeccbf9e9d0 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -421,7 +421,10 @@
power-domains = <&pd_gpu>;
};
- /* ADMA */
+ /* LPDDMA default allows only secured access. inorder to enable
+* These dma channels, Users should ensure that these dma
+* Channels are allowed for non secure access.
+*/
lpd_dma_chan1: dma@ffa8 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 24/27] ARM64: zynqmp: Use 64bit size cell format for main amba bus
Use 64bit size cell for main amba bus instead of 32bit because PCIe
node requires it Change 64bit sizes also for all others IPs.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 130 +++
1 file changed, 65 insertions(+), 65 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 49791d34df32..f67238e89725 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -256,18 +256,18 @@
};
};
- amba: amba@0 {
+ amba: amba {
compatible = "simple-bus";
u-boot,dm-pre-reloc;
#address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0 0 0 0x>;
+ #size-cells = <2>;
+ ranges;
can0: can@ff06 {
compatible = "xlnx,zynq-can-1.0";
status = "disabled";
clock-names = "can_clk", "pclk";
- reg = <0x0 0xff06 0x1000>;
+ reg = <0x0 0xff06 0x0 0x1000>;
interrupts = <0 23 4>;
interrupt-parent = <&gic>;
tx-fifo-depth = <0x40>;
@@ -279,7 +279,7 @@
compatible = "xlnx,zynq-can-1.0";
status = "disabled";
clock-names = "can_clk", "pclk";
- reg = <0x0 0xff07 0x1000>;
+ reg = <0x0 0xff07 0x0 0x1000>;
interrupts = <0 24 4>;
interrupt-parent = <&gic>;
tx-fifo-depth = <0x40>;
@@ -289,7 +289,7 @@
cci: cci@fd6e {
compatible = "arm,cci-400";
- reg = <0x0 0xfd6e 0x9000>;
+ reg = <0x0 0xfd6e 0x0 0x9000>;
ranges = <0x0 0x0 0xfd6e 0x1>;
#address-cells = <1>;
#size-cells = <1>;
@@ -310,7 +310,7 @@
fpd_dma_chan1: dma@fd50 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd50 0x1000>;
+ reg = <0x0 0xfd50 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 124 4>;
clock-names = "clk_main", "clk_apb";
@@ -323,7 +323,7 @@
fpd_dma_chan2: dma@fd51 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd51 0x1000>;
+ reg = <0x0 0xfd51 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 125 4>;
clock-names = "clk_main", "clk_apb";
@@ -336,7 +336,7 @@
fpd_dma_chan3: dma@fd52 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd52 0x1000>;
+ reg = <0x0 0xfd52 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 126 4>;
clock-names = "clk_main", "clk_apb";
@@ -349,7 +349,7 @@
fpd_dma_chan4: dma@fd53 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd53 0x1000>;
+ reg = <0x0 0xfd53 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 127 4>;
clock-names = "clk_main", "clk_apb";
@@ -362,7 +362,7 @@
fpd_dma_chan5: dma@fd54 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd54 0x1000>;
+ reg = <0x0 0xfd54 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 128 4>;
clock-names = "clk_main", "clk_apb";
@@ -375,7 +375,7 @@
fpd_dma_chan6: dma@fd55 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd55 0x1000>;
+ reg = <0x0 0xfd55 0x0 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 129 4>;
clock-names = "clk_main", "clk_apb";
@@ -388,7 +388,7 @@
fpd_dma_chan7: dma@fd56 {
status = "disabled";
compatible = "xlnx,zynqmp-dma-1.0";
- reg = <0x0 0xfd56 0x1000>;
+
[U-Boot] [PATCH 23/27] ARM64: zynqmp: Add ocm node in dtsi
From: Naga Sureshkumar Relli
This patch adds ocm controller node in zynqmp.dtsi.
needed for OCM edac support.
Signed-off-by: Naga Sureshkumar Relli
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index edfa03ac678f..49791d34df32 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -629,6 +629,13 @@
power-domains = <&pd_i2c1>;
};
+ ocm: memory-controller@ff96 {
+ compatible = "xlnx,zynqmp-ocmc-1.0";
+ reg = <0x0 0xff96 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 10 4>;
+ };
+
pcie: pcie@fd0e {
compatible = "xlnx,nwl-pcie-2.11";
status = "disabled";
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 21/27] Revert "ARM64: zynqmp: Added broken-tuning property to SD, eMMC nodes"
This reverts commit bd750e7a6c515c081b72d4ef108a2bfa691a3fd1 Implemented the new workaround for auto tuning based on zynqmp compatible string, so removed the 'broken-tuning' property. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 150472f1e1fb..b796c34449e4 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -705,7 +705,6 @@ interrupts = <0 48 4>; reg = <0x0 0xff16 0x1000>; clock-names = "clk_xin", "clk_ahb"; - broken-tuning; xlnx,device_id = <0>; #stream-id-cells = <1>; iommus = <&smmu 0x870>; @@ -720,7 +719,6 @@ interrupts = <0 49 4>; reg = <0x0 0xff17 0x1000>; clock-names = "clk_xin", "clk_ahb"; - broken-tuning; xlnx,device_id = <1>; #stream-id-cells = <1>; iommus = <&smmu 0x871>; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 22/27] ARM64: zynqmp: Add device tree properties for ZynqMP GT core
From: Anurag Kumar Vulisha
This patch adds the ZynqMP GT core device-tree properties for
zynqmp.dtsi file.
Signed-off-by: Anurag Kumar Vulisha
Tested-by: Hyun Kwon
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index b796c34449e4..edfa03ac678f 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -688,6 +688,29 @@
interrupt-names = "alarm", "sec";
};
+ serdes: zynqmp_phy@fd40 {
+ compatible = "xlnx,zynqmp-psgtr";
+ status = "disabled";
+ reg = <0x0 0xfd40 0x4>,
+ <0x0 0xfd3d 0x1000>,
+ <0x0 0xfd1a 0x1000>,
+ <0x0 0xff5e 0x1000>;
+ reg-names = "serdes", "siou", "fpd", "lpd";
+ xlnx,tx_termination_fix;
+ lane0: lane0 {
+ #phy-cells = <4>;
+ };
+ lane1: lane1 {
+ #phy-cells = <4>;
+ };
+ lane2: lane2 {
+ #phy-cells = <4>;
+ };
+ lane3: lane3 {
+ #phy-cells = <4>;
+ };
+ };
+
sata: ahci@fd0c {
compatible = "ceva,ahci-1v84";
status = "disabled";
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 20/27] ARM64: zynqmp: change sdhci compatible string.
From: Sai Krishna Potthuri
This patch changes the compatible string for sdhci node,
adds "xlnx,device_id" and "xlnx,mio_bank" property to sdhci node.
Signed-off-by: Sai Krishna Potthuri
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-ep108.dts| 2 ++
arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 2 ++
arch/arm/dts/zynqmp-zcu102.dts | 1 +
arch/arm/dts/zynqmp.dtsi | 6 --
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-ep108.dts b/arch/arm/dts/zynqmp-ep108.dts
index db502cf83bad..2483180d38f6 100644
--- a/arch/arm/dts/zynqmp-ep108.dts
+++ b/arch/arm/dts/zynqmp-ep108.dts
@@ -154,10 +154,12 @@
&sdhci0 {
status = "okay";
bus-width = <8>;
+ xlnx,mio_bank = <2>;
};
&sdhci1 {
status = "okay";
+ xlnx,mio_bank = <1>;
};
&spi0 {
diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
index f3bca60c7e8d..b3f42977ab3c 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
@@ -159,12 +159,14 @@
&sdhci0 {
status = "okay";
bus-width = <8>;
+ xlnx,mio_bank = <0>;
};
/* SD1 with level shifter */
&sdhci1 {
status = "okay";
no-1-8-v; /* for 1.0 silicon */
+ xlnx,mio_bank = <1>;
};
&uart0 {
diff --git a/arch/arm/dts/zynqmp-zcu102.dts b/arch/arm/dts/zynqmp-zcu102.dts
index 7715aea5bfbc..0e9150e6b1cb 100644
--- a/arch/arm/dts/zynqmp-zcu102.dts
+++ b/arch/arm/dts/zynqmp-zcu102.dts
@@ -605,6 +605,7 @@
drivers/hwmon/pmbus/Makefile:11:obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
&sdhci1 {
status = "okay";
no-1-8-v; /* for 1.0 silicon */
+ xlnx,mio_bank = <1>;
};
&uart0 {
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 618378fa3d59..150472f1e1fb 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -699,13 +699,14 @@
sdhci0: sdhci@ff16 {
u-boot,dm-pre-reloc;
- compatible = "arasan,sdhci-8.9a";
+ compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 48 4>;
reg = <0x0 0xff16 0x1000>;
clock-names = "clk_xin", "clk_ahb";
broken-tuning;
+ xlnx,device_id = <0>;
#stream-id-cells = <1>;
iommus = <&smmu 0x870>;
power-domains = <&pd_sd0>;
@@ -713,13 +714,14 @@
sdhci1: sdhci@ff17 {
u-boot,dm-pre-reloc;
- compatible = "arasan,sdhci-8.9a";
+ compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 49 4>;
reg = <0x0 0xff17 0x1000>;
clock-names = "clk_xin", "clk_ahb";
broken-tuning;
+ xlnx,device_id = <1>;
#stream-id-cells = <1>;
iommus = <&smmu 0x871>;
power-domains = <&pd_sd1>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 18/27] ARM64: zynqmp: Add support for zynqmp fpga manager
From: Nava kishore Manne
Add support for zynqmp fpga manager.
Signed-off-by: Nava kishore Manne
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 22526268bb4f..2b84bfbd6369 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -233,6 +233,10 @@
compatible = "arm,cortex-a53-edac";
};
+ pcap {
+ compatible = "xlnx,zynqmp-pcap-fpga";
+ };
+
amba_apu: amba_apu@0 {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 19/27] ARM64: zynqmp: List all SMMU ids
Add SMMU description for all tested IPs. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 73 +++- 1 file changed, 72 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 2b84bfbd6369..618378fa3d59 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -315,6 +315,8 @@ interrupts = <0 124 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14e8>; power-domains = <&pd_gdma>; }; @@ -326,6 +328,8 @@ interrupts = <0 125 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14e9>; power-domains = <&pd_gdma>; }; @@ -337,6 +341,8 @@ interrupts = <0 126 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14ea>; power-domains = <&pd_gdma>; }; @@ -348,6 +354,8 @@ interrupts = <0 127 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14eb>; power-domains = <&pd_gdma>; }; @@ -359,6 +367,8 @@ interrupts = <0 128 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14ec>; power-domains = <&pd_gdma>; }; @@ -370,6 +380,8 @@ interrupts = <0 129 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14ed>; power-domains = <&pd_gdma>; }; @@ -381,6 +393,8 @@ interrupts = <0 130 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14ee>; power-domains = <&pd_gdma>; }; @@ -392,6 +406,8 @@ interrupts = <0 131 4>; clock-names = "clk_main", "clk_apb"; xlnx,bus-width = <128>; + #stream-id-cells = <1>; + iommus = <&smmu 0x14ef>; power-domains = <&pd_gdma>; }; @@ -413,6 +429,8 @@ interrupt-parent = <&gic>; interrupts = <0 77 4>; xlnx,bus-width = <64>; + #stream-id-cells = <1>; + iommus = <&smmu 0x868>; power-domains = <&pd_adma>; }; @@ -423,6 +441,8 @@ interrupt-parent = <&gic>; interrupts = <0 78 4>; xlnx,bus-width = <64>; + #stream-id-cells = <1>; + iommus = <&smmu 0x869>; power-domains = <&pd_adma>; }; @@ -433,6 +453,8 @@ interrupt-parent = <&gic>; interrupts = <0 79 4>; xlnx,bus-width = <64>; + #stream-id-cells = <1>; + iommus = <&smmu 0x86a>; power-domains = <&pd_adma>; }; @@ -443,6 +465,8 @@ interrupt-parent = <&gic>; interrupts = <0 80 4>; xlnx,bus-width = <64>; + #stream-id-cells = <1>; + iommus = <&smmu 0x86b>; power-domains = <&pd_adma>; }; @@ -453,6 +477,8 @@ interrupt-parent = <&gic>; interrupts = <0 81 4>; xlnx,bus-width = <64>; + #stream-id-cells = <1>; + iommus = <&smmu 0x86c>; power-domains = <&pd_adma>; }; @@ -463,6 +489,8 @@ interrupt-parent = <&gic>; interrupts = <0 82 4>; xlnx,bus-width = <64>; +
[U-Boot] [PATCH 17/27] ARM64: zynqmp: Add cortexa53 edac node
From: Naga Sureshkumar Relli
This patch adds edac node for arm cortexa53 to report
errors on L1 and L2 caches.
Signed-off-by: Naga Sureshkumar Relli
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index c2f8fc7b70d9..22526268bb4f 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -229,6 +229,10 @@
<1 10 0xf01>;
};
+ edac {
+ compatible = "arm,cortex-a53-edac";
+ };
+
amba_apu: amba_apu@0 {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 16/27] Revert "ARM64: zynqmp: Add serdes address space dp driver"
This reverts commit 786db82bd5bf09cc8f78c8b14445e843d7566b1c.
Since we are using serdes driver , no need of mapping serdes register
space into DP driver.
Signed-off-by: Anurag Kumar Vulisha
Tested-by: Hyun Kwon
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index fc75a40baa70..c2f8fc7b70d9 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -850,8 +850,7 @@
xlnx_dp: dp@fd4a {
compatible = "xlnx,v-dp";
status = "disabled";
- reg = <0x0 0xfd4a 0x1000>,
- <0x0 0xfd40 0x2>;
+ reg = <0x0 0xfd4a 0x1000>;
interrupts = <0 119 4>;
interrupt-parent = <&gic>;
clock-names = "aclk", "aud_clk";
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/27] ARM64: zynqmp: Remove xlnx,id property
Remove unused xlnx,id property because it is not the part of DT binding. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 16 1 file changed, 16 deletions(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 8abaf1fbb319..64438167fbec 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -306,7 +306,6 @@ interrupt-parent = <&gic>; interrupts = <0 124 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <0>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -318,7 +317,6 @@ interrupt-parent = <&gic>; interrupts = <0 125 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <1>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -330,7 +328,6 @@ interrupt-parent = <&gic>; interrupts = <0 126 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <2>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -342,7 +339,6 @@ interrupt-parent = <&gic>; interrupts = <0 127 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <3>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -354,7 +350,6 @@ interrupt-parent = <&gic>; interrupts = <0 128 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <4>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -366,7 +361,6 @@ interrupt-parent = <&gic>; interrupts = <0 129 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <5>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -378,7 +372,6 @@ interrupt-parent = <&gic>; interrupts = <0 130 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <6>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -390,7 +383,6 @@ interrupt-parent = <&gic>; interrupts = <0 131 4>; clock-names = "clk_main", "clk_apb"; - xlnx,id = <7>; xlnx,bus-width = <128>; power-domains = <&pd_gdma>; }; @@ -412,7 +404,6 @@ reg = <0x0 0xffa8 0x1000>; interrupt-parent = <&gic>; interrupts = <0 77 4>; - xlnx,id = <0>; xlnx,bus-width = <64>; power-domains = <&pd_adma>; }; @@ -423,7 +414,6 @@ reg = <0x0 0xffa9 0x1000>; interrupt-parent = <&gic>; interrupts = <0 78 4>; - xlnx,id = <1>; xlnx,bus-width = <64>; power-domains = <&pd_adma>; }; @@ -434,7 +424,6 @@ reg = <0x0 0xffaa 0x1000>; interrupt-parent = <&gic>; interrupts = <0 79 4>; - xlnx,id = <2>; xlnx,bus-width = <64>; power-domains = <&pd_adma>; }; @@ -445,7 +434,6 @@ reg = <0x0 0xffab 0x1000>; interrupt-parent = <&gic>; interrupts = <0 80 4>; - xlnx,id = <3>; xlnx,bus-width = <64>; power-domains = <&pd_adma>; }; @@ -456,7 +444,6 @@ reg = <0x0 0xffac 0x1000>; interrupt-parent = <&gic>; interrupts = <0 81 4>; - xlnx,id = <4>; xlnx,bus-width = <64>; power-domains = <&pd_adma>; }; @@ -467,7 +454,6 @@ reg = <0x0 0xffad 0x1000>; interrupt-parent = <&gic>; interrupts = <0 82 4>; - xlnx,id = <5>; xlnx,bus-width = <64>; power
[U-Boot] [PATCH 15/27] ARM64: zynqmp: drm: Add DMA index
From: Hyun Kwon
Each plane can be associated with multiple DMA channels. So add
index for each DMA channel.
Signed-off-by: Hyun Kwon
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index ff18596eda06..fc75a40baa70 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -836,11 +836,13 @@
xlnx,pixel-format = "rgb565";
plane0 {
dmas = <&xlnx_dpdma 3>;
- dma-names = "dma";
+ dma-names = "dma0";
};
plane1 {
- dmas = <&xlnx_dpdma 0>;
- dma-names = "dma";
+ dmas = <&xlnx_dpdma 0>,
+ <&xlnx_dpdma 1>,
+ <&xlnx_dpdma 2>;
+ dma-names = "dma0", "dma1", "dma2";
};
};
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/27] ARM64: zynqmp: pci: Updating device tree as per upstream
From: Bharat Kumar Gogada Updating required device tree changes as per mainlined driver from 4.6 kernel. Signed-off-by: Bharat Kumar Gogada Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 172ba8cfcf00..8abaf1fbb319 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -605,13 +605,16 @@ #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; + msi-controller; device_type = "pci"; interrupt-parent = <&gic>; interrupts = <0 118 4>, +<0 117 4>, <0 116 4>, <0 115 4>, /* MSI_1 [63...32] */ <0 114 4>; /* MSI_0 [31...0] */ - interrupt-names = "misc", "intx", "msi_1", "msi_0"; + interrupt-names = "misc","dummy","intx", "msi1", "msi0"; + msi-parent = <&pcie>; reg = <0x0 0xfd0e 0x1000>, <0x0 0xfd48 0x1000>, <0x0 0xe000 0x100>; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/27] ARM64: zynqmp: Sync gpio node properties
Keep dtsi in sync with mainline kernel. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 64438167fbec..ff18596eda06 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -553,10 +553,10 @@ compatible = "xlnx,zynqmp-gpio-1.0"; status = "disabled"; #gpio-cells = <0x2>; - #interrupt-cells = <2>; - interrupt-controller; interrupt-parent = <&gic>; interrupts = <0 16 4>; + interrupt-controller; + #interrupt-cells = <2>; reg = <0x0 0xff0a 0x1000>; power-domains = <&pd_gpio>; }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/27] ARM64: zynqmp: Support for multiple PM IDs assigned to a PM domain
From: Filip Drazic
Previously, it was assumed that there is a 1:1 mapping between
PM ID defined in the platform firmware and a PM domain. However, there
can be a situation where multiple PM IDs belong to a single PM domain
(e.g. PM IDs for GPU and two pixel processors correspond to a single
PM domain).
This patch adds support for assigning more than one PM ID to
a single PM domain.
Updated documentation accordingly.
Assigned pixel processors PM IDs to GPU PM domain.
Signed-off-by: Filip Drazic
Signed-off-by: Soren Brinkmann
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index c2eb0c5d4e96..172ba8cfcf00 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -197,7 +197,7 @@
pd_gpu: pd-gpu {
#power-domain-cells = <0x0>;
- pd-id = <0x3a>;
+ pd-id = <0x3a 0x14 0x15>;
};
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/27] ARM64: zynqmp: DT: Add PM domains for GPU and PCIE
From: Filip Drazic
Signed-off-by: Filip Drazic
Signed-off-by: Soren Brinkmann
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 6df8ee9fd1d3..c2eb0c5d4e96 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -189,6 +189,16 @@
#power-domain-cells = <0x0>;
pd-id = <0x30>;
};
+
+ pd_pcie: pd-pcie {
+ #power-domain-cells = <0x0>;
+ pd-id = <0x3b>;
+ };
+
+ pd_gpu: pd-gpu {
+ #power-domain-cells = <0x0>;
+ pd-id = <0x3a>;
+ };
};
pmu {
@@ -392,6 +402,7 @@
interrupt-parent = <&gic>;
interrupts = <0 132 4>, <0 132 4>, <0 132 4>, <0 132
4>, <0 132 4>, <0 132 4>;
interrupt-names = "IRQGP", "IRQGPMMU", "IRQPP0",
"IRQPPMMU0", "IRQPP1", "IRQPPMMU1";
+ power-domains = <&pd_gpu>;
};
/* ADMA */
@@ -611,6 +622,7 @@
<0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
<0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
<0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+ power-domains = <&pd_pcie>;
pcie_intc: legacy-interrupt-controller {
interrupt-controller;
#address-cells = <0>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/27] ARM64: zynqmp: DT: Remove unused DDR PM domain
From: Filip Drazic
DDR power states are handled by the PM firmware, so this domain is
redundant. Also, since there is no device using this PM domain,
it will be powered off during boot, which is wrong.
Signed-off-by: Filip Drazic
Acked-by: Soren Brinkmann
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index f3f4f88cecfa..25d0edac4db9 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -190,11 +190,6 @@
pd-id = <0x30>;
};
- pd_ddr: pd-ddr {
- #power-domain-cells = <0x0>;
- pd-id = <0x37>;
- };
-
pd_apll: pd-apll {
#power-domain-cells = <0x0>;
pd-id = <0x32>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/27] ARM64: zynqmp: DT: Remove unused PM domains for PLL
From: Filip Drazic
Signed-off-by: Filip Drazic
Acked-by: Soren Brinkmann
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 25 -
1 file changed, 25 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 25d0edac4db9..6df8ee9fd1d3 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -189,31 +189,6 @@
#power-domain-cells = <0x0>;
pd-id = <0x30>;
};
-
- pd_apll: pd-apll {
- #power-domain-cells = <0x0>;
- pd-id = <0x32>;
- };
-
- pd_vpll: pd-vpll {
- #power-domain-cells = <0x0>;
- pd-id = <0x33>;
- };
-
- pd_dpll: pd-dpll {
- #power-domain-cells = <0x0>;
- pd-id = <0x34>;
- };
-
- pd_rpll: pd-rpll {
- #power-domain-cells = <0x0>;
- pd-id = <0x35>;
- };
-
- pd_iopll: pd-iopll {
- #power-domain-cells = <0x0>;
- pd-id = <0x36>;
- };
};
pmu {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/27] ARM64: zynqmp: Add dcc port to dtsi
Add dcc to dtsi for supporting system without serial port.
DCC is enabled by default on ZynqMP.
Adding dcc to zcu100 and zcu102 which were tested.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu102.dts | 5 +
arch/arm/dts/zynqmp.dtsi | 6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/dts/zynqmp-zcu102.dts b/arch/arm/dts/zynqmp-zcu102.dts
index 770d98766c73..e7496da23592 100644
--- a/arch/arm/dts/zynqmp-zcu102.dts
+++ b/arch/arm/dts/zynqmp-zcu102.dts
@@ -27,6 +27,7 @@
rtc0 = &rtc;
serial0 = &uart0;
serial1 = &uart1;
+ serial2 = &dcc;
spi0 = &qspi;
usb0 = &usb0;
};
@@ -69,6 +70,10 @@
status = "okay";
};
+&dcc {
+ status = "okay";
+};
+
/* fpd_dma clk 667MHz, lpd_dma 500MHz */
&fpd_dma_chan1 {
status = "okay";
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index ac17c4723a13..f3f4f88cecfa 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -45,6 +45,12 @@
};
};
+ dcc: dcc {
+ compatible = "arm,dcc";
+ status = "disabled";
+ u-boot,dm-pre-reloc;
+ };
+
power-domains {
compatible = "xlnx,zynqmp-genpd";
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/27] ARM64: zynqmp: Remove note about level shifter on zcu102
i2c device is just level shifter. Remove reference from dts. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp-zcu102.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/zynqmp-zcu102.dts b/arch/arm/dts/zynqmp-zcu102.dts index e7496da23592..7715aea5bfbc 100644 --- a/arch/arm/dts/zynqmp-zcu102.dts +++ b/arch/arm/dts/zynqmp-zcu102.dts @@ -394,7 +394,7 @@ drivers/hwmon/pmbus/Makefile:11:obj-$(CONFIG_SENSORS_MAX20751) += max20751.o /* Bus 3 is not connected */ }; - /* FIXME PL connection - u55 , PMOD - j160 */ + /* FIXME PMOD - j160 */ /* FIXME MSP430F - u41 - not detected */ }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/27] ARM64: zynqmp: Enable gpio-led as heartbeat on zcu102
Show user that Linux is alive on the board.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu102.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/zynqmp-zcu102.dts b/arch/arm/dts/zynqmp-zcu102.dts
index b3f5eaacaefc..d6cee07890c5 100644
--- a/arch/arm/dts/zynqmp-zcu102.dts
+++ b/arch/arm/dts/zynqmp-zcu102.dts
@@ -39,6 +39,15 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
+
+ leds {
+ compatible = "gpio-leds";
+ heartbeat_led {
+ label = "heartbeat";
+ gpios = <&gpio 23 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
};
&can1 {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/27] ARM64: zynqmp: Add gpio-keys for zcu102
There is gpio push button on MIO22. Add it to DTS to have full board
description.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu102.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/dts/zynqmp-zcu102.dts b/arch/arm/dts/zynqmp-zcu102.dts
index d6cee07890c5..770d98766c73 100644
--- a/arch/arm/dts/zynqmp-zcu102.dts
+++ b/arch/arm/dts/zynqmp-zcu102.dts
@@ -12,6 +12,7 @@
#include "zynqmp.dtsi"
#include "zynqmp-clk.dtsi"
+#include
/ {
model = "ZynqMP ZCU102 RevA";
@@ -40,6 +41,20 @@
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+ sw19 {
+ label = "sw19";
+ gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ linux,code = <108>; /* down */
+ gpio-key,wakeup;
+ autorepeat;
+ };
+ };
+
leds {
compatible = "gpio-leds";
heartbeat_led {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/27] ARM64: zynqmp: Enable can1 for ep108
From: Naga Sureshkumar Relli
This patch enables can1 for ep108.
Signed-off-by: Naga Sureshkumar Relli
Reviewed-by: Kedareswara rao Appana
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-ep108-clk.dtsi | 4
arch/arm/dts/zynqmp-ep108.dts | 4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/dts/zynqmp-ep108-clk.dtsi
b/arch/arm/dts/zynqmp-ep108-clk.dtsi
index 6b6dca60e86f..1c2efe459d4f 100644
--- a/arch/arm/dts/zynqmp-ep108-clk.dtsi
+++ b/arch/arm/dts/zynqmp-ep108-clk.dtsi
@@ -59,6 +59,10 @@
clocks = <&misc_clk &misc_clk>;
};
+&can1 {
+ clocks = <&misc_clk &misc_clk>;
+};
+
&fpd_dma_chan1 {
clocks = <&clk600>, <&clk100>;
};
diff --git a/arch/arm/dts/zynqmp-ep108.dts b/arch/arm/dts/zynqmp-ep108.dts
index 751717028b50..db502cf83bad 100644
--- a/arch/arm/dts/zynqmp-ep108.dts
+++ b/arch/arm/dts/zynqmp-ep108.dts
@@ -41,6 +41,10 @@
status = "okay";
};
+&can1 {
+ status = "okay";
+};
+
&gem0 {
status = "okay";
phy-handle = <&phy0>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/27] ARM64: zynqmp: Added clocks to DT for ep108
From: VNSL Durga
Added clks for ep108 platform.
Signed-off-by: VNSL Durga
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-ep108-clk.dtsi | 44 ++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/dts/zynqmp-ep108-clk.dtsi
b/arch/arm/dts/zynqmp-ep108-clk.dtsi
index b3ce0de549e0..6b6dca60e86f 100644
--- a/arch/arm/dts/zynqmp-ep108-clk.dtsi
+++ b/arch/arm/dts/zynqmp-ep108-clk.dtsi
@@ -35,6 +35,18 @@
clock-accuracy = <100>;
};
+ clk100: clk100 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ clk600: clk600 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <6>;
+ };
+
dp_aud_clk: clock1 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -47,6 +59,38 @@
clocks = <&misc_clk &misc_clk>;
};
+&fpd_dma_chan1 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan2 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan3 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan4 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan5 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan6 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan7 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&fpd_dma_chan8 {
+ clocks = <&clk600>, <&clk100>;
+};
+
&gem0 {
clocks = <&misc_clk>, <&misc_clk>, <&misc_clk>;
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/27] ARM64: zynqmp: Add clocks for LPDDMA
From: Kedareswara rao Appana
Zynqmp DMA driver expects two clocks (main clock and apb clock)
LPDDMA clock cofiguration is missing for the same in the
zynqmp-clk.dtsi file.
This patch updates for the same.
Reported-by: Sai Pavan Boddu
Signed-off-by: Kedareswara rao Appana
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-clk.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/dts/zynqmp-clk.dtsi b/arch/arm/dts/zynqmp-clk.dtsi
index 0918c686d70e..aa848c864637 100644
--- a/arch/arm/dts/zynqmp-clk.dtsi
+++ b/arch/arm/dts/zynqmp-clk.dtsi
@@ -114,6 +114,38 @@
clocks = <&clk600>, <&clk100>;
};
+&lpd_dma_chan1 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan2 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan3 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan4 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan5 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan6 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan7 {
+ clocks = <&clk600>, <&clk100>;
+};
+
+&lpd_dma_chan8 {
+ clocks = <&clk600>, <&clk100>;
+};
+
&nand0 {
clocks = <&clk100 &clk100>;
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: zynq: Remove DTC 1.2 warnings
DTC 1.2 reports these warnings:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name,
but no reg property
This patch is fixing them.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynq-7000.dtsi | 7 ---
arch/arm/dts/zynq-microzed.dts| 2 +-
arch/arm/dts/zynq-picozed.dts | 2 +-
arch/arm/dts/zynq-topic-miami.dts | 2 +-
arch/arm/dts/zynq-zc702.dts | 2 +-
arch/arm/dts/zynq-zc706.dts | 2 +-
arch/arm/dts/zynq-zc770-xm010.dts | 2 +-
arch/arm/dts/zynq-zc770-xm011.dts | 2 +-
arch/arm/dts/zynq-zc770-xm012.dts | 2 +-
arch/arm/dts/zynq-zc770-xm013.dts | 2 +-
arch/arm/dts/zynq-zed.dts | 2 +-
arch/arm/dts/zynq-zybo.dts| 2 +-
12 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
index b618a3f484f0..6df0329cfc90 100644
--- a/arch/arm/dts/zynq-7000.dtsi
+++ b/arch/arm/dts/zynq-7000.dtsi
@@ -6,9 +6,10 @@
*
* SPDX-License-Identifier:GPL-2.0+
*/
-/include/ "skeleton.dtsi"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "xlnx,zynq-7000";
cpus {
@@ -37,14 +38,14 @@
};
};
- pmu {
+ pmu@f8891000 {
compatible = "arm,cortex-a9-pmu";
interrupts = <0 5 4>, <0 6 4>;
interrupt-parent = <&intc>;
reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
};
- regulator_vccpint: fixedregulator@0 {
+ regulator_vccpint: fixedregulator {
compatible = "regulator-fixed";
regulator-name = "VCCPINT";
regulator-min-microvolt = <100>;
diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
index cb238cd5e7bb..2d07b92e9cff 100644
--- a/arch/arm/dts/zynq-microzed.dts
+++ b/arch/arm/dts/zynq-microzed.dts
@@ -18,7 +18,7 @@
mmc0 = &sdhci0;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-picozed.dts b/arch/arm/dts/zynq-picozed.dts
index 3408df8b8b3d..fea04ab45a72 100644
--- a/arch/arm/dts/zynq-picozed.dts
+++ b/arch/arm/dts/zynq-picozed.dts
@@ -16,7 +16,7 @@
serial0 = &uart1;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-topic-miami.dts
b/arch/arm/dts/zynq-topic-miami.dts
index 8e988f92877c..aa05c4d368b2 100644
--- a/arch/arm/dts/zynq-topic-miami.dts
+++ b/arch/arm/dts/zynq-topic-miami.dts
@@ -21,7 +21,7 @@
mmc0 = &sdhci0;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index 6585010f4bc8..478e9fd4ef25 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -21,7 +21,7 @@
mmc0 = &sdhci0;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index d04880a2cdd3..8b0177bc512a 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -21,7 +21,7 @@
mmc0 = &sdhci0;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-zc770-xm010.dts
b/arch/arm/dts/zynq-zc770-xm010.dts
index 33524cb6def5..42af313c13dd 100644
--- a/arch/arm/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/dts/zynq-zc770-xm010.dts
@@ -25,7 +25,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-zc770-xm011.dts
b/arch/arm/dts/zynq-zc770-xm011.dts
index 463b14b5ea15..7f08961491a6 100644
--- a/arch/arm/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/dts/zynq-zc770-xm011.dts
@@ -23,7 +23,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
diff --git a/arch/arm/dts/zynq-zc770-xm012.dts
b/arch/arm/dts/zynq-zc770-xm012.dts
index 6cab83266770..699cd2c0fb1c 100644
--- a/arch/arm/dts/zynq-zc770-xm012.dts
+++ b/arch/arm/dts/zynq-zc770-xm012.dts
@@ -24,7 +24,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
diff --git a/
[U-Boot] [PATCH 2/2] ARM64: zynqmp: Remove DTC 1.2 warnings
DTC 1.2 reports these warnings:
Warning (unit_address_vs_reg): Node /amba_apu has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /amba has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node /amba/usb@fe20 has a unit name,
but no reg property
Warning (unit_address_vs_reg): Node /amba/usb@fe30 has a unit name,
but no reg property
Warning (unit_address_vs_reg): Node
/amba/dma@fd4c/dma-video0channel@fd4c has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node
/amba/dma@fd4c/dma-video1channel@fd4c has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node
/amba/dma@fd4c/dma-video2channel@fd4c has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node
/amba/dma@fd4c/dma-graphicschannel@fd4c has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node
/amba/dma@fd4c/dma-audio0channel@fd4c has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node
/amba/dma@fd4c/dma-audio1channel@fd4c has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
This patch is fixing them.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-ep108.dts| 2 +-
arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 2 +-
arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 2 +-
arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 2 +-
arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 2 +-
arch/arm/dts/zynqmp-zcu102.dts | 2 +-
arch/arm/dts/zynqmp.dtsi | 20 ++--
7 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/zynqmp-ep108.dts b/arch/arm/dts/zynqmp-ep108.dts
index 0bbf9a759756..751717028b50 100644
--- a/arch/arm/dts/zynqmp-ep108.dts
+++ b/arch/arm/dts/zynqmp-ep108.dts
@@ -31,7 +31,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
index c68a41bea79a..f3bca60c7e8d 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
@@ -34,7 +34,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
diff --git a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
index 3fdfcc8a11ae..09a114be1610 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
@@ -36,7 +36,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
diff --git a/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
b/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
index 03f1ad7934c1..1f03a94820e2 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
@@ -41,7 +41,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
diff --git a/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
b/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
index d754f9f9040a..698e72e0c5d0 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
@@ -32,7 +32,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
diff --git a/arch/arm/dts/zynqmp-zcu102.dts b/arch/arm/dts/zynqmp-zcu102.dts
index de9960245664..b3f5eaacaefc 100644
--- a/arch/arm/dts/zynqmp-zcu102.dts
+++ b/arch/arm/dts/zynqmp-zcu102.dts
@@ -35,7 +35,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 619450e1ba92..ac17c4723a13 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -243,7 +243,7 @@
<1 10 0xf01>;
};
- amba_apu: amba_apu {
+ amba_apu: amba_apu@0 {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
@@ -262,7 +262,7 @@
};
};
- amba: amba {
+ amba: amba@0 {
compatible =
Re: [U-Boot] [PATCH] SPI: fixup typo in omap2_spi.c
This patch missing name in English and Signed-Off-by. please fix. On Fri, Nov 4, 2016 at 8:23 PM, 郑 祎 wrote: > regs->channel[] is an array of registers in SoC. It is indexed by CS# > Fixup the typo which will cause the index error when accessing the hardware. > > In the all other code, regs->channel[] is indexed by 'priv->cs', so I think > it is reasonable to fix that wrongly register accessing. > > --- > drivers/spi/omap3_spi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c > index 60e9d6e..2380a0e 100644 > --- a/drivers/spi/omap3_spi.c > +++ b/drivers/spi/omap3_spi.c > @@ -416,7 +416,7 @@ static void _omap3_spi_set_wordlen(struct omap3_spi_priv > *priv) > unsigned int confr; > > /* McSPI individual channel configuration */ > - confr = readl(&priv->regs->channel[priv->wordlen].chconf); > + confr = readl(&priv->regs->channel[priv->cs].chconf); > > /* wordlength */ > confr &= ~OMAP3_MCSPI_CHCONF_WL_MASK; > -- > 2.10.2 > -- 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
[U-Boot] [PATCH v4 2/2] rpi: passthrough of the firmware provided FDT blob
Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].
If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.
This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob
There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:
fdt addr ${fdt_addr}
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}
Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
Signed-off-by: Cédric Schieli
---
Changes in v4: None
Changes in v3:
- revert back to assembly for save_boot_params()
Changes in v2:
- merge the series in a single patch
- convert the save_boot_params() function to C code
- add a board_get_usable_ram_top() function to protect the blob
during relocation
- remove the (obsolete) extern declaration from include/configs/rpi.h
- rename the global variable to fw_dtb_pointer
- rename the environment variable to ${fdt_addr}
- fix 64-bits compatibility issues
- document possible uses of ${fdt_addr}
board/raspberrypi/rpi/Makefile| 1 +
board/raspberrypi/rpi/lowlevel_init.S | 36 +++
board/raspberrypi/rpi/rpi.c | 29
3 files changed, 66 insertions(+)
create mode 100644 board/raspberrypi/rpi/lowlevel_init.S
diff --git a/board/raspberrypi/rpi/Makefile b/board/raspberrypi/rpi/Makefile
index 4ce2c98..dcb25ac 100644
--- a/board/raspberrypi/rpi/Makefile
+++ b/board/raspberrypi/rpi/Makefile
@@ -5,3 +5,4 @@
#
obj-y := rpi.o
+obj-y += lowlevel_init.o
diff --git a/board/raspberrypi/rpi/lowlevel_init.S
b/board/raspberrypi/rpi/lowlevel_init.S
new file mode 100644
index 000..cdbd8e1
--- /dev/null
+++ b/board/raspberrypi/rpi/lowlevel_init.S
@@ -0,0 +1,36 @@
+/*
+ * (C) Copyright 2016
+ * Cédric Schieli
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+
+.align 8
+.global fw_dtb_pointer
+fw_dtb_pointer:
+#ifdef CONFIG_ARM64
+ .dword 0x0
+#else
+ .word 0x0
+#endif
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ * Description: save ATAG/FDT address provided by the firmware at boot time
+ */
+
+.global save_boot_params
+save_boot_params:
+
+ /* The firmware provided ATAG/FDT address can be found in r2/x0 */
+#ifdef CONFIG_ARM64
+ adr x8, fw_dtb_pointer
+ str x0, [x8]
+#else
+ str r2, fw_dtb_pointer
+#endif
+
+ /* Returns */
+ b save_boot_params_ret
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 6245b36..ffd6d31 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -25,6 +25,9 @@
DECLARE_GLOBAL_DATA_PTR;
+/* From lowlevel_init.S */
+extern unsigned long fw_dtb_pointer;
+
static const struct bcm2835_gpio_platdata gpio_platdata = {
.base = BCM2835_GPIO_BASE,
};
@@ -285,6 +288,31 @@ static void set_fdtfile(void)
setenv("fdtfile", fdtfile);
}
+/*
+ * If the firmware provided a valid FDT at boot time, let's expose it in
+ * ${fdt_addr} so it may be passed unmodified to the kernel.
+ */
+static void set_fdt_addr(void)
+{
+ if (getenv("fdt_addr"))
+ return;
+
+ if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
+ return;
+
+ setenv_hex("fdt_addr", fw_dtb_pointer);
+}
+
+/*
+ * Prevent relocation from stomping on a firmware provided FDT blob.
+ */
+unsigned long board_get_usable_ram_top(unsigned long total_size)
+{
+ if ((gd->ram_top - fw_dtb_pointer) > SZ_64M)
+ return gd->ram_top;
+ return fw_dtb_pointer & ~0x;
+}
+
static void set_usbethaddr(void)
{
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1);
@@ -356,6 +384,7 @@ static void set_serial_number(void)
int misc_init_r(void)
{
+ set_fdt_addr();
set_fdtfile();
set_usbethaddr();
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/2] rpi: passthrough of the firmware provided FDT blob
Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].
If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.
This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob
There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:
fdt addr ${fdt_addr}
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}
Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
Changes in v4:
- add save_boot_params hook for ARM1176 to make the passthrough work
on ARMv6-based original Pis
Changes in v3:
- revert back to assembly for save_boot_params()
Changes in v2:
- merge the series in a single patch
- convert the save_boot_params() function to C code
- add a board_get_usable_ram_top() function to protect the blob
during relocation
- remove the (obsolete) extern declaration from include/configs/rpi.h
- rename the global variable to fw_dtb_pointer
- rename the environment variable to ${fdt_addr}
- fix 64-bits compatibility issues
- document possible uses of ${fdt_addr}
Cédric Schieli (2):
arm: add save_boot_params for ARM1176
rpi: passthrough of the firmware provided FDT blob
arch/arm/cpu/arm1176/start.S | 10 ++
board/raspberrypi/rpi/Makefile| 1 +
board/raspberrypi/rpi/lowlevel_init.S | 36 +++
board/raspberrypi/rpi/rpi.c | 29
4 files changed, 76 insertions(+)
create mode 100644 board/raspberrypi/rpi/lowlevel_init.S
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/2] arm: add save_boot_params for ARM1176
Implement a hook to allow boards to save boot-time CPU state for later use. When U-Boot is chain-loaded by another bootloader, CPU registers may contain useful information such as system configuration information. This feature mirrors the equivalent ARMv7 feature. Signed-off-by: Cédric Schieli --- Changes in v4: - add save_boot_params hook for ARM1176 to make the passthrough work on ARMv6-based original Pis Changes in v3: None Changes in v2: None arch/arm/cpu/arm1176/start.S | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index a602d4e..7c00201 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -16,6 +16,7 @@ #include #include +#include #ifndef CONFIG_SYS_PHY_UBOOT_BASE #define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE @@ -37,6 +38,11 @@ .globl reset reset: + /* Allow the board to save important registers */ + b save_boot_params +.globl save_boot_params_ret +save_boot_params_ret: + /* * set the cpu to SVC32 mode */ @@ -110,3 +116,7 @@ mmu_disable_phys: c_runtime_cpu_setup: mov pc, lr + +WEAK(save_boot_params) + b save_boot_params_ret/* back to my caller */ +ENDPROC(save_boot_params) -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv8/fsl-layerscape: Update CONFIG_LS2080A to CONFIG_FSL_LSCH3
Update CONFIG_LS2080A to CONFIG_FSL_LSCH3 to make those workaround
implementing of erratum reusable for more SoCs.
Signed-off-by: Shengzhou Liu
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index d68eeba..5a4dd39 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -50,16 +50,16 @@ bool soc_has_aiop(void)
return false;
}
-#ifdef CONFIG_LS2080A
+#if defined(CONFIG_FSL_LSCH3)
/*
* This erratum requires setting a value to eddrtqcr1 to
* optimal the DDR performance.
*/
static void erratum_a008336(void)
{
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008336
u32 *eddrtqcr1;
-#ifdef CONFIG_SYS_FSL_ERRATUM_A008336
#ifdef CONFIG_SYS_FSL_DCSR_DDR_ADDR
eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR_ADDR + 0x800;
if (fsl_ddr_get_version(0) == 0x50200)
@@ -79,9 +79,9 @@ static void erratum_a008336(void)
*/
static void erratum_a008514(void)
{
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008514
u32 *eddrtqcr1;
-#ifdef CONFIG_SYS_FSL_ERRATUM_A008514
#ifdef CONFIG_SYS_FSL_DCSR_DDR3_ADDR
eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR3_ADDR + 0x800;
out_le32(eddrtqcr1, 0x63b20002);
@@ -176,6 +176,7 @@ static void erratum_a009203(void)
#endif
#endif
}
+
void bypass_smmu(void)
{
u32 val;
--
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] [PATCH 4/4] sunxi: sina33: Enable the LCD
Hi, On Fri, Nov 4, 2016 at 11:18 PM, Maxime Ripard wrote: > The SinA33 comes with an optional 7" display. Enable it in the > configuration. > > Signed-off-by: Maxime Ripard > --- > configs/Sinlinx_SinA33_defconfig | 4 > 1 file changed, 4 insertions(+), 0 deletions(-) > > diff --git a/configs/Sinlinx_SinA33_defconfig > b/configs/Sinlinx_SinA33_defconfig > index f4719db2d501..26b119a9b92f 100644 > --- a/configs/Sinlinx_SinA33_defconfig > +++ b/configs/Sinlinx_SinA33_defconfig > @@ -6,6 +6,10 @@ CONFIG_DRAM_ZQ=15291 > CONFIG_MMC0_CD_PIN="PB4" > CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > CONFIG_USB0_ID_DET="PH8" > +CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:66000,le:90,ri:160,up:3,lo:127,hs:70,vs:20,sync:3,vmode:0" > +CONFIG_VIDEO_LCD_DCLK_PHASE=0 > +CONFIG_VIDEO_LCD_BL_EN="PH6" > +CONFIG_VIDEO_LCD_BL_PWM="PH0" I'm using the exact same panel with my SinA31s. The schematics show that these 2 pins aren't actually hooked up to the panel at all. Instead of BL_EN, the corresponding pin is pull-ed up to 3.3V by a resistor just before the LCD connector on the base board. Please try it without these 2 pins set. ChenYu P.S. I've also a VGA converter board for the SinA33 which I've never tried. > CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL=y > -- > git-series 0.8.11 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx7: SPI: add suport for SPI flash in mikroBUS slot
On Fri, Nov 11, 2016 at 2:09 AM, Angus Ainslie wrote:
> Enable the escpi3 nets attached to the mikroBUS slot
> on the i.MX7 Sabre evalution board. Also enble the SPI flash
> commands to work with the "flash click" board.
>
> This is V2 of this patch with changes recommended by the maintainer
Patch subject doesn’t show as V2 fix it.
>
> CC: Jagan Teki
> ---
> board/freescale/mx7dsabresd/mx7dsabresd.c | 24
> configs/mx7dsabresd_secure_defconfig | 3 +++
> include/configs/mx7dsabresd.h | 3 +++
> 3 files changed, 30 insertions(+)
>
> diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c
> b/board/freescale/mx7dsabresd/mx7dsabresd.c
> index b936544..6ccdd4b 100644
> --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
> +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
> @@ -50,6 +50,9 @@ DECLARE_GLOBAL_DATA_PTR;
>
> #define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_SLOW |
> PAD_CTL_HYS)
>
> +#define SPI_PAD_CTRL \
> + (PAD_CTL_HYS | PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_FAST)
> +
> #define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
> #ifdef CONFIG_SYS_I2C_MXC
> #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> @@ -68,6 +71,23 @@ static struct i2c_pads_info i2c_pad_info1 = {
> };
> #endif
>
> +static iomux_v3_cfg_t const ecspi3_pads[] = {
> +MX7D_PAD_SAI2_RX_DATA__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +MX7D_PAD_SAI2_TX_SYNC__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +MX7D_PAD_SAI2_TX_BCLK__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +MX7D_PAD_SAI2_TX_DATA__GPIO6_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> +int board_spi_cs_gpio(unsigned bus, unsigned cs)
> +{
> + return (bus == 2 && cs == 0) ? (IMX_GPIO_NR(6, 22)) : -1;
> +}
> +
> +static void setup_spi(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(ecspi3_pads,
> ARRAY_SIZE(ecspi3_pads));
> +}
> +
> int dram_init(void)
> {
> gd->ram_size = PHYS_SDRAM_SIZE;
> @@ -553,6 +573,10 @@ int board_init(void)
> board_qspi_init();
> #endif
>
> +#ifdef CONFIG_MXC_SPI
> + setup_spi();
> +#endif
> +
> return 0;
> }
>
> diff --git a/configs/mx7dsabresd_secure_defconfig
> b/configs/mx7dsabresd_secure_defconfig
> index 126ce31..ef93522 100644
> --- a/configs/mx7dsabresd_secure_defconfig
> +++ b/configs/mx7dsabresd_secure_defconfig
> @@ -45,3 +45,6 @@ CONFIG_G_DNL_MANUFACTURER="FSL"
> CONFIG_G_DNL_VENDOR_NUM=0x0525
> CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
> CONFIG_OF_LIBFDT=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_CMD_SF=y
> +CONFIG_SPI_FLASH_EON=y
> diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
> index 360a5e0..7f468b2 100644
> --- a/include/configs/mx7dsabresd.h
> +++ b/include/configs/mx7dsabresd.h
> @@ -201,6 +201,9 @@
> #define CONFIG_ENV_SIZESZ_8K
> #define CONFIG_ENV_IS_IN_MMC
>
> +/* SPI flash support */
This is not SPI flash it's SPI driver.
> +#define CONFIG_MXC_SPI
> +
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
