[U-Boot] [PATCH 1/2] board/t4240rdb: Disable the non-existent ethernet port on T4240RDB
From: Ying Zhang
There are 12 ethernet port on T4240RDB, but there need to set 16
MAC addressed for ethernets.
There need to disable non-existent ethernet ports in U-boot
Signed-off-by: Ying Zhang
---
board/freescale/t4rdb/eth.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/freescale/t4rdb/eth.c b/board/freescale/t4rdb/eth.c
index e563a61..ae2451e 100644
--- a/board/freescale/t4rdb/eth.c
+++ b/board/freescale/t4rdb/eth.c
@@ -77,6 +77,9 @@ int board_eth_init(bd_t *bis)
puts("Invalid SerDes1 protocol for T4240RDB\n");
}
+ fm_disable_port(FM1_DTSEC5);
+ fm_disable_port(FM1_DTSEC6);
+
for (i = FM1_DTSEC1; i < FM1_DTSEC1 + CONFIG_SYS_NUM_FM1_DTSEC; i++) {
interface = fm_info_get_enet_if(i);
switch (interface) {
@@ -115,6 +118,8 @@ int board_eth_init(bd_t *bis)
puts("Invalid SerDes2 protocol for T4240RDB\n");
}
+ fm_disable_port(FM2_DTSEC5);
+ fm_disable_port(FM2_DTSEC6);
for (i = FM2_DTSEC1; i < FM2_DTSEC1 + CONFIG_SYS_NUM_FM2_DTSEC; i++) {
interface = fm_info_get_enet_if(i);
switch (interface) {
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports shouldn't be detected
From: Ying Zhang FM1_DTSEC9 & FM1_DTSEC10 should not be detected. Signed-off-by: Ying Zhang --- drivers/net/fm/t4240.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/fm/t4240.c b/drivers/net/fm/t4240.c index ae5aca4..70887fa 100644 --- a/drivers/net/fm/t4240.c +++ b/drivers/net/fm/t4240.c @@ -74,7 +74,7 @@ phy_interface_t fman_port_enet_if(enum fm_port port) if ((port == FM1_DTSEC9 || port == FM1_DTSEC10) && ((is_serdes_configured(XFI_FM1_MAC9)) || (is_serdes_configured(XFI_FM1_MAC10 - return PHY_INTERFACE_MODE_XGMII; + return PHY_INTERFACE_MODE_NONE; if ((port == FM2_10GEC1 || port == FM2_10GEC2) && ((is_serdes_configured(XAUI_FM2_MAC9)) || -- 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] sunxi: mctl_mem_matches: Add missing memory barrier
Hi, On 15-04-16 02:46, Siarhei Siamashka wrote: Hello Hans, On Thu, 14 Apr 2016 18:58:04 +0200 Hans de Goede wrote: We are running with the caches disabled when mctl_mem_matches gets called, but the cpu's write buffer is still there and can still get in the way, This does not make much sense to me. The SPL is running with the MMU disabled, because disabling the MMU is one of the first things done by the SPL at the very start. And when the MMU is disabled, all the data accesses are treated as Strongly-ordered and are not supposed to use the write buffer. A quote from the ARMv7 Architecture Manual: "a write to Strongly-ordered memory can complete only when it reaches the peripheral or memory component accessed by the write" I was surprised by this myself too, but I noticed that mctl_mem_matches has started to return always false on one A23 tablet (detecting 1G of mem instead of 512MB), I then tried it on multiple A23 tablets (3 in total) and they all showed the same problem. I also could not remember seeing this before, so went back u-boot versions all the way to v2015.07 but the problem was still there, which makes me believe that it is triggered by recent gcc versions. Note I'm seeing the problem with u-boot build with gcc-5.3 as well as with gcc-6. We can even verify whether the write buffer is actually in use by simply benchmarking something like the memset function. If the write buffer is working, then the sequential write speed will be around 1 GB/s or more. add a memory barrier to fix this. This avoids mctl_mem_matches always returning false in some cases, which was resulting in: U-Boot SPL 2015.07 (Apr 14 2016 - 18:47:26) DRAM: 1024 MiB U-Boot 2015.07 (Apr 14 2016 - 18:47:26 +0200) Allwinner Technology CPU: Allwinner A23 (SUN8I) DRAM: 512 MiB Where 512 MiB is the right amount, but the DRAM controller would be initialized for 1024 MiB. Is it just a single device or board? Has anybody seen anything like this on other devices with the same SoC? 3 a23 devices. I wonder if what you are observing could be possibly explained by just a usual data corruption problem? Which may be happening when the DRAM clock speed is set higher than this particular device is able to handle in a reliable way. Inserting just one or more NOP instructions instead of the barrier could possibly change some timings too. If this patch helps, then it's fine. But I wonder if it is not merely making the problem latent instead of fixing the root cause? I do believe that this patch addresses a real problem and is not hiding some dram timing issues, I might be wrong about the write-buffer being the cause, it could simply be that the compiler is doing something bad (despite the accesses being marked as volatile) and that the DSB stops the compiler from optimizing things too much. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports shouldn't be detected
Dear ying.zh...@freescale.com, In message <1460701149-36278-2-git-send-email-ying.zh...@freescale.com> you wrote: > From: Ying Zhang > > FM1_DTSEC9 & FM1_DTSEC10 should not be detected. Can you please explain (and add the explanation to the commit message) what this means? Are this ports detected, but not predent on this board? Or should they be hidden for some purpose? Why? Or what else? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In Nature there are neither rewards nor punishments, there are conse- quences.-- R.G. Ingersoll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports shouldn't be detected
> -Original Message- > From: Shengzhou Liu > Sent: Friday, April 15, 2016 3:45 PM > To: 'ying.zh...@freescale.com' ; u- > b...@lists.denx.de > Cc: york...@freescale.com; Ying Zhang > Subject: RE: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports > shouldn't be detected > > > > -Original Message- > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > > ying.zh...@freescale.com > > Sent: Friday, April 15, 2016 2:19 PM > > To: u-boot@lists.denx.de > > Cc: york...@freescale.com; Ying Zhang > > Subject: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports > > shouldn't be detected > > > > From: Ying Zhang > > > > FM1_DTSEC9 & FM1_DTSEC10 should not be detected. > > > > Signed-off-by: Ying Zhang > > --- > > drivers/net/fm/t4240.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/fm/t4240.c b/drivers/net/fm/t4240.c index > > ae5aca4..70887fa 100644 > > --- a/drivers/net/fm/t4240.c > > +++ b/drivers/net/fm/t4240.c > > @@ -74,7 +74,7 @@ phy_interface_t fman_port_enet_if(enum fm_port > port) > > if ((port == FM1_DTSEC9 || port == FM1_DTSEC10) && > > ((is_serdes_configured(XFI_FM1_MAC9)) || > > (is_serdes_configured(XFI_FM1_MAC10 > > - return PHY_INTERFACE_MODE_XGMII; > > + return PHY_INTERFACE_MODE_NONE; > > This patch is making things wrongly, FM1_DTSEC9 & FM1_DTSEC10 should > be configured when RCW uses the these MACs. > -Shengzhou Sorry, I missed the condition, the change is right. Shengzhou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports shouldn't be detected
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > ying.zh...@freescale.com > Sent: Friday, April 15, 2016 2:19 PM > To: u-boot@lists.denx.de > Cc: york...@freescale.com; Ying Zhang > Subject: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports > shouldn't be detected > > From: Ying Zhang > > FM1_DTSEC9 & FM1_DTSEC10 should not be detected. > > Signed-off-by: Ying Zhang > --- > drivers/net/fm/t4240.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/fm/t4240.c b/drivers/net/fm/t4240.c index > ae5aca4..70887fa 100644 > --- a/drivers/net/fm/t4240.c > +++ b/drivers/net/fm/t4240.c > @@ -74,7 +74,7 @@ phy_interface_t fman_port_enet_if(enum fm_port port) > if ((port == FM1_DTSEC9 || port == FM1_DTSEC10) && > ((is_serdes_configured(XFI_FM1_MAC9)) || >(is_serdes_configured(XFI_FM1_MAC10 > - return PHY_INTERFACE_MODE_XGMII; > + return PHY_INTERFACE_MODE_NONE; This patch is making things wrongly, FM1_DTSEC9 & FM1_DTSEC10 should be configured when RCW uses the these MACs. -Shengzhou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports shouldn't be detected
Hi Ying, The commit message should be more clear about what is wrong. Like when using protocols to support 10G on MAC9 and MAC10, these MACs should not be identified as 1G interface, otherwise, one MAC will be Listed as two Ethernet ports, for ex. MAC9 will be listed as FM1@TGEC1 And FM1@DTSEC9. Thanks, Shaohui > -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Shengzhou Liu > Sent: Friday, April 15, 2016 3:58 PM > To: ying.zh...@freescale.com; u-boot@lists.denx.de > Cc: york...@freescale.com; Ying Zhang > Subject: Re: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports > shouldn't > be detected > > > > > -Original Message- > > From: Shengzhou Liu > > Sent: Friday, April 15, 2016 3:45 PM > > To: 'ying.zh...@freescale.com' ; u- > > b...@lists.denx.de > > Cc: york...@freescale.com; Ying Zhang > > Subject: RE: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports > > shouldn't be detected > > > > > > > -Original Message- > > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > > > ying.zh...@freescale.com > > > Sent: Friday, April 15, 2016 2:19 PM > > > To: u-boot@lists.denx.de > > > Cc: york...@freescale.com; Ying Zhang > > > Subject: [U-Boot] [PATCH 2/2] board/t4240rdb: some ethernet ports > > > shouldn't be detected > > > > > > From: Ying Zhang > > > > > > FM1_DTSEC9 & FM1_DTSEC10 should not be detected. > > > > > > Signed-off-by: Ying Zhang > > > --- > > > drivers/net/fm/t4240.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/net/fm/t4240.c b/drivers/net/fm/t4240.c index > > > ae5aca4..70887fa 100644 > > > --- a/drivers/net/fm/t4240.c > > > +++ b/drivers/net/fm/t4240.c > > > @@ -74,7 +74,7 @@ phy_interface_t fman_port_enet_if(enum fm_port > > port) > > > if ((port == FM1_DTSEC9 || port == FM1_DTSEC10) && > > > ((is_serdes_configured(XFI_FM1_MAC9)) || > > >(is_serdes_configured(XFI_FM1_MAC10 > > > - return PHY_INTERFACE_MODE_XGMII; > > > + return PHY_INTERFACE_MODE_NONE; > > > > This patch is making things wrongly, FM1_DTSEC9 & FM1_DTSEC10 should > > be configured when RCW uses the these MACs. > > -Shengzhou > Sorry, I missed the condition, the change is right. > Shengzhou > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/16] doc: Add info on using secure devices from TI
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Adds doc/README.ti-secure file to explain in generic terms > how boot images need to be created for secure devices from > Texas Instruments. > > Specific details for creating secure boot images for the > AM43xx, DRA7xx and AM57xx secure devices from Texas > Instruments are also provided in the README file. > > Secure devices require a security development package (SECDEV) > package that can be downloaded from: > > http://www.ti.com/mysecuresoftware > > Login is required and access is granted under appropriate NDA > and export control restrictions. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/16] arm: am33xx: Kconfig: Add secure device definitions
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Adds a new Kconfig file for AM33xx class devices. We > need a common place to define CONFIG parameters > for these SOCs, especially for adding support > for secure devices. > > a) Adds a definition for ISW_ENTRY_ADDR. This is the > address to which the ROM branches when the SOC > ROM hands off execution to the boot loader. > CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set > to this value for AM43xx devices. > > b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to > calculate CONFIG_SPL_MAX_SIZE. This value indicates the > amount of memory needed by the ROM to store data during > the boot process. > > Currently, these CONFIG options are used only by AM43xx, > but in future other AM33xx class SOCs will also use them. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Adding support for AM43xx secure devices require the addition > of some SOC specific config options like the amount of memory > used by public ROM and the address of the entry point of u-boot > or SPL, as seen by the ROM code, for the image to be built > correctly. > > This mandates the addition of am AM43xx CONFIG option and the > ARM Kconfig file has been modified to source this SOC Kconfig > file. Moving the TARGET_AM43XX_EVM config option to the SOC > KConfig and out of the arch/arm/Kconfig. > > Updating defconfigs to add the CONFIG_AM43XX=y statement and > removing the #define CONFIG_AM43XX from the header file. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/16] ti: omap-common: Add commands for generating secure SPL images
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Adds a centralized config_secure.mk in omap-common for > OMAP-style TI secure devices to use for boot image generation > > Depending on the boot media, different images are needed for > secure devices. These commands generates u-boot*_HS_* files that > need to be used to boot secure devices. > > Please refer to README.ti-secure for more information. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/16] ti: omap-common: Add Kconfig file for secure device support
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on > when building images for secure devices. This flag is used > to invoke the secure image creation tools for creating a > boot image that can be used on secure devices. This flag > may also be used to conditionally compile code specific > to secure devices. > > This terminology will be used by all OMAP architecture devices, > hence introducing to a common location. > > With the creation of Kconfig for omap-common, moved the > sourcing of the Kconfig files for the omap3/4/5 and am33xx > devices from arch/arm/KConfig to the omap-common one. > > Signed-off-by: Madan Srinivas > Signed-off-by: Daniel Allred > --- Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/16] ti: AM43xx: config.mk: Add support for generating secure boot images
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Modifies the config.mk to build secure images when building > the SPL for secure devices. > > Depending on the boot media, different images are needed > for secure devices. The build generates u-boot*_HS_* files > as appropriate for the different boot modes. The same u-boot > binary file is processed slightly differently to produce a > different boot image, depending on whether the user wants to > boot off SPI, QSPI or other boot media. > > Refer to README.ti-secure for more information. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/16] ti: AM43xx: Use CONFIG options from SOC Kconfig
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Updates configs/am43xx_evm.h to use CONFIG options from > SOC specific Kconfig file for various calculations. > > On AM43x devices, the address of SPL entry point depends on > the device type, i.e. whether it is secure or non-secure. > > Further, for non-secure devices, the SPL entry point is different > between USB HOST boot mode, other "memory" boot modes (MMC, NAND) > and "peripheral" boot modes (UART, USB) > > To add to the complexity, on secure devices, in addition to the > above differences, the SPL entry point can change because of the > space occupied by other components (other than u-boot or spl) > that go into a secure boot image. > > To prevent the user from having to modify source files every time > any component of the secure image changes, the value of > CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that > is supplied in the am43xx_*_defconfig files > > Using the CONFIG options also enables us to do away with some > compile time flags that were used to specify CONFIG_SPL_TEXT_BASE > for different boot modes. > > On QSPI devices, the same problem described above occurs w.r.t. the > address of the u-boot entry point in flash, when booting secure > devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via > a Kconfig option and the defconfig files. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/16] ti: AM43xx: board: Detect AM43xx HS EVM
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Adds code to detect AM43xx HS EVMS - the string in the > I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to > for evm detection, regardless of whether the evm is for > GP or HS parts, and updates board init to use that. > > Modifies findfdt command to pick up am437x-gp-evm.dtb for > the HS EVMs also, as the boards are similar except for > some security specific changes around power supply and > enclosure protection. Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/16] ti_omap5_common: Update SPL start address on secure parts
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving > the start address past secure reserved memory and the size of the > security certificate that precedes the boot image on secure devices). > Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the > internal memory actually available on the various device flavors > (Common minimum internal RAM guaranteed for various flavors of > DRA7xx/AM57xx is 512KB). Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Adds new defconfig files for AM43xx secure devices. > These are the same as the non-secure parts, except for > CONFIG_TI_SECURE_DEVICE option set to 'y' > CONFIG_ISW_ENTRY_ADDR updated for secure images. > > Signed-off-by: Daniel Allred > Signed-off-by: Madan Srinivas > --- > configs/am43xx_hs_evm_defconfig | 12 > configs/am43xx_hs_evm_ethboot_defconfig | 11 +++ > configs/am43xx_hs_evm_qspiboot_defconfig | 10 ++ > configs/am43xx_hs_evm_rtconly_defconfig | 12 You do not need this defconfig. Also now only DT enabled configs are accepted. Ill let Tom to comment here. Thanks and regards, Lokesh > configs/am43xx_hs_evm_usbhost_boot_defconfig | 11 +++ > configs/am43xx_hs_evm_usbspl_defconfig | 12 > 6 files changed, 68 insertions(+) > create mode 100644 configs/am43xx_hs_evm_defconfig > create mode 100644 configs/am43xx_hs_evm_ethboot_defconfig > create mode 100644 configs/am43xx_hs_evm_qspiboot_defconfig > create mode 100644 configs/am43xx_hs_evm_rtconly_defconfig > create mode 100644 configs/am43xx_hs_evm_usbhost_boot_defconfig > create mode 100644 configs/am43xx_hs_evm_usbspl_defconfig > > diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig > new file mode 100644 > index 000..a79a82b > --- /dev/null > +++ b/configs/am43xx_hs_evm_defconfig > @@ -0,0 +1,12 @@ > +CONFIG_ARM=y > +CONFIG_AM43XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_SPL=y > +CONFIG_ISW_ENTRY_ADDR=0x40302ae0 > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND" > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH=y > diff --git a/configs/am43xx_hs_evm_ethboot_defconfig > b/configs/am43xx_hs_evm_ethboot_defconfig > new file mode 100644 > index 000..06729fd > --- /dev/null > +++ b/configs/am43xx_hs_evm_ethboot_defconfig > @@ -0,0 +1,11 @@ > +CONFIG_ARM=y > +CONFIG_AM43XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_SPL=y > +CONFIG_ISW_ENTRY_ADDR=0x40302ae0 > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT" > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_SPI_FLASH=y > diff --git a/configs/am43xx_hs_evm_qspiboot_defconfig > b/configs/am43xx_hs_evm_qspiboot_defconfig > new file mode 100644 > index 000..8ae4672 > --- /dev/null > +++ b/configs/am43xx_hs_evm_qspiboot_defconfig > @@ -0,0 +1,10 @@ > +CONFIG_ARM=y > +CONFIG_AM43XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_ISW_ENTRY_ADDR=0x30002ae0 > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT" > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_SPI_FLASH=y > diff --git a/configs/am43xx_hs_evm_rtconly_defconfig > b/configs/am43xx_hs_evm_rtconly_defconfig > new file mode 100644 > index 000..25c2db2 > --- /dev/null > +++ b/configs/am43xx_hs_evm_rtconly_defconfig > @@ -0,0 +1,12 @@ > +CONFIG_ARM=y > +CONFIG_AM43XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_SPL=y > +CONFIG_ISW_ENTRY_ADDR=0x40302ae0 > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_RTC_ONLY_SUPPORT" > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH=y > diff --git a/configs/am43xx_hs_evm_usbhost_boot_defconfig > b/configs/am43xx_hs_evm_usbhost_boot_defconfig > new file mode 100644 > index 000..776f669 > --- /dev/null > +++ b/configs/am43xx_hs_evm_usbhost_boot_defconfig > @@ -0,0 +1,11 @@ > +CONFIG_ARM=y > +CONFIG_AM43XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_SPL=y > +CONFIG_ISW_ENTRY_ADDR=0x40302ae0 > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT" > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_SPI_FLASH=y > diff --git a/configs/am43xx_hs_evm_usbspl_defconfig > b/configs/am43xx_hs_evm_usbspl_defconfig > new file mode 100644 > index 000..5a3f566 > --- /dev/null > +++ b/configs/am43xx_hs_evm_usbspl_defconfig > @@ -0,0 +1,12 @@ > +CONFIG_ARM=y > +CONFIG_AM43XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_SPL=y > +CONFIG_ISW_ENTRY_ADDR=0x40302ae0 > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USBETH_SUPPORT" > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH=y > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Update the CPU string output so that the device > type is now included as part of the CPU string that > is printed as the SPL or u-boot comes up. This update > adds a suffix of the form "-GP" or "-HS" for production > devices, so that general purpose (GP) and high security > (HS) can be distiguished. Applies to all OMAP5 variants. > > Signed-off-by: Daniel Allred > Signed-off-by: Madan Srinivas Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE > is in use (which it should be when building for secure parts), > the TI secure development package is used to create a valid > secure boot image. The u-boot SPL build processes is NOT aware > of the details of creating the boot image - all of that information > is encapsulated in the TI secure development package, which is > available from TI. More info can be found in README.ti-secure > > Right now, two image types are generated, MLO and X-LOADER. The types > are important, as certain boot modes implemented by the device's ROM > boot loader require one or the other (they are not equivalent). The > output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The > u-boot-spl_HS_MLO image is also copied to a file named MLO, which is > the name that the device ROM bootloader requires for loading from the > FAT partition of an SD card (same as on non-secure devices). Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/16] ARM: omap5: add hooks for cpu/SoC fdt fixups
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds an fdt.c file in that defines the ft_cpu_setup() function,
> which should be called from a board-specific ft_board_setup()).
> This ft_cpu_setup() will currently do nothing for non-secure (GP)
> devices but contains pertinent updates for booting on secure (HS)
> devices.
>
> Update the omap5 Makefile to include the fdt.c in the build.
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
>
> Signed-off-by: Daniel Allred
> Signed-off-by: Madan Srinivas
> ---
> arch/arm/cpu/armv7/omap5/Makefile | 1 +
> arch/arm/cpu/armv7/omap5/fdt.c| 183
> ++
> 2 files changed, 184 insertions(+)
> create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c
>
> diff --git a/arch/arm/cpu/armv7/omap5/Makefile
> b/arch/arm/cpu/armv7/omap5/Makefile
> index f2930d5..3caba86 100644
> --- a/arch/arm/cpu/armv7/omap5/Makefile
> +++ b/arch/arm/cpu/armv7/omap5/Makefile
> @@ -12,4 +12,5 @@ obj-y += sdram.o
> obj-y+= prcm-regs.o
> obj-y+= hw_data.o
> obj-y+= abb.o
> +obj-y+= fdt.o
> obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
> diff --git a/arch/arm/cpu/armv7/omap5/fdt.c b/arch/arm/cpu/armv7/omap5/fdt.c
> new file mode 100644
> index 000..f2f40f0
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/omap5/fdt.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright 2016 Texas Instruments, Inc.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#ifdef CONFIG_TI_SECURE_DEVICE
> +
> +/* Give zero values if not already defined */
> +#ifndef CONFIG_SECURE_BOOT_SRAM
> +#define CONFIG_SECURE_BOOT_SRAM (0)
> +#endif
> +#ifndef CONFIG_SECURE_RUN_SRAM
> +#define CONFIG_SECURE_RUN_SRAM (0)
> +#endif
> +
> +static u32 hs_irq_skip[] = {
> + 8, /* Secure violation reporting interrupt */
> + 15, /* One interrupt for SDMA by secure world */
> + 118 /* One interrupt for Crypto DMA by secure world */
> +};
> +
> +static int ft_hs_fixup_crossbar(void *fdt, bd_t *bd)
> +{
> + const char *path;
> + int offs;
> + int ret;
> + int len, i, old_cnt, new_cnt;
> + u32 *temp;
> + const u32 *p_data;
> +
> + /*
> + * Increase the size of the fdt
> + * so we have some breathing room
> + */
> + ret = fdt_increase_size(fdt, 512);
> + if (ret < 0) {
> + printf("Could not increase size of device tree: %s\n",
> +fdt_strerror(ret));
> + return ret;
> + }
> +
> + /* Reserve IRQs that are used/needed by secure world */
> + path = "/ocp/crossbar";
> + offs = fdt_path_offset(fdt, path);
> + if (offs < 0) {
> + debug("Node %s not found.\n", path);
> + return 0;
> + }
> +
> + /* Get current entries */
> + p_data = fdt_getprop(fdt, offs, "ti,irqs-skip", &len);
> + if (p_data)
> + old_cnt = len / sizeof(u32);
> + else
> + old_cnt = 0;
> +
> + new_cnt = sizeof(hs_irq_skip) /
> + sizeof(hs_irq_skip[0]);
> +
> + /* Create new/updated skip list for HS parts */
> + temp = malloc(sizeof(u32) * (old_cnt + new_cnt));
> + for (i = 0; i < new_cnt; i++)
> + temp[i] = cpu_to_fdt32(hs_irq_skip[i]);
> + for (i = 0; i < old_cnt; i++)
> + temp[i + new_cnt] = p_data[i];
> +
> + /* Blow away old data and set new data */
> + fdt_delprop(fdt, offs, "ti,irqs-skip");
> + ret = fdt_setprop(fdt, offs, "ti,irqs-skip",
> + temp,
> + (old_cnt + new_cnt) * sizeof(u32));
> + free(temp);
> +
> + /* Check if the update worked */
> + if (ret < 0) {
> + printf("Could not add ti,irqs-skip property to node %s: %s\n",
> +path, fdt_strerror(ret));
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ft_hs_disable_rng(void *fdt, bd_t *bd)
> +{
> + const char *path;
> + int offs;
> + int ret;
> +
> + /* Make HW RNG reserved for secure world use */
> + path = "/ocp/rng";
> + offs = fdt_path_offset(fdt, path);
> + if (offs < 0) {
> + debug("Node %s not found.\n", path);
> + return 0;
> + }
> + ret = fdt_setprop_string(fdt, offs,
> + "status", "disabled");
> + if (ret < 0) {
> + printf("Could not add status property to node %s: %s\n",
> +path, fdt_strerror(ret));
> + return ret;
> + }
> + return 0;
> +}
> +
> +#if (CONFIG_SECURE_BOOT_SRAM != 0) || (CONFIG_SECURE_RUN_SRAM != 0)
> +static int ft_hs_fixup_sram(void *fdt, bd_t *bd)
> +{
> + const char *path;
> + int offs;
> + int ret;
> + u32 temp[2];
> +
> + /*
> + * Update SRAM reservations on secure devices. The OCMC RAM
> + * is always reserved for secure use
Re: [U-Boot] [PATCH 14/16] ARM: omap5: add ft_board_setup for dra7xx/am57xx
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Adds the board specific ft_board_setup() functions that > are called when CONFIG_OF_BOARD_SETUP is defined. These functions > will currently just call the ft_cpu_setup() function. > > Signed-off-by: Daniel Allred > Signed-off-by: Madan Srinivas Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/16] ARM: omap5: Add config for board/cpu fdt fixups
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Adds CONFIG_OF_BOARD_SETUP to the config header files > for dra7xx_evm and am57xx_evm. > > Signed-off-by: Daniel Allred > Signed-off-by: Madan Srinivas Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/16] defconfig: ti: Add configs for OMAP5-class secure parts
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > Adds new defconfig files for DRA7xx and AM57xx secure devices. > These are the same as the non-secure parts, but with the addition > of the CONFIG_TI_SECURE_DEVICE option set to 'y'. > > Signed-off-by: Daniel Allred > Signed-off-by: Madan Srinivas Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh > --- > configs/am57xx_hs_evm_defconfig | 20 > configs/dra72_hs_evm_defconfig | 28 > configs/dra74_hs_evm_defconfig | 27 +++ > 3 files changed, 75 insertions(+) > create mode 100644 configs/am57xx_hs_evm_defconfig > create mode 100644 configs/dra72_hs_evm_defconfig > create mode 100644 configs/dra74_hs_evm_defconfig > > diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig > new file mode 100644 > index 000..062471e > --- /dev/null > +++ b/configs/am57xx_hs_evm_defconfig > @@ -0,0 +1,20 @@ > +CONFIG_ARM=y > +CONFIG_OMAP54XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_BEAGLE_X15=y > +CONFIG_DM_SERIAL=y > +CONFIG_DM_GPIO=y > +CONFIG_SPL_STACK_R_ADDR=0x8200 > +CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15" > +CONFIG_SPL=y > +CONFIG_SPL_STACK_R=y > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_GPIO=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_OF_CONTROL=y > +CONFIG_DM=y > +CONFIG_DM_MMC=y > +CONFIG_SPI_FLASH=y > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SYS_NS16550=y > diff --git a/configs/dra72_hs_evm_defconfig b/configs/dra72_hs_evm_defconfig > new file mode 100644 > index 000..49f2b49 > --- /dev/null > +++ b/configs/dra72_hs_evm_defconfig > @@ -0,0 +1,28 @@ > +CONFIG_ARM=y > +CONFIG_OMAP54XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_TARGET_DRA7XX_EVM=y > +CONFIG_DM_SERIAL=y > +CONFIG_DM_SPI=y > +CONFIG_DM_SPI_FLASH=y > +CONFIG_DM_GPIO=y > +CONFIG_SPL_STACK_R_ADDR=0x8200 > +CONFIG_DEFAULT_DEVICE_TREE="dra72-evm" > +CONFIG_SPL=y > +CONFIG_SPL_STACK_R=y > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_GPIO=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_OF_CONTROL=y > +CONFIG_DM=y > +CONFIG_SPI_FLASH=y > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH_SPANSION=y > +CONFIG_SYS_NS16550=y > +CONFIG_TI_QSPI=y > +CONFIG_TIMER=y > +CONFIG_OMAP_TIMER=y > +CONFIG_USB=y > +CONFIG_USB_GADGET=y > diff --git a/configs/dra74_hs_evm_defconfig b/configs/dra74_hs_evm_defconfig > new file mode 100644 > index 000..0339d7f > --- /dev/null > +++ b/configs/dra74_hs_evm_defconfig > @@ -0,0 +1,27 @@ > +CONFIG_ARM=y > +CONFIG_OMAP54XX=y > +CONFIG_TI_SECURE_DEVICE=y > +CONFIG_TARGET_DRA7XX_EVM=y > +CONFIG_DM_SERIAL=y > +CONFIG_DM_SPI=y > +CONFIG_DM_SPI_FLASH=y > +CONFIG_DM_GPIO=y > +CONFIG_SPL_STACK_R_ADDR=0x8200 > +CONFIG_DEFAULT_DEVICE_TREE="dra7-evm" > +CONFIG_SPL=y > +CONFIG_SPL_STACK_R=y > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_GPIO=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_OF_CONTROL=y > +CONFIG_DM=y > +CONFIG_SPI_FLASH=y > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH_SPANSION=y > +CONFIG_SYS_NS16550=y > +CONFIG_TI_QSPI=y > +CONFIG_TIMER=y > +CONFIG_OMAP_TIMER=y > +CONFIG_USB=y > +CONFIG_USB_GADGET=y > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: dts: socfpga: fix DTC unit name warnings
Fix following DTC warnings for all socfpga boards:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/main_pll has a
reg or ranges property, but no unit name
Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/main_pll/mpuclk
has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/main_pll/mainclk has a reg or ranges property, but
no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/main_pll/dbg_base_clk has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/main_pll/main_qspi_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/main_pll/main_nand_sdmmc_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/main_pll/cfg_h2f_usr0_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/periph_pll has
a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/periph_pll/emac0_clk has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/periph_pll/emac1_clk has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/periph_pll/per_qsi_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/periph_pll/per_nand_mmc_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/periph_pll/per_base_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/periph_pll/h2f_usr1_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/sdram_pll has a
reg or ranges property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/sdram_pll/ddr_dqs_clk has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/sdram_pll/ddr_2x_dqs_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/sdram_pll/ddr_dq_clk has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node
/soc/clkmgr@ffd04000/clocks/sdram_pll/h2f_usr2_clk has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /soc/usbphy@0 has a unit name, but no reg
property
Signed-off-by: Heiko Schocher
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v
Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/u-boot/u-boot/jobs/122880430
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123238779
arch/arm/dts/skeleton.dtsi | 2 +-
arch/arm/dts/socfpga.dtsi | 40 +-
arch/arm/dts/socfpga_arria5_socdk.dts | 2 +-
arch/arm/dts/socfpga_cyclone5_de0_nano_soc.dts | 2 +-
arch/arm/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
arch/arm/dts/socfpga_cyclone5_socdk.dts| 2 +-
arch/arm/dts/socfpga_cyclone5_sockit.dts | 2 +-
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 +-
8 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm/dts/skeleton.dtsi b/arch/arm/dts/skeleton.dtsi
index b41d241..a20da0a 100644
--- a/arch/arm/dts/skeleton.dtsi
+++ b/arch/arm/dts/skeleton.dtsi
@@ -9,5 +9,5 @@
#size-cells = <1>;
chosen { };
aliases { };
- memory { device_type = "memory"; reg = <0 0>; };
+ memory@0 { device_type = "memory"; reg = <0 0>; };
};
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 8588221..b4196ef 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -128,7 +128,7 @@
compatible = "fixed-clock";
};
- main_pll: main_pll {
+ main_pll: main_pll@40 {
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <0>;
@@ -136,7 +136,7 @@
clocks = <&osc1>;
reg = <0x40>;
- mpuclk: mpuclk {
+ mpuclk: mpuclk@48 {
#clock-cells = <0>;
compatible =
"
Re: [U-Boot] [uboot] [PATCH v5 1/7] drivers: net: cpsw: Add reading of DT phy-handle node
On Monday 11 April 2016 05:48 PM, Dan Murphy wrote:
> Add the ability to read the phy-handle node of the
> cpsw slave. Upon reading this handle the phy-id
> can be stored based on the reg node in the DT.
>
> The phy-handle also needs to be stored and passed
> to the phy to access any phy data that is available.
>
> Signed-off-by: Dan Murphy
> ---
>
> v5 - Fix checkpatch warning no spaces before tabs and typo is subject -
> https://patchwork.ozlabs.org/patch/608082/
>
> drivers/net/cpsw.c | 18 --
> include/cpsw.h | 1 +
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
> index 7104754..8ee33a6 100644
> --- a/drivers/net/cpsw.c
> +++ b/drivers/net/cpsw.c
> @@ -965,6 +965,9 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct
> cpsw_slave *slave)
> phydev->supported &= supported;
> phydev->advertising = phydev->supported;
>
> + if (slave->data->phy_of_handle)
> + phydev->dev->of_offset = slave->data->phy_of_handle;
> +
> priv->phydev = phydev;
> phy_config(phydev);
>
> @@ -1217,8 +1220,19 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice
> *dev)
> if (phy_mode)
> priv->data.slave_data[slave_index].phy_if =
> phy_get_interface_by_name(phy_mode);
> - fdtdec_get_int_array(fdt, subnode, "phy_id", phy_id, 2);
> - priv->data.slave_data[slave_index].phy_addr = phy_id[1];
> +
> + priv->data.slave_data[slave_index].phy_of_handle =
> + fdtdec_lookup_phandle(fdt, subnode,
> "phy-handle");
> +
> + if (priv->data.slave_data[slave_index].phy_of_handle) {
This check is wrong, it should be
if (priv->data.slave_data[slave_index].phy_of_handle >= 0) {
on failure fdtdec_lookup_phandle() will return -error_value and not 0
> + priv->data.slave_data[slave_index].phy_addr =
> + fdtdec_get_int(gd->fdt_blob,
> +
> priv->data.slave_data[slave_index].phy_of_handle,
> + "reg", -1);
> + } else {
> + fdtdec_get_int_array(fdt, subnode, "phy_id",
> phy_id, 2);
> + priv->data.slave_data[slave_index].phy_addr =
> phy_id[1];
> + }
> slave_index++;
> }
>
> diff --git a/include/cpsw.h b/include/cpsw.h
> index cf1d30b..ff95cd8 100644
> --- a/include/cpsw.h
> +++ b/include/cpsw.h
> @@ -21,6 +21,7 @@ struct cpsw_slave_data {
> u32 sliver_reg_ofs;
> int phy_addr;
> int phy_if;
> + int phy_of_handle;
> };
>
> enum {
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 04/14/2016 03:20 PM, Diego wrote: > On 18.02.2016, Schrempf Frieder wrote: >> At the moment I have two sticks with the same chip around for which >> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. >> Also one of our customers tested a few non-working sticks with this >> change and reported, that it fixed it for him. > > Hi all, > > sorry for reopening this thread, but I'd like to provide some additional > infos. > > I was experiencing the same problem with several USB thumb drives, especially > with some Kingston DataTraveler. > > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI > timed > out on TD" but also fixed a more subtle problem. So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look into that one stick deeper, that's real bad. > Additionally, on a Kingston DataTraveler labelled "DTSE9 G2 USB 3.0": > ID 0951:1666 Kingston Technology DataTraveler G4 > I was experiencing apparently successful "load" transfers, but the data > loaded > was actually corrupted when loaded in memory, as a subsequent gzwrite > reported > broken CRC. > > U-Boot > usb dev 0 > > USB device 0: > Device 0: Vendor: Kingston Rev: PMAP Prod: DataTraveler 3.0 > Type: Removable Hard Disk > Capacity: 15004.3 MB = 14.6 GB (30728832 x 512) > ... is now current device > U-Boot > load usb 0:1 0x10008000 my-image.sdcard.gz > reading my-image.sdcard.gz > 112364153 bytes read in 3306 ms (32.4 MiB/s) > U-Boot > gzwrite mmc 1 0x10008000 $filesize > Error: inflate() returned -3 > > uncompressed 4194304 of 2218786816 > crcs == 0xa85fe71c/0xd0244792 > > > The decrease of USB_MAX_XFER_BLK from 65535 to 32767 fixed also that > "corrupted > load" problem, so from what I experienced 32767 is a much more practical and > "real life" reliable value. > > If, as Fabio Estevam suggested, changing USB_MAX_XFER_BLK to 32767 is being > considered, I definitely vote for it. > > Bests, > Diego > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: dts: fix DTC unit name warnings
Fix following DTC warnings for all x86 boards.
There was a warning like:
Warning (unit_address_vs_reg): Node /microcode/update@0 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /microcode/update@1 has a unit name, but no
reg property
I replaced "udpate@" with "update_". Please test
this patch
Signed-off-by: Heiko Schocher
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v
Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/u-boot/u-boot/jobs/122880432
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281030
Tested with sandbox, following steps work as before:
make sandbox_defconfig
make
./u-boot -d u-boot.dtb
but "ut all" drops warnings ... but this patch introduced
no new warnings ...
output of test/py :
(deleted the long lines)
+make O=/home/hs/zug/travis/u-boot.git/build-sandbox -s sandbox_defconfig
+make O=/home/hs/zug/travis/u-boot.git/build-sandbox -s -j8
platform linux2 -- Python 2.7.10, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
rootdir: /home/hs/zug/travis/u-boot.git, inifile:
collected 204 items
test/py/tests/test_000_version.py .
test/py/tests/test_dfu.py s
test/py/tests/test_env.py
test/py/tests/test_help.py .
test/py/tests/test_hush_if_test.py
...
test/py/tests/test_md.py ..
test/py/tests/test_net.py .
test/py/tests/test_sandbox_exit.py ..
test/py/tests/test_shell_basics.py
test/py/tests/test_sleep.py .
test/py/tests/test_ums.py s
test/py/tests/test_unknown_cmd.py .
test/py/tests/test_ut.py
..F...
u_boot_console = , ut_subtest = 'dm spi_flash'
def test_ut(u_boot_console, ut_subtest):
"""Execute a "ut" subtest."""
output = u_boot_console.run_command('ut ' + ut_subtest)
> assert output.endswith('Failures: 0')
E assert ('Failures: 0')
E+ where =
'Test: dm_test_spi_flash\r\r\n2097152 bytes written in 24 ms (83.3
MiB/s)\r\r\nSF: Detected M25P16 with page size 256 ...d_list( "sb save hostfs -
0 spi.bin 20;" "sf probe;" "sf test 0 1", -1, 0): Expected 0, got
1\r\r\nFailures: 1'.endswith
test/py/tests/test_ut.py:29: AssertionError
=> ut dm spi_flash
Test: dm_test_spi_flash
2097152 bytes written in 24 ms (83.3 MiB/s)
SF: Detected M25P16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB
SPI flash test:
SF: Timeout!
Erase failed
Test failed
../test/dm/sf.c:34, dm_test_spi_flash(): 0 == run_command_list( "sb save hostfs
- 0 spi.bin 20;" "sf probe;" "sf test 0 1", -1, 0): Expected 0, got 1
Failures: 1
=>
This error is also without this patch ... may I find
time to fix it too...
arch/sandbox/dts/sandbox.dts | 30
arch/sandbox/dts/test.dts | 58 +++
arch/x86/dts/bayleybay.dts| 22 ++--
arch/x86/dts/broadwell_som-6896.dts | 2 +-
arch/x86/dts/chromebook_link.dts | 22 ++--
arch/x86/dts/chromebook_samus.dts | 30
arch/x86/dts/chromebox_panther.dts| 12 +++
arch/x86/dts/conga-qeval20-qa3-e3845.dts | 20 +--
arch/x86/dts/cougarcanyon2.dts| 18 +-
arch/x86/dts/crownbay.dts | 8 ++---
arch/x86/dts/galileo.dts | 8 ++---
arch/x86/dts/minnowmax.dts| 30
arch/x86/dts/qemu-x86_i440fx.dts | 2 +-
arch/x86/dts/qemu-x86_q35.dts | 2 +-
arch/x86/dts/rtc.dtsi | 2 +-
arch/x86/dts/serial.dtsi | 2 +-
arch/x86/dts/skeleton.dtsi| 2 +-
doc/device-tree-bindings/pmic/sandbox.txt | 2 +-
drivers/misc/cros_ec.c| 6 ++--
include/sandbox-adc.h | 2 +-
test/dm/bus.c | 4 +--
test/dm/eth.c | 4 +--
test/dm/gpio.c| 2 +-
test/dm/pmic.c| 4 +--
test/dm/spmi.c| 2 +-
test/dm/test-fdt.c| 16 -
26 files changed, 156 insertions(+), 156 deletions(-)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 2ae4014..796de3a 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -34,13 +34,13 @@
#size-cells = <1>;
/* Information for sandbox */
- ro {
+ ro@0 {
reg = <0 0xf000>;
};
- wp-ro {
+ wp-ro@f000 {
reg = <0xf000 0x1000>;
};
- rw {
+ rw@1 {
reg = <0x1 0x1>;
[U-Boot] [PATCH] arm: dts: vf6: fix DTC unit warnings
Fix following warnings for all vf6 based boards:
Warning (unit_address_vs_reg): Node
/soc/ifc@153/board-control@3,0/mdio-mux-emi1 has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node /soc/aips-bus@4000 has a unit name, but
no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@4008 has a unit name, but
no reg property
Signed-off-by: Heiko Schocher
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v
Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/u-boot/u-boot/jobs/122880431
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123238780
arch/arm/dts/ls1021a-qds.dtsi | 2 +-
arch/arm/dts/vf.dtsi | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/ls1021a-qds.dtsi b/arch/arm/dts/ls1021a-qds.dtsi
index ca9e835..4cb6337 100644
--- a/arch/arm/dts/ls1021a-qds.dtsi
+++ b/arch/arm/dts/ls1021a-qds.dtsi
@@ -138,7 +138,7 @@
device-width = <1>;
ranges = <0 3 0 0x100>;
- mdio-mux-emi1 {
+ mdio-mux-emi1@54 {
compatible = "mdio-mux-mmioreg";
mdio-parent-bus = <&mdio0>;
#address-cells = <1>;
diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
index 1530d2f..99f3269 100644
--- a/arch/arm/dts/vf.dtsi
+++ b/arch/arm/dts/vf.dtsi
@@ -28,7 +28,7 @@
compatible = "simple-bus";
ranges;
- aips0: aips-bus@4000 {
+ aips0: aips-bus_4000 {
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
@@ -115,7 +115,7 @@
};
};
- aips1: aips-bus@4008 {
+ aips1: aips-bus_4008 {
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.5.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] arm, m68k: fix out-of-range jump
fix the following build error for m68k boards: Building current source for 48 boards (2 threads, 1 job per thread) m68k: + M54455EVB_i66 +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +arch/m68k/cpu/mcf5445x/start.S:668:(.text+0x45a): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 Signed-off-by: Heiko Schocher --- This commit fixes build error: https://travis-ci.org/hsdenx/u-boot/jobs/123254183 fixed log see: https://travis-ci.org/hsdenx/u-boot/jobs/123281032 Any ideas why the changes did not work for: arch/m68k/cpu/mcf523x/start.S arch/m68k/cpu/mcf52x2/start.S arch/m68k/cpu/mcf532x/start.S but work for arch/m68k/cpu/mcf5445x/start.S I have no real m68k experiences, so help is appreciated! arch/m68k/cpu/mcf523x/start.S | 4 ++-- arch/m68k/cpu/mcf52x2/start.S | 4 ++-- arch/m68k/cpu/mcf532x/start.S | 4 ++-- arch/m68k/cpu/mcf5445x/start.S | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S index 8a23e72..ad7bde4 100644 --- a/arch/m68k/cpu/mcf523x/start.S +++ b/arch/m68k/cpu/mcf523x/start.S @@ -141,8 +141,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S index 8a59496..a16b589 100644 --- a/arch/m68k/cpu/mcf52x2/start.S +++ b/arch/m68k/cpu/mcf52x2/start.S @@ -198,8 +198,8 @@ _after_flashbar_copy: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf532x/start.S b/arch/m68k/cpu/mcf532x/start.S index 3b9ede0..50d301c 100644 --- a/arch/m68k/cpu/mcf532x/start.S +++ b/arch/m68k/cpu/mcf532x/start.S @@ -155,8 +155,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf5445x/start.S b/arch/m68k/cpu/mcf5445x/start.S index ae261b1..ff8d627 100644 --- a/arch/m68k/cpu/mcf5445x/start.S +++ b/arch/m68k/cpu/mcf5445x/start.S @@ -664,8 +664,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ -- 2.5.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mips: fix DTC unit warnings
Fix following warnings for all mips based boards:
mips: + pic32mzdask
+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
+Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no reg
property
Signed-off-by: Heiko Schocher
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v
Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033
arch/mips/dts/pic32mzda.dtsi | 2 +-
arch/mips/dts/skeleton.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
index 8a554f9..791c364 100644
--- a/arch/mips/dts/pic32mzda.dtsi
+++ b/arch/mips/dts/pic32mzda.dtsi
@@ -27,7 +27,7 @@
};
cpus {
- cpu@0 {
+ cpu {
compatible = "mips,mips14kc";
};
};
diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
index 24ee6c3..643996c 100644
--- a/arch/mips/dts/skeleton.dtsi
+++ b/arch/mips/dts/skeleton.dtsi
@@ -16,7 +16,7 @@
aliases {
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0 0>;
};
--
2.5.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig
On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote: > From: Madan Srinivas > > Adding support for AM43xx secure devices require the addition > of some SOC specific config options like the amount of memory > used by public ROM and the address of the entry point of u-boot > or SPL, as seen by the ROM code, for the image to be built > correctly. > > This mandates the addition of am AM43xx CONFIG option and the > ARM Kconfig file has been modified to source this SOC Kconfig > file. Moving the TARGET_AM43XX_EVM config option to the SOC > KConfig and out of the arch/arm/Kconfig. > > Updating defconfigs to add the CONFIG_AM43XX=y statement and > removing the #define CONFIG_AM43XX from the header file. > > Signed-off-by: Madan Srinivas > Signed-off-by: Daniel Allred > --- > arch/arm/Kconfig | 19 +-- > arch/arm/cpu/armv7/am33xx/Kconfig | 13 + > configs/am43xx_evm_defconfig | 1 + > configs/am43xx_evm_ethboot_defconfig | 1 + > configs/am43xx_evm_qspiboot_defconfig | 1 + > configs/am43xx_evm_usbhost_boot_defconfig | 1 + > include/configs/am43xx_evm.h | 2 -- > 7 files changed, 30 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index f18dbe6..088d6e0 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -381,12 +381,6 @@ config TARGET_AM335X_SL50 > select DM > select DM_SERIAL > > -config TARGET_AM43XX_EVM > - bool "Support am43xx_evm" > - select CPU_V7 > - select SUPPORT_SPL > - select TI_I2C_BOARD_DETECT > - > config TARGET_BAV335X > bool "Support bav335x" > select CPU_V7 > @@ -507,6 +501,17 @@ config OMAP54XX > select CPU_V7 > select SUPPORT_SPL > > +config AM43XX > + bool "AM43XX SoC" > + select CPU_V7 > + select SUPPORT_SPL > + help > + Support for AM43xx SOC from Texas Instruments. > + The AM43xx high performance SOC features a Cortex-A9 > + ARM core, a quad core PRU-ICSS for industrial Ethernet > + protocols, dual camera support, optional 3D graphics > + and an optional customer programmable secure boot. > + > config RMOBILE > bool "Renesas ARM SoCs" > select CPU_V7 > @@ -776,6 +781,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig" > > source "arch/arm/cpu/armv7/omap5/Kconfig" > > +source "arch/arm/cpu/armv7/am33xx/Kconfig" > + > source "arch/arm/mach-orion5x/Kconfig" > > source "arch/arm/cpu/armv7/rmobile/Kconfig" > diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig > b/arch/arm/cpu/armv7/am33xx/Kconfig > index 39759cd..68bcc64 100644 > --- a/arch/arm/cpu/armv7/am33xx/Kconfig > +++ b/arch/arm/cpu/armv7/am33xx/Kconfig > @@ -1,3 +1,15 @@ > +if AM43XX > +config TARGET_AM43XX_EVM > + bool "Support am43xx_evm" > + select CREATE_BOARD_SYMLINK This should be TI_I2C_BOARD_DETECT or else you will get a build error. Thanks and regards, Lokesh > + help > + This option specifies support for the AM43xx > + GP and HS EVM development platforms.The AM437x > + GP EVM is a standalone test, development, and > + evaluation module system that enables developers > + to write software and develop hardware around > + an AM43xx processor subsystem. > + > config ISW_ENTRY_ADDR > hex "Address in memory or XIP flash of bootloader entry point" > help > @@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE > image, this area is no longer used, and can be reclaimed > for run time use by the boot image. > default 0x8400 > +endif > diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig > index cc83006..4b0a188 100644 > --- a/configs/am43xx_evm_defconfig > +++ b/configs/am43xx_evm_defconfig > @@ -1,4 +1,5 @@ > CONFIG_ARM=y > +CONFIG_AM43XX=y > CONFIG_TARGET_AM43XX_EVM=y > CONFIG_SPL=y > CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND" > diff --git a/configs/am43xx_evm_ethboot_defconfig > b/configs/am43xx_evm_ethboot_defconfig > index a720c14..20001ca 100644 > --- a/configs/am43xx_evm_ethboot_defconfig > +++ b/configs/am43xx_evm_ethboot_defconfig > @@ -1,4 +1,5 @@ > CONFIG_ARM=y > +CONFIG_AM43XX=y > CONFIG_TARGET_AM43XX_EVM=y > CONFIG_SPL=y > CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT" > diff --git a/configs/am43xx_evm_qspiboot_defconfig > b/configs/am43xx_evm_qspiboot_defconfig > index 6db389b..2170a68 100644 > --- a/configs/am43xx_evm_qspiboot_defconfig > +++ b/configs/am43xx_evm_qspiboot_defconfig > @@ -1,4 +1,5 @@ > CONFIG_ARM=y > +CONFIG_AM43XX=y > CONFIG_TARGET_AM43XX_EVM=y > CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT" > # CONFIG_CMD_IMLS is not set > diff --git a/configs/am43xx_evm_usbhost_boot_defconfig > b/configs/am43xx_evm_usbhost_boot_defconfig > index cbaf5a5..14343a9 100644 > --- a/configs/am43xx_evm_usbhost_boot_defconfig > +++ b/configs/am43xx_evm_usbhost_boot_defconfig > @@ -1,4 +1,5 @@ > CONFI
Re: [U-Boot] [uboot] [PATCH v5 1/7] drivers: net: cpsw: Add reading of DT phy-handle node
On Monday 11 April 2016 05:48 PM, Dan Murphy wrote:
> Add the ability to read the phy-handle node of the
> cpsw slave. Upon reading this handle the phy-id
> can be stored based on the reg node in the DT.
>
> The phy-handle also needs to be stored and passed
> to the phy to access any phy data that is available.
>
> Signed-off-by: Dan Murphy
> ---
>
> v5 - Fix checkpatch warning no spaces before tabs and typo is subject -
> https://patchwork.ozlabs.org/patch/608082/
>
> drivers/net/cpsw.c | 18 --
> include/cpsw.h | 1 +
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
> index 7104754..8ee33a6 100644
> --- a/drivers/net/cpsw.c
> +++ b/drivers/net/cpsw.c
> @@ -965,6 +965,9 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct
> cpsw_slave *slave)
> phydev->supported &= supported;
> phydev->advertising = phydev->supported;
>
> + if (slave->data->phy_of_handle)
> + phydev->dev->of_offset = slave->data->phy_of_handle;
This has to be protected with ifdef CONFIG_DM_ETH as dev->of_offset is
available only in DM_ETH
Build error for non-dm-eth case
drivers/net/cpsw.c: In function ‘cpsw_phy_init’:
drivers/net/cpsw.c:970:14: error: ‘struct eth_device’ has no member
named ‘of_offset’
phydev->dev->of_offset = slave->data->phy_of_handle;
^
scripts/Makefile.build:280: recipe for target 'drivers/net/cpsw.o' failed
make[1]: *** [drivers/net/cpsw.o] Error 1
> +
> priv->phydev = phydev;
> phy_config(phydev);
>
> @@ -1217,8 +1220,19 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice
> *dev)
> if (phy_mode)
> priv->data.slave_data[slave_index].phy_if =
> phy_get_interface_by_name(phy_mode);
> - fdtdec_get_int_array(fdt, subnode, "phy_id", phy_id, 2);
> - priv->data.slave_data[slave_index].phy_addr = phy_id[1];
> +
> + priv->data.slave_data[slave_index].phy_of_handle =
> + fdtdec_lookup_phandle(fdt, subnode,
> "phy-handle");
> +
> + if (priv->data.slave_data[slave_index].phy_of_handle) {
> + priv->data.slave_data[slave_index].phy_addr =
> + fdtdec_get_int(gd->fdt_blob,
> +
> priv->data.slave_data[slave_index].phy_of_handle,
> + "reg", -1);
> + } else {
> + fdtdec_get_int_array(fdt, subnode, "phy_id",
> phy_id, 2);
> + priv->data.slave_data[slave_index].phy_addr =
> phy_id[1];
> + }
> slave_index++;
> }
>
> diff --git a/include/cpsw.h b/include/cpsw.h
> index cf1d30b..ff95cd8 100644
> --- a/include/cpsw.h
> +++ b/include/cpsw.h
> @@ -21,6 +21,7 @@ struct cpsw_slave_data {
> u32 sliver_reg_ofs;
> int phy_addr;
> int phy_if;
> + int phy_of_handle;
> };
>
> enum {
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot] [PATCH v5 4/7] net: phy: ti: Allow the driver to be more configurable
On Monday 11 April 2016 05:48 PM, Dan Murphy wrote:
> Not all devices use the same internal delay or fifo depth.
> Add the ability to set the internal delay for rx or tx and the
> fifo depth via the devicetree. If the value is not set in the
> devicetree then set the delay to the default.
>
> If devicetree is not used then use the default defines within the
> driver.
>
> Signed-off-by: Dan Murphy
> ---
>
> v5 - Removed extra space and renamed the bindings per the bindings document -
> https://patchwork.ozlabs.org/patch/608087/
>
> drivers/net/phy/ti.c | 85
> +---
> 1 file changed, 75 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
> index 937426b..b8f3ebd 100644
> --- a/drivers/net/phy/ti.c
> +++ b/drivers/net/phy/ti.c
> @@ -6,6 +6,14 @@
> */
> #include
> #include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
> /* TI DP83867 */
> #define DP83867_DEVADDR 0x1f
> @@ -71,6 +79,17 @@
> #define MII_MMD_CTRL_INCR_RDWT 0x8000 /* post increment on reads &
> writes */
> #define MII_MMD_CTRL_INCR_ON_WT 0xC000 /* post increment on writes only
> */
>
> +/* User setting - can be taken from DTS */
> +#define DEFAULT_RX_ID_DELAY DP83867_RGMIIDCTL_2_25_NS
> +#define DEFAULT_TX_ID_DELAY DP83867_RGMIIDCTL_2_75_NS
> +#define DEFAULT_FIFO_DEPTH DP83867_PHYCR_FIFO_DEPTH_4_B_NIB
> +
> +struct dp83867_private {
> + int rx_id_delay;
> + int tx_id_delay;
> + int fifo_depth;
> +};
> +
> /**
> * phy_read_mmd_indirect - reads data from the MMD registers
> * @phydev: The PHY device bus
> @@ -148,16 +167,58 @@ static inline bool phy_interface_is_rgmii(struct
> phy_device *phydev)
> phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
> }
>
> -/* User setting - can be taken from DTS */
> -#define RX_ID_DELAY 8
> -#define TX_ID_DELAY 0xa
> -#define FIFO_DEPTH 1
> +#if defined(CONFIG_DM_ETH)
> +/**
> + * dp83867_data_init - Convenience function for setting PHY specific data
> + *
> + * @phydev: the phy_device struct
> + */
> +static int dp83867_of_init(struct phy_device *phydev)
> +{
> + struct dp83867_private *dp83867 = phydev->priv;
> + struct udevice *dev = phydev->dev;
> +
> + dp83867->rx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
> + "ti,rx-internal-delay", -1);
> +
> + dp83867->tx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
> + "ti,tx-internal-delay", -1);
> +
> + dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
> + "ti,fifo-depth", -1);
> +
> + return 0;
> +}
> +#else
> +static int dp83867_of_init(struct phy_device *phydev)
> +{
> + dp83867->rx_id_delay = DEFAULT_RX_ID_DELAY;
> + dp83867->tx_id_delay = DEFAULT_TX_ID_DELAY;
> + dp83867->fifo_depth = DEFAULT_FIFO_DEPTH;
> +
> + return 0;
> +}
Below statement missing:
struct dp83867_private *dp83867 = phydev->priv;
Build error:
drivers/net/phy/ti.c: In function ‘dp83867_of_init’:
drivers/net/phy/ti.c:184:2: error: ‘dp83867’ undeclared (first use in
this function)
dp83867->rx_id_delay = DEFAULT_RX_ID_DELAY;
^
drivers/net/phy/ti.c:184:2: note: each undeclared identifier is reported
only once for each function it appears in
scripts/Makefile.build:280: recipe for target 'drivers/net/phy/ti.o' failed
> +#endif
>
> static int dp83867_config(struct phy_device *phydev)
> {
> + struct dp83867_private *dp83867;
> unsigned int val, delay, cfg2;
> int ret;
>
> + if (!phydev->priv) {
> + dp83867 = kzalloc(sizeof(*dp83867), GFP_KERNEL);
> + if (!dp83867)
> + return -ENOMEM;
> +
> + phydev->priv = dp83867;
> + ret = dp83867_of_init(phydev);
> + if (ret)
> + goto err_out;
> + } else {
> + dp83867 = (struct dp83867_private *)phydev->priv;
> + }
> +
> /* Restart the PHY. */
> val = phy_read(phydev, MDIO_DEVAD_NONE, DP83867_CTRL);
> phy_write(phydev, MDIO_DEVAD_NONE, DP83867_CTRL,
> @@ -166,9 +227,9 @@ static int dp83867_config(struct phy_device *phydev)
> if (phy_interface_is_rgmii(phydev)) {
> ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
> (DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
> - (FIFO_DEPTH << DP83867_PHYCR_FIFO_DEPTH_SHIFT));
> + (dp83867->fifo_depth <<
> DP83867_PHYCR_FIFO_DEPTH_SHIFT));
> if (ret)
> - return ret;
> + goto err_out;
> } else {
> phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
> (BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
> @@ -189,8 +250,8 @@ static int dp83867_config(struct ph
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
On 04/15/2016 04:29 PM, Heiko Schocher wrote:
> Fix following warnings for all mips based boards:
> mips: + pic32mzdask
> +Warning (unit_address_vs_reg): Node /memory has a reg or ranges property,
> but no unit name
> +Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no reg
> property
>
> Signed-off-by: Heiko Schocher
> ---
> This warnings pop up with the DTC compiler:
> $ /tmp/dtc/dtc -v
> Version: DTC 1.4.1-gbeef80b8
>
> This fixes the compile warnings for:
> https://travis-ci.org/hsdenx/u-boot/jobs/123254184
>
> see:
> https://travis-ci.org/hsdenx/u-boot/jobs/123281033
>
>
> arch/mips/dts/pic32mzda.dtsi | 2 +-
> arch/mips/dts/skeleton.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> index 8a554f9..791c364 100644
> --- a/arch/mips/dts/pic32mzda.dtsi
> +++ b/arch/mips/dts/pic32mzda.dtsi
> @@ -27,7 +27,7 @@
> };
>
> cpus {
> - cpu@0 {
> + cpu {
> compatible = "mips,mips14kc";
> };
> };
> diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> index 24ee6c3..643996c 100644
> --- a/arch/mips/dts/skeleton.dtsi
> +++ b/arch/mips/dts/skeleton.dtsi
> @@ -16,7 +16,7 @@
> aliases {
> };
>
> - memory {
> + memory@0 {
> device_type = "memory";
> reg = <0 0>;
> };
Reviewed-by: Purna Chandra Mandal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> Fix following warnings for all mips based boards:
> mips: + pic32mzdask
> +Warning (unit_address_vs_reg): Node /memory has a reg or ranges property,
> but no unit name
> +Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no reg
> property
>
> Signed-off-by: Heiko Schocher
> ---
Acked-by: Daniel Schwierzeck
> This warnings pop up with the DTC compiler:
> $ /tmp/dtc/dtc -v
> Version: DTC 1.4.1-gbeef80b8
>
> This fixes the compile warnings for:
> https://travis-ci.org/hsdenx/u-boot/jobs/123254184
>
> see:
> https://travis-ci.org/hsdenx/u-boot/jobs/123281033
>
>
> arch/mips/dts/pic32mzda.dtsi | 2 +-
> arch/mips/dts/skeleton.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> index 8a554f9..791c364 100644
> --- a/arch/mips/dts/pic32mzda.dtsi
> +++ b/arch/mips/dts/pic32mzda.dtsi
> @@ -27,7 +27,7 @@
> };
>
> cpus {
> - cpu@0 {
> + cpu {
> compatible = "mips,mips14kc";
> };
> };
> diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> index 24ee6c3..643996c 100644
> --- a/arch/mips/dts/skeleton.dtsi
> +++ b/arch/mips/dts/skeleton.dtsi
> @@ -16,7 +16,7 @@
> aliases {
> };
>
> - memory {
> + memory@0 {
> device_type = "memory";
> reg = <0 0>;
> };
>
--
- Daniel
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ath79: fix some minor defects
Am 12.04.2016 um 05:09 schrieb Wills Wang: > > These series of patch based on top of mips/next, it fix some defects on > the previous patch series "add support for atheros ath79 based SOCs". > > > Wills Wang (4): > ath79: spi: Remove the explicit pinctrl setting > ar933x: serial: Remove the explicit pinctrl setting > ath79: ar933x: use BIT macro for bit shift operation > ath79: add readonly attribute for ath79_soc_desc > > arch/mips/mach-ath79/ar933x/ddr.c | 14 +++--- > arch/mips/mach-ath79/cpu.c| 8 > drivers/serial/serial_ar933x.c| 16 ++-- > drivers/spi/ath79_spi.c | 12 > 4 files changed, 13 insertions(+), 37 deletions(-) > all four patches applied to u-boot-mips/next, thanks! -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] EHCI timed out on TD - token=0x80008d80 on U-Boot 2013.04
Hello All, I am using U-Boot 2013.04. I have tried enabling the USB support at u-boot. Now i get the following log on successful detection of a USB device. U-Boot > usb start (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found scanning usb for storage devices... EHCI timed out on TD - token=0x80008c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 error in inquiry 1 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Once this error occurs at next boot i am unable to detect the usb. What might be the problem? If there is solution as a patch would be helpful. Regards, Manju ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: dts: amX/draX: fix DTC unit name warnings
Fi all DTC warnings for TI boards.
Signed-off-by: Heiko Schocher
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v
Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123238798
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123254198
arch/arm/dts/am335x-bone-common.dtsi | 12 +-
arch/arm/dts/am335x-evm.dts | 16 +-
arch/arm/dts/am33xx-clocks.dtsi | 90 -
arch/arm/dts/am33xx.dtsi | 4 +-
arch/arm/dts/am4372.dtsi | 10 +-
arch/arm/dts/am437x-gp-evm.dts | 4 +-
arch/arm/dts/am437x-sk-evm.dts | 12 +-
arch/arm/dts/am43xx-clocks.dtsi | 114 +--
arch/arm/dts/am57xx-beagle-x15.dts | 10 +-
arch/arm/dts/dra7-evm.dts| 2 +-
arch/arm/dts/dra7.dtsi | 16 +-
arch/arm/dts/dra72-evm.dts | 2 +-
arch/arm/dts/dra74x.dtsi | 2 +-
arch/arm/dts/dra7xx-clocks.dtsi | 370 +--
arch/arm/dts/k2e-clocks.dtsi | 8 +-
arch/arm/dts/k2e-netcp.dtsi | 6 +-
arch/arm/dts/k2e.dtsi| 2 +-
arch/arm/dts/k2g-netcp.dtsi | 6 +-
arch/arm/dts/k2g.dtsi| 4 +-
arch/arm/dts/k2hk-clocks.dtsi| 74 +++
arch/arm/dts/k2hk-netcp.dtsi | 8 +-
arch/arm/dts/k2hk.dtsi | 16 +-
arch/arm/dts/k2l-clocks.dtsi | 44 ++---
arch/arm/dts/k2l-netcp.dtsi | 6 +-
arch/arm/dts/k2l.dtsi| 8 +-
arch/arm/dts/keystone-clocks.dtsi| 52 ++---
arch/arm/dts/keystone.dtsi | 6 +-
27 files changed, 452 insertions(+), 452 deletions(-)
diff --git a/arch/arm/dts/am335x-bone-common.dtsi
b/arch/arm/dts/am335x-bone-common.dtsi
index fec7834..68d87ca 100644
--- a/arch/arm/dts/am335x-bone-common.dtsi
+++ b/arch/arm/dts/am335x-bone-common.dtsi
@@ -13,7 +13,7 @@
};
};
- memory {
+ memory@8000 {
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
};
@@ -24,28 +24,28 @@
compatible = "gpio-leds";
- led@2 {
+ led2 {
label = "beaglebone:green:heartbeat";
gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
default-state = "off";
};
- led@3 {
+ led3 {
label = "beaglebone:green:mmc0";
gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "mmc0";
default-state = "off";
};
- led@4 {
+ led4 {
label = "beaglebone:green:usr2";
gpios = <&gpio1 23 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "cpu0";
default-state = "off";
};
- led@5 {
+ led5 {
label = "beaglebone:green:usr3";
gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "mmc1";
@@ -53,7 +53,7 @@
};
};
- vmmcsd_fixed: fixedregulator@0 {
+ vmmcsd_fixed: fixedregulator {
compatible = "regulator-fixed";
regulator-name = "vmmcsd_fixed";
regulator-min-microvolt = <330>;
diff --git a/arch/arm/dts/am335x-evm.dts b/arch/arm/dts/am335x-evm.dts
index c0bc2af..f9cdcdb 100644
--- a/arch/arm/dts/am335x-evm.dts
+++ b/arch/arm/dts/am335x-evm.dts
@@ -25,12 +25,12 @@
};
};
- memory {
+ memory@8000 {
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
};
- vbat: fixedregulator@0 {
+ vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
regulator-min-microvolt = <500>;
@@ -38,13 +38,13 @@
regulator-boot-on;
};
- lis3_reg: fixedregulator@1 {
+ lis3_reg: fixedregulator1 {
compatible = "regulator-fixed";
regulator-name = "lis3_reg";
regulator-boot-on;
};
- wlan_en_reg: fixedregulator@2 {
+ wlan_en_reg: fixedregulator2 {
compatible = "regulator-fixed";
regulator-name = "wlan-en-regulator";
regulator-min-microvolt = <180>;
@@ -58,7 +58,7 @@
enable-active-high;
};
- matrix_keypad: matrix_keypad@0 {
+ matrix_keypad: matrix_keypad {
compatible = "gpio-matrix-keypad";
debounce-delay-ms = <5>;
col-scan-delay-us = <2>;
@@ -78,20 +78,20 @@
0x0201006c>;
[U-Boot] [PATCH] arm64: add missing gic_init_secure_percpu for non multi-entry
Per-CPU initialization of GIC is necessary even when CONFIG_ARMV8_MULTIENTRY is undefined. Signed-off-by: Masahiro Yamada --- arch/arm/cpu/armv8/start.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index dceedd7..124a274 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -208,6 +208,8 @@ WEAK(lowlevel_init) */ ldr x0, =GICD_BASE bl gic_init_secure + ldr x0, =GICR_BASE + bl gic_init_secure_percpu #endif #else /* CONFIG_ARMV8_MULTIENTRY is set */ #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
In data venerdì 15 aprile 2016 12:53:36, Marek Vasut ha scritto: > On 04/14/2016 03:20 PM, Diego wrote: > > On 18.02.2016, Schrempf Frieder wrote: > >> At the moment I have two sticks with the same chip around for which > >> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. > >> Also one of our customers tested a few non-working sticks with this > >> change and reported, that it fixed it for him. > > > > Hi all, > > > > sorry for reopening this thread, but I'd like to provide some additional > > infos. > > > > I was experiencing the same problem with several USB thumb drives, > > especially with some Kingston DataTraveler. > > > > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI > > timed out on TD" but also fixed a more subtle problem. > > So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look > into that one stick deeper, that's real bad. > Hi Marek, yes, I was getting the following error with the Kingston DTSE9 USB 2.0: EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 The model is the one in this photo: http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg ID 0951:1689 Kingston Technology DataTraveler SE9 I'm available if you want any additional info. Bests, Diego ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pinctrl: uniphier: fix NAND pin-mux setting for PH1-LD11/LD20
The initial version missed to set up the pin number 17.
Signed-off-by: Masahiro Yamada
---
drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index 3d5ac5f..1fb2898 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -22,9 +22,9 @@ static const unsigned i2c3_muxvals[] = {1, 1};
static const unsigned i2c4_pins[] = {61, 62};
static const unsigned i2c4_muxvals[] = {1, 1};
static const unsigned nand_pins[] = {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
-15, 16};
+15, 16, 17};
static const unsigned nand_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0};
+ 0, 0, 0};
static const unsigned nand_cs1_pins[] = {};
static const unsigned nand_cs1_muxvals[] = {};
static const unsigned sd_pins[] = {10, 11, 12, 13, 14, 15, 16, 17};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 6/7] net: phy: Add phy_interface_is_sgmii to phy.h
Add a helper to phy.h to identify whether the
phy is configured for SGMII all variables.
Signed-off-by: Dan Murphy
Reviewed-by: Mugunthan V N
Reviewed-by: Michal Simek
---
v6 - No changes - https://patchwork.ozlabs.org/patch/608766/
include/phy.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/phy.h b/include/phy.h
index 7b2d1ff..ef3eb51 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -288,6 +288,17 @@ static inline bool phy_interface_is_rgmii(struct
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
}
+/**
+ * phy_interface_is_sgmii - Convenience function for testing if a PHY interface
+ * is SGMII (all variants)
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_interface_is_sgmii(struct phy_device *phydev)
+{
+ return phydev->interface >= PHY_INTERFACE_MODE_SGMII &&
+ phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
+}
+
/* PHY UIDs for various PHYs that are referenced in external code */
#define PHY_UID_CS4340 0x13e51002
#define PHY_UID_TN2020 0x00a19410
--
2.8.1.116.g7b0d47b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/7] net: phy: dp83867: Add device tree bindings and documentation
Add the device tree bindings and the accompanying documentation
for the TI DP83867 Giga bit ethernet phy driver.
The original document was from:
[commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]
Signed-off-by: Dan Murphy
Reviewed-by: Mugunthan V N
---
v6 - No Changes - https://patchwork.ozlabs.org/patch/608768/
doc/device-tree-bindings/net/ti,dp83867.txt | 25 +
include/dt-bindings/net/ti-dp83867.h| 35 +
2 files changed, 60 insertions(+)
create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
create mode 100644 include/dt-bindings/net/ti-dp83867.h
diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt
b/doc/device-tree-bindings/net/ti,dp83867.txt
new file mode 100644
index 000..cb77fdf
--- /dev/null
+++ b/doc/device-tree-bindings/net/ti,dp83867.txt
@@ -0,0 +1,25 @@
+* Texas Instruments - dp83867 Giga bit ethernet phy
+
+Required properties:
+ - reg - The ID number for the phy, usually a small integer
+ - ti,rx-internal-delay - RGMII Recieve Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,tx-internal-delay - RGMII Transmit Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
+ for applicable values
+
+Default child nodes are standard Ethernet PHY device
+nodes as described in doc/devicetree/bindings/net/ethernet.txt
+
+Example:
+
+ ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = ;
+ ti,tx-internal-delay = ;
+ ti,fifo-depth = ;
+ };
+
+Datasheet can be found:
+http://www.ti.com/product/DP83867IR/datasheet
diff --git a/include/dt-bindings/net/ti-dp83867.h
b/include/dt-bindings/net/ti-dp83867.h
new file mode 100644
index 000..1843757
--- /dev/null
+++ b/include/dt-bindings/net/ti-dp83867.h
@@ -0,0 +1,35 @@
+/*
+ * TI DP83867 PHY drivers
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ *
+ */
+
+#ifndef _DT_BINDINGS_TI_DP83867_H
+#define _DT_BINDINGS_TI_DP83867_H
+
+/* PHY CTRL bits */
+#define DP83867_PHYCR_FIFO_DEPTH_3_B_NIB 0x00
+#define DP83867_PHYCR_FIFO_DEPTH_4_B_NIB 0x01
+#define DP83867_PHYCR_FIFO_DEPTH_6_B_NIB 0x02
+#define DP83867_PHYCR_FIFO_DEPTH_8_B_NIB 0x03
+
+/* RGMIIDCTL internal delay for rx and tx */
+#define DP83867_RGMIIDCTL_250_PS 0x0
+#define DP83867_RGMIIDCTL_500_PS 0x1
+#define DP83867_RGMIIDCTL_750_PS 0x2
+#define DP83867_RGMIIDCTL_1_NS 0x3
+#define DP83867_RGMIIDCTL_1_25_NS 0x4
+#define DP83867_RGMIIDCTL_1_50_NS 0x5
+#define DP83867_RGMIIDCTL_1_75_NS 0x6
+#define DP83867_RGMIIDCTL_2_00_NS 0x7
+#define DP83867_RGMIIDCTL_2_25_NS 0x8
+#define DP83867_RGMIIDCTL_2_50_NS 0x9
+#define DP83867_RGMIIDCTL_2_75_NS 0xa
+#define DP83867_RGMIIDCTL_3_00_NS 0xb
+#define DP83867_RGMIIDCTL_3_25_NS 0xc
+#define DP83867_RGMIIDCTL_3_50_NS 0xd
+#define DP83867_RGMIIDCTL_3_75_NS 0xe
+#define DP83867_RGMIIDCTL_4_00_NS 0xf
+
+#endif
--
2.8.1.116.g7b0d47b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/7] drivers: net: cpsw: Add reading of DT phy-handle node
Add the ability to read the phy-handle node of the
cpsw slave. Upon reading this handle the phy-id
can be stored based on the reg node in the DT.
The phy-handle also needs to be stored and passed
to the phy to access any phy data that is available.
Signed-off-by: Dan Murphy
---
v6 - Fix build error when DM_ETH is not defined and updated phy_handle error
handling - https://patchwork.ozlabs.org/patch/608763/
drivers/net/cpsw.c | 20 ++--
include/cpsw.h | 1 +
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 7104754..3d6f0ce 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -965,6 +965,11 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct
cpsw_slave *slave)
phydev->supported &= supported;
phydev->advertising = phydev->supported;
+#ifdef CONFIG_DM_ETH
+ if (slave->data->phy_of_handle)
+ phydev->dev->of_offset = slave->data->phy_of_handle;
+#endif
+
priv->phydev = phydev;
phy_config(phydev);
@@ -1217,8 +1222,19 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice
*dev)
if (phy_mode)
priv->data.slave_data[slave_index].phy_if =
phy_get_interface_by_name(phy_mode);
- fdtdec_get_int_array(fdt, subnode, "phy_id", phy_id, 2);
- priv->data.slave_data[slave_index].phy_addr = phy_id[1];
+
+ priv->data.slave_data[slave_index].phy_of_handle =
+ fdtdec_lookup_phandle(fdt, subnode,
"phy-handle");
+
+ if (priv->data.slave_data[slave_index].phy_of_handle >=
0) {
+ priv->data.slave_data[slave_index].phy_addr =
+ fdtdec_get_int(gd->fdt_blob,
+
priv->data.slave_data[slave_index].phy_of_handle,
+ "reg", -1);
+ } else {
+ fdtdec_get_int_array(fdt, subnode, "phy_id",
phy_id, 2);
+ priv->data.slave_data[slave_index].phy_addr =
phy_id[1];
+ }
slave_index++;
}
diff --git a/include/cpsw.h b/include/cpsw.h
index cf1d30b..ff95cd8 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -21,6 +21,7 @@ struct cpsw_slave_data {
u32 sliver_reg_ofs;
int phy_addr;
int phy_if;
+ int phy_of_handle;
};
enum {
--
2.8.1.116.g7b0d47b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 4/7] net: phy: ti: Allow the driver to be more configurable
Not all devices use the same internal delay or fifo depth.
Add the ability to set the internal delay for rx or tx and the
fifo depth via the devicetree. If the value is not set in the
devicetree then set the delay to the default.
If devicetree is not used then use the default defines within the
driver.
Signed-off-by: Dan Murphy
---
v6 - Fix build error when DM_ETH is not configured -
https://patchwork.ozlabs.org/patch/608764/
drivers/net/phy/ti.c | 87 ++--
1 file changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 937426b..4c4f0c1 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -6,6 +6,14 @@
*/
#include
#include
+#include
+#include
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
/* TI DP83867 */
#define DP83867_DEVADDR0x1f
@@ -71,6 +79,17 @@
#define MII_MMD_CTRL_INCR_RDWT 0x8000 /* post increment on reads & writes */
#define MII_MMD_CTRL_INCR_ON_WT0xC000 /* post increment on writes only
*/
+/* User setting - can be taken from DTS */
+#define DEFAULT_RX_ID_DELAYDP83867_RGMIIDCTL_2_25_NS
+#define DEFAULT_TX_ID_DELAYDP83867_RGMIIDCTL_2_75_NS
+#define DEFAULT_FIFO_DEPTH DP83867_PHYCR_FIFO_DEPTH_4_B_NIB
+
+struct dp83867_private {
+ int rx_id_delay;
+ int tx_id_delay;
+ int fifo_depth;
+};
+
/**
* phy_read_mmd_indirect - reads data from the MMD registers
* @phydev: The PHY device bus
@@ -148,16 +167,60 @@ static inline bool phy_interface_is_rgmii(struct
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
}
-/* User setting - can be taken from DTS */
-#define RX_ID_DELAY8
-#define TX_ID_DELAY0xa
-#define FIFO_DEPTH 1
+#if defined(CONFIG_DM_ETH)
+/**
+ * dp83867_data_init - Convenience function for setting PHY specific data
+ *
+ * @phydev: the phy_device struct
+ */
+static int dp83867_of_init(struct phy_device *phydev)
+{
+ struct dp83867_private *dp83867 = phydev->priv;
+ struct udevice *dev = phydev->dev;
+
+ dp83867->rx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,rx-internal-delay", -1);
+
+ dp83867->tx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,tx-internal-delay", -1);
+
+ dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,fifo-depth", -1);
+
+ return 0;
+}
+#else
+static int dp83867_of_init(struct phy_device *phydev)
+{
+ struct dp83867_private *dp83867 = phydev->priv;
+
+ dp83867->rx_id_delay = DEFAULT_RX_ID_DELAY;
+ dp83867->tx_id_delay = DEFAULT_TX_ID_DELAY;
+ dp83867->fifo_depth = DEFAULT_FIFO_DEPTH;
+
+ return 0;
+}
+#endif
static int dp83867_config(struct phy_device *phydev)
{
+ struct dp83867_private *dp83867;
unsigned int val, delay, cfg2;
int ret;
+ if (!phydev->priv) {
+ dp83867 = kzalloc(sizeof(*dp83867), GFP_KERNEL);
+ if (!dp83867)
+ return -ENOMEM;
+
+ phydev->priv = dp83867;
+ ret = dp83867_of_init(phydev);
+ if (ret)
+ goto err_out;
+ } else {
+ dp83867 = (struct dp83867_private *)phydev->priv;
+ }
+
/* Restart the PHY. */
val = phy_read(phydev, MDIO_DEVAD_NONE, DP83867_CTRL);
phy_write(phydev, MDIO_DEVAD_NONE, DP83867_CTRL,
@@ -166,9 +229,9 @@ static int dp83867_config(struct phy_device *phydev)
if (phy_interface_is_rgmii(phydev)) {
ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
(DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
- (FIFO_DEPTH << DP83867_PHYCR_FIFO_DEPTH_SHIFT));
+ (dp83867->fifo_depth <<
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
- return ret;
+ goto err_out;
} else {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
(BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
@@ -189,8 +252,8 @@ static int dp83867_config(struct phy_device *phydev)
DP83867_PHYCTRL_SGMIIEN |
(DP83867_MDI_CROSSOVER_MDIX <<
DP83867_MDI_CROSSOVER) |
- (FIFO_DEPTH << DP83867_PHYCTRL_RXFIFO_SHIFT) |
- (FIFO_DEPTH << DP83867_PHYCTRL_TXFIFO_SHIFT));
+ (dp83867->fifo_depth << DP83867_PHYCTRL_RXFIFO_SHIFT)
|
+ (dp83867->fifo_depth <<
DP83867_PHYCTRL_TXFIFO_SHIFT));
phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_BISCR, 0x0);
}
@@ -212,8 +275,8 @@ static int dp83867_config(struct phy_device *phydev)
phy_w
[U-Boot] [PATCH v6 7/7] net: phy: dp83867: Add SGMII helper for configuration
The code assumed that if the interface is not RGMII configured
then it must be SGMII configured. This device has the ability
to support most of the MII interfaces. Therefore add the
helper for SGMII and only configure the device if the interface is
configured for SGMII.
Signed-off-by: Dan Murphy
Reviewed-by: Mugunthan V N
Reviewed-by: Michal Simek
---
v6 - No changes - https://patchwork.ozlabs.org/patch/608767/
drivers/net/phy/ti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 4c19353..c55dd97 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -221,7 +221,7 @@ static int dp83867_config(struct phy_device *phydev)
(dp83867->fifo_depth <<
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
goto err_out;
- } else {
+ } else if (phy_interface_is_sgmii(phydev)) {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
(BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
--
2.8.1.116.g7b0d47b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 5/7] net: phy: Move is_rgmii helper to phy.h
Move the phy_interface_is_rgmii to the phy.h
file for all phy's to be able to use the API.
This now aligns with the Linux kernel based on
commit e463d88c36d42211aa72ed76d32fb8bf37820ef1
Signed-off-by: Dan Murphy
Reviewed-by: Mugunthan V N
Reviewed-by: Michal Simek
---
v6 - No changes - https://patchwork.ozlabs.org/patch/608765/
drivers/net/phy/ti.c | 11 ---
include/phy.h| 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 4c4f0c1..4c19353 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -156,17 +156,6 @@ void phy_write_mmd_indirect(struct phy_device *phydev, int
prtad,
phy_write(phydev, addr, MII_MMD_DATA, data);
}
-/**
- * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
- * is RGMII (all variants)
- * @phydev: the phy_device struct
- */
-static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
-{
- return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
- phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
-}
-
#if defined(CONFIG_DM_ETH)
/**
* dp83867_data_init - Convenience function for setting PHY specific data
diff --git a/include/phy.h b/include/phy.h
index 21459a8..7b2d1ff 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -277,6 +277,17 @@ int get_phy_id(struct mii_dev *bus, int addr, int devad,
u32 *phy_id);
*/
int phy_get_interface_by_name(const char *str);
+/**
+ * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
+ * is RGMII (all variants)
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
+{
+ return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
+ phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
+}
+
/* PHY UIDs for various PHYs that are referenced in external code */
#define PHY_UID_CS4340 0x13e51002
#define PHY_UID_TN2020 0x00a19410
--
2.8.1.116.g7b0d47b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/7] net: zynq_gem: Add the passing of the phy-handle node
Add the ability to pass the phy-handle node offset
to the phy driver. This allows the phy driver
to access the DT subnode's data and parse accordingly.
Signed-off-by: Dan Murphy
Tested-by: Michal Simek
---
v6 - No changes - https://patchwork.ozlabs.org/patch/608769/
drivers/net/zynq_gem.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index aec8077..f9b22c4 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -179,6 +179,7 @@ struct zynq_gem_priv {
struct zynq_gem_regs *iobase;
phy_interface_t interface;
struct phy_device *phydev;
+ int phy_of_handle;
struct mii_dev *bus;
};
@@ -352,6 +353,10 @@ static int zynq_phy_init(struct udevice *dev)
priv->phydev->supported = supported | ADVERTISED_Pause |
ADVERTISED_Asym_Pause;
priv->phydev->advertising = priv->phydev->supported;
+
+ if (priv->phy_of_handle > 0)
+ priv->phydev->dev->of_offset = priv->phy_of_handle;
+
phy_config(priv->phydev);
return 0;
@@ -675,7 +680,6 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_platdata(dev);
struct zynq_gem_priv *priv = dev_get_priv(dev);
- int offset = 0;
const char *phy_mode;
pdata->iobase = (phys_addr_t)dev_get_addr(dev);
@@ -684,10 +688,11 @@ static int zynq_gem_ofdata_to_platdata(struct udevice
*dev)
priv->emio = 0;
priv->phyaddr = -1;
- offset = fdtdec_lookup_phandle(gd->fdt_blob, dev->of_offset,
- "phy-handle");
- if (offset > 0)
- priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
+ priv->phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob,
+ dev->of_offset, "phy-handle");
+ if (priv->phy_of_handle > 0)
+ priv->phyaddr = fdtdec_get_int(gd->fdt_blob,
+ priv->phy_of_handle, "reg", -1);
phy_mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "phy-mode", NULL);
if (phy_mode)
--
2.8.1.116.g7b0d47b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unaligned flush_dcache_range in axs101.c
Hi Marek, On Mon, 2016-04-11 at 20:48 +0200, Marek Vasut wrote: > On 04/11/2016 08:13 PM, Alexey Brodkin wrote: > > > > Hi Marek, > > > > On Mon, 2016-04-11 at 19:54 +0200, Marek Vasut wrote: > > > > > > On 04/11/2016 07:48 PM, Alexey Brodkin wrote: > > > > > > > > > > > > Hi Alex, > > > > > > > > On Mon, 2016-04-04 at 09:38 +0200, Alexander Graf wrote: > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > Marek just pointed out to me the fact that flush_dcache_range on arm > > > > > expects cache line aligned arguments. However, it seems like in > > > > > axs101.c > > > > > we have an unaligned cache flush: > > > > > > > > > > flush_dcache_range(RESET_VECTOR_ADDR, RESET_VECTOR_ADDR + > > > > > sizeof(int)); > > > > > > > > > > Could you please verify whether this is correct and if not just send a > > > > > quick patch to fix it? > > > > First this code is for support of Synopsys DesignWare AXS10x boards. > > > > And AFAIK there's no such board that may sport ARM CPU instead or ARC. > > > > So I'm wondering how did you bumped into that [issue?]? > > > > > > > > Then I'm not really sure if there's a common requirement for arguments > > > > of > > > > flush_dcache_range(). At least in "include/common.h" there's no comment > > > > about > > > > that. > > > Such comment should then be added. Sub-cacheline flush/invalidate calls > > > can corrupt surrounding data. > > Well this is not that simple really. > > > > For example that's what we have on ARC: > > > > [1] We may deal with each cache line separately. And BTW that's what we have > > now in U-boot, see > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arc/lib/cache.c#l328 > > In that case we only mention address of cache line start and regardless > > of its length > > line will be processed by HW. > Can you flush/invalidate on sub-cacheline level? If not, you should not > paper over the issue and avoid re-aligning the end address. > > > > > [2] We may although deal with ranges as well (still this is not implemented > > in u-boot yet). > > In that case we need to set addresses of range beginning and end. > > But if start address falls actually in the middle of cache line it will > > be processed. > > And the same is valid for end of the region. > Same complaint as above, if you cannot flush with sub-cacheline > granularity, do not paper over the issue by re-aligning the start address. > > > > > So from above I may conclude that it's more important to place data > > properly in memory. > > I.e. if you put 2 completely independent substances in 1 cache line you > > won't be able to > > deal with cache entries for them separately (at least on ARC). > > > > I'm not really sure if ARM or any other arch in hardware may > > invalidate/writeback only part of > > one cache line - that might very well be the case. > It can not, which is the reason we have a warning on sub-cacheline > invalidate/flush on ARM. > > > > > But in the original case my implementation makes perfect sense because what > > it does > > it writes back instructions modified by the active CPU so others may see > > these changes. > > and here I'd like ideally to have an option to write back only 1 CPU word > > (because that's > > what I really modified) but this is not possible due to described above > > limitations of our HW. > Consider a layout where you have first half of the cacheline used as > DMAble memory while the second half of the cacheline is used for some > variable, say some counter. > > Consider this sequence of operations: > > 1. start DMA > 2. counter++ > 3. invalidate_dcache_line > 4. read DMAed buffer > 5. print the counter > > What will happen in step 5 ? Will you get the incremented counter or the > stale data which were in the DRAM ? > > I see it this way -- In step 3, the increment of counter performed in > step 2 will be discarded. In step 4, the cacheline will be re-populated > by stale data from DRAM and in step 5, you will print the old value of > the counter. Let's not mix data and tools that operate with that data. Cache management functions should be implemented per arch or platform and so that they match requirements of underlying hardware. If hardware may only work on whole cache line then cache routines must do exactly this. As an extra options there could be a check for input arguments in those functions that will warn a user if he or she passes unaligned start and/or end addresses. Now speaking about data layout your example is very correct and we saw a lot of such real use-cases - developer of drivers should design data layout such that cache management doesn't lead to data corruption. But again the code in question has nothing to do with cache line. I only need to writeback 1 word and don't care what really happens with all remaining words in the same cache line. And my implementation of flush_dcache_range() will do everything perfectly correct - it will flush exactly 1 line that co
Re: [U-Boot] Unaligned flush_dcache_range in axs101.c
On 04/15/2016 03:00 PM, Alexey Brodkin wrote: > Hi Marek, > > On Mon, 2016-04-11 at 20:48 +0200, Marek Vasut wrote: >> On 04/11/2016 08:13 PM, Alexey Brodkin wrote: >>> >>> Hi Marek, >>> >>> On Mon, 2016-04-11 at 19:54 +0200, Marek Vasut wrote: On 04/11/2016 07:48 PM, Alexey Brodkin wrote: > > > Hi Alex, > > On Mon, 2016-04-04 at 09:38 +0200, Alexander Graf wrote: >> >> >> Hi Alexey, >> >> Marek just pointed out to me the fact that flush_dcache_range on arm >> expects cache line aligned arguments. However, it seems like in axs101.c >> we have an unaligned cache flush: >> >> flush_dcache_range(RESET_VECTOR_ADDR, RESET_VECTOR_ADDR + sizeof(int)); >> >> Could you please verify whether this is correct and if not just send a >> quick patch to fix it? > First this code is for support of Synopsys DesignWare AXS10x boards. > And AFAIK there's no such board that may sport ARM CPU instead or ARC. > So I'm wondering how did you bumped into that [issue?]? > > Then I'm not really sure if there's a common requirement for arguments of > flush_dcache_range(). At least in "include/common.h" there's no comment > about > that. Such comment should then be added. Sub-cacheline flush/invalidate calls can corrupt surrounding data. >>> Well this is not that simple really. >>> >>> For example that's what we have on ARC: >>> >>> [1] We may deal with each cache line separately. And BTW that's what we have >>> now in U-boot, see >>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arc/lib/cache.c#l328 >>> In that case we only mention address of cache line start and regardless >>> of its length >>> line will be processed by HW. >> Can you flush/invalidate on sub-cacheline level? If not, you should not >> paper over the issue and avoid re-aligning the end address. >> >>> >>> [2] We may although deal with ranges as well (still this is not implemented >>> in u-boot yet). >>> In that case we need to set addresses of range beginning and end. >>> But if start address falls actually in the middle of cache line it will >>> be processed. >>> And the same is valid for end of the region. >> Same complaint as above, if you cannot flush with sub-cacheline >> granularity, do not paper over the issue by re-aligning the start address. >> >>> >>> So from above I may conclude that it's more important to place data >>> properly in memory. >>> I.e. if you put 2 completely independent substances in 1 cache line you >>> won't be able to >>> deal with cache entries for them separately (at least on ARC). >>> >>> I'm not really sure if ARM or any other arch in hardware may >>> invalidate/writeback only part of >>> one cache line - that might very well be the case. >> It can not, which is the reason we have a warning on sub-cacheline >> invalidate/flush on ARM. >> >>> >>> But in the original case my implementation makes perfect sense because what >>> it does >>> it writes back instructions modified by the active CPU so others may see >>> these changes. >>> and here I'd like ideally to have an option to write back only 1 CPU word >>> (because that's >>> what I really modified) but this is not possible due to described above >>> limitations of our HW. >> Consider a layout where you have first half of the cacheline used as >> DMAble memory while the second half of the cacheline is used for some >> variable, say some counter. >> >> Consider this sequence of operations: >> >> 1. start DMA >> 2. counter++ >> 3. invalidate_dcache_line >> 4. read DMAed buffer >> 5. print the counter >> >> What will happen in step 5 ? Will you get the incremented counter or the >> stale data which were in the DRAM ? >> >> I see it this way -- In step 3, the increment of counter performed in >> step 2 will be discarded. In step 4, the cacheline will be re-populated >> by stale data from DRAM and in step 5, you will print the old value of >> the counter. > > Let's not mix data and tools that operate with that data. > > Cache management functions should be implemented per arch or platform and so > that they match requirements of underlying hardware. If hardware may only > work on > whole cache line then cache routines must do exactly this. Is ARC designed this way ? > As an extra options there could be a check for input arguments in those > functions > that will warn a user if he or she passes unaligned start and/or end > addresses. Right, ARMv7 does it already, ARM926 too, others need fixing. > Now speaking about data layout your example is very correct and we saw a lot > of > such real use-cases - developer of drivers should design data layout such that > cache management doesn't lead to data corruption. Right. > But again the code in question has nothing to do with cache line. > I only need to writeback 1 word and don't care what really happens with > all remaining words in the same cache line. And my implementation of
Re: [U-Boot] [PATCH] arm: dts: vf6: fix DTC unit warnings
On 04/15/2016 04:28 PM, Heiko Schocher wrote:
Fix following warnings for all vf6 based boards:
Warning (unit_address_vs_reg): Node
/soc/ifc@153/board-control@3,0/mdio-mux-emi1 has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node /soc/aips-bus@4000 has a unit name, but
no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@4008 has a unit name, but
no reg property
May be this fix[1] which Stefan Agner submitted lately is also
applicable here.
[1] https://lkml.org/lkml/2016/4/2/11
Signed-off-by: Heiko Schocher
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v
Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/u-boot/u-boot/jobs/122880431
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123238780
arch/arm/dts/ls1021a-qds.dtsi | 2 +-
arch/arm/dts/vf.dtsi | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/ls1021a-qds.dtsi b/arch/arm/dts/ls1021a-qds.dtsi
index ca9e835..4cb6337 100644
--- a/arch/arm/dts/ls1021a-qds.dtsi
+++ b/arch/arm/dts/ls1021a-qds.dtsi
@@ -138,7 +138,7 @@
device-width = <1>;
ranges = <0 3 0 0x100>;
- mdio-mux-emi1 {
+ mdio-mux-emi1@54 {
compatible = "mdio-mux-mmioreg";
mdio-parent-bus = <&mdio0>;
#address-cells = <1>;
diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
index 1530d2f..99f3269 100644
--- a/arch/arm/dts/vf.dtsi
+++ b/arch/arm/dts/vf.dtsi
@@ -28,7 +28,7 @@
compatible = "simple-bus";
ranges;
- aips0: aips-bus@4000 {
+ aips0: aips-bus_4000 {
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
@@ -115,7 +115,7 @@
};
};
- aips1: aips-bus@4008 {
+ aips1: aips-bus_4008 {
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
Best regards,
Bhuvan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: designware_i2c: Prepare for DM driver conversion
On 12 April 2016 at 07:21, Stefan Roese wrote: > This patch prepares the designware I2C driver for the DM conversion. > This is mainly done by removing struct i2c_adapter from the functions > that shall be used by the DM driver version as well. > > Signed-off-by: Stefan Roese > Cc: Simon Glass > Reviewed-by: Bin Meng > Cc: Marek Vasut > Cc: Heiko Schocher > --- > v3: > - Rebased on top of latest version > > drivers/i2c/designware_i2c.c | 173 > ++- > 1 file changed, 90 insertions(+), 83 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 01/10] drivers: usb: dwc3: remove devm_zalloc from linux_compact
Hi Mugunthan, On 15 March 2016 at 07:59, Tom Rini wrote: > > On Tue, Mar 15, 2016 at 05:44:10PM +0530, Mugunthan V N wrote: > > > devm_zalloc() is already defined in dm/device.h header, so > > devm_zalloc can be removed from linux_compact.h beader file. > > > > Signed-off-by: Mugunthan V N > > Reviewed-by: Tom Rini > > -- > Tom Unfortunately I still cannot apply this as there are build errors. Can you please take a look and resend the entire series (along with the lonely patch) rebased to u-boot-dm/master? 09: drivers: usb: dwc3: remove devm_zalloc from linux_compact arm: + omap5_uevm + omap = devm_kzalloc((struct udevice *)dev, sizeof(*omap), GFP_KERNEL); + ^ + ^ +drivers/usb/dwc3/built-in.o: In function `dwc3_omap_uboot_init': +build/../drivers/usb/dwc3/dwc3-omap.c:380: undefined reference to `devm_kzalloc' +arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696 +arm-unknown-linux-gnueabi-ld.bfd: error: required section '.rel.plt' not found in the linker script +arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 w+../drivers/usb/dwc3/dwc3-omap.c: In function 'dwc3_omap_uboot_init': w+../drivers/usb/dwc3/dwc3-omap.c:380:2: warning: implicit declaration of function 'devm_kzalloc' [-Wimplicit-function-declaration] w+../drivers/usb/dwc3/dwc3-omap.c:380:7: warning: assignment makes pointer from integer without a cast 10: drivers: usb: dwc3-omap: move usb_gadget_handle_interrupts from board files to drivers -build/../drivers/usb/dwc3/dwc3-omap.c:380: undefined reference to `devm_kzalloc' +drivers/usb/dwc3/built-in.o: In function `usb_gadget_handle_interrupts': +:(.text.usb_gadget_handle_interrupts+0x0): multiple definition of `usb_gadget_handle_interrupts' +board/ti/omap5_uevm/built-in.o:build/../board/ti/omap5_uevm/evm.c:122: first defined here +:(.text.dwc3_omap_uboot_init+0xa): undefined reference to `devm_kzalloc' w-../drivers/usb/dwc3/dwc3-omap.c:380:2: warning: implicit declaration of function 'devm_kzalloc' [-Wimplicit-function-declaration] w-../drivers/usb/dwc3/dwc3-omap.c:380:7: warning: assignment makes pointer from integer without a cast w+../drivers/usb/dwc3/dwc3-omap.c:381:2: warning: implicit declaration of function 'devm_kzalloc' [-Wimplicit-function-declaration] w+../drivers/usb/dwc3/dwc3-omap.c:381:7: warning: assignment makes pointer from integer without a cast 11: am437x: board: do not register usb devices when CONFIG_DM_USB is defined 12: dra7xx: board: do not register usb devices when CONFIG_DM_USB is defined 13: drivers: usb: dwc3: add ti dwc3 misc driver for wrapper - omap = devm_kzalloc((struct udevice *)dev, sizeof(*omap), GFP_KERNEL); - ^ - ^ -drivers/usb/dwc3/built-in.o: In function `dwc3_omap_uboot_init': -:(.text.dwc3_omap_uboot_init+0xa): undefined reference to `devm_kzalloc' -arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696 -arm-unknown-linux-gnueabi-ld.bfd: error: required section '.rel.plt' not found in the linker script -arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation w-../drivers/usb/dwc3/dwc3-omap.c: In function 'dwc3_omap_uboot_init': w-../drivers/usb/dwc3/dwc3-omap.c:381:2: warning: implicit declaration of function 'devm_kzalloc' [-Wimplicit-function-declaration] w-../drivers/usb/dwc3/dwc3-omap.c:381:7: warning: assignment makes pointer from integer without a cast 14: drivers: usb: common: add support to get maximum speed from dt 15: drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model support arm: + odroid-xu3 +board/samsung/common/built-in.o: In function `board_usb_cleanup': +build/../board/samsung/common/board.c:382: undefined reference to `dwc3_uboot_exit' +board/samsung/common/built-in.o: In function `usb_gadget_handle_interrupts': +build/../board/samsung/common/exynos5-dt.c:318: undefined reference to `dwc3_uboot_handle_interrupt' +board/samsung/common/built-in.o: In function `board_usb_init': +build/../board/samsung/common/exynos5-dt.c:335: undefined reference to `dwc3_uboot_init' +arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696 +arm-unknown-linux-gnueabi-ld.bfd: error: required section '.rel.plt' not found in the linker script +arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation 16: am43xx: Add USB device boot support to SPL Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use
On 12 April 2016 at 13:11, Tom Rini wrote: > In rollback_space_kernel we were not initializing the reserved fields > which should be for safety sake, and doing memset here means we don't > need to set the version field specifically either. > > Reported-by: Coverity (CID: 143917) > Cc: Simon Glass > Signed-off-by: Tom Rini > --- > drivers/tpm/tpm_tis_sandbox.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 v2 1/2] m68k: add malloc memory for early malloc
Hi Angelo, On 27 December 2015 at 21:22, Simon Glass wrote: > On 20 December 2015 at 08:54, Angelo Dureghello wrote: >> To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used. >> So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and >> call to board_init_f_mem() is added for all cpu's. >> >> Signed-off-by: Angelo Dureghello >> >> --- >> >> Changes in v2: None >> >> arch/m68k/cpu/mcf5227x/start.S | 8 >> arch/m68k/cpu/mcf523x/start.S| 8 >> arch/m68k/cpu/mcf52x2/start.S| 8 >> arch/m68k/cpu/mcf530x/cpu_init.c | 2 +- >> arch/m68k/cpu/mcf530x/start.S| 8 >> arch/m68k/cpu/mcf532x/start.S| 8 >> arch/m68k/cpu/mcf5445x/start.S | 8 >> arch/m68k/cpu/mcf547x_8x/start.S | 8 >> arch/m68k/include/asm/config.h | 2 -- >> 9 files changed, 57 insertions(+), 3 deletions(-) > > Reviewed-by: Simon Glass Unfortunately this breaks a lot of boards so I cannot apply it: 22: m68k: add malloc memory for early malloc m68k: + M5475FFE M5475GFE M5485AFE M5475BFE M52277EVB M5485FFE M54451EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5475EFE M5485CFE M54451EVB_stmicro M5485BFE M5485HFE M54418TWR_serial_rmii M5475DFE M52277EVB_stmicro M5475AFE M5485GFE M54418TWR_nand_mii eb_cpu5282_internal amcore M53017EVB M54418TWR_nand_rmii_lowfreq M54418TWR M5475CFE M5485EFE M5485DFE eb_cpu5282 +arch/m68k/cpu/mcf547x_8x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf547x_8x/start.S:153: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf547x_8x/start.S:153:(.text+0x470): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 +arch/m68k/cpu/mcf5227x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf5227x/start.S:384: undefined reference to `board_init_f_mem' +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf5445x/start.S:669: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf5445x/start.S:669:(.text+0x41c): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +build/../arch/m68k/cpu/mcf5227x/start.S:384:(.text+0x44a): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf52x2/start.o: In function `_after_flashbar_copy': +build/../arch/m68k/cpu/mcf52x2/start.S:203: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x494): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf530x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf530x/start.S:142: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf530x/start.S:142:(.text+0x45e): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf532x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf532x/start.S:160: undefined reference to `board_init_f_mem' +arch/m68k/cpu/mcf52x2/start.o: In function `_start': +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x456): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: dts: socfpga: fix DTC unit name warnings
On 04/15/2016 12:41 PM, Heiko Schocher wrote:
> Fix following DTC warnings for all socfpga boards:
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
> no unit name
> Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/main_pll has
> a reg or ranges property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/main_pll/mpuclk has a reg or ranges property, but
> no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/main_pll/mainclk has a reg or ranges property,
> but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/main_pll/dbg_base_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/main_pll/main_qspi_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/main_pll/main_nand_sdmmc_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/main_pll/cfg_h2f_usr0_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/periph_pll
> has a reg or ranges property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/periph_pll/emac0_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/periph_pll/emac1_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/periph_pll/per_qsi_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/periph_pll/per_nand_mmc_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/periph_pll/per_base_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/periph_pll/h2f_usr1_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node /soc/clkmgr@ffd04000/clocks/sdram_pll has
> a reg or ranges property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/sdram_pll/ddr_dqs_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/sdram_pll/ddr_2x_dqs_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/sdram_pll/ddr_dq_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node
> /soc/clkmgr@ffd04000/clocks/sdram_pll/h2f_usr2_clk has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): Node /soc/usbphy@0 has a unit name, but no reg
> property
How come Linux isn't affected by this ?
> Signed-off-by: Heiko Schocher
> ---
> This warnings pop up with the DTC compiler:
> $ /tmp/dtc/dtc -v
> Version: DTC 1.4.1-gbeef80b8
>
> This fixes the compile warnings for:
> https://travis-ci.org/u-boot/u-boot/jobs/122880430
>
> see:
> https://travis-ci.org/hsdenx/u-boot/jobs/123238779
>
> arch/arm/dts/skeleton.dtsi | 2 +-
> arch/arm/dts/socfpga.dtsi | 40
> +-
> arch/arm/dts/socfpga_arria5_socdk.dts | 2 +-
> arch/arm/dts/socfpga_cyclone5_de0_nano_soc.dts | 2 +-
> arch/arm/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
> arch/arm/dts/socfpga_cyclone5_socdk.dts| 2 +-
> arch/arm/dts/socfpga_cyclone5_sockit.dts | 2 +-
> arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 +-
> 8 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/dts/skeleton.dtsi b/arch/arm/dts/skeleton.dtsi
> index b41d241..a20da0a 100644
> --- a/arch/arm/dts/skeleton.dtsi
> +++ b/arch/arm/dts/skeleton.dtsi
> @@ -9,5 +9,5 @@
> #size-cells = <1>;
> chosen { };
> aliases { };
> - memory { device_type = "memory"; reg = <0 0>; };
> + memory@0 { device_type = "memory"; reg = <0 0>; };
> };
Can you split this into skeleton.dtsi patch and socfpga-only patch?
That'd help containing the changes.
Thanks!
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm, m68k: fix out-of-range jump
Hi Heiko, On 15/04/2016 12:59, Heiko Schocher wrote: fix the following build error for m68k boards: Building current source for 48 boards (2 threads, 1 job per thread) m68k: + M54455EVB_i66 +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +arch/m68k/cpu/mcf5445x/start.S:668:(.text+0x45a): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 Signed-off-by: Heiko Schocher --- This commit fixes build error: https://travis-ci.org/hsdenx/u-boot/jobs/123254183 fixed log see: https://travis-ci.org/hsdenx/u-boot/jobs/123281032 Any ideas why the changes did not work for: arch/m68k/cpu/mcf523x/start.S arch/m68k/cpu/mcf52x2/start.S arch/m68k/cpu/mcf532x/start.S but work for arch/m68k/cpu/mcf5445x/start.S I have no real m68k experiences, so help is appreciated! arch/m68k/cpu/mcf523x/start.S | 4 ++-- arch/m68k/cpu/mcf52x2/start.S | 4 ++-- arch/m68k/cpu/mcf532x/start.S | 4 ++-- arch/m68k/cpu/mcf5445x/start.S | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S index 8a23e72..ad7bde4 100644 --- a/arch/m68k/cpu/mcf523x/start.S +++ b/arch/m68k/cpu/mcf523x/start.S @@ -141,8 +141,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S index 8a59496..a16b589 100644 --- a/arch/m68k/cpu/mcf52x2/start.S +++ b/arch/m68k/cpu/mcf52x2/start.S @@ -198,8 +198,8 @@ _after_flashbar_copy: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf532x/start.S b/arch/m68k/cpu/mcf532x/start.S index 3b9ede0..50d301c 100644 --- a/arch/m68k/cpu/mcf532x/start.S +++ b/arch/m68k/cpu/mcf532x/start.S @@ -155,8 +155,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf5445x/start.S b/arch/m68k/cpu/mcf5445x/start.S index ae261b1..ff8d627 100644 --- a/arch/m68k/cpu/mcf5445x/start.S +++ b/arch/m68k/cpu/mcf5445x/start.S @@ -664,8 +664,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ I just sent a very similar patch some days ago. https://patchwork.ozlabs.org/patch/609150/ Issue should be fixed. Regards, Angelo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: gadget: Disable gadget options in SPL
During Kconfig migrating process we missed to check some gadget options for SPL_BUILD. Do it now to properly disable gadget in SPL build for those platforms that disabled it before migrating options to Kconfig. Signed-off-by: Sam Protsenko --- include/configs/am43xx_evm.h | 1 + include/configs/mx6sabre_common.h | 11 +++ include/configs/siemens-am33x-common.h| 10 ++ include/configs/smartweb.h| 9 + include/configs/tegra-common-usb-gadget.h | 11 +++ 5 files changed, 42 insertions(+) diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 5d5ae5e..c8beacd 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -127,6 +127,7 @@ #undef CONFIG_USB_DWC3 #undef CONFIG_USB_DWC3_GADGET +#undef CONFIG_USB_GADGET #undef CONFIG_USB_GADGET_DOWNLOAD #undef CONFIG_USB_GADGET_VBUS_DRAW #undef CONFIG_G_DNL_MANUFACTURER diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index 87bbf2e..5ca0fda 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -252,4 +252,15 @@ #define CONFIG_DFU_SF #endif +#ifdef CONFIG_SPL_BUILD +#undef CONFIG_CI_UDC +#undef CONFIG_USB_GADGET +#undef CONFIG_USB_GADGET_VBUS_DRAW +#undef CONFIG_USB_GADGET_DUALSPEED +#undef CONFIG_USB_GADGET_DOWNLOAD +#undef CONFIG_G_DNL_MANUFACTURER +#undef CONFIG_G_DNL_VENDOR_NUM +#undef CONFIG_G_DNL_PRODUCT_NUM +#endif + #endif /* __MX6QSABRE_COMMON_CONFIG_H */ diff --git a/include/configs/siemens-am33x-common.h b/include/configs/siemens-am33x-common.h index 5b94fad..d11566e 100644 --- a/include/configs/siemens-am33x-common.h +++ b/include/configs/siemens-am33x-common.h @@ -253,6 +253,16 @@ #endif /* CONFIG_SPL_BUILD */ +#ifdef CONFIG_SPL_BUILD +#undef CONFIG_USB_MUSB_GADGET +#undef CONFIG_USB_GADGET +#undef CONFIG_USB_GADGET_VBUS_DRAW +#undef CONFIG_USB_GADGET_DOWNLOAD +#undef CONFIG_G_DNL_MANUFACTURER +#undef CONFIG_G_DNL_VENDOR_NUM +#undef CONFIG_G_DNL_PRODUCT_NUM +#endif + /* * Default to using SPI for environment, etc. We have multiple copies * of SPL as the ROM will check these locations. diff --git a/include/configs/smartweb.h b/include/configs/smartweb.h index 0352379..f2e9b90 100644 --- a/include/configs/smartweb.h +++ b/include/configs/smartweb.h @@ -181,6 +181,15 @@ #define CONFIG_SYS_CACHELINE_SIZE 0x2000 #endif +#ifdef CONFIG_SPL_BUILD +#undef CONFIG_USB_GADGET +#undef CONFIG_USB_GADGET_VBUS_DRAW +#undef CONFIG_USB_GADGET_DOWNLOAD +#undef CONFIG_G_DNL_MANUFACTURER +#undef CONFIG_G_DNL_VENDOR_NUM +#undef CONFIG_G_DNL_PRODUCT_NUM +#endif + /* General Boot Parameter */ #define CONFIG_BOOTDELAY 3 #define CONFIG_BOOTCOMMAND "run flashboot" diff --git a/include/configs/tegra-common-usb-gadget.h b/include/configs/tegra-common-usb-gadget.h index 18851ca..1d6b99e 100644 --- a/include/configs/tegra-common-usb-gadget.h +++ b/include/configs/tegra-common-usb-gadget.h @@ -28,4 +28,15 @@ #define CONFIG_DFU_RAM #endif +#ifdef CONFIG_SPL_BUILD +#undef CONFIG_CI_UDC +#undef CONFIG_USB_GADGET +#undef CONFIG_USB_GADGET_VBUS_DRAW +#undef CONFIG_USB_GADGET_DUALSPEED +#undef CONFIG_USB_GADGET_DOWNLOAD +#undef CONFIG_G_DNL_MANUFACTURER +#undef CONFIG_G_DNL_VENDOR_NUM +#undef CONFIG_G_DNL_PRODUCT_NUM +#endif + #endif /* _TEGRA_COMMON_USB_GADGET_H_ */ -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] m68k: add malloc memory for early malloc
Hi Simon, On 15/04/2016 16:14, Simon Glass wrote: Hi Angelo, On 27 December 2015 at 21:22, Simon Glass wrote: On 20 December 2015 at 08:54, Angelo Dureghello wrote: To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used. So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and call to board_init_f_mem() is added for all cpu's. Signed-off-by: Angelo Dureghello --- Changes in v2: None arch/m68k/cpu/mcf5227x/start.S | 8 arch/m68k/cpu/mcf523x/start.S| 8 arch/m68k/cpu/mcf52x2/start.S| 8 arch/m68k/cpu/mcf530x/cpu_init.c | 2 +- arch/m68k/cpu/mcf530x/start.S| 8 arch/m68k/cpu/mcf532x/start.S| 8 arch/m68k/cpu/mcf5445x/start.S | 8 arch/m68k/cpu/mcf547x_8x/start.S | 8 arch/m68k/include/asm/config.h | 2 -- 9 files changed, 57 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass Unfortunately this breaks a lot of boards so I cannot apply it: 22: m68k: add malloc memory for early malloc m68k: + M5475FFE M5475GFE M5485AFE M5475BFE M52277EVB M5485FFE M54451EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5475EFE M5485CFE M54451EVB_stmicro M5485BFE M5485HFE M54418TWR_serial_rmii M5475DFE M52277EVB_stmicro M5475AFE M5485GFE M54418TWR_nand_mii eb_cpu5282_internal amcore M53017EVB M54418TWR_nand_rmii_lowfreq M54418TWR M5475CFE M5485EFE M5485DFE eb_cpu5282 +arch/m68k/cpu/mcf547x_8x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf547x_8x/start.S:153: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf547x_8x/start.S:153:(.text+0x470): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 +arch/m68k/cpu/mcf5227x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf5227x/start.S:384: undefined reference to `board_init_f_mem' +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf5445x/start.S:669: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf5445x/start.S:669:(.text+0x41c): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +build/../arch/m68k/cpu/mcf5227x/start.S:384:(.text+0x44a): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf52x2/start.o: In function `_after_flashbar_copy': +build/../arch/m68k/cpu/mcf52x2/start.S:203: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x494): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf530x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf530x/start.S:142: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf530x/start.S:142:(.text+0x45e): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf532x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf532x/start.S:160: undefined reference to `board_init_f_mem' +arch/m68k/cpu/mcf52x2/start.o: In function `_start': +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x456): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' Issue was not there at that submit time, now it seems due to growing of u-boot size. The "truncated to fit" issue is fixed with this patch. https://patchwork.ozlabs.org/patch/609150/ So if you apply the above, and then this current, all should work. Regards, Angelo Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: zynq: Fix microzed build
Add missing USB gadget options, so that microzed platfrom is uniform to other zed platforms. This fixes build with zynq_microzed_defconfig. Signed-off-by: Sam Protsenko --- configs/zynq_microzed_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig index bd261c1..fb0a9ea 100644 --- a/configs/zynq_microzed_defconfig +++ b/configs/zynq_microzed_defconfig @@ -25,3 +25,8 @@ CONFIG_USB=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y +CONFIG_CI_UDC=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_G_DNL_MANUFACTURER="Xilinx" +CONFIG_G_DNL_VENDOR_NUM=0x03fd +CONFIG_G_DNL_PRODUCT_NUM=0x0300 -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] m68k: add malloc memory for early malloc
Hi Angelo, On 15 April 2016 at 08:42, Angelo Dureghello wrote: > Hi Simon, > > > On 15/04/2016 16:14, Simon Glass wrote: >> >> Hi Angelo, >> >> On 27 December 2015 at 21:22, Simon Glass wrote: >>> >>> On 20 December 2015 at 08:54, Angelo Dureghello wrote: To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used. So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and call to board_init_f_mem() is added for all cpu's. Signed-off-by: Angelo Dureghello --- Changes in v2: None arch/m68k/cpu/mcf5227x/start.S | 8 arch/m68k/cpu/mcf523x/start.S| 8 arch/m68k/cpu/mcf52x2/start.S| 8 arch/m68k/cpu/mcf530x/cpu_init.c | 2 +- arch/m68k/cpu/mcf530x/start.S| 8 arch/m68k/cpu/mcf532x/start.S| 8 arch/m68k/cpu/mcf5445x/start.S | 8 arch/m68k/cpu/mcf547x_8x/start.S | 8 arch/m68k/include/asm/config.h | 2 -- 9 files changed, 57 insertions(+), 3 deletions(-) >>> >>> >>> Reviewed-by: Simon Glass >> >> >> Unfortunately this breaks a lot of boards so I cannot apply it: >> >> 22: m68k: add malloc memory for early malloc >>m68k: + M5475FFE M5475GFE M5485AFE M5475BFE M52277EVB >> M5485FFE M54451EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5475EFE >> M5485CFE M54451EVB_stmicro M5485BFE M5485HFE M54418TWR_serial_rmii >> M5475DFE M52277EVB_stmicro M5475AFE M5485GFE M54418TWR_nand_mii >> eb_cpu5282_internal amcore M53017EVB M54418TWR_nand_rmii_lowfreq >> M54418TWR M5475CFE M5485EFE M5485DFE eb_cpu5282 >> +arch/m68k/cpu/mcf547x_8x/start.o: In function `_start': >> +build/../arch/m68k/cpu/mcf547x_8x/start.S:153: undefined reference to >> `board_init_f_mem' >> +build/../arch/m68k/cpu/mcf547x_8x/start.S:153:(.text+0x470): >> relocation truncated to fit: R_68K_PC16 against undefined symbol >> `board_init_f_mem' >> +make[1]: *** [u-boot] Error 1 >> +make: *** [sub-make] Error 2 >> +arch/m68k/cpu/mcf5227x/start.o: In function `_start': >> +build/../arch/m68k/cpu/mcf5227x/start.S:384: undefined reference to >> `board_init_f_mem' >> +arch/m68k/cpu/mcf5445x/start.o: In function `_start': >> +build/../arch/m68k/cpu/mcf5445x/start.S:669: undefined reference to >> `board_init_f_mem' >> +build/../arch/m68k/cpu/mcf5445x/start.S:669:(.text+0x41c): relocation >> truncated to fit: R_68K_PC16 against undefined symbol >> `board_init_f_mem' >> +build/../arch/m68k/cpu/mcf5227x/start.S:384:(.text+0x44a): relocation >> truncated to fit: R_68K_PC16 against undefined symbol >> `board_init_f_mem' >> +arch/m68k/cpu/mcf52x2/start.o: In function `_after_flashbar_copy': >> +build/../arch/m68k/cpu/mcf52x2/start.S:203: undefined reference to >> `board_init_f_mem' >> +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x494): relocation >> truncated to fit: R_68K_PC16 against undefined symbol >> `board_init_f_mem' >> +arch/m68k/cpu/mcf530x/start.o: In function `_start': >> +build/../arch/m68k/cpu/mcf530x/start.S:142: undefined reference to >> `board_init_f_mem' >> +build/../arch/m68k/cpu/mcf530x/start.S:142:(.text+0x45e): relocation >> truncated to fit: R_68K_PC16 against undefined symbol >> `board_init_f_mem' >> +arch/m68k/cpu/mcf532x/start.o: In function `_start': >> +build/../arch/m68k/cpu/mcf532x/start.S:160: undefined reference to >> `board_init_f_mem' >> +arch/m68k/cpu/mcf52x2/start.o: In function `_start': >> +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x456): relocation >> truncated to fit: R_68K_PC16 against undefined symbol >> `board_init_f_mem' >> > > Issue was not there at that submit time, now it seems due to growing of > u-boot size. > > The "truncated to fit" issue is fixed with this patch. > > https://patchwork.ozlabs.org/patch/609150/ > > So if you apply the above, and then this current, all should work. There is mention of a v2 patch there - is it coming? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> Fix following warnings for all mips based boards:
> mips: + pic32mzdask
> +Warning (unit_address_vs_reg): Node /memory has a reg or ranges property,
> but no unit name
> +Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no reg
> property
>
> Signed-off-by: Heiko Schocher
> ---
> This warnings pop up with the DTC compiler:
> $ /tmp/dtc/dtc -v
> Version: DTC 1.4.1-gbeef80b8
>
> This fixes the compile warnings for:
> https://travis-ci.org/hsdenx/u-boot/jobs/123254184
>
> see:
> https://travis-ci.org/hsdenx/u-boot/jobs/123281033
>
>
> arch/mips/dts/pic32mzda.dtsi | 2 +-
> arch/mips/dts/skeleton.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> index 8a554f9..791c364 100644
> --- a/arch/mips/dts/pic32mzda.dtsi
> +++ b/arch/mips/dts/pic32mzda.dtsi
> @@ -27,7 +27,7 @@
> };
>
> cpus {
> - cpu@0 {
> + cpu {
> compatible = "mips,mips14kc";
> };
> };
> diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> index 24ee6c3..643996c 100644
> --- a/arch/mips/dts/skeleton.dtsi
> +++ b/arch/mips/dts/skeleton.dtsi
> @@ -16,7 +16,7 @@
> aliases {
> };
>
> - memory {
> + memory@0 {
I have just been told on linux-rockchip mailing list that such a change
should not be done as /memory is being special-cased in dtc warnings for
the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
size on /memory@0.
If that is untrue, please someone object on the Linux mailing lists.
Regards,
Andreas
> device_type = "memory";
> reg = <0 0>;
> };
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: implement dev_get_addr_name()
On 6 April 2016 at 17:16, Simon Glass wrote: > On 6 April 2016 at 12:49, Stephen Warren wrote: >> From: Stephen Warren >> >> This function parses the reg property based on an index found in the >> reg-names property. This is required for bindings that are written >> using reg-names rather than hard-coding indices in reg. >> >> Signed-off-by: Stephen Warren >> --- >> drivers/core/device.c | 16 >> include/dm/device.h | 12 >> 2 files changed, 28 insertions(+) > > Acked-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use
On 15 April 2016 at 08:12, Simon Glass wrote: > On 12 April 2016 at 13:11, Tom Rini wrote: >> In rollback_space_kernel we were not initializing the reserved fields >> which should be for safety sake, and doing memset here means we don't >> need to set the version field specifically either. >> >> Reported-by: Coverity (CID: 143917) >> Cc: Simon Glass >> Signed-off-by: Tom Rini >> --- >> drivers/tpm/tpm_tis_sandbox.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sandbox: Enable many more commands
On 19 March 2016 at 18:33, Tom Rini wrote: > > On Sat, Mar 19, 2016 at 06:25:48PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On 15 March 2016 at 21:32, Simon Glass wrote: > > > > > > On 15 March 2016 at 11:20, Tom Rini wrote: > > > > good enough. > > > > - Make include like other arches do > > > > - Enable many many more drivers in sandbox_defconfig so that we can get > > > > more build-time testing on this platform. > > > > > > > > Cc: Simon Glass > > > > Signed-off-by: Tom Rini > > > > --- > > > > arch/sandbox/include/asm/cache.h |1 + > > > > arch/sandbox/include/asm/io.h|1 + > > > > configs/sandbox_defconfig| 56 > > > > -- > > > > 3 files changed, 56 insertions(+), 2 deletions(-) > > > > > > Great! > > > > > > Reviewed-by: Simon Glass > > > > I am seeing errors with this patch building for sandbox: > > > > tools/bin2header.c: In function ‘main’: > > tools/bin2header.c:26:3: warning: implicit declaration of function > > ‘read’ [-Wimplicit-function-declaration] > >nread = read(0, buf, sizeof(buf)); > >^ > > cmd/license.c:15:21: fatal error: license.h: No such file or directory > > #include > > ^ > > compilation terminated. > > make[2]: *** [cmd/license.o] Error 1 > > make[2]: *** Waiting for unfinished jobs > > make[1]: *** [cmd] Error 2 > > make[1]: *** Waiting for unfinished jobs > > make: *** [sub-make] Error 2 > > > > > > Can you take a look? If it matters I am doing an out-of-tree build. > > Yeah, sorry, this relies on the cmd: license patch I posted in order to > work as nothing uses the license command today and it's pretty badly > broken, but easily fixed. I was hoping Masahiro would chime in on the > kbuild fun that the patch does, but if you wanna pull it in that's fine, > I'll probably grab it soon otherwise myself. Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, Unfortunately I'm still unable to apply many of the patches in my queue due to build errors. But in the meantime, here are the ones that are OK. The following changes since commit ff6552e8cc13c9b2283002144e297d63b30ac400: R xpress: Update include (2016-04-13 15:45:50 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 7e019daf7ab9dca3bf782d6de866b36d44ede95e: drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use (2016-04-15 08:14:37 -0600) Jagan Teki (2): doc: driver-model: Update dm tests run using test.py board: README.sandbox: Update dm test command Nishanth Menon (1): dm: part: fix missing driver name in debug print Peng Fan (1): dm: core: device: set pinctrl state for pinctrl device Stefan Roese (1): dm: device.c: Minor coding-style fix Stephen Warren (1): fdt: implement dev_get_addr_name() Tom Rini (3): test/dm/core.c: Make pre-reloc test use pre-reloc struct sandbox: Enable many more commands drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use arch/sandbox/include/asm/cache.h | 1 + arch/sandbox/include/asm/io.h| 1 + board/sandbox/README.sandbox | 3 +- configs/sandbox_defconfig| 63 +++--- disk/part.c | 3 +- doc/driver-model/README.txt | 229 - drivers/core/device.c| 31 ++--- drivers/tpm/tpm_tis_sandbox.c| 2 +- include/dm/device.h | 12 + test/dm/core.c | 2 +- 10 files changed, 230 insertions(+), 117 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: add missing gic_init_secure_percpu for non multi-entry
On 04/15/2016 05:41 AM, Masahiro Yamada wrote: Per-CPU initialization of GIC is necessary even when CONFIG_ARMV8_MULTIENTRY is undefined. diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S @@ -208,6 +208,8 @@ WEAK(lowlevel_init) */ ldr x0, =GICD_BASE bl gic_init_secure + ldr x0, =GICR_BASE + bl gic_init_secure_percpu #endif #else /* CONFIG_ARMV8_MULTIENTRY is set */ #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) The #else branch currently there does something quite different for GICV2 and GICV3. The code you added above seems to be identical to that code's GIVC3 case and ignore GICV2. I assume that's a bug? If so, and the fix is to make the non-multientry code do the exact same call to gic_init_secure_percpu that the multientry code does, I would suggest unifying the two branches, replacing that entire top-level #if/#else block with: #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef CONFIG_ARMV8_MULTIENTRY branch_if_slave x0, 1f #endif ldr x0, =GICD_BASE bl gic_init_secure 1: #if defined(CONFIG_GICV3) ldr x0, =GICR_BASE bl gic_init_secure_percpu #elif defined(CONFIG_GICV2) ldr x0, =GICD_BASE ldr x1, =GICC_BASE bl gic_init_secure_percpu #endif #endif At least, that's what I think looking at the code with basically zero understanding of what initialization the GIC actually needs... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> > Fix following warnings for all mips based boards:
> > mips: + pic32mzdask
> > +Warning (unit_address_vs_reg): Node /memory has a reg or ranges property,
> > but no unit name
> > +Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no
> > reg property
> >
> > Signed-off-by: Heiko Schocher
> > ---
> > This warnings pop up with the DTC compiler:
> > $ /tmp/dtc/dtc -v
> > Version: DTC 1.4.1-gbeef80b8
> >
> > This fixes the compile warnings for:
> > https://travis-ci.org/hsdenx/u-boot/jobs/123254184
> >
> > see:
> > https://travis-ci.org/hsdenx/u-boot/jobs/123281033
> >
> >
> > arch/mips/dts/pic32mzda.dtsi | 2 +-
> > arch/mips/dts/skeleton.dtsi | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> > index 8a554f9..791c364 100644
> > --- a/arch/mips/dts/pic32mzda.dtsi
> > +++ b/arch/mips/dts/pic32mzda.dtsi
> > @@ -27,7 +27,7 @@
> > };
> >
> > cpus {
> > - cpu@0 {
> > + cpu {
> > compatible = "mips,mips14kc";
> > };
> > };
> > diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> > index 24ee6c3..643996c 100644
> > --- a/arch/mips/dts/skeleton.dtsi
> > +++ b/arch/mips/dts/skeleton.dtsi
> > @@ -16,7 +16,7 @@
> > aliases {
> > };
> >
> > - memory {
> > + memory@0 {
>
> I have just been told on linux-rockchip mailing list that such a change
> should not be done as /memory is being special-cased in dtc warnings for
> the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> size on /memory@0.
>
> If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
commit c9d9121683b35281239305e15adddfff2b462cf9
Author: Stephen Warren
Date: Fri Feb 19 15:59:29 2016 +1100
Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
node that has a reg property must include a unit address in its name
with value matching the first entry in its reg property. Conversely, if
a node does not have a reg property, the node name must not include a
unit address. Also allow ranges property as it is deemed valid, but ePAPR
is not clear about it.
Implement a check for this. The code doesn't validate the format of the
unit address; ePAPR implies this may vary from (containing bus) binding
to binding, so doing so would be much more complex.
Signed-off-by: Stephen Warren
[robh: also allow non-empty ranges]
Signed-off-by: Rob Herring
[moved new test in check_table]
Signed-off-by: David Gibson
That's where that warning comes from.
But some real quick grepping makes it seem like the cpu@0 error is also
a sign of a bigger problem in the dts file
But I would suggest that whomever is making special case warnings for
U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're
not a black box...
--
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 v2 1/2] m68k: add malloc memory for early malloc
Hi Simon, On 15/04/2016 17:23, Simon Glass wrote: Hi Angelo, On 15 April 2016 at 08:42, Angelo Dureghello wrote: Hi Simon, On 15/04/2016 16:14, Simon Glass wrote: Hi Angelo, On 27 December 2015 at 21:22, Simon Glass wrote: On 20 December 2015 at 08:54, Angelo Dureghello wrote: To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used. So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and call to board_init_f_mem() is added for all cpu's. Signed-off-by: Angelo Dureghello --- Changes in v2: None arch/m68k/cpu/mcf5227x/start.S | 8 arch/m68k/cpu/mcf523x/start.S| 8 arch/m68k/cpu/mcf52x2/start.S| 8 arch/m68k/cpu/mcf530x/cpu_init.c | 2 +- arch/m68k/cpu/mcf530x/start.S| 8 arch/m68k/cpu/mcf532x/start.S| 8 arch/m68k/cpu/mcf5445x/start.S | 8 arch/m68k/cpu/mcf547x_8x/start.S | 8 arch/m68k/include/asm/config.h | 2 -- 9 files changed, 57 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass Unfortunately this breaks a lot of boards so I cannot apply it: 22: m68k: add malloc memory for early malloc m68k: + M5475FFE M5475GFE M5485AFE M5475BFE M52277EVB M5485FFE M54451EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5475EFE M5485CFE M54451EVB_stmicro M5485BFE M5485HFE M54418TWR_serial_rmii M5475DFE M52277EVB_stmicro M5475AFE M5485GFE M54418TWR_nand_mii eb_cpu5282_internal amcore M53017EVB M54418TWR_nand_rmii_lowfreq M54418TWR M5475CFE M5485EFE M5485DFE eb_cpu5282 +arch/m68k/cpu/mcf547x_8x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf547x_8x/start.S:153: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf547x_8x/start.S:153:(.text+0x470): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 +arch/m68k/cpu/mcf5227x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf5227x/start.S:384: undefined reference to `board_init_f_mem' +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf5445x/start.S:669: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf5445x/start.S:669:(.text+0x41c): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +build/../arch/m68k/cpu/mcf5227x/start.S:384:(.text+0x44a): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf52x2/start.o: In function `_after_flashbar_copy': +build/../arch/m68k/cpu/mcf52x2/start.S:203: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x494): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf530x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf530x/start.S:142: undefined reference to `board_init_f_mem' +build/../arch/m68k/cpu/mcf530x/start.S:142:(.text+0x45e): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' +arch/m68k/cpu/mcf532x/start.o: In function `_start': +build/../arch/m68k/cpu/mcf532x/start.S:160: undefined reference to `board_init_f_mem' +arch/m68k/cpu/mcf52x2/start.o: In function `_start': +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x456): relocation truncated to fit: R_68K_PC16 against undefined symbol `board_init_f_mem' Issue was not there at that submit time, now it seems due to growing of u-boot size. The "truncated to fit" issue is fixed with this patch. https://patchwork.ozlabs.org/patch/609150/ So if you apply the above, and then this current, all should work. There is mention of a v2 patch there - is it coming? No, v2 was an attempt to fix the issue trough the linker script, but was too complex. So this is the definitive patch. Regards, Simon Regards, Angelo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
On 04/15/2016 10:30 AM, Tom Rini wrote:
On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Fix following warnings for all mips based boards:
mips: + pic32mzdask
+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
+Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no reg
property
Note that I am quite out-of-the-loop on these warning. I wrote the dtc
patch that triggers them years ago, but it's only recently been applied
due to Rob's efforts. I'm at most tangentially aware of the discussions
surrounding applying it now.
diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
cpus {
- cpu@0 {
+ cpu {
compatible = "mips,mips14kc";
Surely the correct fix is to add a reg property? (Of course, this
depends on the binding definition; for ARM my assertion would certainly
be true). If not, what does MIPS do about SMP? Even if you write, say, 4
nodes with name "cpu" they'll all become the same single node in the DTB.
diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
- memory {
+ memory@0 {
I have just been told on linux-rockchip mailing list that such a change
should not be done as /memory is being special-cased in dtc warnings for
the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
size on /memory@0.
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
I vaguely recall seeing discussion that /memory *would* be
special-cased, but as you point out obviously isn't yet. I doubt it's
anything to do with U-Boot itself, but rather the more general problem
that if /memory@ changes name based on what RAM is present, it's not
possible for any bootloader to update it in a sane way (what node name
do you search for to edit), or any OS to read it in a sane way (what
node name do you search for to find out where memory is). As such, a
special case is logically required.
commit c9d9121683b35281239305e15adddfff2b462cf9
Author: Stephen Warren
Date: Fri Feb 19 15:59:29 2016 +1100
Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
node that has a reg property must include a unit address in its name
with value matching the first entry in its reg property. Conversely, if
a node does not have a reg property, the node name must not include a
unit address. Also allow ranges property as it is deemed valid, but ePAPR
is not clear about it.
Implement a check for this. The code doesn't validate the format of the
unit address; ePAPR implies this may vary from (containing bus) binding
to binding, so doing so would be much more complex.
Signed-off-by: Stephen Warren
[robh: also allow non-empty ranges]
Signed-off-by: Rob Herring
[moved new test in check_table]
Signed-off-by: David Gibson
That's where that warning comes from.
But some real quick grepping makes it seem like the cpu@0 error is also
a sign of a bigger problem in the dts file
But I would suggest that whomever is making special case warnings for
U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're
not a black box...
Equally though, anyone working on DT in U-Boot should be hanging out on
the device tree mailing list, and getting actively involved in
discussions, rather than hiding here.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
On Fri, Apr 15, 2016 at 10:56:40AM -0600, Stephen Warren wrote:
> On 04/15/2016 10:30 AM, Tom Rini wrote:
> >On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> >>Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> >>>Fix following warnings for all mips based boards:
> >>> mips: + pic32mzdask
> >>>+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property,
> >>>but no unit name
> >>>+Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no
> >>>reg property
>
> Note that I am quite out-of-the-loop on these warning. I wrote the
> dtc patch that triggers them years ago, but it's only recently been
> applied due to Rob's efforts. I'm at most tangentially aware of the
> discussions surrounding applying it now.
>
>
> >>>diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
>
> >>> cpus {
> >>>- cpu@0 {
> >>>+ cpu {
> >>> compatible = "mips,mips14kc";
>
> Surely the correct fix is to add a reg property? (Of course, this
> depends on the binding definition; for ARM my assertion would
> certainly be true). If not, what does MIPS do about SMP? Even if you
> write, say, 4 nodes with name "cpu" they'll all become the same
> single node in the DTB.
So the likely answer here is that the dtsi is wrong and needs to be
fixed rather than just dropping @0.
> >>>diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
>
> >>>- memory {
> >>>+ memory@0 {
> >>
> >>I have just been told on linux-rockchip mailing list that such a change
> >>should not be done as /memory is being special-cased in dtc warnings for
> >>the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> >>size on /memory@0.
> >>
> >>If that is untrue, please someone object on the Linux mailing lists.
> >
> >Uh, what? From dtc:
>
> I vaguely recall seeing discussion that /memory *would* be
> special-cased, but as you point out obviously isn't yet. I doubt
> it's anything to do with U-Boot itself, but rather the more general
> problem that if /memory@ changes name based on what RAM is
> present, it's not possible for any bootloader to update it in a sane
> way (what node name do you search for to edit), or any OS to read it
> in a sane way (what node name do you search for to find out where
> memory is). As such, a special case is logically required.
Right, makes sense. But it'll also have to handle that today (nearly)
everyone is /memory@.
> >commit c9d9121683b35281239305e15adddfff2b462cf9
> >Author: Stephen Warren
> >Date: Fri Feb 19 15:59:29 2016 +1100
> >
> > Warn on node name unit-address presence/absence mismatch
> >
> > ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> > node that has a reg property must include a unit address in its name
> > with value matching the first entry in its reg property. Conversely, if
> > a node does not have a reg property, the node name must not include a
> > unit address. Also allow ranges property as it is deemed valid, but
> > ePAPR
> > is not clear about it.
> >
> > Implement a check for this. The code doesn't validate the format of the
> > unit address; ePAPR implies this may vary from (containing bus) binding
> > to binding, so doing so would be much more complex.
> >
> > Signed-off-by: Stephen Warren
> > [robh: also allow non-empty ranges]
> > Signed-off-by: Rob Herring
> > [moved new test in check_table]
> > Signed-off-by: David Gibson
> >
> >That's where that warning comes from.
> >
> >But some real quick grepping makes it seem like the cpu@0 error is also
> >a sign of a bigger problem in the dts file
> >
> >But I would suggest that whomever is making special case warnings for
> >U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're
> >not a black box...
>
> Equally though, anyone working on DT in U-Boot should be hanging out
> on the device tree mailing list, and getting actively involved in
> discussions, rather than hiding here.
True. And devicetree-spec is very quiet and devicetree is very very
loud, and somewhere along the line for me at least vger kicked me off,
sigh. Fixing that at least.
--
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] mips: fix DTC unit warnings
On 04/15/2016 11:11 AM, Tom Rini wrote:
On Fri, Apr 15, 2016 at 10:56:40AM -0600, Stephen Warren wrote:
On 04/15/2016 10:30 AM, Tom Rini wrote:
On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Fix following warnings for all mips based boards:
mips: + pic32mzdask
+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
+Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no reg
property
Note that I am quite out-of-the-loop on these warning. I wrote the
dtc patch that triggers them years ago, but it's only recently been
applied due to Rob's efforts. I'm at most tangentially aware of the
discussions surrounding applying it now.
diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
cpus {
- cpu@0 {
+ cpu {
compatible = "mips,mips14kc";
Surely the correct fix is to add a reg property? (Of course, this
depends on the binding definition; for ARM my assertion would
certainly be true). If not, what does MIPS do about SMP? Even if you
write, say, 4 nodes with name "cpu" they'll all become the same
single node in the DTB.
So the likely answer here is that the dtsi is wrong and needs to be
fixed rather than just dropping @0.
diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
- memory {
+ memory@0 {
I have just been told on linux-rockchip mailing list that such a change
should not be done as /memory is being special-cased in dtc warnings for
the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
size on /memory@0.
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
I vaguely recall seeing discussion that /memory *would* be
special-cased, but as you point out obviously isn't yet. I doubt
it's anything to do with U-Boot itself, but rather the more general
problem that if /memory@ changes name based on what RAM is
present, it's not possible for any bootloader to update it in a sane
way (what node name do you search for to edit), or any OS to read it
in a sane way (what node name do you search for to find out where
memory is). As such, a special case is logically required.
Right, makes sense. But it'll also have to handle that today (nearly)
everyone is /memory@.
Nodes without a unit address are far more common currently, on ARM at least:
u-boot$ grep -HrnI 'memory@' arch/arm/dts|wc -l
3
u-boot$ grep -HrnI 'memory {' arch/arm/dts|wc -l
86
kernel.git$ grep -HrnI 'memory {' arch/arm/boot/dts|wc -l
528
kernel.git$ grep -HrnI memory@ arch/arm/boot/dts|wc -l
27
kernel.git$ cat arch/arm/boot/dts/skeleton.dtsi
...
memory { device_type = "memory"; reg = <0 0>; };
(That last one is the base DT file that is typically included in all
board files, and so should in theory set the correct example).
U-Boot's /memory updating code doesn't handle a unit address; see
common/fdt_support.c fdt_fixup_memory_banks().
Linux's /memory parsing code doesn't handle a unit address, except for
one PPC32 special case; see drivers/of/fdt.c early_init_dt_scan_memory().
(Which makes me wonder how any of the systems which do have /memory@nnn
rather than plain /memory actual work...)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
On Fri, Apr 15, 2016 at 11:37:40AM -0600, Stephen Warren wrote:
> On 04/15/2016 11:11 AM, Tom Rini wrote:
> >On Fri, Apr 15, 2016 at 10:56:40AM -0600, Stephen Warren wrote:
> >>On 04/15/2016 10:30 AM, Tom Rini wrote:
> >>>On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> >Fix following warnings for all mips based boards:
> > mips: + pic32mzdask
> >+Warning (unit_address_vs_reg): Node /memory has a reg or ranges
> >property, but no unit name
> >+Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no
> >reg property
> >>
> >>Note that I am quite out-of-the-loop on these warning. I wrote the
> >>dtc patch that triggers them years ago, but it's only recently been
> >>applied due to Rob's efforts. I'm at most tangentially aware of the
> >>discussions surrounding applying it now.
> >>
> >>
> >diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> >>
> > cpus {
> >-cpu@0 {
> >+cpu {
> > compatible = "mips,mips14kc";
> >>
> >>Surely the correct fix is to add a reg property? (Of course, this
> >>depends on the binding definition; for ARM my assertion would
> >>certainly be true). If not, what does MIPS do about SMP? Even if you
> >>write, say, 4 nodes with name "cpu" they'll all become the same
> >>single node in the DTB.
> >
> >So the likely answer here is that the dtsi is wrong and needs to be
> >fixed rather than just dropping @0.
> >
> >diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> >>
> >-memory {
> >+memory@0 {
>
> I have just been told on linux-rockchip mailing list that such a change
> should not be done as /memory is being special-cased in dtc warnings for
> the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> size on /memory@0.
>
> If that is untrue, please someone object on the Linux mailing lists.
> >>>
> >>>Uh, what? From dtc:
> >>
> >>I vaguely recall seeing discussion that /memory *would* be
> >>special-cased, but as you point out obviously isn't yet. I doubt
> >>it's anything to do with U-Boot itself, but rather the more general
> >>problem that if /memory@ changes name based on what RAM is
> >>present, it's not possible for any bootloader to update it in a sane
> >>way (what node name do you search for to edit), or any OS to read it
> >>in a sane way (what node name do you search for to find out where
> >>memory is). As such, a special case is logically required.
> >
> >Right, makes sense. But it'll also have to handle that today (nearly)
> >everyone is /memory@.
>
> Nodes without a unit address are far more common currently, on ARM at least:
Brain fart, you are correct. I git grepped both memory and cpu and then
got 'em backwards in my reply.
--
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] arm64: add missing gic_init_secure_percpu for non multi-entry
Hi Stephen, 2016-04-16 0:55 GMT+09:00 Stephen Warren : > On 04/15/2016 05:41 AM, Masahiro Yamada wrote: >> >> Per-CPU initialization of GIC is necessary even when >> CONFIG_ARMV8_MULTIENTRY is undefined. > > >> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > > >> @@ -208,6 +208,8 @@ WEAK(lowlevel_init) >> */ >> ldr x0, =GICD_BASE >> bl gic_init_secure >> + ldr x0, =GICR_BASE >> + bl gic_init_secure_percpu >> #endif >> #else /* CONFIG_ARMV8_MULTIENTRY is set */ >> #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) > > > The #else branch currently there does something quite different for GICV2 > and GICV3. The code you added above seems to be identical to that code's > GIVC3 case and ignore GICV2. I assume that's a bug? You are right. My new SoC is equipped with GICv3 and I missed the GICv2 case. > If so, and the fix is to make the non-multientry code do the exact same call > to gic_init_secure_percpu that the multientry code does, I would suggest > unifying the two branches, replacing that entire top-level #if/#else block > with: > > #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) > #ifdef CONFIG_ARMV8_MULTIENTRY > branch_if_slave x0, 1f > #endif > ldr x0, =GICD_BASE > bl gic_init_secure > 1: > #if defined(CONFIG_GICV3) > ldr x0, =GICR_BASE > bl gic_init_secure_percpu > #elif defined(CONFIG_GICV2) > ldr x0, =GICD_BASE > ldr x1, =GICC_BASE > bl gic_init_secure_percpu > #endif > #endif > > At least, that's what I think looking at the code with basically zero > understanding of what initialization the GIC actually needs... > Good idea! It fixes the problem I noticed and also makes the code much cleaner. Could you post it as a patch, please? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: fix DTC unit warnings
Am Freitag, 15. April 2016, 12:30:58 schrieb Tom Rini:
> On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> > Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> > > Fix following warnings for all mips based boards:
> > > mips: + pic32mzdask
> > >
> > > +Warning (unit_address_vs_reg): Node /memory has a reg or ranges
> > > property, but no unit name +Warning (unit_address_vs_reg): Node
> > > /cpus/cpu@0 has a unit name, but no reg property
> > >
> > > Signed-off-by: Heiko Schocher
> > > ---
> > > This warnings pop up with the DTC compiler:
> > > $ /tmp/dtc/dtc -v
> > > Version: DTC 1.4.1-gbeef80b8
> > >
> > > This fixes the compile warnings for:
> > > https://travis-ci.org/hsdenx/u-boot/jobs/123254184
> > >
> > > see:
> > > https://travis-ci.org/hsdenx/u-boot/jobs/123281033
> > >
> > > arch/mips/dts/pic32mzda.dtsi | 2 +-
> > > arch/mips/dts/skeleton.dtsi | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> > > index 8a554f9..791c364 100644
> > > --- a/arch/mips/dts/pic32mzda.dtsi
> > > +++ b/arch/mips/dts/pic32mzda.dtsi
> > > @@ -27,7 +27,7 @@
> > >
> > > };
> > >
> > > cpus {
> > >
> > > - cpu@0 {
> > > + cpu {
> > >
> > > compatible = "mips,mips14kc";
> > >
> > > };
> > >
> > > };
> > >
> > > diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> > > index 24ee6c3..643996c 100644
> > > --- a/arch/mips/dts/skeleton.dtsi
> > > +++ b/arch/mips/dts/skeleton.dtsi
> > > @@ -16,7 +16,7 @@
> > >
> > > aliases {
> > > };
> > >
> > > - memory {
> > > + memory@0 {
> >
> > I have just been told on linux-rockchip mailing list that such a change
> > should not be done as /memory is being special-cased in dtc warnings for
> > the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> > size on /memory@0.
> >
> > If that is untrue, please someone object on the Linux mailing lists.
>
> Uh, what? From dtc:
>
> commit c9d9121683b35281239305e15adddfff2b462cf9
> Author: Stephen Warren
> Date: Fri Feb 19 15:59:29 2016 +1100
>
> Warn on node name unit-address presence/absence mismatch
>
> ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> node that has a reg property must include a unit address in its name
> with value matching the first entry in its reg property. Conversely, if
> a node does not have a reg property, the node name must not include a
> unit address. Also allow ranges property as it is deemed valid, but
> ePAPR is not clear about it.
>
> Implement a check for this. The code doesn't validate the format of the
> unit address; ePAPR implies this may vary from (containing bus) binding
> to binding, so doing so would be much more complex.
>
> Signed-off-by: Stephen Warren
> [robh: also allow non-empty ranges]
> Signed-off-by: Rob Herring
> [moved new test in check_table]
> Signed-off-by: David Gibson
>
> That's where that warning comes from.
and that is supposed to get a special case for memory. On the kernel variant
of dtc the change got deactivated again and will only trigger the warnings
with a special command currently.
Also in another thread [0] on the arm-kernel-list Rob Herring explicitly
stated:
>> This has come up before and been beaten to death. Bottom line is plain
>> "memory" is allowed, and I plan to add that exception to dtc."
And as stated there as well, memory@0 is not correct in all cases, as it would
need to be memory@baseaddress, so for example on Rockchip
- memory@0 for the rk3288
- memory@6000 for rk3188 and other A9s
So it's definitly not suitable for a general node in that skeleton,dtsi
Heiko
[0] http://www.spinics.net/lists/arm-kernel/msg494038.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: Fix OUT transaction length alignment
On Thu, Apr 14, 2016 at 3:18 AM, Roger Quadros wrote:
> Hi,
>
> On 13/04/16 19:56, Sam Protsenko wrote:
> > On Wed, Apr 13, 2016 at 3:32 PM, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 13/04/16 15:01, Semen Protsenko wrote:
> >>> From: Sam Protsenko
> >>>
> >>> Some UDC controllers may require buffer size to be aligned to
> >>> wMaxPacketSize. It's indicated by gadget->quirk_ep_out_aligned_size
> >>> field being set to "true" (in UDC driver code). In that case
> >>> rx_bytes_expected must be aligned to wMaxPacket size, otherwise stuck
> on
> >>> transaction will happen. For example, it's required by DWC3 controller
> >>> data manual:
> >>>
> >>> section 8.2.3.3 Buffer Size Rules and Zero-Length Packets:
> >>>
> >>> For OUT endpoints, the following rules apply:
> >>> - The BUFSIZ field must be ≥ 1 byte.
> >>> - The total size of a Buffer Descriptor must be a multiple of
> >>> MaxPacketSize
> >>> - A received zero-length packet still requires a MaxPacketSize
> buffer.
> >>> Therefore, if the expected amount of data to be received is a
> multiple
> >>> of MaxPacketSize, software should add MaxPacketSize bytes to the
> buffer
> >>> to sink a possible zero-length packet at the end of the transfer.
> >>>
> >>> But other UDC controllers don't need such alignment, so mentioned field
> >>> is set to "false". If buffer size is aligned to wMaxPacketSize, those
> >>> controllers may stuck on transaction. The example is DWC2.
> >>>
> >>> This patch checks gadget->quirk_ep_out_aligned_size field and aligns
> >>> rx_bytes_expected to wMaxPacketSize only when it's needed.
> >>>
> >>> Signed-off-by: Sam Protsenko
> >>> ---
> >>> drivers/usb/gadget/f_fastboot.c | 9 +
> >>> 1 file changed, 9 insertions(+)
> >>>
> >>> diff --git a/drivers/usb/gadget/f_fastboot.c
> b/drivers/usb/gadget/f_fastboot.c
> >>> index 2e87fee..54dcce0 100644
> >>> --- a/drivers/usb/gadget/f_fastboot.c
> >>> +++ b/drivers/usb/gadget/f_fastboot.c
> >>> @@ -58,6 +58,7 @@ static unsigned int fastboot_flash_session_id;
> >>> static unsigned int download_size;
> >>> static unsigned int download_bytes;
> >>> static bool is_high_speed;
> >>> +static bool quirk_ep_out_aligned_size;
> >>>
> >>> static struct usb_endpoint_descriptor fs_ep_in = {
> >>> .bLength= USB_DT_ENDPOINT_SIZE,
> >>> @@ -240,6 +241,8 @@ static int fastboot_set_alt(struct usb_function *f,
> >>> debug("%s: func: %s intf: %d alt: %d\n",
> >>> __func__, f->name, interface, alt);
> >>>
> >>> + quirk_ep_out_aligned_size = gadget->quirk_ep_out_aligned_size;
> >>> +
> >>> /* make sure we don't enable the ep twice */
> >>> if (gadget->speed == USB_SPEED_HIGH) {
> >>> ret = usb_ep_enable(f_fb->out_ep, &hs_ep_out);
> >>> @@ -435,12 +438,18 @@ static unsigned int rx_bytes_expected(unsigned
> int maxpacket)
> >>> return 0;
> >>> if (rx_remain > EP_BUFFER_SIZE)
> >>> return EP_BUFFER_SIZE;
> >>> +
> >>> + if (!quirk_ep_out_aligned_size)
> >>> + goto out;
> >>> +
> >>> if (rx_remain < maxpacket) {
> >>> rx_remain = maxpacket;
> >>> } else if (rx_remain % maxpacket != 0) {
> >>> rem = rx_remain % maxpacket;
> >>> rx_remain = rx_remain + (maxpacket - rem);
> >>> }
> >>> +
> >>> +out:
> >>> return rx_remain;
> >>> }
> >>>
> >>>
> >>
> >> Why do we need a special flag for this driver if other drivers e.g.
> mass storage
> >> are doing perfectly fine without it?
> >>
> >
> > I don't know how it works in other gadgets, but please see this patch
> > in kernel: [1]. That patch is doing just the same as I did (and also
> > in gadget code), using usb_ep_align_maybe() function for alignment.
>
> NOTE: there haven't been such quirks in the kernel drivers except for that
> one
> driver that has a user mode interface and needs more moral policing for
> user
> provided buffers. So that example is not something we should be using as
> reference.
> Our buffers are alreay aligned to maxpacket size. The only thing we need
> to worry
> about is the length of the last transaction that is not integral multiple
> of
> maxpacket size.
>
> If my understanding is right all USB controllers should work fine with
> bulk OUT requests that are integral multiple of maxpacket size.
> So we shouldn't be needing any quirk flags.
>
> >
> >> This patch is just covering up the real problem, by bypassing the
> faulty code
> >> with a flag.
> >>
> >> The buffer size is EP_BUFFER_SIZE and is already aligned to
> wMaxPacketSize so
> >> the problem shouldn't have happened in the first place. But it is
> happening
> >> indicating something else is wrong.
> >>
> >
> > There is what I'm observing on platform with DWC3 controller:
> > - when doing "fastboot flash xloader MLO":
> > - the whole size of data to send is 70964 bytes
> > - the size of all packets (except of last packet) is 4096 bytes
> > - so tho
Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize
On Thu, Apr 14, 2016 at 4:15 AM, Roger Quadros wrote:
> Steve,
>
> On 13/04/16 04:55, Steve Rae wrote:
> > On Tue, Apr 12, 2016 at 6:50 AM, Roger Quadros wrote:
> >> Lukasz,
> >>
> >> On 12/04/16 16:37, Lukasz Majewski wrote:
> >>> Hi Roger,
> >>>
> Hi,
>
> On 12/04/16 14:19, Lukasz Majewski wrote:
> > Hi Tom, Mugunthan
> >
> >> On Mon, Apr 11, 2016 at 05:04:56PM +0530, Mugunthan V N wrote:
> >>> On Friday 08 April 2016 12:10 AM, Marek Vasut wrote:
> On 04/07/2016 06:46 PM, Sam Protsenko wrote:
> > On Thu, Apr 7, 2016 at 10:36 AM, Lukasz Majewski
> > wrote:
> >> Hi Steve,
> >>
> >>> No -- I do not believe that this issue is caused by different
> >>> fastboot (client) versions (the executable that runs on the
> >>> host computer - Linux, Windows, Mac, etc.)
> >>> I have personally attempted three (3) different versions, and
> >>> the results are consistent.
> >>>
> >>> And no I don't think that I "am the only hope at fixing this
> >>> proper" -- as you will see below,
> >>> this" issue" seems to be unique to the "TI platforms" (...
> >>> nobody else has stated they have an issue either way -- but I
> >>> don't think many use this feature )
> >>> So maybe someone with "TI platforms" could investigate this
> >>> more thoroughly...
> >>>
> >>> HISTORY:
> >>>
> >>> The U-Boot code, up to Feb 25, worked properly on my Broadcom
> >>> boards -- this code contains:
> >>>req->length = rx_bytes_expected();
> >>> if (req->length < ep->maxpacket)
> >>> req->length = ep->maxpacket;
> >>> which aligned the remaining "rx_bytes_expected" to be aligned
> >>> to the "ep->maxpacket" size.
> >>>
> >>> On Feb 25, there was a patch applied from
> >>> which forces the remaining
> >>> "rx_bytes_expected" to be aligned to the "wMaxPacketSize" size
> >>> -- this patch broke all Broadcom boards:
> >>> + if (rx_remain < maxpacket) {
> >>> + rx_remain = maxpacket;
> >>> + } else if (rx_remain % maxpacket != 0) {
> >>> + rem = rx_remain % maxpacket;
> >>> + rx_remain = rx_remain + (maxpacket - rem);
> >>> + }
> >>>
> >>> After attempting to unsuccessfully contact Dileep, I requested
> >>> that this patch be reverted -- because it broke my boards!
> >>> (see the other email thread).
> >>>
> >>> Sam Protsenko has stated that
> >>> this Feb 25 change is required to make "fastboot work on TI
> >>> platforms".
> >>>
> >>> Thus,
> >>> - Broadcom boards require alignment to "ep->maxpacket" size
> >>> - TI platforms require alignment to "wMaxPacketSize" size
> >>> And we seem to be at a stale-mate.
> >>> Unfortunately, I do not know enough about the USB internals to
> >>> understand why this change breaks the Broadcom boards; or why
> >>> it _is_ required on the TI platforms
> >>> ( Is there any debugging that can be turned on to validate
> >>> what is happening at the lower levels? )
> >>
> >> I can only speak about DWC2 (from Synopsis) embedded at Samsung
> >> boards. There are low level debugging registers (documented,
> >> but not supposed to be used at normal operation), which give
> >> you some impression regarding very low level events.
> >>
> >> DWC2 at Samsung is using those to work properly since we had
> >> some problems with dwc2 IP blocks implementation on early
> >> Samsung platforms :-). This approach works in u-boot up till
> >> now.
> >>
> >> Another option is to use JTAG debugger (like Lauterbach) to
> >> inspect state of this IP block.
> >>
> >>> ( Can anyone explain why "wMaxPacketSize" size would be
> >>> required? -- my limited understanding of endpoints makes me
> >>> think that "ep->maxpacket" size is actually the correct value!
> >>> )
> >>>
> >>> I asked Sam to submit a patch which conditionally applied the
> >>> alignment to "wMaxPacketSize" size change -- he stated that he
> >>> was too busy right now -- so I submitted this patch on his
> >>> behalf (although he still needs to add the Kconfig for the TI
> >>> platforms in order to make his boards work)
> >>>
> >>> I suppose I could also propose a patch where the condition
> >>> _removes_ this feature (and define it on the Broadcom boards)
> >>> -- do we generally like "negated" conditionals?
> >>> +#ifndef
> >>>
> CONFIG_
[U-Boot] [PATCH] ARM: always perform per-CPU GIC init
From: Stephen Warren The current code in ARMv8's lowlevel_init() skips the per-CPU GIC initialization ifndef CONFIG_ARMV8_MULTIENTRY. However, the per-CPU init should always occur; it's just the one-time init that should only happen on the master. Once this consideration is taken into account, the only difference between the paths when CONFIG_ARMV8_MULTIENTRY is undefined/defined is the use of branch_if_slave. Naively, any unified code would need to invoke this conditionally upon ifdef CONFIG_ARMV8_MULTIENTRY. However, branch_if_slave already checks CONFIG_ARMV8_MULTIENTRY and does nothing if it isn't defined, so we don't even need that ifdef at the call site. Reported-by: Masahiro Yamada Signed-off-by: Stephen Warren --- arch/arm/cpu/armv8/start.S | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index dceedd7100ae..deb44a895fda 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -201,15 +201,6 @@ ENDPROC(apply_core_errata) WEAK(lowlevel_init) mov x29, lr /* Save LR */ -#ifndef CONFIG_ARMV8_MULTIENTRY -#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) - /* -* For single-entry systems the lowlevel init is very simple. -*/ - ldr x0, =GICD_BASE - bl gic_init_secure -#endif -#else /* CONFIG_ARMV8_MULTIENTRY is set */ #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) branch_if_slave x0, 1f ldr x0, =GICD_BASE @@ -223,7 +214,6 @@ WEAK(lowlevel_init) ldr x1, =GICC_BASE bl gic_init_secure_percpu #endif -#endif branch_if_master x0, x1, 2f -- 2.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Revert "rockchip: rk3288: correct sdram setting"
This reverts commit b5788dc0dd9570e98552833767f4373db965985d. Ram size is incorrectly reported as 512MB on a firefly-rk3288 board with 2GB of ram. Reverting this patch displays the full amount of ram. Signed-off-by: Vagrant Cascadian --- arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c index 71330cb..2e21282 100644 --- a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c +++ b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c @@ -561,14 +561,14 @@ static void dram_all_config(const struct dram_info *dram, &sdram_params->ch[chan]; sys_reg |= info->row_3_4 << SYS_REG_ROW_3_4_SHIFT(chan); - sys_reg |= 1 << SYS_REG_CHINFO_SHIFT(chan); + sys_reg |= chan << SYS_REG_CHINFO_SHIFT(chan); sys_reg |= (info->rank - 1) << SYS_REG_RANK_SHIFT(chan); sys_reg |= (info->col - 9) << SYS_REG_COL_SHIFT(chan); - sys_reg |= info->bk == 3 ? 0 : 1 << SYS_REG_BK_SHIFT(chan); + sys_reg |= info->bk == 3 ? 1 << SYS_REG_BK_SHIFT(chan) : 0; sys_reg |= (info->cs0_row - 13) << SYS_REG_CS0_ROW_SHIFT(chan); sys_reg |= (info->cs1_row - 13) << SYS_REG_CS1_ROW_SHIFT(chan); - sys_reg |= (2 >> info->bw) << SYS_REG_BW_SHIFT(chan); - sys_reg |= (2 >>info->dbw) << SYS_REG_DBW_SHIFT(chan); + sys_reg |= info->bw << SYS_REG_BW_SHIFT(chan); + sys_reg |= info->dbw << SYS_REG_DBW_SHIFT(chan); dram_cfg_rbc(&dram->chan[chan], chan, sdram_params); } @@ -720,13 +720,13 @@ size_t sdram_size_mb(struct rk3288_pmu *pmu) rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) & SYS_REG_RANK_MASK); col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & SYS_REG_COL_MASK); - bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK) ; + bk = sys_reg & (1 << SYS_REG_BK_SHIFT(ch)) ? 3 : 0; cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) & SYS_REG_CS0_ROW_MASK); cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) & SYS_REG_CS1_ROW_MASK); - bw = (2 >> (sys_reg >> SYS_REG_BW_SHIFT(ch)) & - SYS_REG_BW_MASK); + bw = (sys_reg >> SYS_REG_BW_SHIFT(ch)) & + SYS_REG_BW_MASK; row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) & SYS_REG_ROW_3_4_MASK; -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable
On 14.04.16 00:29, Tom Rini wrote: > On Wed, Apr 13, 2016 at 07:42:11PM +0200, Andreas Färber wrote: > [snip] >> $fdtfile needs to be the Linux filename. It does not always follow the >> same pattern as the U-Boot variables you suggest here. >> CONFIG_DEFAULT_DEVICE_TREE ".dtb" might work better, and that was my >> question to you. >> >> It's part of the generic mechanism, so not just select boards. Yet I was >> told that all boards are expected to set their cacheline size (although >> that is not a board but CPU property), so similarly we can (yes, newly) >> desire all boards to provide DT related settings as well. >> >> If you would supply a feature-complete DT in the first place, we >> wouldn't need $fdtfile here, but it seemed that that was not realistic >> to expect for the upcoming U-Boot release. > > So here's the thing. Figuring out what the device tree to load is, and > where it's going to reside is a sucky problem. For most of the complex > cases we do this today with "run findfdt". Why? Well, check out the > implementations in "git grep -l findfdt=" right now. It sounds like we > need to figure out how to get EFI in line with everything else that > U-Boot does/supports rather than to re-invent the wheel here. Sure, I fully agree. Where exactly do you see the EFI bits reimplementing the wheel here? We use the same logic as the rest of U-Boot for this. Findfdt gets called before the distro boot command, so we use that. If a board sets fdtfile, we use that. If it doesn't, with v2 we fall back to the same logic as pxe boot for fdtfile naming fallbacks. So in the end, I'd say it's pretty much in line :). Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm, m68k: fix out-of-range jump
Hi Heiko, On 15/04/2016 12:59, Heiko Schocher wrote: fix the following build error for m68k boards: Building current source for 48 boards (2 threads, 1 job per thread) m68k: + M54455EVB_i66 +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +arch/m68k/cpu/mcf5445x/start.S:668:(.text+0x45a): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 Signed-off-by: Heiko Schocher --- This commit fixes build error: https://travis-ci.org/hsdenx/u-boot/jobs/123254183 fixed log see: https://travis-ci.org/hsdenx/u-boot/jobs/123281032 Any ideas why the changes did not work for: arch/m68k/cpu/mcf523x/start.S arch/m68k/cpu/mcf52x2/start.S arch/m68k/cpu/mcf532x/start.S but work for arch/m68k/cpu/mcf5445x/start.S I have no real m68k experiences, so help is appreciated! sorry, i realized later you was asking the reason why jbsr is not working with > arch/m68k/cpu/mcf523x/start.S > arch/m68k/cpu/mcf52x2/start.S > arch/m68k/cpu/mcf532x/start.S jbsr is an alias for bsr.l that is supported only from ISA_B. In ISA_A it is likely translated to 16bit relative jump. I prepared some notes, you can check ISA Revisions here: http://www.denx.de/wiki/U-Boot/ColdFireNotes Best regards, Angelo Dureghello arch/m68k/cpu/mcf523x/start.S | 4 ++-- arch/m68k/cpu/mcf52x2/start.S | 4 ++-- arch/m68k/cpu/mcf532x/start.S | 4 ++-- arch/m68k/cpu/mcf5445x/start.S | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S index 8a23e72..ad7bde4 100644 --- a/arch/m68k/cpu/mcf523x/start.S +++ b/arch/m68k/cpu/mcf523x/start.S @@ -141,8 +141,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S index 8a59496..a16b589 100644 --- a/arch/m68k/cpu/mcf52x2/start.S +++ b/arch/m68k/cpu/mcf52x2/start.S @@ -198,8 +198,8 @@ _after_flashbar_copy: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf532x/start.S b/arch/m68k/cpu/mcf532x/start.S index 3b9ede0..50d301c 100644 --- a/arch/m68k/cpu/mcf532x/start.S +++ b/arch/m68k/cpu/mcf532x/start.S @@ -155,8 +155,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf5445x/start.S b/arch/m68k/cpu/mcf5445x/start.S index ae261b1..ff8d627 100644 --- a/arch/m68k/cpu/mcf5445x/start.S +++ b/arch/m68k/cpu/mcf5445x/start.S @@ -664,8 +664,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: increase maximum frame size to accomediate VLAN packets
On Wed, Apr 13, 2016 at 04:38:02PM -0700, Stefan Agner wrote: > Ethernet packages with IEEE 802.1Q VLAN support may be up to 1522 > bytes long. Increase the default size used to allocate packet > storage by 4 bytes. While at it, let git care about history and > rewrite the comment to represent the situation today only. > > Signed-off-by: Stefan Agner 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 v2 2/2] configs: ks2: move CMD_NAND to defconfigs
On Wed, Apr 13, 2016 at 09:51:00AM +0530, Lokesh Vutla wrote: > NAND is not yet enabled on all Keystone2 platforms. So enabled > CMD_NAND in the respective defconfigs only if available. > > Reported-by: Nishanth Menon > Signed-off-by: Lokesh Vutla 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 v2 1/2] memory: Move TI_AEMIF config to KCONFIG
On Wed, Apr 13, 2016 at 09:50:59AM +0530, Lokesh Vutla wrote: > Not all Keystone2 devices has AEMIF NAND controller. So adding Kconfig > entry for CONFIG_TI_AEMIF and enabling it in respective defconfigs on > platforms with AEMIF controller. > > Reported-by: Nishanth Menon > Signed-off-by: Lokesh Vutla 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] ARM: AM43xx: Fix BOOT_DEVICE_USB ID
On Wed, Apr 13, 2016 at 09:57:04AM +0530, Lokesh Vutla wrote:
> commit 62c5674ea136a ("omap: SPL boot devices cleanup and completion")
> cleans up the boot device ids for amx3xx soc. But mistakenly updates wrong
> device IDs for AM43xx USB. Fixing the same here.
>
> Signed-off-by: Lokesh Vutla
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] net: fix vlan validation
On Wed, Apr 13, 2016 at 04:38:01PM -0700, Stefan Agner wrote: > VLAN identifiers are 12-bit decimal numbers, not IP addresses. > > Signed-off-by: Stefan Agner 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] Please pull u-boot-dm
On Fri, Apr 15, 2016 at 09:50:11AM -0600, Simon Glass wrote: > Hi Tom, > > Unfortunately I'm still unable to apply many of the patches in my > queue due to build errors. But in the meantime, here are the ones that > are OK. > > > The following changes since commit ff6552e8cc13c9b2283002144e297d63b30ac400: > R > xpress: Update include (2016-04-13 15:45:50 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-dm.git > > for you to fetch changes up to 7e019daf7ab9dca3bf782d6de866b36d44ede95e: > > drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use > (2016-04-15 08:14:37 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: rpi: fix 64-bit CONFIG_SYS_TEXT_BASE
The Pi firmware has changed the default "kernel" load address for 64-bit mode. The authors have confirmed that this is a deliberate and long-term change. Adapt U-Boot to the new value. Signed-off-by: Stephen Warren --- include/configs/rpi.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/rpi.h b/include/configs/rpi.h index b83d622b9784..19ca606214d5 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -48,7 +48,11 @@ /* Memory layout */ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x +#ifdef CONFIG_ARM64 +#define CONFIG_SYS_TEXT_BASE 0x0008 +#else #define CONFIG_SYS_TEXT_BASE 0x8000 +#endif #define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE /* * The board really has 256M. However, the VC (VideoCore co-processor) shares -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] fastboot: sparse image handling and sessionId
Maxime, I suspect that the issue fixed in commit c7529dbfastboot: sparse: fix block addressing for don't care chunk type complicated the assumptions which led to the implementation of the "sessionId" in commit 1f8690asparse: Implement several chunks flashing The fastboot client will split the sparse images into several chunks if the image that it tries to flash is bigger than what the device can handle. In such a case, the bootloader is supposed to retain the last offset to which it wrote to, so that it can resume the writes at the right offset when flashing the next chunk. Retain the last offset we used, and use the session ID to know if we need it or not. Testing of this scenario has revealed that "fastboot flash" works as follows: When the image to download is larger than the "target reported max download size of 4096 bytes", the fastboot client (running on the host) essentially performs multiple, independent fastboot download/write steps. As seen in the logs below, each download/write step: (a) starts at the same address (the address of the first block of the partition...) (b) ends at the same address (start address plus number of blocks "written"...) (c) and uses the CHUNK_TYPE_DONT_CARE 'chunk_sz' to manipulate the addresses to achieve (a) and (b) Here is an example of the first three fastboot download/writes for a large image to "file-system": - in the first, data is written to 0x24000-0x37848, then there is a CHUNK_TYPE_DONT_CARE which "moves" the address pointer to 0x424000 - in the second, it starts with a CHUNK_TYPE_DONT_CARE which "moves" the address from 0x24000 to 0x37848, then writes from 0x37848-0x4b098, then there is a CHUNK_TYPE_DONT_CARE which "moves" the address pointer to 0x424000 - in the third, it starts with a CHUNK_TYPE_DONT_CARE which "moves" the address from 0x24000 to 0x4b098, then writes from 0x4b098-0x5e8e0, then there is a CHUNK_TYPE_DONT_CARE which "moves" the address pointer to 0x424000 Starting download of 40932412 bytes .. downloading of 40932412 bytes finished Flashing sparse image at offset 147456 Flashing Sparse Image - this is the starting address: 0x24000 (writing to flash) - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x37848 - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x424000 - this is the endingaddress: 0x424000 wrote 4194304 blocks to 'file-system' Starting download of 40954208 bytes .. downloading of 40954208 bytes finished Flashing sparse image at offset 147456 Flashing Sparse Image - this is the starting address: 0x24000 - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x24000 - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x37848 (writing to flash) - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x4b098 - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x424000 - this is the endingaddress: 0x424000 wrote 4194304 blocks to 'file-system' Starting download of 40955896 bytes .. downloading of 40955896 bytes finished Flashing sparse image at offset 147456 Flashing Sparse Image - this is the starting address: 0x24000 - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x24000 - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x4b098 (writing to flash) - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x5e8e0 - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x424000 - this is the endingaddress: 0x424000 wrote 4194304 blocks to 'file-system' [... snip ...] Therefore, I think that the "sessonId" that is implemented in U-Boot is actually incorrect. There is no need to keep track of the addresses as each "fastboot flash" download/write step is completely independent. And I actually need to remove it in order to get this working again: - if (session_id > 0) - start = last_offset; - else - start = storage->start; + start = storage->start; Additionally (unfortunately) as with the previous discussion that we had about this code: #ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV total_blocks += blkcnt; #endif the NAND implementation requires a method to process "blkcnt" to ensure the blkcnt skips the bad blocks... Please advise, Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
