Re: [U-Boot] [PATCH] drivers: net: remove dead drivers
Hi Joe, On Thu, 31 Jul 2014 14:32:47 -0500 Joe Hershberger joe.hershber...@gmail.com wrote: On Wed, Jul 30, 2014 at 5:26 AM, Masahiro Yamada yamad...@jp.panasonic.com wrote: The following configs are not defined at all: - CONFIG_FTMAC110 - CONFIG_INCA_IP_SWITCH - CONFIG_PBL2800_ETHER - CONFIG_PHY_ICPLUS Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- drivers/net/Makefile | 3 - drivers/net/ftmac110.c| 480 -- drivers/net/ftmac110.h| 176 - drivers/net/phy/Makefile | 1 - drivers/net/phy/icplus.c | 80 drivers/net/phy/phy.c | 3 - drivers/net/plb2800_eth.c | 373 --- include/netdev.h | 2 - 8 files changed, 1118 deletions(-) delete mode 100644 drivers/net/ftmac110.c delete mode 100644 drivers/net/ftmac110.h delete mode 100644 drivers/net/phy/icplus.c delete mode 100644 drivers/net/plb2800_eth.c The Faraday driver is newly added and I believe they are trying to add some support for IP that they include in their made-to-order ASICs. I'm not sure what the plan is for including the MAC in some board definition that builds it to get build testing in the mainline, but that should be addressed with the Faraday maintainer. Probably the include/configs/a320evb.h should define CONFIG_FTMAC110. The others can be removed it seems. Thanks! I will revive the Raraday driver and post v2. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] sunxi-common.h: Remove CONFIG_SYS_BOOT_GET_CMDLINE
sunxi does not need this and it should never have been enabled for it in the first place. Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 6a3044f..e3dc9c4 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -126,8 +126,6 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ bootm_size=0x1000\0 -#define CONFIG_SYS_BOOT_GET_CMDLINE - #include config_cmd_default.h #define CONFIG_FAT_WRITE /* enable write access */ -- 2.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pxe: automatically add console= to bootargs when not specified in append
From: Dennis Gilmore den...@ausil.us
if there is a console variable in the u-boot environment and not one on
the append line from syslinux config add what is in the environment to
the bootargs.
This is necessary to allow distros to have a single extlinux/extlinux.conf
file which will work on multiple boards, even if these boards have different
consoles (e.g. ttyS0 vs ttyAMA0).
Signed-off-by: Hans de Goede hdego...@redhat.com
---
common/cmd_pxe.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index ba48692..147d7d1 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -606,6 +606,7 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
char initrd_str[22];
char mac_str[29] = ;
char ip_str[68] = ;
+ char console[30] = ;
char *bootargs;
int bootm_argc = 3;
int len = 0;
@@ -665,8 +666,14 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
}
#endif
- if (label-append)
+ if (label-append) {
len += strlen(label-append);
+ /* If no console in append and $console is set, use it */
+ if (!strstr(label-append, console=) getenv(console)) {
+ sprintf(console, console=%s, getenv(console));
+ len += strlen(console);
+ }
+ }
if (len) {
bootargs = malloc(len + 1);
@@ -675,6 +682,7 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
bootargs[0] = '\0';
if (label-append)
strcpy(bootargs, label-append);
+ strcat(bootargs, console);
strcat(bootargs, ip_str);
strcat(bootargs, mac_str);
--
2.0.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] sunxi-common.h: Don't undef CONFIG_CMD_NET only to redefine it again later
config_distro_defaults.h which is include later will redefine CONFIG_CMD_NET, drop the useless / meaningless undef of it. While at also move the undef of CONFIG_CMD_FPGA up to directly under the include of config_cmd_defaults.h, to make it clear that it overwrites the setting done from config_cmd_defaults.h . Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index cbe8b40..4c712f3 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -127,6 +127,7 @@ bootm_size=0x1000\0 #include config_cmd_default.h +#undef CONFIG_CMD_FPGA #define CONFIG_FAT_WRITE /* enable write access */ @@ -166,9 +167,6 @@ #define CONFIG_SYS_SPL_MALLOC_START0x4ff0 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0008 /* 512 KiB */ -#undef CONFIG_CMD_FPGA -#undef CONFIG_CMD_NET - /* I2C */ #define CONFIG_SPL_I2C_SUPPORT #define CONFIG_SYS_I2C -- 2.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] sunxi-common.h: Remove dead #ifdef CONFIG_CMD_NET code block
We undef CONFIG_CMD_NET at line 167, and there is nothing re-defining it between line 167 and the #ifdef CONFIG_CMD_NET, so remove this effectively dead block. Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 8 1 file changed, 8 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index e3dc9c4..9d4801a 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -205,14 +205,6 @@ #define CONFIG_PHYLIB #endif -#ifdef CONFIG_CMD_NET -#define CONFIG_CMD_NFS -#define CONFIG_CMD_DNS -#define CONFIG_NETCONSOLE -#define CONFIG_BOOTP_DNS2 -#define CONFIG_BOOTP_SEND_HOSTNAME -#endif - #ifdef CONFIG_USB_EHCI #define CONFIG_CMD_USB #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1 -- 2.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] sunxi-common.h: Don't undefine CONFIG_CMD_NFS
I see no reason to override the choice to include this from config_cmd_defauls.h . Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 9d4801a..cbe8b40 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -168,7 +168,6 @@ #undef CONFIG_CMD_FPGA #undef CONFIG_CMD_NET -#undef CONFIG_CMD_NFS /* I2C */ #define CONFIG_SPL_I2C_SUPPORT -- 2.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] sunxi-common.h: Use new generic $bootcmd
Use the new standard bootcmd from config_distro_bootcmd.h. Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 27 --- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4c712f3..f5a702a 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -123,9 +123,6 @@ #define CONFIG_ENV_OFFSET (544 10) /* (8 + 24 + 512) KiB */ #define CONFIG_ENV_SIZE(128 10) /* 128 KiB */ -#define CONFIG_EXTRA_ENV_SETTINGS \ - bootm_size=0x1000\0 - #include config_cmd_default.h #undef CONFIG_CMD_FPGA @@ -219,6 +216,30 @@ #ifndef CONFIG_SPL_BUILD #include config_distro_defaults.h + +#ifdef CONFIG_AHCI +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(SCSI, scsi, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#else +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#endif + +#include config_distro_bootcmd.h + +#define CONFIG_EXTRA_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + BOOTENV + +#else /* ifndef CONFIG_SPL_BUILD */ +#define CONFIG_EXTRA_ENV_SETTINGS #endif #endif /* _SUNXI_COMMON_CONFIG_H */ -- 2.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
Automatic booting using an extlinux.conf file requires various environment variables to be set. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig | 3 +++ configs/A10-OLinuXino-Lime_defconfig | 1 + configs/A10s-OLinuXino-M_defconfig| 1 + configs/A13-OLinuXinoM_defconfig | 1 + configs/A13-OLinuXino_defconfig | 1 + configs/A20-OLinuXino_MICRO_defconfig | 1 + configs/Auxtek-T004_defconfig | 1 + configs/Bananapi_defconfig| 1 + configs/Cubieboard2_FEL_defconfig | 1 + configs/Cubieboard2_defconfig | 1 + configs/Cubieboard_defconfig | 1 + configs/Cubietruck_FEL_defconfig | 1 + configs/Cubietruck_defconfig | 1 + configs/Linksprite_pcDuino3_defconfig | 1 + configs/Mele_A1000G_defconfig | 1 + configs/Mele_A1000_defconfig | 1 + configs/Mini-X-1Gb_defconfig | 1 + configs/Mini-X_defconfig | 1 + configs/ba10_tv_box_defconfig | 1 + configs/i12-tvbox_defconfig | 1 + configs/qt840a_defconfig | 1 + configs/r7-tv-dongle_defconfig| 1 + include/configs/sunxi-common.h| 18 +++--- 23 files changed, 39 insertions(+), 3 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 24cca47..c61c650 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -36,4 +36,7 @@ config SYS_SOC string default sunxi +config FTDFILE + string Default ftdfile env setting for this board + endif diff --git a/configs/A10-OLinuXino-Lime_defconfig b/configs/A10-OLinuXino-Lime_defconfig index a414953..b93ae7d 100644 --- a/configs/A10-OLinuXino-Lime_defconfig +++ b/configs/A10-OLinuXino-Lime_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A10_OLINUXINO_L,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI +CONFIG_FTDFILE=sun4i-a10-olinuxino-lime.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN4I=y diff --git a/configs/A10s-OLinuXino-M_defconfig b/configs/A10s-OLinuXino-M_defconfig index 1560ab1..f206970 100644 --- a/configs/A10s-OLinuXino-M_defconfig +++ b/configs/A10s-OLinuXino-M_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A10S_OLINUXINO_M,SPL,AXP152_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPB(10) +CONFIG_FTDFILE=sun5i-a10s-olinuxino-micro.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A13-OLinuXinoM_defconfig b/configs/A13-OLinuXinoM_defconfig index fb510d5..8529dbe 100644 --- a/configs/A13-OLinuXinoM_defconfig +++ b/configs/A13-OLinuXinoM_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A13_OLINUXINOM,SPL,CONS_INDEX=2,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11) +CONFIG_FTDFILE=sun5i-a13-olinuxino-micro.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A13-OLinuXino_defconfig b/configs/A13-OLinuXino_defconfig index ba21136..c3a12cc 100644 --- a/configs/A13-OLinuXino_defconfig +++ b/configs/A13-OLinuXino_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A13_OLINUXINO,SPL,CONS_INDEX=2,AXP209_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11) +CONFIG_FTDFILE=sun5i-a13-olinuxino.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A20-OLinuXino_MICRO_defconfig b/configs/A20-OLinuXino_MICRO_defconfig index 52a857a..c91319d 100644 --- a/configs/A20-OLinuXino_MICRO_defconfig +++ b/configs/A20-OLinuXino_MICRO_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A20_OLINUXINO_M,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI +CONFIG_FTDFILE=sun7i-a20-olinuxino-micro.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN7I=y diff --git a/configs/Auxtek-T004_defconfig b/configs/Auxtek-T004_defconfig index 643e628..193019c 100644 --- a/configs/Auxtek-T004_defconfig +++ b/configs/Auxtek-T004_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AUXTEK_T004,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13) +CONFIG_FTDFILE=sun5i-a10s-auxtek-t004.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/Bananapi_defconfig b/configs/Bananapi_defconfig index be3d815..dc68469 100644 --- a/configs/Bananapi_defconfig +++ b/configs/Bananapi_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=BANANAPI,SPL,AXP209_POWER,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),AHCI,USB_EHCI +CONFIG_FTDFILE=sun7i-a20-bananapi.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN7I=y diff --git a/configs/Cubieboard2_FEL_defconfig b/configs/Cubieboard2_FEL_defconfig index 63636b0..ae5e25a 100644 --- a/configs/Cubieboard2_FEL_defconfig +++ b/configs/Cubieboard2_FEL_defconfig @@ -1,4 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=CUBIEBOARD2,SPL_FEL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI +CONFIG_FTDFILE=sun7i-a20-cubieboard2.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN7I=y diff --git a/configs/Cubieboard2_defconfig b/configs/Cubieboard2_defconfig index fa34c51..df87edc 100644 ---
[U-Boot] [PATCH 6/7] sunxi: Kconfig: move common settings into a shared code block
SYS_CPU, SYS_BOARD and SYS_SOC are identical for all sunxi boards, move them to a shared code block. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig | 32 ++-- 1 file changed, 6 insertions(+), 26 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index b06b5e0..24cca47 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -1,17 +1,5 @@ if TARGET_SUN4I -config SYS_CPU - string - default armv7 - -config SYS_BOARD - string - default sunxi - -config SYS_SOC - string - default sunxi - config SYS_CONFIG_NAME string default sun4i @@ -20,25 +8,21 @@ endif if TARGET_SUN5I -config SYS_CPU +config SYS_CONFIG_NAME string - default armv7 + default sun5i -config SYS_BOARD - string - default sunxi +endif -config SYS_SOC - string - default sunxi +if TARGET_SUN7I config SYS_CONFIG_NAME string - default sun5i + default sun7i endif -if TARGET_SUN7I +if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN7I config SYS_CPU string @@ -52,8 +36,4 @@ config SYS_SOC string default sunxi -config SYS_CONFIG_NAME - string - default sun7i - endif -- 2.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] sunxi-common.h: Use new generic $bootcmd
Hi, On 08/01/2014 09:46 AM, Hans de Goede wrote: Use the new standard bootcmd from config_distro_bootcmd.h. Note this applies on top of Stephen Warren's [PATCH 1/3] config: introduce a generic $bootcmd Regards, Hans Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 27 --- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4c712f3..f5a702a 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -123,9 +123,6 @@ #define CONFIG_ENV_OFFSET(544 10) /* (8 + 24 + 512) KiB */ #define CONFIG_ENV_SIZE (128 10) /* 128 KiB */ -#define CONFIG_EXTRA_ENV_SETTINGS \ - bootm_size=0x1000\0 - #include config_cmd_default.h #undef CONFIG_CMD_FPGA @@ -219,6 +216,30 @@ #ifndef CONFIG_SPL_BUILD #include config_distro_defaults.h + +#ifdef CONFIG_AHCI +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(SCSI, scsi, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#else +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#endif + +#include config_distro_bootcmd.h + +#define CONFIG_EXTRA_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + BOOTENV + +#else /* ifndef CONFIG_SPL_BUILD */ +#define CONFIG_EXTRA_ENV_SETTINGS #endif #endif /* _SUNXI_COMMON_CONFIG_H */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] buildman: Add some notes about moving from MAKEALL
Hi. On Mon, 28 Jul 2014 23:53:29 -0600 Simon Glass s...@chromium.org wrote: For those used to MAKEALL, buildman seems strange. Add some notes to ease the transition. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Minor changes to the text tools/buildman/README | 92 +++ 1 file changed, 92 insertions(+) diff --git a/tools/buildman/README b/tools/buildman/README index a5d181c..1c919af 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -3,6 +3,8 @@ # SPDX-License-Identifier: GPL-2.0+ # +(Please read 'How to change from MAKEALL' if you are used to that tool) + What is this? = @@ -663,6 +665,96 @@ Other options Buildman has various other command line options. Try --help to see them. +How to change from MAKEALL +== + +Buildman includes most of the features of MAKEALL and is generally faster +and easier to use. In particular it builds entire branches: if a particular +commit introduces an error in a particular board, buildman can easily show +you this, even if a later commit fixes that error. + +The reasons to deprecate MAKEALL are: +- We don't want to maintain two build systems +- Buildman is typically faster +- Buildman has a lot more features + +But still, many people will be sad to lose MAKEALL. If you are used to +MAKEALL, here are a few pointers. +First you need to set up your tool chains - see the 'Setting up' section +for details. Once you have your required toolchain(s) detected then you are +ready to go. + +Buildman works on entire branches, so the normal use is: + + ./tools/buildman/buildman -b branch_name list of things to build + +followed by (afterwards, or perhaps concurrently in another terminal): + + ./tools/buildman/buildman -b branch_name -s list of things to build The biggest difference I see between buildman and MAKEALL is that buildman tests commits in git-log, whereas MAKEALL tests the current source tree. It means buildman does not work for tarball users. Maybe we can excuse because I guess most develpers are working on a git-repo. But I find MAKEALL is much eaiser for a quick test. It is very useful for my work flow; Just change some code and invoke ./MAKEALL -s uniphier I can test local changes without commiting them. In buildman, I need to commit the local changes once and do git branch --set-upstream-to upstream-branch tools/buildman/buildman -b topic-branch which requires me lots of typing. 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] pxe: automatically add console= to bootargs when not specified in append
Hi, On 08/01/2014 09:46 AM, Hans de Goede wrote: From: Dennis Gilmore den...@ausil.us if there is a console variable in the u-boot environment and not one on the append line from syslinux config add what is in the environment to the bootargs. This is necessary to allow distros to have a single extlinux/extlinux.conf file which will work on multiple boards, even if these boards have different consoles (e.g. ttyS0 vs ttyAMA0). Signed-off-by: Hans de Goede hdego...@redhat.com I asked Dennis for its Signed-off-by for this, and instead I got this: NAK, I was planning to drop the patch entirely, while its useful in some cases, it breaks things like plymouth working, as well it will force anaconda installs to always be text over the serial port. wandboard and cubox-i for instance boot happily without a console= line and you get plymouth on the screen when video is initialised. having it add the console line if u-boot has the console set to serial would be okay. I think it needs some more thought and careful planning. Dennis So lets drop this one for now. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pxe: automatically add console= to bootargs when not specified in append
Hi, On 08/01/2014 10:20 AM, Hans de Goede wrote: Hi, On 08/01/2014 09:46 AM, Hans de Goede wrote: From: Dennis Gilmore den...@ausil.us if there is a console variable in the u-boot environment and not one on the append line from syslinux config add what is in the environment to the bootargs. This is necessary to allow distros to have a single extlinux/extlinux.conf file which will work on multiple boards, even if these boards have different consoles (e.g. ttyS0 vs ttyAMA0). Signed-off-by: Hans de Goede hdego...@redhat.com I asked Dennis for its Signed-off-by for this, and instead I got this: s/its/his/ sorry. NAK, I was planning to drop the patch entirely, while its useful in some cases, it breaks things like plymouth working, as well it will force anaconda installs to always be text over the serial port. wandboard and cubox-i for instance boot happily without a console= line and you get plymouth on the screen when video is initialised. having it add the console line if u-boot has the console set to serial would be okay. I think it needs some more thought and careful planning. Dennis So lets drop this one for now. So if we're not going to do this one we're going to need something else, because without this sunxi is useless, as the last message the user sees is Starting kernel ... and then nothing. Sow how about allowing the use of u-boot environment variables in append, so that extlinux.conf can have: label Fedora-Minimal-armhfp-rawhide-20140731 (3.16.0-0.rc7.git1.1.fc22.armv7hl) kernel /vmlinuz-3.16.0-0.rc7.git1.1.fc22.armv7hl append ro root=UUID=a6446dcb-320d-421f-9b71-725b68e5a41b console=$console fdtdir /dtb-3.16.0-0.rc7.git1.1.fc22.armv7hl/ initrd /initramfs-3.16.0-0.rc7.git1.1.fc22.armv7hl.img And then put 2 entries in extlinux.conf one for booting with the console on the framebuffer, and one for using the serial console ? Even with systems where we have video the user may not have the video hooked up and use the serial console for initial setup. Alternatively we could use something like this: console=tty0 console=ttyS0,115200 that will give us boot messages on both video out and ttyS0, dunno what firstboot will do in this case. Anyways I think we need to separate this discussion in 2 things: 1) Mechanism: u-boot should offer a way for extlinux.conf to find out the right device + baudrate for the serial console. Traditionally this has been done through the console environment variable. If we teach u-boot's extlinux support to interpret $foo variables in the append string, then that mechanism can be used for extlinux.conf booting too, and I think this is the best way to do this. 2) Policy: Once we have 1). the question becomes how to use it in generic ARM distros like Fedora, that discussion is probably best held on the Fedora ARM list and not here. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: atmel: sama5d3: add timings register
Signed-off-by: Bo Shen voice.s...@atmel.com
---
arch/arm/include/asm/arch-at91/sama5d3_smc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-at91/sama5d3_smc.h
b/arch/arm/include/asm/arch-at91/sama5d3_smc.h
index 6caa9b6..a859b6d 100644
--- a/arch/arm/include/asm/arch-at91/sama5d3_smc.h
+++ b/arch/arm/include/asm/arch-at91/sama5d3_smc.h
@@ -14,7 +14,8 @@
#define AT91_ASM_SMC_SETUP0(ATMEL_BASE_SMC + 0x600)
#define AT91_ASM_SMC_PULSE0(ATMEL_BASE_SMC + 0x604)
#define AT91_ASM_SMC_CYCLE0(ATMEL_BASE_SMC + 0x608)
-#define AT91_ASM_SMC_MODE0 (ATMEL_BASE_SMC + 0x60C)
+#define AT91_ASM_SMC_TIMINGS0 (ATMEL_BASE_SMC + 0x60c)
+#define AT91_ASM_SMC_MODE0 (ATMEL_BASE_SMC + 0x610)
#else
struct at91_cs {
u32 setup; /* 0x600 SMC Setup Register */
--
1.8.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] Question about the (new) U-Boot Timer API
Hi, Wolfgang: The wiki (http://www.denx.de/wiki/U-Boot/TaskTimerAPI) introduced new U-Boot Timer API, such as: time_ms_delta_raw() time_ms_delta_max() .. Not find in 2014.07 code package. Were they not adopted by u-boot maintainer? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pxe: Allow use of environment variables in append string
Use run_command(setenv bootargs label-append) so that environment
variables (e.g. $console) can be used in append strings.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
common/cmd_pxe.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index ba48692..3866604 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -571,14 +571,23 @@ static void label_print(void *data)
static int label_localboot(struct pxe_label *label)
{
char *localcmd;
+ char *bootargs;
localcmd = from_env(localcmd);
if (!localcmd)
return -ENOENT;
- if (label-append)
- setenv(bootargs, label-append);
+ if (label-append) {
+ bootargs = malloc(strlen(setenv bootargs ) +
+ strlen(label-append) + 1);
+ if (!bootargs)
+ return 1;
+ strcpy(bootargs, setenv bootargs );
+ strcat(bootargs, label-append);
+ run_command(bootargs, 0);
+ free(bootargs);
+ }
debug(running: %s\n, localcmd);
@@ -669,17 +678,17 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
len += strlen(label-append);
if (len) {
- bootargs = malloc(len + 1);
+ bootargs = malloc(strlen(setenv bootargs ) + len + 1);
if (!bootargs)
return 1;
- bootargs[0] = '\0';
+ strcpy(bootargs, setenv bootargs );
if (label-append)
- strcpy(bootargs, label-append);
+ strcat(bootargs, label-append);
strcat(bootargs, ip_str);
strcat(bootargs, mac_str);
- setenv(bootargs, bootargs);
- printf(append: %s\n, bootargs);
+ run_command(bootargs, 0);
+ printf(append: %s\n, getenv(bootargs));
free(bootargs);
}
--
2.0.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Falcon boot mode
Hello, Does Falcon boot mode only support raw NAND devices as described in the README.falcon file will it also work with SPI NOR devices and eMMC NAND, SDC card as well? Thanks, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: mconf.c: remove texts referring to modules
As we don't have the concept of 'loadable modules' in u-boot,
remove texts referring to modules.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
scripts/kconfig/mconf.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 14cea74..1c952b5 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -26,21 +26,21 @@ static const char mconf_readme[] = N_(
Overview\n
\n
This interface lets you select features and parameters for the build.\n
-Features can either be built-in, modularized, or ignored. Parameters\n
+Features can either be built-in or ignored. Parameters\n
must be entered in as decimal or hexadecimal numbers or text.\n
\n
Menu items beginning with following braces represent features that\n
[ ] can be built in or removed\n
-can be built in, modularized or removed\n
- { } can be built in or modularized (selected by other feature)\n
+can be built in or removed\n
+ { } can be built in (selected by other feature)\n
- - are selected by other feature,\n
-while *, M or whitespace inside braces means to build in, build as\n
-a module or to exclude the feature respectively.\n
+while * or whitespace inside braces means to build in\n
+or to exclude the feature respectively.\n
\n
To change any of these features, highlight it with the cursor\n
-keys and press Y to build it in, M to make it a module or\n
+keys and press Y to build it in or\n
N to remove it. You may also press the Space Bar to cycle\n
-through the available options (i.e. Y-N-M-Y).\n
+through the available options (i.e. Y-N-Y).\n
\n
Some additional keyboard hints:\n
\n
@@ -176,9 +176,9 @@ menu_instructions[] = N_(
Arrow keys navigate the menu.
Enter selects submenus --- (or empty submenus ).
Highlighted letters are hotkeys.
- Pressing Y includes, N excludes, M modularizes features.
+ Pressing Y includes, N excludes features.
Press EscEsc to exit, ? for Help, / for Search.
- Legend: [*] built-in [ ] excluded M modulemodule capable),
+ Legend: [*] built-in [ ] excluded),
radiolist_instructions[] = N_(
Use the arrow keys to navigate this window or
press the hotkey of the item you wish to select
@@ -194,9 +194,6 @@ inputbox_instructions_hex[] = N_(
inputbox_instructions_string[] = N_(
Please enter a string value.
Use the TAB key to move from the input field to the buttons below
it.),
-setmod_text[] = N_(
- This feature depends on another which has been configured as a
module.\n
- As a result, this feature will be built as a module.),
load_config_text[] = N_(
Enter the name of the configuration file you wish to load.
Accept the name shown to restore the configuration you
@@ -722,8 +719,6 @@ static void conf(struct menu *menu, struct menu
*active_menu)
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
- if (sym_set_tristate_value(sym, mod))
- show_textbox(NULL, setmod_text, 6, 74);
}
break;
case 6:
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] blackfin: convert blackfin board_f and board_r to use generic board init functions
From: Sonic Zhang sonic.zh...@analog.com
- move blackfin specific cpu init code from blackfin board.c to cpu.c
- remove blackfin specific board init code and invoke generic board_f fron cpu
init entry
- rename section name bss_vma to bss_start in order to match the generic board
init code
- add a fake relocate_code function to set up the new stack only
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
arch/blackfin/config.mk| 3 +
arch/blackfin/cpu/cpu.c| 333 +---
arch/blackfin/cpu/start.S | 14 +-
arch/blackfin/cpu/u-boot.lds | 4 +-
arch/blackfin/include/asm/u-boot.h | 3 +
arch/blackfin/lib/Makefile | 7 +-
arch/blackfin/lib/board.c | 443 -
arch/blackfin/lib/sections.c | 11 +
include/configs/bfin_adi_common.h | 4 +
9 files changed, 334 insertions(+), 488 deletions(-)
delete mode 100644 arch/blackfin/lib/board.c
create mode 100644 arch/blackfin/lib/sections.c
diff --git a/arch/blackfin/config.mk b/arch/blackfin/config.mk
index fcaa44f..96730dd 100644
--- a/arch/blackfin/config.mk
+++ b/arch/blackfin/config.mk
@@ -20,6 +20,9 @@ CONFIG_BFIN_CPU := $(strip $(CONFIG_BFIN_CPU:%=%))
endif
CONFIG_BFIN_BOOT_MODE := $(strip $(CONFIG_BFIN_BOOT_MODE:%=%))
+# Support generic board on Blackfin
+__HAVE_ARCH_GENERIC_BOARD := y
+
PLATFORM_RELFLAGS += -ffixed-P3 -fomit-frame-pointer -mno-fdpic
PLATFORM_CPPFLAGS += -DCONFIG_BLACKFIN
diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index 2409c30..6913879 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -11,17 +11,21 @@
#include common.h
#include command.h
+#include serial.h
+#include version.h
+
#include asm/blackfin.h
#include asm/cplb.h
+#include asm/clock.h
#include asm/mach-common/bits/core.h
#include asm/mach-common/bits/ebiu.h
#include asm/mach-common/bits/trace.h
-#include asm/serial.h
#include cpu.h
#include initcode.h
ulong bfin_poweron_retx;
+DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_CORE1_RUN) defined(COREB_L1_CODE_START)
void bfin_core1_start(void)
@@ -48,6 +52,252 @@ void bfin_core1_start(void)
}
#endif
+__attribute__((always_inline))
+static inline void serial_early_puts(const char *s)
+{
+#ifdef CONFIG_DEBUG_EARLY_SERIAL
+ serial_puts(Early: );
+ serial_puts(s);
+#endif
+}
+
+static int global_board_data_init(void)
+{
+#ifndef CONFIG_SYS_GBL_DATA_ADDR
+# define CONFIG_SYS_GBL_DATA_ADDR 0
+#endif
+#ifndef CONFIG_SYS_BD_INFO_ADDR
+# define CONFIG_SYS_BD_INFO_ADDR 0
+#endif
+
+ bd_t *bd;
+
+ if (CONFIG_SYS_GBL_DATA_ADDR) {
+ gd = (gd_t *)(CONFIG_SYS_GBL_DATA_ADDR);
+ memset((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
+ } else {
+ static gd_t _bfin_gd;
+ gd = _bfin_gd;
+ }
+ if (CONFIG_SYS_BD_INFO_ADDR) {
+ bd = (bd_t *)(CONFIG_SYS_BD_INFO_ADDR);
+ memset(bd, 0, GENERATED_BD_INFO_SIZE);
+ } else {
+ static bd_t _bfin_bd;
+ bd = _bfin_bd;
+ }
+
+ gd-bd = bd;
+
+ bd-bi_r_version = version_string;
+ bd-bi_cpu = __stringify(CONFIG_BFIN_CPU);
+ bd-bi_board_name = CONFIG_SYS_BOARD;
+ bd-bi_vco = get_vco();
+ bd-bi_cclk = get_cclk();
+ bd-bi_sclk = get_sclk();
+ bd-bi_memstart = CONFIG_SYS_SDRAM_BASE;
+ bd-bi_memsize = CONFIG_SYS_MAX_RAM_SIZE;
+
+ gd-ram_size = CONFIG_SYS_MAX_RAM_SIZE;
+
+ return 0;
+}
+
+static void display_global_data(void)
+{
+ bd_t *bd;
+
+#ifndef CONFIG_DEBUG_EARLY_SERIAL
+ return;
+#endif
+
+ bd = gd-bd;
+ printf( gd: %p\n, gd);
+ printf( |-flags: %lx\n, gd-flags);
+ printf( |-board_type: %lx\n, gd-arch.board_type);
+ printf( |-baudrate: %u\n, gd-baudrate);
+ printf( |-have_console: %lx\n, gd-have_console);
+ printf( |-ram_size: %lx\n, gd-ram_size);
+ printf( |-env_addr: %lx\n, gd-env_addr);
+ printf( |-env_valid: %lx\n, gd-env_valid);
+ printf( |-jt(%p): %p\n, gd-jt, *(gd-jt));
+ printf( \\-bd: %p\n, gd-bd);
+ printf( |-bi_boot_params: %lx\n, bd-bi_boot_params);
+ printf( |-bi_memstart: %lx\n, bd-bi_memstart);
+ printf( |-bi_memsize: %lx\n, bd-bi_memsize);
+ printf( |-bi_flashstart: %lx\n, bd-bi_flashstart);
+ printf( |-bi_flashsize: %lx\n, bd-bi_flashsize);
+ printf( \\-bi_flashoffset: %lx\n, bd-bi_flashoffset);
+}
+
+#define CPLB_PAGE_SIZE (4 * 1024 * 1024)
+#define CPLB_PAGE_MASK (~(CPLB_PAGE_SIZE - 1))
+#if defined(__ADSPBF60x__)
+#define CPLB_EX_PAGE_SIZE (16 * 1024 * 1024)
+#define CPLB_EX_PAGE_MASK (~(CPLB_EX_PAGE_SIZE - 1))
+#else
+#define CPLB_EX_PAGE_SIZE CPLB_PAGE_SIZE
+#define CPLB_EX_PAGE_MASK CPLB_PAGE_MASK
+#endif
+void init_cplbtables(void)
+{
+ uint32_t *ICPLB_ADDR, *ICPLB_DATA;
+ uint32_t *DCPLB_ADDR, *DCPLB_DATA;
+ uint32_t extern_memory;
+
[U-Boot] [PATCH v3 2/2] support blackfin board initialization in generic board_f
From: Sonic Zhang sonic.zh...@analog.com
- init hardware watchdog if applicable
- use CONFIG_SYS_MONITOR_LEN as the gd monitor len for Blackfin
- reserve u-boot memory at the top field of the RAM for Blackfin
- avoid refer to CONFIG_SYS_MONITOR_LEN, which is not defined by Blackfin
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
v2-changes:
- make hardware watchdog init depend on BLACKFIN || M68K || MICROBLAZE || SH
- define watchdog init and reset macros for both software and hardware watchdog
v3-changes:
- allocate board info struct only when it is not already allocated in arch init
---
common/board_f.c | 35 ---
include/watchdog.h | 2 +-
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index bdab38e..c934365 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -104,9 +104,14 @@ __weak void blue_led_off(void) {}
* Could the CONFIG_SPL_BUILD infection become a flag in gd?
*/
-#if defined(CONFIG_WATCHDOG)
+#if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG)
static int init_func_watchdog_init(void)
{
+# if defined(CONFIG_HW_WATCHDOG) (defined(CONFIG_BLACKFIN) || \
+ defined(CONFIG_M68K) || defined(CONFIG_MICROBLAZE) || \
+ defined(CONFIG_SH))
+ hw_watchdog_init();
+# endif
puts( Watchdog enabled\n);
WATCHDOG_RESET();
@@ -144,7 +149,11 @@ static int display_text_info(void)
bss_end = (ulong)__bss_end;
debug(U-Boot code: %08X - %08lX BSS: - %08lX\n,
+#ifdef CONFIG_SYS_TEXT_BASE
CONFIG_SYS_TEXT_BASE, bss_start, bss_end);
+#else
+ CONFIG_SYS_MONITOR_BASE, bss_start, bss_end);
+#endif
#endif
#ifdef CONFIG_MODEM_SUPPORT
@@ -259,6 +268,8 @@ static int setup_mon_len(void)
gd-mon_len = (ulong)__bss_end - (ulong)_start;
#elif defined(CONFIG_SANDBOX)
gd-mon_len = (ulong)_end - (ulong)_init;
+#elif defined(CONFIG_BLACKFIN)
+ gd-mon_len = CONFIG_SYS_MONITOR_LEN;
#else
/* TODO: use (ulong)__bss_end - (ulong)__text_start; ? */
gd-mon_len = (ulong)__bss_end - CONFIG_SYS_MONITOR_BASE;
@@ -514,11 +525,13 @@ static int reserve_malloc(void)
/* (permanently) allocate a Board Info struct */
static int reserve_board(void)
{
- gd-start_addr_sp -= sizeof(bd_t);
- gd-bd = (bd_t *)map_sysmem(gd-start_addr_sp, sizeof(bd_t));
- memset(gd-bd, '\0', sizeof(bd_t));
- debug(Reserving %zu Bytes for Board Info at: %08lx\n,
- sizeof(bd_t), gd-start_addr_sp);
+ if (!gd-bd) {
+ gd-start_addr_sp -= sizeof(bd_t);
+ gd-bd = (bd_t *)map_sysmem(gd-start_addr_sp, sizeof(bd_t));
+ memset(gd-bd, '\0', sizeof(bd_t));
+ debug(Reserving %zu Bytes for Board Info at: %08lx\n,
+ sizeof(bd_t), gd-start_addr_sp);
+ }
return 0;
}
#endif
@@ -719,7 +732,9 @@ static int reloc_fdt(void)
static int setup_reloc(void)
{
+#ifdef CONFIG_SYS_TEXT_BASE
gd-reloc_off = gd-relocaddr - CONFIG_SYS_TEXT_BASE;
+#endif
memcpy(gd-new_gd, (char *)gd, sizeof(gd_t));
debug(Relocation Offset is: %08lx\n, gd-reloc_off);
@@ -802,7 +817,7 @@ static init_fnc_t init_sequence_f[] = {
/* TODO: can we rename this to timer_init()? */
init_timebase,
#endif
-#if defined(CONFIG_ARM) || defined(CONFIG_MIPS)
+#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || defined(CONFIG_BLACKFIN)
timer_init, /* initialize timer */
#endif
#ifdef CONFIG_SYS_ALLOC_DPRAM
@@ -901,6 +916,10 @@ static init_fnc_t init_sequence_f[] = {
* - board info struct
*/
setup_dest_addr,
+#if defined(CONFIG_BLACKFIN)
+ /* Blackfin u-boot monitor should be on top of the ram */
+ reserve_uboot,
+#endif
#if defined(CONFIG_LOGBUFFER) !defined(CONFIG_ALT_LB_ADDR)
reserve_logbuffer,
#endif
@@ -921,7 +940,9 @@ static init_fnc_t init_sequence_f[] = {
!defined(CONFIG_ARM) !defined(CONFIG_X86)
reserve_video,
#endif
+#if !defined(CONFIG_BLACKFIN)
reserve_uboot,
+#endif
#ifndef CONFIG_SPL_BUILD
reserve_malloc,
reserve_board,
diff --git a/include/watchdog.h b/include/watchdog.h
index aacacb9..437df4b 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -21,7 +21,7 @@
int init_func_watchdog_reset(void);
#endif
-#ifdef CONFIG_WATCHDOG
+#if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG)
#define INIT_FUNC_WATCHDOG_INITinit_func_watchdog_init,
#define INIT_FUNC_WATCHDOG_RESET init_func_watchdog_reset,
#else
--
1.8.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cosmetic: mconf.c: remove texts referring to modules
Hi. On Fri, 1 Aug 2014 11:38:56 +0200 Maxin B. John maxin.j...@enea.com wrote: As we don't have the concept of 'loadable modules' in u-boot, remove texts referring to modules. Signed-off-by: Maxin B. John maxin.j...@enea.com Thanks for your patch, but personally, I am against this patch. It is true the help message mentioning loadable modules is funny but it is almost harmless. So I vote for keeping this file in sync with Linux. Besides, we already have a similar concept feature, so-called standalone application. Perhaps we can use Kconfig's loadable modules feature for the standalone application... Waiting for comments from other people. 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] cosmetic: mconf.c: remove texts referring to modules
Hi Masahiro-san, On Fri, Aug 01, 2014 at 07:42:06PM +0900, Masahiro Yamada wrote: Hi. On Fri, 1 Aug 2014 11:38:56 +0200 Maxin B. John maxin.j...@enea.com wrote: As we don't have the concept of 'loadable modules' in u-boot, remove texts referring to modules. Signed-off-by: Maxin B. John maxin.j...@enea.com Thanks for your patch, but personally, I am against this patch. It is true the help message mentioning loadable modules is funny but it is almost harmless. So I vote for keeping this file in sync with Linux. I agree with your opinion. This was just a cosmetic change anyway. Please ignore this patch. Besides, we already have a similar concept feature, so-called standalone application. Perhaps we can use Kconfig's loadable modules feature for the standalone application... Waiting for comments from other people. Best Regards Masahiro Yamada Best Regards, Maxin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
From: Andre Przywara andre.przyw...@linaro.org
To enable hypervisors utilizing the ARMv7 virtualization extension
on the Arndale board, add the simple SMP pen address writer function
and add the required configuration variables to switch all cores to
HYP mode before launching the OS.
This allows booting KVM and Xen directly from u-boot.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
Note that Andre previously reported a board reset on initial boot with
this patch, but I have applied this patch on upstream master of U-Boot
and tested on two separate Arndale boards and it boots perfectly fine
and lets you use KVM, so I recommend taking this patch as is.
board/samsung/arndale/arndale.c | 10 ++
include/configs/arndale.h | 8
2 files changed, 18 insertions(+)
diff --git a/board/samsung/arndale/arndale.c b/board/samsung/arndale/arndale.c
index ef88314..83fd3bd 100644
--- a/board/samsung/arndale/arndale.c
+++ b/board/samsung/arndale/arndale.c
@@ -117,3 +117,13 @@ int checkboard(void)
return 0;
}
#endif
+
+#ifdef CONFIG_S5P_PA_SYSRAM
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ writel(addr, CONFIG_S5P_PA_SYSRAM);
+
+ /* make sure this write is really executed */
+ __asm__ volatile (dsb\n);
+}
+#endif
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 64b54ab..75f9933 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -250,4 +250,12 @@
/* Enable Time Command */
#define CONFIG_CMD_TIME
+#define CONFIG_S5P_PA_SYSRAM 0x0202
+#define CONFIG_SMP_PEN_ADDRCONFIG_S5P_PA_SYSRAM
+
+/* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override it
*/
+#define CONFIG_ARM_GIC_BASE_ADDRESS0x1048
+
+#define CONFIG_ARMV7_VIRT
+
#endif /* __CONFIG_H */
--
1.8.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Removing the need for boards.cfg
Hi, At present, as a work-around, we generate boards.cfg if needed. This is quite a slow process since each board config must be fully processed. What can we do to improve this? We only need a small number of options in order to start buildman - things like CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. I wonder if we could run a script which adds these to the defconfigs for each board and then apply a patch to mainline? Would that require removing the options from the config.h files? Or could we do that later as a separate step? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] mx6: imx-regs: Remove unused 'omux' field from iomux struct
From: Fabio Estevam fabio.este...@freescale.com
'omux' field is not used anywhere and such layout is not valid for mx6solox.
Instead of adding more ifdef's into the structure, let's simply remove this
unused 'omux' field.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 437b434..d4ce8a8 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -404,8 +404,6 @@ struct iomuxc {
u8 reserved[0x4000];
#endif
u32 gpr[14];
- u32 omux[5];
- /* mux and pad registers */
};
#define IOMUXC_GPR2_COUNTER_RESET_VAL_OFFSET 20
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] mx6: crm_regs: Fix CDCDR_SPDIF0_CLK_PODF mask and offset
From: Fabio Estevam fabio.este...@freescale.com
According to the Reference Manual the 'spdif0_clk_podf' field of register
CCM_CDCDR corresponds to bits 22, 23 and 24, so fix the mask and offset
definitions accordingly.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 0fcef69..9afe788 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -335,8 +335,8 @@ struct mxc_ccm_reg {
#endif
#define MXC_CCM_CDCDR_SPDIF0_CLK_PRED_MASK (0x7 25)
#define MXC_CCM_CDCDR_SPDIF0_CLK_PRED_OFFSET 25
-#define MXC_CCM_CDCDR_SPDIF0_CLK_PODF_MASK (0x7 19)
-#define MXC_CCM_CDCDR_SPDIF0_CLK_PODF_OFFSET 19
+#define MXC_CCM_CDCDR_SPDIF0_CLK_PODF_MASK (0x7 22)
+#define MXC_CCM_CDCDR_SPDIF0_CLK_PODF_OFFSET 22
#define MXC_CCM_CDCDR_SPDIF0_CLK_SEL_MASK (0x3 20)
#define MXC_CCM_CDCDR_SPDIF0_CLK_SEL_OFFSET20
#define MXC_CCM_CDCDR_SPDIF1_CLK_PRED_MASK (0x7 12)
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] mx6: crm_regs: Fix MXC_CCM_CLPCR_WB_PER_AT_LPM definition
From: Fabio Estevam fabio.este...@freescale.com
According to the Reference Manual the 'wb_per_at_lpm' field of register
CCM_CLPCR corresponds to bit 16 so fix its definition accordingly.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 9afe788..e1cdcec 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -432,7 +432,7 @@ struct mxc_ccm_reg {
#define MXC_CCM_CLPCR_BYP_MMDC_CH0_LPM_HS (1 19)
#define MXC_CCM_CLPCR_WB_CORE_AT_LPM (1 17)
#endif
-#define MXC_CCM_CLPCR_WB_PER_AT_LPM(1 17)
+#define MXC_CCM_CLPCR_WB_PER_AT_LPM(1 16)
#define MXC_CCM_CLPCR_COSC_PWRDOWN (1 11)
#define MXC_CCM_CLPCR_STBY_COUNT_MASK (0x3 9)
#define MXC_CCM_CLPCR_STBY_COUNT_OFFSET9
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] pmic: pmic_pfuze100: Use a shorter name for PMIC name
From: Fabio Estevam fabio.este...@freescale.com
It is redundant to use 'PFUZE100_PMIC' as the PMIC name because we already
know it is a PMIC.
Call it simply 'PFUZE100' instead.
Cc: Tim Harvey thar...@gateworks.com
Cc: Markus Niebel markus.nie...@tq-group.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 2 +-
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 2 +-
board/gateworks/gw_ventana/gw_ventana.c | 2 +-
board/tqc/tqma6/tqma6.c | 4 ++--
drivers/power/pmic/pmic_pfuze100.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index d7c4b4f..80c8ebd 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -466,7 +466,7 @@ static int pfuze_init(void)
if (ret)
return ret;
- p = pmic_get(PFUZE100_PMIC);
+ p = pmic_get(PFUZE100);
ret = pmic_probe(p);
if (ret)
return ret;
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 24d6a51..6cd2b4a 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -90,7 +90,7 @@ static int pfuze_init(void)
if (ret)
return ret;
- p = pmic_get(PFUZE100_PMIC);
+ p = pmic_get(PFUZE100);
ret = pmic_probe(p);
if (ret)
return ret;
diff --git a/board/gateworks/gw_ventana/gw_ventana.c
b/board/gateworks/gw_ventana/gw_ventana.c
index 9967f80..ae1cf87 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -903,7 +903,7 @@ int power_init_board(void)
/* configure PFUZE100 PMIC */
if (board_type == GW54xx || board_type == GW54proto) {
power_pfuze100_init(I2C_PMIC);
- p = pmic_get(PFUZE100_PMIC);
+ p = pmic_get(PFUZE100);
if (p !pmic_probe(p)) {
pmic_reg_read(p, PFUZE100_DEVICEID, reg);
printf(PMIC: PFUZE100 ID=0x%02x\n, reg);
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index 69c4551..b552bb8 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -229,10 +229,10 @@ int board_late_init(void)
* fixed in generic power code
*/
power_pfuze100_init(TQMA6_PFUZE100_I2C_BUS);
- p = pmic_get(PFUZE100_PMIC);
+ p = pmic_get(PFUZE100);
if (p !pmic_probe(p)) {
pmic_reg_read(p, PFUZE100_DEVICEID, reg);
- printf(PMIC: PFUZE100_PMIC ID=0x%02x\n, reg);
+ printf(PMIC: PFUZE100 ID=0x%02x\n, reg);
}
tqma6_bb_board_late_init();
diff --git a/drivers/power/pmic/pmic_pfuze100.c
b/drivers/power/pmic/pmic_pfuze100.c
index 21f12d2..22a04c0 100644
--- a/drivers/power/pmic/pmic_pfuze100.c
+++ b/drivers/power/pmic/pmic_pfuze100.c
@@ -13,7 +13,7 @@
int power_pfuze100_init(unsigned char bus)
{
- static const char name[] = PFUZE100_PMIC;
+ static const char name[] = PFUZE100;
struct pmic *p = pmic_alloc();
if (!p) {
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] mx6: crm_regs: Fix MXC_CCM_CIMR_MASK_PERIPH2_CLK_SEL_LOADED
From: Fabio Estevam fabio.este...@freescale.com
According to the Reference Manual the 'mask_periph2_clk_sel_loaded' field of
register CCM_CIMR corresponds to bit 19 so fix its definition accordingly.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index e1cdcec..9a7fb34 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -469,7 +469,7 @@ struct mxc_ccm_reg {
#define MXC_CCM_CIMR_MASK_PERIPH_CLK_SEL_LOADED(1 22)
#define MXC_CCM_CIMR_MASK_MMDC_CH1_PODF_LOADED (1 21)
#define MXC_CCM_CIMR_MASK_AHB_PODF_LOADED (1 20)
-#define MXC_CCM_CIMR_MASK_PERIPH2_CLK_SEL_LOADED (1 22)
+#define MXC_CCM_CIMR_MASK_PERIPH2_CLK_SEL_LOADED (1 19)
#define MXC_CCM_CIMR_MASK_AXI_PODF_LOADED (1 17)
#define MXC_CCM_CIMR_MASK_COSC_READY (1 6)
#define MXC_CCM_CIMR_MASK_LRF_PLL 1
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Dear Alexander Holler,
In message 1405352998-7707-2-git-send-email-hol...@ahsoftware.de you wrote:
When this option is enabled, CRLF is treated like LF when importing
environments
from text files, which means CRs ('\r') in front of LFs ('\n') are just
ignored.
Drawback of enabling this option is that (maybe exported) variables which have
a trailing CR in their content will get imported without that CR. But this
drawback is very unlikely and the big advantage of letting Windows user create
a *working* uEnv.txt too is likely more welcome.
Should we not, for reasons of symmetry, then also extend env export
by such a -r option?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When it is incorrect, it is, at least *authoritatively* incorrect.
- Hitchiker's Guide To The Galaxy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] usb/gadget: fastboot: add sparse image definitions
On Thursday, July 31, 2014 at 07:32:51 PM, Steve Rae wrote:
On 14-07-30 06:25 PM, Marek Vasut wrote:
On Thursday, June 26, 2014 at 10:13:21 PM, Steve Rae wrote:
- to prepare for the support of fastboot sparse images
Signed-off-by: Steve Rae s...@broadcom.com
---
This file is ASIS from:
https://raw.githubusercontent.com/AOSB/android_system_core/master/libspa
rs e/sparse_format.h (commit 28fa5bc347390480fe190294c6c385b6a9f0d68b)
except for the __UBOOT__ conditional include.
Changes in v3: None
Changes in v2: None
include/sparse_format.h | 58
+ 1 file changed, 58
insertions(+)
create mode 100644 include/sparse_format.h
diff --git a/include/sparse_format.h b/include/sparse_format.h
new file mode 100644
index 000..21fbd05
--- /dev/null
+++ b/include/sparse_format.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2010 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied. + * See the License for the specific language governing
permissions and + * limitations under the License.
Please use the SPDX licence identifiers (pelase see Licenses/README)?
+ */
+
+#ifndef _LIBSPARSE_SPARSE_FORMAT_H_
+#define _LIBSPARSE_SPARSE_FORMAT_H_
+#define __UBOOT__
+#ifndef __UBOOT__
+#include sparse_defs.h
+#endif
+
+typedef struct sparse_header {
+ __le32 magic; /* 0xed26ff3a */
+ __le16 major_version; /* (0x1) - reject images with higher major
versions */ + __le16 minor_version; /* (0x0) - allow images with
higer
minor versions */ + __le16file_hdr_sz;/* 28 bytes for first
revision
of the file format */ + __le16chunk_hdr_sz; /* 12 bytes for first
revision of the file format */ + __le32 blk_sz; /* block size in
bytes,
must be a
multiple of 4 (4096) */ + __le32 total_blks; /* total blocks in the
non-sparse output image */ + __le32 total_chunks; /* total chunks
in
the sparse input image */ + __le32image_checksum; /* CRC32
checksum
of the original data, counting don't care */ +
/*
as 0.
Standard 802.3
polynomial, use a Public Domain */
+ /* table implementation */
+} sparse_header_t;
+
+#define SPARSE_HEADER_MAGIC 0xed26ff3a
+
+#define CHUNK_TYPE_RAW0xCAC1
+#define CHUNK_TYPE_FILL 0xCAC2
+#define CHUNK_TYPE_DONT_CARE 0xCAC3
+#define CHUNK_TYPE_CRC320xCAC4
+
+typedef struct chunk_header {
+ __le16 chunk_type; /* 0xCAC1 - raw; 0xCAC2 - fill; 0xCAC3 -
don't
care */ + __le16 reserved1;
+ __le32 chunk_sz; /* in blocks in output image */
+ __le32 total_sz; /* in bytes of chunk input file including chunk
header
and data */ +} chunk_header_t;
+
+/* Following a Raw or Fill or CRC32 chunk is data.
The comment here is not aligned with coding style, I'll leave fixing it
up to you, since the license header text needs revisiting.
+ * For a Raw chunk, it's the data in chunk_sz * blk_sz.
+ * For a Fill chunk, it's 4 bytes of the fill data.
+ * For a CRC32 chunk, it's 4 bytes of CRC32
+ */
+
+#endif
To clarify:
I am taking this file ASIS from the location stated in the commit
message
Do we _really_ want to modify _anything_ in this file (especially when
the content is not changing); or do we want to leaving it pristine?
I'd prefer consistency with the rest of the codebase. Let's wait what others
think.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Removing the need for boards.cfg
Hi. On Fri, 1 Aug 2014 12:48:44 +0100 Simon Glass s...@chromium.org wrote: Hi, At present, as a work-around, we generate boards.cfg if needed. This is quite a slow process since each board config must be fully processed. What can we do to improve this? We only need a small number of options in order to start buildman - things like CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. I wonder if we could run a script which adds these to the defconfigs for each board and then apply a patch to mainline? Would that require removing the options from the config.h files? Or could we do that later as a separate step? We cannot add CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. to defconfigs because they are not user-editable options. (They must be always selected in correct combination.) This is already discussed when I posted the RFC version of the Kconfig series. We can easily do [1] Choose boards by arch Just grep CONFIG_ARM=y, CONFIG_MIPS=y, CONFIG_SANDBOX=y in defconfigs [2] Choose boards by board name It is the file name of defconfigs My question is, do we really need to choose by CPU, Vendor, SoC ? I know they are useful. For ex. nvidia developers probably want to build only Tegra boards. One possible idea I come up with is to have 'board group' in .buildman file so people can build only boards they are interested in. Something like this: --8--- [board-alisa] tegra20: harmony seaboard ventana tegra30: beaver tegra114: dalmore tegra124: venice2 tegra:tegra20 tegra30 tegra114 tegra124 ---8--- With the settings above, tools/buildman/buildman tegra20 is the same as tools/buildman/buildman harmony seaboard ventana tools/buildman/buildman tegra is the same as tools/buildman/buildmantegra20 tegra30 tegra114 tegra124 and also the same as tools/buildman/buildmanharmony seaboard ventana beaver dalmore venice2 We have to setup ~/.buildman at the first run. (and modify it when adding new boards) Better to provide a tool to auto-generate .buildman file? 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 3/3] driver/mc: print Management Complex version info
On Fri, Aug 1, 2014 at 12:13 AM, Lijun Pan lijun@freescale.com wrote: After the MC is booted, u-boot should print out the Management Complex version info where appropriate. Also, clean up the code to make checkpatch.pl happy. Signed-off-by: Lijun Pan lijun@freescale.com Signed-off-by: J. German Rivera german.riv...@freescale.com Couldn't this be squashed into 1/3? This seems an extension to it which could be add in the iitial patch. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
On 1 August 2014 14:46, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Can you just add when applying the patch? Signed-off-by: Christoffer Dall christoffer.d...@linaro.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
On 1 August 2014 14:59, Andre Przywara andre.przyw...@arm.com wrote: On 01/08/14 13:53, Christoffer Dall wrote: On 1 August 2014 14:46, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Can you just add when applying the patch? Signed-off-by: Christoffer Dall christoffer.d...@linaro.org Andreas, I wonder if you could change (or add) my new address, as my Linaro address does not work any more (just tested). Signed-off-by: Andre Przywara andre.przyw...@arm.com So I actually did not know the policy here, given that you did the work under your linaro.org address, so I decided to keep this as they were and just cc your arm address. If you're fine with using the @arm.com address I can respin the patch with the right addresses and signed-off-by's. -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
On 01/08/14 13:53, Christoffer Dall wrote: On 1 August 2014 14:46, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Can you just add when applying the patch? Signed-off-by: Christoffer Dall christoffer.d...@linaro.org Andreas, I wonder if you could change (or add) my new address, as my Linaro address does not work any more (just tested). Signed-off-by: Andre Przywara andre.przyw...@arm.com Christoffer, thanks for taking care of this! Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
On 01/08/14 14:02, Christoffer Dall wrote: On 1 August 2014 14:59, Andre Przywara andre.przyw...@arm.com wrote: On 01/08/14 13:53, Christoffer Dall wrote: On 1 August 2014 14:46, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Can you just add when applying the patch? Signed-off-by: Christoffer Dall christoffer.d...@linaro.org Andreas, I wonder if you could change (or add) my new address, as my Linaro address does not work any more (just tested). Signed-off-by: Andre Przywara andre.przyw...@arm.com So I actually did not know the policy here, given that you did the work under your linaro.org address, so I decided to keep this as they were and just cc your arm address. If you're fine with using the @arm.com address I can respin the patch with the right addresses and signed-off-by's. I don't know about the policy either - actually I hoped you could help here ;-) I am perfectly fine with giving Linaro as a sponsor credit for this, but I am just concerned about potential feedback, which would bounce and at best annoy people. As long as a post goes to a list also I catch it, but private only email would be stuck. This said I am fine both ways - maybe we keep both addresses for reference in? Andreas, could you just add Christoffer's Signed-off-by and my Signed-off-by @arm.com without a respin? Regards, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Convert CONFIG_CONS_INDEX into a menu choice
- Drop CONFIG_SERIAL[1-6] and use CONFIG_CONS_INDEX tests instead
- Add choice and help text to board/ti/am335x/Kconfig
- Correct comment about IDK in board/ti/am335x/mux.c
- Remove am335x_evm_uart* defconfig files as they're just variations
on a config option now.
Signed-off-by: Tom Rini tr...@ti.com
---
board/ti/am335x/Kconfig |9 +
board/ti/am335x/board.c | 19 +++
board/ti/am335x/mux.c|7 +--
configs/am335x_evm_defconfig |3 ++-
configs/am335x_evm_nor_defconfig |3 ++-
configs/am335x_evm_norboot_defconfig |3 ++-
configs/am335x_evm_spiboot_defconfig |3 ++-
configs/am335x_evm_uart1_defconfig |4
configs/am335x_evm_uart2_defconfig |4
configs/am335x_evm_uart3_defconfig |4
configs/am335x_evm_uart4_defconfig |4
configs/am335x_evm_uart5_defconfig |4
configs/am335x_evm_usbspl_defconfig |3 ++-
13 files changed, 27 insertions(+), 43 deletions(-)
delete mode 100644 configs/am335x_evm_uart1_defconfig
delete mode 100644 configs/am335x_evm_uart2_defconfig
delete mode 100644 configs/am335x_evm_uart3_defconfig
delete mode 100644 configs/am335x_evm_uart4_defconfig
delete mode 100644 configs/am335x_evm_uart5_defconfig
diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig
index c3b61af2..0e5149c 100644
--- a/board/ti/am335x/Kconfig
+++ b/board/ti/am335x/Kconfig
@@ -20,4 +20,13 @@ config SYS_CONFIG_NAME
string
default am335x_evm
+config CONS_INDEX
+ int UART used for console
+ default 1
+ help
+ The AM335x SoC has a total of 6 UARTs (UART0 to UART5 as referenced
+ in documentation, etc) available to it. Depending on your specific
+ board you may want something other than UART0 as for example the IDK
+ uses UART3 so enter 4 here.
+
endif
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index d81eec9..0739e60 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -383,24 +383,19 @@ const struct dpll_params *get_dpll_ddr_params(void)
void set_uart_mux_conf(void)
{
-#ifdef CONFIG_SERIAL1
+#if CONFIG_CONS_INDEX == 1
enable_uart0_pin_mux();
-#endif /* CONFIG_SERIAL1 */
-#ifdef CONFIG_SERIAL2
+#elif CONFIG_CONS_INDEX == 2
enable_uart1_pin_mux();
-#endif /* CONFIG_SERIAL2 */
-#ifdef CONFIG_SERIAL3
+#elif CONFIG_CONS_INDEX == 3
enable_uart2_pin_mux();
-#endif /* CONFIG_SERIAL3 */
-#ifdef CONFIG_SERIAL4
+#elif CONFIG_CONS_INDEX == 4
enable_uart3_pin_mux();
-#endif /* CONFIG_SERIAL4 */
-#ifdef CONFIG_SERIAL5
+#elif CONFIG_CONS_INDEX == 5
enable_uart4_pin_mux();
-#endif /* CONFIG_SERIAL5 */
-#ifdef CONFIG_SERIAL6
+#elif CONFIG_CONS_INDEX == 6
enable_uart5_pin_mux();
-#endif /* CONFIG_SERIAL6 */
+#endif
}
void set_mux_conf_regs(void)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index b2bfda5..3fdbedf 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -358,12 +358,7 @@ void enable_board_pin_mux(struct am335x_baseboard_id
*header)
configure_module_pin_mux(spi0_pin_mux);
}
} else if (board_is_idk(header)) {
- /*
-* Industrial Motor Control (IDK)
-* note: IDK console is on UART3 by default.
-* So u-boot mus be build with CONFIG_SERIAL4 and
-* CONFIG_CONS_INDEX=4
-*/
+ /* Industrial Motor Control (IDK) */
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_no_cd_pin_mux);
} else if (board_is_evm_sk(header)) {
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 7710dc0..2e5aeaa 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -1,4 +1,5 @@
CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NAND
+CONFIG_SYS_EXTRA_OPTIONS=NAND
+CONFIG_CONS_INDEX=1
+S:CONFIG_ARM=y
+S:CONFIG_TARGET_AM335X_EVM=y
diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
index fecec5e..2e5aeaa 100644
--- a/configs/am335x_evm_nor_defconfig
+++ b/configs/am335x_evm_nor_defconfig
@@ -1,4 +1,5 @@
CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NAND,NOR
+CONFIG_SYS_EXTRA_OPTIONS=NAND
+CONFIG_CONS_INDEX=1
+S:CONFIG_ARM=y
+S:CONFIG_TARGET_AM335X_EVM=y
diff --git a/configs/am335x_evm_norboot_defconfig
b/configs/am335x_evm_norboot_defconfig
index 6005c22..872a493 100644
--- a/configs/am335x_evm_norboot_defconfig
+++ b/configs/am335x_evm_norboot_defconfig
@@ -1,3 +1,4 @@
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT
+CONFIG_SYS_EXTRA_OPTIONS=NAND
+CONFIG_CONS_INDEX=1
CONFIG_ARM=y
CONFIG_TARGET_AM335X_EVM=y
diff --git a/configs/am335x_evm_spiboot_defconfig
b/configs/am335x_evm_spiboot_defconfig
index 389d1d8..2e5aeaa 100644
---
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
On 1 August 2014 15:29, Andre Przywara andre.przyw...@arm.com wrote: On 01/08/14 14:02, Christoffer Dall wrote: On 1 August 2014 14:59, Andre Przywara andre.przyw...@arm.com wrote: On 01/08/14 13:53, Christoffer Dall wrote: On 1 August 2014 14:46, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Can you just add when applying the patch? Signed-off-by: Christoffer Dall christoffer.d...@linaro.org Andreas, I wonder if you could change (or add) my new address, as my Linaro address does not work any more (just tested). Signed-off-by: Andre Przywara andre.przyw...@arm.com So I actually did not know the policy here, given that you did the work under your linaro.org address, so I decided to keep this as they were and just cc your arm address. If you're fine with using the @arm.com address I can respin the patch with the right addresses and signed-off-by's. I don't know about the policy either - actually I hoped you could help here ;-) I am perfectly fine with giving Linaro as a sponsor credit for this, but I am just concerned about potential feedback, which would bounce and at best annoy people. As long as a post goes to a list also I catch it, but private only email would be stuck. This said I am fine both ways - maybe we keep both addresses for reference in? Andreas, could you just add Christoffer's Signed-off-by and my Signed-off-by @arm.com without a respin? Andreas pointed out that he's not the maintainer, so let's see what the maintainer says :) all this policy stuff seems to be bikeshedding anyhow. -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Removing the need for boards.cfg
On Fri, Aug 01, 2014 at 09:22:42PM +0900, Masahiro Yamada wrote: Hi. On Fri, 1 Aug 2014 12:48:44 +0100 Simon Glass s...@chromium.org wrote: Hi, At present, as a work-around, we generate boards.cfg if needed. This is quite a slow process since each board config must be fully processed. What can we do to improve this? We only need a small number of options in order to start buildman - things like CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. I wonder if we could run a script which adds these to the defconfigs for each board and then apply a patch to mainline? Would that require removing the options from the config.h files? Or could we do that later as a separate step? We cannot add CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. to defconfigs because they are not user-editable options. (They must be always selected in correct combination.) This is already discussed when I posted the RFC version of the Kconfig series. We can easily do [1] Choose boards by arch Just grep CONFIG_ARM=y, CONFIG_MIPS=y, CONFIG_SANDBOX=y in defconfigs [2] Choose boards by board name It is the file name of defconfigs My question is, do we really need to choose by CPU, Vendor, SoC ? I know they are useful. For ex. nvidia developers probably want to build only Tegra boards. For me, I don't see CPU or Vendor as super important but SoC is. I'll often be doing some TI work for say am335x or am43xx and be checking over those two board configs but once I'm done (or nearing done) I need to build for SoC==am33xx to catch all of the other vendors that have boards in the family. -- 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: enable ARMv7 virt support for the Arndale board
Am 01.08.2014 15:29, schrieb Andre Przywara: On 01/08/14 14:02, Christoffer Dall wrote: On 1 August 2014 14:59, Andre Przywara andre.przyw...@arm.com wrote: On 01/08/14 13:53, Christoffer Dall wrote: On 1 August 2014 14:46, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: From: Andre Przywara andre.przyw...@linaro.org To enable hypervisors utilizing the ARMv7 virtualization extension on the Arndale board, add the simple SMP pen address writer function and add the required configuration variables to switch all cores to HYP mode before launching the OS. This allows booting KVM and Xen directly from u-boot. Reviewed-by: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Andre Przywara andre.przyw...@linaro.org You forgot to sign off the patch. But nice to see progress on this! Can you just add when applying the patch? Signed-off-by: Christoffer Dall christoffer.d...@linaro.org Andreas, I wonder if you could change (or add) my new address, as my Linaro address does not work any more (just tested). Signed-off-by: Andre Przywara andre.przyw...@arm.com So I actually did not know the policy here, given that you did the work under your linaro.org address, so I decided to keep this as they were and just cc your arm address. If you're fine with using the @arm.com address I can respin the patch with the right addresses and signed-off-by's. I don't know about the policy either - actually I hoped you could help here ;-) I am perfectly fine with giving Linaro as a sponsor credit for this, but I am just concerned about potential feedback, which would bounce and at best annoy people. As long as a post goes to a list also I catch it, but private only email would be stuck. This said I am fine both ways - maybe we keep both addresses for reference in? Andreas, could you just add Christoffer's Signed-off-by and my Signed-off-by @arm.com without a respin? Guys, I just reacted to this patch because I spotted virt and we have a small farm of Arndale boards for OBS. Please take a look at http://www.denx.de/wiki/U-Boot/Custodians, which lists Albert for ARM and Minkyu for Samsung (CC'ed). Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x_evm: Convert CONFIG_CONS_INDEX into a menu choice
On Fri, Aug 01, 2014 at 09:36:54AM -0400, Tom Rini wrote: - Drop CONFIG_SERIAL[1-6] and use CONFIG_CONS_INDEX tests instead - Add choice and help text to board/ti/am335x/Kconfig - Correct comment about IDK in board/ti/am335x/mux.c - Remove am335x_evm_uart* defconfig files as they're just variations on a config option now. [snip] diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig index 6005c22..872a493 100644 --- a/configs/am335x_evm_norboot_defconfig +++ b/configs/am335x_evm_norboot_defconfig @@ -1,3 +1,4 @@ -CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT +CONFIG_SYS_EXTRA_OPTIONS=NAND Regex gone wild here, oops, V2 shortly. -- 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 v2] am335x_evm: Convert CONFIG_CONS_INDEX into a menu choice
- Drop CONFIG_SERIAL[1-6] and use CONFIG_CONS_INDEX tests instead
- Add choice and help text to board/ti/am335x/Kconfig
- Correct comment about IDK in board/ti/am335x/mux.c
- Remove am335x_evm_uart* defconfig files as they're just variations
on a config option now.
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v2:
- Correct nor/spi defconfig related thinkos
---
board/ti/am335x/Kconfig |9 +
board/ti/am335x/board.c | 19 +++
board/ti/am335x/mux.c|7 +--
configs/am335x_evm_defconfig |3 ++-
configs/am335x_evm_nor_defconfig |3 ++-
configs/am335x_evm_norboot_defconfig |3 ++-
configs/am335x_evm_spiboot_defconfig |3 ++-
configs/am335x_evm_uart1_defconfig |4
configs/am335x_evm_uart2_defconfig |4
configs/am335x_evm_uart3_defconfig |4
configs/am335x_evm_uart4_defconfig |4
configs/am335x_evm_uart5_defconfig |4
configs/am335x_evm_usbspl_defconfig |3 ++-
13 files changed, 27 insertions(+), 43 deletions(-)
delete mode 100644 configs/am335x_evm_uart1_defconfig
delete mode 100644 configs/am335x_evm_uart2_defconfig
delete mode 100644 configs/am335x_evm_uart3_defconfig
delete mode 100644 configs/am335x_evm_uart4_defconfig
delete mode 100644 configs/am335x_evm_uart5_defconfig
diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig
index c3b61af2..0e5149c 100644
--- a/board/ti/am335x/Kconfig
+++ b/board/ti/am335x/Kconfig
@@ -20,4 +20,13 @@ config SYS_CONFIG_NAME
string
default am335x_evm
+config CONS_INDEX
+ int UART used for console
+ default 1
+ help
+ The AM335x SoC has a total of 6 UARTs (UART0 to UART5 as referenced
+ in documentation, etc) available to it. Depending on your specific
+ board you may want something other than UART0 as for example the IDK
+ uses UART3 so enter 4 here.
+
endif
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index d81eec9..0739e60 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -383,24 +383,19 @@ const struct dpll_params *get_dpll_ddr_params(void)
void set_uart_mux_conf(void)
{
-#ifdef CONFIG_SERIAL1
+#if CONFIG_CONS_INDEX == 1
enable_uart0_pin_mux();
-#endif /* CONFIG_SERIAL1 */
-#ifdef CONFIG_SERIAL2
+#elif CONFIG_CONS_INDEX == 2
enable_uart1_pin_mux();
-#endif /* CONFIG_SERIAL2 */
-#ifdef CONFIG_SERIAL3
+#elif CONFIG_CONS_INDEX == 3
enable_uart2_pin_mux();
-#endif /* CONFIG_SERIAL3 */
-#ifdef CONFIG_SERIAL4
+#elif CONFIG_CONS_INDEX == 4
enable_uart3_pin_mux();
-#endif /* CONFIG_SERIAL4 */
-#ifdef CONFIG_SERIAL5
+#elif CONFIG_CONS_INDEX == 5
enable_uart4_pin_mux();
-#endif /* CONFIG_SERIAL5 */
-#ifdef CONFIG_SERIAL6
+#elif CONFIG_CONS_INDEX == 6
enable_uart5_pin_mux();
-#endif /* CONFIG_SERIAL6 */
+#endif
}
void set_mux_conf_regs(void)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index b2bfda5..3fdbedf 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -358,12 +358,7 @@ void enable_board_pin_mux(struct am335x_baseboard_id
*header)
configure_module_pin_mux(spi0_pin_mux);
}
} else if (board_is_idk(header)) {
- /*
-* Industrial Motor Control (IDK)
-* note: IDK console is on UART3 by default.
-* So u-boot mus be build with CONFIG_SERIAL4 and
-* CONFIG_CONS_INDEX=4
-*/
+ /* Industrial Motor Control (IDK) */
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_no_cd_pin_mux);
} else if (board_is_evm_sk(header)) {
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 7710dc0..2e5aeaa 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -1,4 +1,5 @@
CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NAND
+CONFIG_SYS_EXTRA_OPTIONS=NAND
+CONFIG_CONS_INDEX=1
+S:CONFIG_ARM=y
+S:CONFIG_TARGET_AM335X_EVM=y
diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
index fecec5e..41f31cc02 100644
--- a/configs/am335x_evm_nor_defconfig
+++ b/configs/am335x_evm_nor_defconfig
@@ -1,4 +1,5 @@
CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NAND,NOR
+CONFIG_SYS_EXTRA_OPTIONS=NAND,NOR
+CONFIG_CONS_INDEX=1
+S:CONFIG_ARM=y
+S:CONFIG_TARGET_AM335X_EVM=y
diff --git a/configs/am335x_evm_norboot_defconfig
b/configs/am335x_evm_norboot_defconfig
index 6005c22..7dbfa27 100644
--- a/configs/am335x_evm_norboot_defconfig
+++ b/configs/am335x_evm_norboot_defconfig
@@ -1,3 +1,4 @@
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT
+CONFIG_SYS_EXTRA_OPTIONS=NOR,NOR_BOOT
+CONFIG_CONS_INDEX=1
CONFIG_ARM=y
CONFIG_TARGET_AM335X_EVM=y
diff --git a/configs/am335x_evm_spiboot_defconfig
Re: [U-Boot] Removing the need for boards.cfg
Simon, Tom, On Fri, 1 Aug 2014 09:38:03 -0400 Tom Rini tr...@ti.com wrote: On Fri, Aug 01, 2014 at 09:22:42PM +0900, Masahiro Yamada wrote: Hi. On Fri, 1 Aug 2014 12:48:44 +0100 Simon Glass s...@chromium.org wrote: Hi, At present, as a work-around, we generate boards.cfg if needed. This is quite a slow process since each board config must be fully processed. What can we do to improve this? We only need a small number of options in order to start buildman - things like CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. I wonder if we could run a script which adds these to the defconfigs for each board and then apply a patch to mainline? Would that require removing the options from the config.h files? Or could we do that later as a separate step? We cannot add CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. to defconfigs because they are not user-editable options. (They must be always selected in correct combination.) This is already discussed when I posted the RFC version of the Kconfig series. We can easily do [1] Choose boards by arch Just grep CONFIG_ARM=y, CONFIG_MIPS=y, CONFIG_SANDBOX=y in defconfigs [2] Choose boards by board name It is the file name of defconfigs My question is, do we really need to choose by CPU, Vendor, SoC ? I know they are useful. For ex. nvidia developers probably want to build only Tegra boards. For me, I don't see CPU or Vendor as super important but SoC is. I'll often be doing some TI work for say am335x or am43xx and be checking over those two board configs but once I'm done (or nearing done) I need to build for SoC==am33xx to catch all of the other vendors that have boards in the family. If MAKEALL/buildman is invoked without any arguments (which means build all the board), boards.cfg is not necessary in the first place. It that case, can we skip generating boards.cfg ? (We can get the board list by 'ls configs' ) We need a database only when we want to select boards by CPU, Vendor, SoC. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] unlock NVRAM for writing from within U-boot shell
Embedded Linux device: how is performed NVRAM update?
For example, updates of firmware, u-boot, uimage and other are performed from
U-Boot, here sample code from U-boot:
update_uboot=tftpboot 0x8100 u-boot.bin protect off 0x4800
+${filesize} erase 0x4800 +${filesize} sleep ${sdelay} cp.b
${fileaddr} 0x4800 ${filesize} protect on 0x4800 +${filesize}
update_uimage=tftpboot 0x8100 uImage protect off ${UBFIADDR1}
+${filesize} erase ${UBFIADDR1} +${filesize} sleep ${sdelay} cp.b
${fileaddr} ${UBFIADDR1} ${filesize} protect on ${UBFIADDR1} +${filesize}
There is no any directions or tips related to NVRAM update in U-boot code. The
nvram.bin offset address is specified in code, so is it possible to write to
NVRAM from U-boot shell mode? (even if there is no directions on U-boot) If
yes, how to unlock NVRAM for writing from within u-boot shell?
Spansion Serial Flash FLASH_S25FL064A
here is U-boot dump with all commands inside:
http://pastebin.com/raw.php?i=W6mnfUaq
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] usb/gadget: fastboot: add sparse image definitions
On Thu, Jun 26, 2014 at 1:45 PM, Steve Rae s...@broadcom.com wrote: - to prepare for the support of fastboot sparse images Signed-off-by: Steve Rae s...@broadcom.com --- This file is ASIS from: https://raw.githubusercontent.com/AOSB/android_system_core/master/libsparse/sparse_format.h (commit 28fa5bc347390480fe190294c6c385b6a9f0d68b) except for the __UBOOT__ conditional include. Changes in v2: None include/sparse_format.h | 58 + 1 file changed, 58 insertions(+) create mode 100644 include/sparse_format.h diff --git a/include/sparse_format.h b/include/sparse_format.h new file mode 100644 index 000..21fbd05 --- /dev/null +++ b/include/sparse_format.h @@ -0,0 +1,58 @@ +/* + * Copyright (C) 2010 The Android Open Source Project + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ My understanding is Apache license is not compatible with GPL. There are multiple versions of fastboot files to be found in AOSP with different licenses, so you need to find this with a BSD license. Probably the u-boot (in AOSP) or little-kernel tree has it. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] usb/gadget: fastboot: add sparse image definitions
On Fri, Aug 01, 2014 at 09:42:19AM -0500, Rob Herring wrote: On Thu, Jun 26, 2014 at 1:45 PM, Steve Rae s...@broadcom.com wrote: - to prepare for the support of fastboot sparse images Signed-off-by: Steve Rae s...@broadcom.com --- This file is ASIS from: https://raw.githubusercontent.com/AOSB/android_system_core/master/libsparse/sparse_format.h (commit 28fa5bc347390480fe190294c6c385b6a9f0d68b) except for the __UBOOT__ conditional include. Changes in v2: None include/sparse_format.h | 58 + 1 file changed, 58 insertions(+) create mode 100644 include/sparse_format.h diff --git a/include/sparse_format.h b/include/sparse_format.h new file mode 100644 index 000..21fbd05 --- /dev/null +++ b/include/sparse_format.h @@ -0,0 +1,58 @@ +/* + * Copyright (C) 2010 The Android Open Source Project + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ My understanding is Apache license is not compatible with GPL. There are multiple versions of fastboot files to be found in AOSP with different licenses, so you need to find this with a BSD license. Probably the u-boot (in AOSP) or little-kernel tree has it. You are correct in that Apache-2.0 is not GPL compatible. However (and this question came up inside TI as well), as far as I can tell the sparse file format is NOT available in other licenses (unlike fastboot itself). If anyone out there knows who at Google to ask about getting the file re-licensed that would be great... -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/16] sandbox: dts: Add a serial console node
+ uart0: serial {
+ compatible = sandbox,serial;
+ u-boot,dm-pre-reloc;
Shouldn't that be handled by the driver. It's certainly something that's
only relevant to the internals of U-Boot, and hence inappropriate to put
into DT.
Hence the u-boot prefix. This is described in the driver model docs. I
have found a work-around (which forces a driver to be inited pre-reloc
if none is found) but I'm not 100% happy with it.
I'm arguing that the property shouldn't exist in DT at all. DT is supposed
to be a pure description of the HW, and not encode details that are specific
to the implementation of particular SW. The fact that U-Boot performs
relocation of its code during boot is completely irrelevant to a HW
description.
As such, the issue isn't whether there is a u-boot, prefix on that property,
but whether it's there at all.
Right. And I've arguing that U-Boot should use exactly the same
descriptions that are in the Kernel even. Those DTS descriptions should
be common, applicable to both or neither, exactly because they do
describe the HW and are agnostic WRT the SW that is using them.
HTH,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Driver Model and DTS Parsing
Firstly we need to establish that GPIOs have names and that these should be supported in U-Boot. Without agreement on this point we might not get much further. Can I please press you on this point, as it is important to establish this first. Oh, you were talking about agreeing with me? I thought this was more of a general comment, since you'd indicated earlier that amending the gpio to handle names was outside the scope of this patchset, and GPIO names are basically only relevant if the user-interface exposes/handles the names. Yeah, but that applied to my request to use names that were derived and identified by those strings/names supplied in the DTS files. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/1] ARM: kirkwood: add mvsdio driver
Hi there, On Jul 29, 2014, at 7:39 PM, drEagle wrote: Hi Stefan, On 26/07/2014 13:54, Stefan Roese wrote: On 25.07.2014 21:07, Gerald Kerma wrote: This patch add Marvell kirkwood MVSDIO/MMC driver and enable it for Sheevaplugs and OpenRD boards. Signed-off-by: Gerald Kerma drea...@doukki.net Looks good now, so: Reviewed-by: Stefan Roese s...@denx.de Thank for you review. Is there any action I have to do now ? Enjoy Applied, thanks. -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2] bcm2835_sdhci: Add SDHCI_QUIRK_NO_HISPD_BIT flag
Hi Lubomir, On Jul 17, 2014, at 2:57 PM, Lubomir Rintel wrote: Seems like the controller doesn't support the flag. None of the hi-speed cards I've tried could be read, while they successfully worked with the quirk enabled. Signed-off-by: Lubomir Rintel lkund...@v3.sk Tested-by: Stephen Warren swar...@wwwdotorg.org --- Changes to v2: - I've sent the first version with extra and irrelevant hunk. Sorry. drivers/mmc/bcm2835_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c index 54cfabf..82079d6 100644 --- a/drivers/mmc/bcm2835_sdhci.c +++ b/drivers/mmc/bcm2835_sdhci.c @@ -179,7 +179,7 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq) host-name = bcm2835_sdhci; host-ioaddr = (void *)regbase; host-quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B | - SDHCI_QUIRK_WAIT_SEND_CMD; + SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_NO_HISPD_BIT; host-voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195; host-ops = bcm2835_ops; -- 1.8.3.1 Thanks, Applied. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/12] mmc: s3c: Add SD driver
Hi Marek, On Jul 22, 2014, at 3:34 AM, Marek Vasut wrote: Implement SD driver for the S3C24xx family. This implementation is currently only capable of using the PIO transfers, DMA is not supported. Signed-off-by: Marek Vasut ma...@denx.de Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com Cc: Vladimir Zapolskiy v...@mleia.com --- arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 6 + drivers/mmc/Makefile| 1 + drivers/mmc/s3c_sdi.c | 321 3 files changed, 328 insertions(+) create mode 100644 drivers/mmc/s3c_sdi.c [snip] Applied, thanks -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/12] mmc: s3c: Add SD driver
Hi Marek, On Jul 22, 2014, at 3:34 AM, Marek Vasut wrote: Implement SD driver for the S3C24xx family. This implementation is currently only capable of using the PIO transfers, DMA is not supported. Signed-off-by: Marek Vasut ma...@denx.de Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com Cc: Vladimir Zapolskiy v...@mleia.com --- arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 6 + drivers/mmc/Makefile| 1 + drivers/mmc/s3c_sdi.c | 321 3 files changed, 328 insertions(+) create mode 100644 drivers/mmc/s3c_sdi.c [snip] Applied, thanks. -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc/dw_mmc: Fix clock divider calculation error for bypass mode
Hi Chin, On Jun 10, 2014, at 9:26 AM, Chin Liang See wrote: To fix the clock divider calculation error when the controller clock same as the operating frequency. This is known as bypass mode. In this mode, the divider should be 0. Signed-off-by: Chin Liang See cl...@altera.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com Cc: Rajeshwari Shinde rajeshwar...@samsung.com Cc: Jaehoon Chung jh80.ch...@samsung.com Cc: Mischa Jonker mjon...@synopsys.com --- drivers/mmc/dw_mmc.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index 5bf36a0..0df30bc 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -245,7 +245,10 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 freq) return -EINVAL; } - div = DIV_ROUND_UP(sclk, 2 * freq); + if (sclk == freq) + div = 0;/* bypass mode */ + else + div = DIV_ROUND_UP(sclk, 2 * freq); dwmci_writel(host, DWMCI_CLKENA, 0); dwmci_writel(host, DWMCI_CLKSRC, 0); -- 1.7.9.5 Applied, thanks. -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/16] sandbox: dts: Add a serial console node
On Fri, Aug 01, 2014 at 10:46:31AM -0500, Jon Loeliger wrote:
+ uart0: serial {
+ compatible = sandbox,serial;
+ u-boot,dm-pre-reloc;
Shouldn't that be handled by the driver. It's certainly something that's
only relevant to the internals of U-Boot, and hence inappropriate to put
into DT.
Hence the u-boot prefix. This is described in the driver model docs. I
have found a work-around (which forces a driver to be inited pre-reloc
if none is found) but I'm not 100% happy with it.
I'm arguing that the property shouldn't exist in DT at all. DT is supposed
to be a pure description of the HW, and not encode details that are specific
to the implementation of particular SW. The fact that U-Boot performs
relocation of its code during boot is completely irrelevant to a HW
description.
As such, the issue isn't whether there is a u-boot, prefix on that property,
but whether it's there at all.
Right. And I've arguing that U-Boot should use exactly the same
descriptions that are in the Kernel even. Those DTS descriptions should
be common, applicable to both or neither, exactly because they do
describe the HW and are agnostic WRT the SW that is using them.
I also agree with this. We'll have to sort out the fall-out.
--
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 2/3] MMC: atmel_mci: add configuration register definition
Hi Bo,
On Jul 31, 2014, at 9:39 AM, Bo Shen wrote:
Add configuration register definition, this register only
exists on MCI IP version = 0x300.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
include/atmel_mci.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/atmel_mci.h b/include/atmel_mci.h
index 3d2870f..de24148 100644
--- a/include/atmel_mci.h
+++ b/include/atmel_mci.h
@@ -36,7 +36,9 @@ typedef struct atmel_mci {
u32 ier;/* 0x44 */
u32 idr;/* 0x48 */
u32 imr;/* 0x4c */
- u32 reserved[43];
+ u32 dma;/* 0x50 */
+ u32 cfg;/* 0x54 */
+ u32 reserved[41];
u32 version;
} atmel_mci_t;
@@ -189,6 +191,16 @@ typedef struct atmel_mci {
#define MMCI_TRTYP_MULTI_BLOCK1
#define MMCI_TRTYP_STREAM 2
+/* Bitfields in CFG */
+#define MMCI_FIFOMODE_OFFSET 0
+#define MMCI_FIFOMODE_SIZE 1
+#define MMCI_FERRCTRL_OFFSET 4
+#define MMCI_FERRCTRL_SIZE 1
+#define MMCI_HSMODE_OFFSET 8
+#define MMCI_HSMODE_SIZE 1
+#define MMCI_LSYNC_OFFSET12
+#define MMCI_LSYNC_SIZE 1
+
/* Bit manipulation macros */
#define MMCI_BIT(name)\
(1 MMCI_##name##_OFFSET)
--
1.8.5.2
Applied, thanks.
-- Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] MMC: atmel_mci: refactor setting the mode register
Hi Bo,
On Jul 31, 2014, at 9:39 AM, Bo Shen wrote:
The mode register is different between MCI IP version.
So, according to MCI IP version to set the mode register.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/mmc/gen_atmel_mci.c | 56 +
include/atmel_mci.h | 4
2 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index a57a9b1..8778a4d 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -58,30 +58,58 @@ static void mci_set_mode(struct mmc *mmc, u32 hz, u32
blklen)
atmel_mci_t *mci = mmc-priv;
u32 bus_hz = get_mci_clk_rate();
u32 clkdiv = 255;
+ unsigned int version = atmel_mci_get_version(mci);
+ u32 clkodd = 0;
+ u32 mr;
debug(mci: bus_hz is %u, setting clock %u Hz, block size %u\n,
bus_hz, hz, blklen);
if (hz 0) {
- /* find lowest clkdiv yielding a rate = than requested */
- for (clkdiv=0; clkdiv255; clkdiv++) {
- if ((bus_hz / (clkdiv+1) / 2) = hz)
- break;
+ if (version = 0x500) {
+ clkdiv = DIV_ROUND_UP(bus_hz, hz) - 2;
+ if (clkdiv 511)
+ clkdiv = 511;
+
+ clkodd = clkdiv 1;
+ clkdiv = 1;
+
+ printf(mci: setting clock %u Hz, block size %u\n,
+bus_hz / (clkdiv * 2 + clkodd + 2), blklen);
+ } else {
+ /* find clkdiv yielding a rate = than requested */
+ for (clkdiv = 0; clkdiv 255; clkdiv++) {
+ if ((bus_hz / (clkdiv + 1) / 2) = hz)
+ break;
+ }
+ printf(mci: setting clock %u Hz, block size %u\n,
+(bus_hz / (clkdiv + 1)) / 2, blklen);
+
}
}
- printf(mci: setting clock %u Hz, block size %u\n,
- (bus_hz / (clkdiv+1)) / 2, blklen);
blklen = 0xfffc;
- /* On some platforms RDPROOF and WRPROOF are ignored */
- writel((MMCI_BF(CLKDIV, clkdiv)
- | MMCI_BF(BLKLEN, blklen)
- | MMCI_BIT(RDPROOF)
- | MMCI_BIT(WRPROOF)), mci-mr);
+
+ mr = MMCI_BF(CLKDIV, clkdiv);
+
+ /* MCI IP version = 0x200 has R/WPROOF */
+ if (version = 0x200)
+ mr |= MMCI_BIT(RDPROOF) | MMCI_BIT(WRPROOF);
+
/*
- * On some new platforms BLKLEN in mci-mr is ignored.
- * Should use the BLKLEN in the block register.
+ * MCI IP version = 0x500 use bit 16 as clkodd.
+ * MCI IP version 0x500 use upper 16 bits for blklen.
*/
- writel(MMCI_BF(BLKLEN, blklen), mci-blkr);
+ if (version = 0x500)
+ mr |= MMCI_BF(CLKODD, clkodd);
+ else
+ mr |= MMCI_BF(BLKLEN, blklen);
+
+ writel(mr, mci-mr);
+
+ /* MCI IP version = 0x200 has blkr */
+ if (version = 0x200)
+ writel(MMCI_BF(BLKLEN, blklen), mci-blkr);
+
initialized = 1;
}
diff --git a/include/atmel_mci.h b/include/atmel_mci.h
index 090574d..3d2870f 100644
--- a/include/atmel_mci.h
+++ b/include/atmel_mci.h
@@ -67,6 +67,10 @@ typedef struct atmel_mci {
#define MMCI_PDCPADV_SIZE 1
#define MMCI_PDCMODE_OFFSET 15
#define MMCI_PDCMODE_SIZE 1
+/* MCI IP version = 0x500, MR bit 16 used for CLKODD */
+#define MMCI_CLKODD_OFFSET 16
+#define MMCI_CLKODD_SIZE 1
+/* MCI IP version 0x200, MR higher 16bits for BLKLEN */
#define MMCI_BLKLEN_OFFSET16
#define MMCI_BLKLEN_SIZE 16
--
1.8.5.2
Looks good.
Applied, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] MMC: atmel_mci: enable high speed mode support
Hi Bo,
On Jul 31, 2014, at 9:39 AM, Bo Shen wrote:
If the MCI IP version = 0x300, it supports hight speed mode
option, this patch enable it.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/mmc/gen_atmel_mci.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index 8778a4d..45bcffb 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -110,6 +110,9 @@ static void mci_set_mode(struct mmc *mmc, u32 hz, u32
blklen)
if (version = 0x200)
writel(MMCI_BF(BLKLEN, blklen), mci-blkr);
+ if (mmc-card_caps mmc-cfg-host_caps MMC_MODE_HS)
+ writel(MMCI_BIT(HSMODE), mci-cfg);
+
initialized = 1;
}
@@ -404,8 +407,10 @@ int atmel_mci_init(void *regs)
/* need to be able to pass these in on a board by board basis */
cfg-voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
version = atmel_mci_get_version(mci);
- if ((version 0xf00) = 0x300)
+ if ((version 0xf00) = 0x300) {
cfg-host_caps = MMC_MODE_8BIT;
+ cfg-host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+ }
cfg-host_caps |= MMC_MODE_4BIT;
--
1.8.5.2
Applied, thanks.
-- Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] env_mmc: support env partition setup in runtime
Hi Dmitry,
On Jul 30, 2014, at 1:19 PM, Dmitry Lifshitz wrote:
Add callback with __weak annotation to allow setup of environment
partition number in runtime from a board file.
Propagate mmc_switch_part() return value into init_mmc_for_env() instead
of -1 in case of failure.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in v2:
* Added mmc_get_env_part() proto in environment.h.
common/env_mmc.c | 35 +++
include/environment.h |3 +++
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 7da10e6..a7621a8 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -62,16 +62,36 @@ int env_init(void)
return 0;
}
-static int init_mmc_for_env(struct mmc *mmc)
-{
#ifdef CONFIG_SYS_MMC_ENV_PART
+__weak uint mmc_get_env_part(struct mmc *mmc)
+{
+ return CONFIG_SYS_MMC_ENV_PART;
+}
+
+static int mmc_set_env_part(struct mmc *mmc)
+{
+ uint part = mmc_get_env_part(mmc);
int dev = CONFIG_SYS_MMC_ENV_DEV;
+ int ret = 0;
#ifdef CONFIG_SPL_BUILD
dev = 0;
#endif
+
+ if (part != mmc-part_num) {
+ ret = mmc_switch_part(dev, part);
+ if (ret)
+ puts(MMC partition switch failed\n);
+ }
+
+ return ret;
+}
+#else
+static inline int mmc_set_env_part(struct mmc *mmc) {return 0; };
#endif
+static int init_mmc_for_env(struct mmc *mmc)
+{
if (!mmc) {
puts(No MMC card found\n);
return -1;
@@ -82,16 +102,7 @@ static int init_mmc_for_env(struct mmc *mmc)
return -1;
}
-#ifdef CONFIG_SYS_MMC_ENV_PART
- if (CONFIG_SYS_MMC_ENV_PART != mmc-part_num) {
- if (mmc_switch_part(dev, CONFIG_SYS_MMC_ENV_PART)) {
- puts(MMC partition switch failed\n);
- return -1;
- }
- }
-#endif
-
- return 0;
+ return mmc_set_env_part(mmc);
}
static void fini_mmc_for_env(struct mmc *mmc)
diff --git a/include/environment.h b/include/environment.h
index d7a1adf..1fdbdad 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -184,6 +184,9 @@ extern void env_reloc(void);
#include mmc.h
extern int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr);
+# ifdef CONFIG_SYS_MMC_ENV_PART
+extern uint mmc_get_env_part(struct mmc *mmc);
+# endif
#endif
#ifndef DO_DEPS_ONLY
--
1.7.5.4
Applied, thanks.
-- Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] env_mmc: add mmc_get_env_addr() prototype
Hi Dmitry, On Jul 30, 2014, at 1:19 PM, Dmitry Lifshitz wrote: Add missing mmc_get_env_addr() prototype in environment.h Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il --- include/environment.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/environment.h b/include/environment.h index 08679ae..d7a1adf 100644 --- a/include/environment.h +++ b/include/environment.h @@ -180,6 +180,12 @@ extern unsigned char env_get_char_spec(int); extern void env_reloc(void); #endif +#ifdef CONFIG_ENV_IS_IN_MMC +#include mmc.h + +extern int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr); +#endif + #ifndef DO_DEPS_ONLY #include env_attr.h -- 1.7.5.4 Applied, thanks. -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-mmc 1/08/2014
Hi Tom, The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to 6e7b7df4df435742fcfde5f384760ae1bda2e39c: env_mmc: support env partition setup in runtime (2014-08-01 20:12:15 +0300) Bo Shen (3): MMC: atmel_mci: refactor setting the mode register MMC: atmel_mci: add configuration register definition MMC: atmel_mci: enable high speed mode support Chin Liang See (1): mmc/dw_mmc: Fix clock divider calculation error for bypass mode Dmitry Lifshitz (2): env_mmc: add mmc_get_env_addr() prototype env_mmc: support env partition setup in runtime DrEagle (1): ARM: kirkwood: add mvsdio driver Lubomir Rintel (1): bcm2835_sdhci: Add SDHCI_QUIRK_NO_HISPD_BIT flag Marek Vasut (2): arm: s3c: Unify the S3C24xx SDI structure mmc: s3c: Add SD driver arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 9 +++ arch/arm/include/asm/arch-kirkwood/kirkwood.h | 1 + arch/arm/include/asm/arch-s3c24x0/s3c2410.h | 4 +- arch/arm/include/asm/arch-s3c24x0/s3c2440.h | 4 +- arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 19 +++-- common/env_mmc.c | 35 ++--- drivers/mmc/Makefile | 2 + drivers/mmc/bcm2835_sdhci.c | 2 +- drivers/mmc/dw_mmc.c | 5 +- drivers/mmc/gen_atmel_mci.c | 63 +++ drivers/mmc/mvebu_mmc.c | 361 ++ drivers/mmc/s3c_sdi.c | 321 include/atmel_mci.h | 18 - include/configs/openrd.h | 8 ++ include/configs/sheevaplug.h | 11 +++ include/environment.h | 9 +++ include/mvebu_mmc.h | 278 ++ 17 files changed, 1109 insertions(+), 41 deletions(-) create mode 100644 drivers/mmc/mvebu_mmc.c create mode 100644 drivers/mmc/s3c_sdi.c create mode 100644 include/mvebu_mmc.h Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_fat.c: Make sure our buffer is cache aligned
We must ensure the buffer we read the env into is aligned or we may get
warnings later on.
Signed-off-by: Tom Rini tr...@ti.com
---
common/env_fat.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/env_fat.c b/common/env_fat.c
index 328c09d..8db0160 100644
--- a/common/env_fat.c
+++ b/common/env_fat.c
@@ -73,7 +73,7 @@ int saveenv(void)
void env_relocate_spec(void)
{
- char buf[CONFIG_ENV_SIZE];
+ ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE);
block_dev_desc_t *dev_desc = NULL;
disk_partition_t info;
int dev, part;
@@ -92,7 +92,7 @@ void env_relocate_spec(void)
goto err_env_relocate;
}
- err = file_fat_read(FAT_ENV_FILE, (uchar *)buf, CONFIG_ENV_SIZE);
+ err = file_fat_read(FAT_ENV_FILE, buf, CONFIG_ENV_SIZE);
if (err == -1) {
printf(\n** Unable to read \%s\ from %s%d:%d **\n,
FAT_ENV_FILE, FAT_ENV_INTERFACE, dev, part);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mmc 1/08/2014
On Friday, August 01, 2014 at 07:21:23 PM, Pantelis Antoniou wrote: Hi Tom, The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to 6e7b7df4df435742fcfde5f384760ae1bda2e39c: env_mmc: support env partition setup in runtime (2014-08-01 20:12:15 +0300) Bo Shen (3): MMC: atmel_mci: refactor setting the mode register MMC: atmel_mci: add configuration register definition MMC: atmel_mci: enable high speed mode support Chin Liang See (1): mmc/dw_mmc: Fix clock divider calculation error for bypass mode Dmitry Lifshitz (2): env_mmc: add mmc_get_env_addr() prototype env_mmc: support env partition setup in runtime DrEagle (1): What is this nickname doing here ? Where is the full name of this person ? ARM: kirkwood: add mvsdio driver [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mmc 1/08/2014
On 01/08/2014 20:22, Marek Vasut wrote: On Friday, August 01, 2014 at 07:21:23 PM, Pantelis Antoniou wrote: Hi Tom, The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to 6e7b7df4df435742fcfde5f384760ae1bda2e39c: env_mmc: support env partition setup in runtime (2014-08-01 20:12:15 +0300) Bo Shen (3): MMC: atmel_mci: refactor setting the mode register MMC: atmel_mci: add configuration register definition MMC: atmel_mci: enable high speed mode support Chin Liang See (1): mmc/dw_mmc: Fix clock divider calculation error for bypass mode Dmitry Lifshitz (2): env_mmc: add mmc_get_env_addr() prototype env_mmc: support env partition setup in runtime DrEagle (1): What is this nickname doing here ? Where is the full name of this person ? I do not know that nickname was forbidden to contribute. My Real name is Gérald Kerma. ARM: kirkwood: add mvsdio driver [...] Best regards, Marek Vasut Enjoy, Gérald 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] Removing the need for boards.cfg
Dear Masahiro, In message 20140801225339.d541.aa925...@jp.panasonic.com you wrote: It that case, can we skip generating boards.cfg ? (We can get the board list by 'ls configs' ) This would neither give all build target names no=r do the needed translation of names (like upper case - lower case translations), etc. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Microsoft Compatibility: your old Windows 3.11 application crash exactly as the new ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: remove custom define for Jetson TK1
On 07/31/2014 09:12 PM, Masahiro Yamada wrote:
Hi Stephen,
On Thu, 31 Jul 2014 17:29:38 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
Now that Kconfig has a per-board option, we can use that directly rather
than inventing a custom define for the AS3722 code to determine which
board it's being built for.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
board/nvidia/venice2/as3722_init.h | 2 +-
configs/jetson-tk1_defconfig | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/board/nvidia/venice2/as3722_init.h
b/board/nvidia/venice2/as3722_init.h
index a7b24039f6aa..06c366e0d0d8 100644
--- a/board/nvidia/venice2/as3722_init.h
+++ b/board/nvidia/venice2/as3722_init.h
@@ -18,7 +18,7 @@
#define AS3722_LDO6VOLTAGE_REG0x16/* VDD_SDMMC */
#define AS3722_LDCONTROL_REG 0x4E
-#ifdef CONFIG_BOARD_JETSON_TK1
+#ifdef CONFIG_TARGET_JETSON_TK1
#define AS3722_SD0VOLTAGE_DATA(0x3C00 | AS3722_SD0VOLTAGE_REG)
#else
#define AS3722_SD0VOLTAGE_DATA(0x2800 | AS3722_SD0VOLTAGE_REG)
diff --git a/configs/jetson-tk1_defconfig b/configs/jetson-tk1_defconfig
index 9ce97c9f61b2..6926257d894b 100644
--- a/configs/jetson-tk1_defconfig
+++ b/configs/jetson-tk1_defconfig
@@ -1,4 +1,3 @@
CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=BOARD_JETSON_TK1=
+S:CONFIG_ARM=y
+S:CONFIG_TARGET_JETSON_TK1=y
--
1.9.1
Or you may rename CONFIG_TARGET_JETSON_TK1 to CONFIG_BOARD_JETSON_TK1
or another name.
I don't want to force CONFIG_TARGET_ name convention.
You can change config names if you like. It is up to you.
I assume you don't object to the current patch, but were just pointing
out that I could rename the variable if I wanted?
All the configs/${board}_defconfig I looked at use
CONFIG_TARGET_${board}, so I think it's best if I just convert the code
to using that so everything is consistent.
...
When I see Tegra family, each board has its own config header.
CONFIG_BOARD_ as well as CONFIG_TARGET_ will work.
AFAIK, only Jetson TK1 used a custom CONFIG_BOARD_xxx variable. I only
did that because it shares some code with Venice2 and needed to define
some variable do distinguish the two boards, and there wasn't already a
standard variable for this in the build process. I'm quite happy to
convert to the standard (or even de-facto) standard variable we have now.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] sunxi-common.h: Use new generic $bootcmd
On 08/01/2014 01:46 AM, Hans de Goede wrote: Use the new standard bootcmd from config_distro_bootcmd.h. Acked-by: Stephen Warren swar...@nvidia.com diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h +#ifdef CONFIG_AHCI +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(SCSI, scsi, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#else +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#endif In the spirit of using crazy macros (!) :-) I might code that as: #ifdef CONFIG_AHCI #define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) #else #define BOOT_TARGET_DEVICES_SCSI(func) #endif #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ BOOT_TARGET_DEVICES_SCSI(func) \ func(USB, usb, 0) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) ... since it doesn't duplicate the rest of the main macro, but either way is fine by me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pxe: automatically add console= to bootargs when not specified in append
On 08/01/2014 01:46 AM, Hans de Goede wrote:
From: Dennis Gilmore den...@ausil.us
if there is a console variable in the u-boot environment and not one on
the append line from syslinux config add what is in the environment to
the bootargs.
This is necessary to allow distros to have a single extlinux/extlinux.conf
file which will work on multiple boards, even if these boards have different
consoles (e.g. ttyS0 vs ttyAMA0).
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
I know you rejected this afterwards, but since I read the patch before
the reply, a couple of comments for anyone who finds this code in the
archived and wants to copy it:
+ char console[30] = ;
- if (label-append)
+ if (label-append) {
len += strlen(label-append);
+ /* If no console in append and $console is set, use it */
+ if (!strstr(label-append, console=) getenv(console)) {
This would get a false positive match for the text fooconsole= in the
existing command-line. It might be better to strtok() (or similar) the
existing value, so it can guarantee to match only options that start
with console= not that contain console=.
+ sprintf(console, console=%s, getenv(console));
This should check for buffer overflows, e.g. use snprintf().
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pxe: Allow use of environment variables in append string
On 08/01/2014 03:21 AM, Hans de Goede wrote:
Use run_command(setenv bootargs label-append) so that environment
variables (e.g. $console) can be used in append strings.
I'm slightly worried that this changes the semantics of the append line
in the PXE/extlinux config file. Namely, you suddenly have to start
worrying about escaping any $ signs or semi-colons etc..
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
if (!localcmd)
return -ENOENT;
- if (label-append)
- setenv(bootargs, label-append);
+ if (label-append) {
+ bootargs = malloc(strlen(setenv bootargs ) +
+ strlen(label-append) + 1);
+ if (!bootargs)
+ return 1;
Shouldn't this return a -ve error code for consistency with the other
pre-existing error case I quoted above.
+ strcpy(bootargs, setenv bootargs );
+ strcat(bootargs, label-append);
+ run_command(bootargs, 0);
Using whatever C function that the shell uses to expand variable
references in the command-line, rather than run_command(), would at
least avoid the issue of ; in label-append causing part of
label-append after the ; to be execututed as a separate command.
There would still be the issue of $ suddenly meaning something different.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] bootm: use genimg_get_kernel_addr()
On 07/31/2014 06:40 PM, Bryan Wu wrote: Use the new API which is originally taken out from boot_get_kernel of bootm.c diff --git a/common/bootm.c b/common/bootm.c case IMAGE_FORMAT_FIT: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); I'd be tempted to try and rework patch 1/3 so that it could return the fit_uname_* values too. That way, you wouldn't need to call fit_parse_*() a second time here. This probably isn't a big issue though. The series, Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: restore *_config target
The switch to KConfig break the [board]_config target. This breaks backwards compatibility and hence all documentation about how to build u-boot is no longer valid. It is also annoying for general recipes to build u-boot as contained in buildroot, crochet, oe, poky, eldk etc. Hence restore the *_config target. cc: Tom Rini tr...@ti.com cc: Masahiro Yamada yamad...@jp.panasonic.com cc: Simon Glass s...@chromium.org Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 5e49545..2a339aa 100644 --- a/Makefile +++ b/Makefile @@ -413,7 +413,7 @@ endif version_h := include/generated/version_autogenerated.h timestamp_h := include/generated/timestamp_autogenerated.h -no-dot-config-targets := clean clobber mrproper distclean \ +no-dot-config-targets := clean clobber %_config mrproper distclean \ help %docs check% coccicheck \ ubootversion backup tools-only @@ -436,6 +436,11 @@ ifeq ($(KBUILD_EXTMOD),) endif endif +# Before the switch to KConfig the configure target was %_config instead +# of %_defconfig. Just reinvoke make to be backwards compatible. +%_config: FORCE + $(Q)$(MAKE) $(@:_config=_defconfig) + ifeq ($(mixed-targets),1) # === # We're called with mixed targets (*config and build targets). -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. I really think you should set bootm_size to something reasonable. beaglebones for instance has to be 0x1000 as the beaglebone white only has 256M of ram. and let u-boot move things around, ensuring we do not get into a place where the decompressed kernel overwrites memory. This behaviour is what I had in the docs I had written earlier in the year. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On 08/01/2014 02:05 PM, Dennis Gilmore wrote: On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. What kind of issues? At least for Tegra, I've carefully chosen the values for the various load addresses so that there won't be issues. (Without that I can easily see the potential for issues.) I've seen far more repeated problems when U-Boot moves the DT/initrd around than than when it didn't (none in that case). Besides, it's completely redundant and unnecessary work if the blobs are already loaded at sane addresses, which they are on Tegra at least. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On Fri, 01 Aug 2014 14:22:40 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 02:05 PM, Dennis Gilmore wrote: On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. What kind of issues? At least for Tegra, I've carefully chosen the values for the various load addresses so that there won't be issues. (Without that I can easily see the potential for issues.) I've seen far more repeated problems when U-Boot moves the DT/initrd around than than when it didn't (none in that case). Besides, it's completely redundant and unnecessary work if the blobs are already loaded at sane addresses, which they are on Tegra at least. Mostly to do with the decompressed kernel overwriting the initrd or dtb resulting in machines that would hang on boot. it came up quite a few times earlier this year on both imx and omap. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On Fri, Aug 01, 2014 at 02:22:40PM -0600, Stephen Warren wrote: On 08/01/2014 02:05 PM, Dennis Gilmore wrote: On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. What kind of issues? At least for Tegra, I've carefully chosen the values for the various load addresses so that there won't be issues. (Without that I can easily see the potential for issues.) I've seen far more repeated problems when U-Boot moves the DT/initrd around than than when it didn't (none in that case). Besides, it's completely redundant and unnecessary work if the blobs are already loaded at sane addresses, which they are on Tegra at least. Just how large of a kernel have you thrown on a Tegra? 32MB might seem reasonable at first but it wouldn't be overly surprised if someone can shove a BSS into there. I know I shoved DT into 128MB by default because a 32bit ARM kernel isn't functional at that size. -- 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] Pull request: u-boot-mmc 1/08/2014
On Friday, August 01, 2014 at 08:27:26 PM, drEagle wrote: On 01/08/2014 20:22, Marek Vasut wrote: On Friday, August 01, 2014 at 07:21:23 PM, Pantelis Antoniou wrote: Hi Tom, The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to 6e7b7df4df435742fcfde5f384760ae1bda2e39c: env_mmc: support env partition setup in runtime (2014-08-01 20:12:15 +0300) Bo Shen (3): MMC: atmel_mci: refactor setting the mode register MMC: atmel_mci: add configuration register definition MMC: atmel_mci: enable high speed mode support Chin Liang See (1): mmc/dw_mmc: Fix clock divider calculation error for bypass mode Dmitry Lifshitz (2): env_mmc: add mmc_get_env_addr() prototype env_mmc: support env partition setup in runtime DrEagle (1): What is this nickname doing here ? Where is the full name of this person ? I do not know that nickname was forbidden to contribute. My Real name is Gérald Kerma. http://lwn.net/Articles/195643/ this is where it all started. I'd suggest you to read up on it. It's good the patch at least has a proper SoB line, so it's not _that_ big of a deal. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git master
Tom, The following changes since commit fb5368789a45ca5ee4396cbbf563a8f16ab24f9c: board/freescale: use generic board architecture for t2080qds and t2080rdb (2014-07-23 12:40:30 -0700) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to e3917b21c05776b41663bdfcc7666aca11a381a0: kmp204x: prepare to use CPU watchdog (2014-08-01 14:18:59 -0700) Boschung, Rainer (9): mpc85xx: fix interrupt init to not affect watchdog powerpc: macros for e500mc timer regs added mpc85xx: watchdog initialisation added powerpc: mpc85xx watchdog init added to init_func kmp204x: CPU watchdog enabled kmp204x/qrio: prepare support for the CPU watchdog reset reason kmp204x: set CPU watchdog reset reason flag kmp204x/qrio: support for setting the CPU reset request mode kmp204x: prepare to use CPU watchdog arch/powerpc/cpu/mpc85xx/cpu.c|8 arch/powerpc/cpu/mpc85xx/interrupts.c |2 +- arch/powerpc/include/asm/processor.h |5 + arch/powerpc/lib/board.c |3 +++ board/keymile/kmp204x/kmp204x.c | 15 +++ board/keymile/kmp204x/kmp204x.h |7 +++ board/keymile/kmp204x/qrio.c | 32 include/configs/km/kmp204x-common.h |8 include/watchdog.h|4 9 files changed, 83 insertions(+), 1 deletion(-) Thanks, York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/16] tegra: dts: Add serial port details
Hi Stephen,
On 1 August 2014 00:06, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/31/2014 04:10 PM, Simon Glass wrote:
Hi Stephen,
On 31 July 2014 21:16, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/30/2014 03:49 AM, Simon Glass wrote:
Some Tegra device tree files do not include information about the serial
ports. Add this and also add information about the input clock speed.
The console alias needs to be set up to indicate which port is used for
the console.
Also add a binding file since this is missing.
diff --git a/arch/arm/dts/tegra114-dalmore.dts
b/arch/arm/dts/tegra114-dalmore.dts
index 435c01e..e2426ef 100644
--- a/arch/arm/dts/tegra114-dalmore.dts
+++ b/arch/arm/dts/tegra114-dalmore.dts
@@ -7,6 +7,7 @@
compatible = nvidia,dalmore, nvidia,tegra114;
aliases {
+ console = uart_d;
I don't think that's a standard alias name. There was some recent
discussion
in the devicetree mailing list re: using some property in /chosen for
this
purpose instead. U-Boot and the kernel should use the same representation
here.
This is U-Boot's approach at present,
That's not the U-Boot approach on Tegra boards before this patch. I do not
want Tegra U-Boot do adopt any more U-Boot-specific
not-really-DT-but-pretending-to-be bindings.
if we change it then we should
change it everywhere. I worry that 'chosen' is for Linux rather than
U-Boot and we might get very confused about what chosen is for?
That discussion should be had on the devicetree mailing list.
Please go ahead if you wish, but this is not a Linux issue. The
aliases are used for U-Boot and have been for some time.
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+ uart_a: serial@70006000 {
+ compatible = nvidia,tegra20-uart;
This property needs to include both the specific HW (i.e. Tegra114) and
any
HW it's compatible with (i.e. Tegra20).
So something like this?
compatible = nvidia,tegra114-uart, nvidia,tegra20-uart;
Yes.
+ reg = 0x70006000 0x40;
+ reg-shift = 2;
+ clock-frequency = 40800;
This isn't a property that's defined by the Tegra serial binding. This
information should be obtained by looking up the relevant clock, and
querying its rate.
We can't do that in the ns16550 driver as yet since there is no
generic U-Boot clock infrastructure. I suspect that will come with
time.
The solution here is to put the clock infra-structure in place first. One
thing I've learned from the kernel DT experience is that a lot of time would
have been saved by putting the correct infra-structure in place first, then
using it, rather than hacking around things the wrong way, then putting the
infra-structure in place, then converting to it. That's a lot more work, and
rather painful. Equally, if we don't just do the infra-structure right,
there's really little guarantee that we'll ever convert to the correct
approach. Just look at all the DT content in use in U-Boot that don't match
the real DT bindings, even after it's been around years.
OK, is there a plan to put this in place? Who is working on it?
For reference, here's the DT node for this UART in the kernel DT, which
complies with the relevant binding document:
uarta: serial@70006000 {
compatible = nvidia,tegra114-uart,
nvidia,tegra20-uart;
reg = 0x70006000 0x40;
reg-shift = 2;
interrupts = GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH;
clocks = tegra_car TEGRA114_CLK_UARTA;
resets = tegra_car 6;
reset-names = serial;
dmas = apbdma 8, apbdma 8;
dma-names = rx, tx;
status = disabled;
};
All the comment above apply to all the files in this patch.
My intent was to make this work with a more generic binding for now -
ns16550 is a pretty standard thing and I thought I could avoid making
the driver Tegra-specific. Then we could allow many SoCs to use it.
Why does Tegra have its own binding in the kernel for this standard
UART?
The HW is not a PC-style UART where all you care about is the 16550
registers, and clocks/resets/DMA/... can be ignored or deferred to firmware
to set up before DT-driven SW runs.
I'm not sure what you are referring to here. Are you saying that
U-Boot needs to support these things? I agree it would be great to add
a generic clock/reset framework and have made considerable efforts in
Tegra towards this myself. But we don't have it yet.
As an aside, /almost/ all reviewed DT bindings use DT properties of the
form:
clocks = provider parameters;
rather than:
clock-rate = number;
So, that aspect of the Tegra UART binding isn't anything remotely
unusual/non-standard.
The great is the enemy of the good. In this case, I think I might just
leave the clock as a
Re: [U-Boot] [PATCH v3 07/16] sandbox: dts: Add a serial console node
Hi,
On 1 August 2014 17:53, Tom Rini tr...@ti.com wrote:
On Fri, Aug 01, 2014 at 10:46:31AM -0500, Jon Loeliger wrote:
+ uart0: serial {
+ compatible = sandbox,serial;
+ u-boot,dm-pre-reloc;
Shouldn't that be handled by the driver. It's certainly something that's
only relevant to the internals of U-Boot, and hence inappropriate to put
into DT.
Hence the u-boot prefix. This is described in the driver model docs. I
have found a work-around (which forces a driver to be inited pre-reloc
if none is found) but I'm not 100% happy with it.
I'm arguing that the property shouldn't exist in DT at all. DT is supposed
to be a pure description of the HW, and not encode details that are
specific
to the implementation of particular SW. The fact that U-Boot performs
relocation of its code during boot is completely irrelevant to a HW
description.
As such, the issue isn't whether there is a u-boot, prefix on that
property,
but whether it's there at all.
Right. And I've arguing that U-Boot should use exactly the same
descriptions that are in the Kernel even. Those DTS descriptions should
be common, applicable to both or neither, exactly because they do
describe the HW and are agnostic WRT the SW that is using them.
I also agree with this. We'll have to sort out the fall-out.
As mentioned I think I have found a way (with serial at least) to work
around this - when the serial probe files, this series has code which
forces binding of the node referenced by the 'console' alias. It's a
bit of a hack but it might be good enough...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/16] sandbox: dts: Add a serial console node
Hi Stephen,
On 1 August 2014 00:09, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/31/2014 04:13 PM, Simon Glass wrote:
Hi Stephen,
On 31 July 2014 21:20, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/30/2014 03:49 AM, Simon Glass wrote:
If the sandbox device tree is provided to U-Boot (with the -d flag) then
it
will use the device tree version in preference to the built-in device.
The
only difference is the colour.
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
+ uart0: serial {
+ compatible = sandbox,serial;
+ u-boot,dm-pre-reloc;
Shouldn't that be handled by the driver. It's certainly something that's
only relevant to the internals of U-Boot, and hence inappropriate to put
into DT.
Hence the u-boot prefix. This is described in the driver model docs. I
have found a work-around (which forces a driver to be inited pre-reloc
if none is found) but I'm not 100% happy with it.
I'm arguing that the property shouldn't exist in DT at all. DT is supposed
to be a pure description of the HW, and not encode details that are specific
to the implementation of particular SW. The fact that U-Boot performs
relocation of its code during boot is completely irrelevant to a HW
description.
As such, the issue isn't whether there is a u-boot, prefix on that property,
but whether it's there at all.
I completely agree in theory, although in practice this can become a
huge pain. I'm open to suggestions. On the other hand as you well know
I'm more inclined to use a convenient solution and iterate/improve
later than sit on my hands and fret :-) Please check the dm README for
the issue involved.
+ text-colour = cyan;
That's property should likely have a uboot, prefix, since it's
non-standard.
Can I not just declare a binding for 'sandbox,serial'?
Properties that are relevant only to a particular binding, rather than being
something quite generic an applicable to a whole class of devices, typically
have a vendor prefix.
A binding should/must exist for every node or compatible value. So, whether
you actually write the binding document or not makes no difference to the
names or vendor prefixes of the properties the binding uses.
So here you are saying it should be:
sandbox,text-colour = cyan;
Is that right?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On 08/01/2014 02:43 PM, Tom Rini wrote: On Fri, Aug 01, 2014 at 02:22:40PM -0600, Stephen Warren wrote: On 08/01/2014 02:05 PM, Dennis Gilmore wrote: On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. What kind of issues? At least for Tegra, I've carefully chosen the values for the various load addresses so that there won't be issues. (Without that I can easily see the potential for issues.) I've seen far more repeated problems when U-Boot moves the DT/initrd around than than when it didn't (none in that case). Besides, it's completely redundant and unnecessary work if the blobs are already loaded at sane addresses, which they are on Tegra at least. Just how large of a kernel have you thrown on a Tegra? 32MB might seem reasonable at first but it wouldn't be overly surprised if someone can shove a BSS into there. I know I shoved DT into 128MB by default because a 32bit ARM kernel isn't functional at that size. There's enough space for the following: 16M decompressed kernel 16M compressed kernel 1M DTB The kernel I typically boot is ~4.MB zImage, and ~9MB Image (which doesn't include BSS). Note that if the decompressed/compressed kernel overlap, the kernel decompresser takes care of relocating the compressed kernel before doing the decompression, and IIRC is supposed to take care not to clobber the DTB (or initrd?) when doing so. Fedora's rawhide zImage is a bit larger at ~6MB. That works fine too. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/16] tegra: dts: Add serial port details
On 08/01/2014 03:32 PM, Simon Glass wrote:
Hi Stephen,
On 1 August 2014 00:06, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/31/2014 04:10 PM, Simon Glass wrote:
Hi Stephen,
On 31 July 2014 21:16, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/30/2014 03:49 AM, Simon Glass wrote:
Some Tegra device tree files do not include information about the serial
ports. Add this and also add information about the input clock speed.
The console alias needs to be set up to indicate which port is used for
the console.
Also add a binding file since this is missing.
diff --git a/arch/arm/dts/tegra114-dalmore.dts
b/arch/arm/dts/tegra114-dalmore.dts
index 435c01e..e2426ef 100644
--- a/arch/arm/dts/tegra114-dalmore.dts
+++ b/arch/arm/dts/tegra114-dalmore.dts
@@ -7,6 +7,7 @@
compatible = nvidia,dalmore, nvidia,tegra114;
aliases {
+ console = uart_d;
I don't think that's a standard alias name. There was some recent
discussion
in the devicetree mailing list re: using some property in /chosen for
this
purpose instead. U-Boot and the kernel should use the same representation
here.
This is U-Boot's approach at present,
That's not the U-Boot approach on Tegra boards before this patch. I do not
want Tegra U-Boot do adopt any more U-Boot-specific
not-really-DT-but-pretending-to-be bindings.
if we change it then we should
change it everywhere. I worry that 'chosen' is for Linux rather than
U-Boot and we might get very confused about what chosen is for?
That discussion should be had on the devicetree mailing list.
Please go ahead if you wish, but this is not a Linux issue. The
aliases are used for U-Boot and have been for some time.
No, it's not a Linux issue, it's DT issue.
DT schemas/bindings MUST be identical between U-Boot, Linux, FreeBSD,
Barebox, ... (all of which use DT). As such, all the DT bindings MUST be
discussed on the devicetree mailing list.
Since you're the author of the patch, it's your responsibility to have
that discussion.
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+ uart_a: serial@70006000 {
+ compatible = nvidia,tegra20-uart;
+ reg = 0x70006000 0x40;
+ reg-shift = 2;
+ clock-frequency = 40800;
This isn't a property that's defined by the Tegra serial binding. This
information should be obtained by looking up the relevant clock, and
querying its rate.
We can't do that in the ns16550 driver as yet since there is no
generic U-Boot clock infrastructure. I suspect that will come with
time.
The solution here is to put the clock infra-structure in place first. One
thing I've learned from the kernel DT experience is that a lot of time would
have been saved by putting the correct infra-structure in place first, then
using it, rather than hacking around things the wrong way, then putting the
infra-structure in place, then converting to it. That's a lot more work, and
rather painful. Equally, if we don't just do the infra-structure right,
there's really little guarantee that we'll ever convert to the correct
approach. Just look at all the DT content in use in U-Boot that don't match
the real DT bindings, even after it's been around years.
OK, is there a plan to put this in place? Who is working on it?
I don't know whether anyone is or not. However, the fact that nobody is
working on a clock driver is no excuse for using the incorrect DT
bindings in order to hack around its lack of existence.
For reference, here's the DT node for this UART in the kernel DT, which
complies with the relevant binding document:
uarta: serial@70006000 {
compatible = nvidia,tegra114-uart,
nvidia,tegra20-uart;
reg = 0x70006000 0x40;
reg-shift = 2;
interrupts = GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH;
clocks = tegra_car TEGRA114_CLK_UARTA;
resets = tegra_car 6;
reset-names = serial;
dmas = apbdma 8, apbdma 8;
dma-names = rx, tx;
status = disabled;
};
All the comment above apply to all the files in this patch.
My intent was to make this work with a more generic binding for now -
ns16550 is a pretty standard thing and I thought I could avoid making
the driver Tegra-specific. Then we could allow many SoCs to use it.
Why does Tegra have its own binding in the kernel for this standard
UART?
The HW is not a PC-style UART where all you care about is the 16550
registers, and clocks/resets/DMA/... can be ignored or deferred to firmware
to set up before DT-driven SW runs.
I'm not sure what you are referring to here. Are you saying that
U-Boot needs to support these things? I agree it would be great to add
a generic clock/reset framework and have made considerable efforts in
Tegra towards this myself. But we don't have it yet.
Yes.
Part of the decision to use DT is to
Re: [U-Boot] [PATCH v3 07/16] sandbox: dts: Add a serial console node
On 08/01/2014 03:40 PM, Simon Glass wrote:
Hi Stephen,
On 1 August 2014 00:09, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/31/2014 04:13 PM, Simon Glass wrote:
Hi Stephen,
On 31 July 2014 21:20, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/30/2014 03:49 AM, Simon Glass wrote:
If the sandbox device tree is provided to U-Boot (with the -d flag) then it
will use the device tree version in preference to the built-in device. The
only difference is the colour.
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
+ uart0: serial {
+ compatible = sandbox,serial;
+ u-boot,dm-pre-reloc;
...
+ text-colour = cyan;
That's property should likely have a uboot, prefix, since it's
non-standard.
Can I not just declare a binding for 'sandbox,serial'?
Properties that are relevant only to a particular binding, rather than being
something quite generic an applicable to a whole class of devices, typically
have a vendor prefix.
A binding should/must exist for every node or compatible value. So, whether
you actually write the binding document or not makes no difference to the
names or vendor prefixes of the properties the binding uses.
So here you are saying it should be:
sandbox,text-colour = cyan;
Is that right?
I think that sounds right yes.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] driver/ddr: Restruct driver to allow standalone memory space
U-boot has been initializing DDR for the main memory. The presumption
is the memory stays as a big continuous block, either linear or
interleaved. This change is to support putting some DDR controllers
to separated space without counting into main memory. The standalone
memory controller could use different number of DIMM slots.
Signed-off-by: York Sun york...@freescale.com
---
README |6 +
arch/powerpc/cpu/mpc85xx/cpu.c |4 +-
drivers/ddr/fsl/ddr4_dimm_params.c | 12 +-
drivers/ddr/fsl/main.c | 244
drivers/ddr/fsl/options.c | 23 ++--
drivers/ddr/fsl/util.c | 26 +++-
include/fsl_ddr.h | 15 ++-
include/fsl_ddr_sdram.h| 16 ++-
8 files changed, 238 insertions(+), 108 deletions(-)
diff --git a/README b/README
index 4ac7399..dcfff51 100644
--- a/README
+++ b/README
@@ -538,6 +538,12 @@ The following options need to be configured:
interleaving mode, handled by Dickens for Freescale layerscape
SoCs with ARM core.
+ CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS
+ Number of controllers used as main memory.
+
+ CONFIG_SYS_FSL_OTHER_DDR_NUM_CTRLS
+ Number of controllers used for other than main memory.
+
- Intel Monahans options:
CONFIG_SYS_MONAHANS_RUN_MODE_OSC_RATIO
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 6274f92..3d6ec84 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -441,7 +441,7 @@ phys_size_t initdram(int board_type)
/* Board-specific functions defined in each board's ddr.c */
void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
- unsigned int ctrl_num);
+ unsigned int ctrl_num, unsigned int dimm_slots_per_ctrl);
void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize, unsigned long *epn,
phys_addr_t *rpn);
unsigned int
@@ -459,7 +459,7 @@ static void dump_spd_ddr_reg(void)
spd[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR];
for (i = 0; i CONFIG_NUM_DDR_CONTROLLERS; i++)
- fsl_ddr_get_spd(spd[i], i);
+ fsl_ddr_get_spd(spd[i], i, CONFIG_DIMM_SLOTS_PER_CTLR);
puts(SPD data of all dimms (zero vaule is omitted)...\n);
puts(Byte (hex) );
diff --git a/drivers/ddr/fsl/ddr4_dimm_params.c
b/drivers/ddr/fsl/ddr4_dimm_params.c
index 4745b7f..2418dca 100644
--- a/drivers/ddr/fsl/ddr4_dimm_params.c
+++ b/drivers/ddr/fsl/ddr4_dimm_params.c
@@ -113,7 +113,7 @@ compute_ranksize(const struct ddr4_spd_eeprom_s *spd)
#define spd_to_ps(mtb, ftb)\
(mtb * pdimm-mtb_ps + (ftb * pdimm-ftb_10th_ps) / 10)
/*
- * ddr_compute_dimm_parameters for DDR3 SPD
+ * ddr_compute_dimm_parameters for DDR4 SPD
*
* Compute DIMM parameters based upon the SPD information in spd.
* Writes the results to the dimm_params_t structure pointed by pdimm.
@@ -165,17 +165,17 @@ ddr_compute_dimm_parameters(const generic_spd_eeprom_t
*spd,
+ pdimm-ec_sdram_width;
pdimm-device_width = 1 ((spd-organization 0x7) + 2);
- /* These are the types defined by the JEDEC DDR3 SPD spec */
+ /* These are the types defined by the JEDEC SPD spec */
pdimm-mirrored_dimm = 0;
pdimm-registered_dimm = 0;
- switch (spd-module_type DDR3_SPD_MODULETYPE_MASK) {
- case DDR3_SPD_MODULETYPE_RDIMM:
+ switch (spd-module_type DDR4_SPD_MODULETYPE_MASK) {
+ case DDR4_SPD_MODULETYPE_RDIMM:
/* Registered/buffered DIMMs */
pdimm-registered_dimm = 1;
break;
- case DDR3_SPD_MODULETYPE_UDIMM:
- case DDR3_SPD_MODULETYPE_SO_DIMM:
+ case DDR4_SPD_MODULETYPE_UDIMM:
+ case DDR4_SPD_MODULETYPE_SO_DIMM:
/* Unbuffered DIMMs */
if (spd-mod_section.unbuffered.addr_mapping 0x1)
pdimm-mirrored_dimm = 1;
diff --git a/drivers/ddr/fsl/main.c b/drivers/ddr/fsl/main.c
index 5e001fc..b43b669 100644
--- a/drivers/ddr/fsl/main.c
+++ b/drivers/ddr/fsl/main.c
@@ -135,7 +135,7 @@ __attribute__((weak, alias(__get_spd)))
void get_spd(generic_spd_eeprom_t *spd, u8 i2c_address);
void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
- unsigned int ctrl_num)
+ unsigned int ctrl_num, unsigned int dimm_slots_per_ctrl)
{
unsigned int i;
unsigned int i2c_address = 0;
@@ -145,14 +145,14 @@ void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
return;
}
- for (i = 0; i CONFIG_DIMM_SLOTS_PER_CTLR; i++) {
+ for (i = 0; i dimm_slots_per_ctrl; i++) {
i2c_address = spd_i2c_addr[ctrl_num][i];
get_spd((ctrl_dimms_spd[i]), i2c_address);
}
}
#else
void fsl_ddr_get_spd(generic_spd_eeprom_t
[U-Boot] [PATCH 2/2] ARMv8/ls2085a_emu: Enable DP-DDR as standalone memory block
DP-DDR is used for DPAA, separated from main memory pool for general
use. It has 32-bit bus width and use a standard DDR4 DIMM (64-bit).
Signed-off-by: York Sun york...@freescale.com
---
arch/arm/include/asm/arch-fsl-lsch3/config.h |3 ++-
board/freescale/ls2085a/ddr.c| 36 +++---
board/freescale/ls2085a/ddr.h| 29 +
board/freescale/ls2085a/ls2085a.c| 13 +-
include/configs/ls2085a_common.h | 14 +-
include/configs/ls2085a_emu.h|1 +
6 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-fsl-lsch3/config.h
b/arch/arm/include/asm/arch-fsl-lsch3/config.h
index b17410a..f632c82 100644
--- a/arch/arm/include/asm/arch-fsl-lsch3/config.h
+++ b/arch/arm/include/asm/arch-fsl-lsch3/config.h
@@ -16,6 +16,7 @@
#define CONFIG_SYS_IMMR0x0100
#define CONFIG_SYS_FSL_DDR_ADDR(CONFIG_SYS_IMMR +
0x0008)
#define CONFIG_SYS_FSL_DDR2_ADDR (CONFIG_SYS_IMMR + 0x0009)
+#define CONFIG_SYS_FSL_DDR3_ADDR 0x0821
#define CONFIG_SYS_FSL_GUTS_ADDR (CONFIG_SYS_IMMR + 0x00E0)
#define CONFIG_SYS_FSL_PMU_ADDR(CONFIG_SYS_IMMR +
0x00E3)
#define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR (CONFIG_SYS_IMMR + 0x0030)
@@ -60,7 +61,7 @@
#ifdef CONFIG_LS2085A
#define CONFIG_MAX_CPUS16
#define CONFIG_SYS_FSL_IFC_BANK_COUNT 8
-#define CONFIG_NUM_DDR_CONTROLLERS 2
+#define CONFIG_NUM_DDR_CONTROLLERS 3
#define CONFIG_SYS_FSL_CLUSTER_CLOCKS { 1, 1, 4, 4 }
#else
#error SoC not defined
diff --git a/board/freescale/ls2085a/ddr.c b/board/freescale/ls2085a/ddr.c
index 257bc16..d173707 100644
--- a/board/freescale/ls2085a/ddr.c
+++ b/board/freescale/ls2085a/ddr.c
@@ -18,7 +18,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
const struct board_specific_parameters *pbsp, *pbsp_highest = NULL;
ulong ddr_freq;
- if (ctrl_num 3) {
+ if (ctrl_num 4) {
printf(Not supported controller number %d\n, ctrl_num);
return;
}
@@ -30,9 +30,9 @@ void fsl_ddr_board_options(memctl_options_t *popts,
* to pbsp = rdimms[ctrl_num] or pbsp = udimms[ctrl_num];
*/
if (popts-registered_dimm_en)
- pbsp = rdimms[0];
+ pbsp = rdimms[ctrl_num];
else
- pbsp = udimms[0];
+ pbsp = udimms[ctrl_num];
/* Get clk_adjust, wrlvl_start, wrlvl_ctl, according to the board ddr
@@ -72,6 +72,12 @@ found:
pbsp-clk_adjust, pbsp-wrlvl_start, pbsp-wrlvl_ctl_2,
pbsp-wrlvl_ctl_3);
+ if (ctrl_num == CONFIG_DP_DDR_CTRL) {
+ /* force DDR bus width to 32 bits */
+ popts-data_bus_width = 1;
+ popts-otf_burst_chop_en = 0;
+ popts-burst_length = DDR_BL8;
+ }
/*
* Factors to consider for half-strength driver enable:
* - number of DIMMs installed
@@ -163,6 +169,10 @@ phys_size_t initdram(int board_type)
void dram_init_banksize(void)
{
+#ifdef CONFIG_SYS_DP_DDR_BASE_PHY
+ phys_size_t dp_ddr_size;
+#endif
+
gd-bd-bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
if (gd-ram_size CONFIG_SYS_LS2_DDR_BLOCK1_SIZE) {
gd-bd-bi_dram[0].size = CONFIG_SYS_LS2_DDR_BLOCK1_SIZE;
@@ -172,4 +182,24 @@ void dram_init_banksize(void)
} else {
gd-bd-bi_dram[0].size = gd-ram_size;
}
+
+#ifdef CONFIG_SYS_DP_DDR_BASE_PHY
+ /* initialize DP-DDR here */
+ puts(DP-DDR: );
+ /*
+* DDR controller use 0 as the base address for binding.
+* It is mapped to CONFIG_SYS_DP_DDR_BASE for core to access.
+*/
+ dp_ddr_size = fsl_other_ddr_sdram(CONFIG_SYS_DP_DDR_BASE_PHY,
+ CONFIG_DP_DDR_CTRL,
+ CONFIG_DP_DDR_NUM_CTRLS,
+ CONFIG_DP_DDR_DIMM_SLOTS_PER_CTLR,
+ NULL, NULL, NULL);
+ if (dp_ddr_size) {
+ gd-bd-bi_dram[2].start = CONFIG_SYS_DP_DDR_BASE;
+ gd-bd-bi_dram[2].size = dp_ddr_size;
+ } else {
+ puts(Not detected);
+ }
+#endif
}
diff --git a/board/freescale/ls2085a/ddr.h b/board/freescale/ls2085a/ddr.h
index 77f6aaf..9958a68 100644
--- a/board/freescale/ls2085a/ddr.h
+++ b/board/freescale/ls2085a/ddr.h
@@ -33,6 +33,18 @@ static const struct board_specific_parameters udimm0[] = {
{}
};
+/* DP-DDR DIMM */
+static const struct board_specific_parameters udimm2[] = {
+ /*
+* memory controller 2
+* num| hi| rank| clk| wrlvl | wrlvl | wrlvl
+* ranks| mhz| GB
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On Fri, Aug 01, 2014 at 03:43:23PM -0600, Stephen Warren wrote: On 08/01/2014 02:43 PM, Tom Rini wrote: On Fri, Aug 01, 2014 at 02:22:40PM -0600, Stephen Warren wrote: On 08/01/2014 02:05 PM, Dennis Gilmore wrote: On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. What kind of issues? At least for Tegra, I've carefully chosen the values for the various load addresses so that there won't be issues. (Without that I can easily see the potential for issues.) I've seen far more repeated problems when U-Boot moves the DT/initrd around than than when it didn't (none in that case). Besides, it's completely redundant and unnecessary work if the blobs are already loaded at sane addresses, which they are on Tegra at least. Just how large of a kernel have you thrown on a Tegra? 32MB might seem reasonable at first but it wouldn't be overly surprised if someone can shove a BSS into there. I know I shoved DT into 128MB by default because a 32bit ARM kernel isn't functional at that size. There's enough space for the following: 16M decompressed kernel 16M compressed kernel ... which is potentially small :) 1M DTB The kernel I typically boot is ~4.MB zImage, and ~9MB Image (which doesn't include BSS). Note that if the decompressed/compressed kernel overlap, the kernel decompresser takes care of relocating the compressed kernel before doing the decompression, and IIRC is supposed to take care not to clobber the DTB (or initrd?) when doing so. The decompressor is happy to clobber over other things I would swear which is how people end up in the oops, my DT was eaten case when things are placed too close and _not_ relocated prior to booting. Fedora's rawhide zImage is a bit larger at ~6MB. That works fine too. Right but what's the worst case you can come up with? There's folks out there attempting to feed the same kernel into their testboard farm of relatively wild differnet HW but all works on multi_v7_defconfig. -- 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 v2 1/3] arm: bcm281xx: Add Ethernet Clock support
From: Jiandong Zheng jdzh...@broadcom.com
Enable Ethernet clock when Broadcom StarFighter2 Ethernet block
(CONFIG_BCM_SF2_ETH) is enabled.
Signed-off-by: Jiandong Zheng jdzh...@broadcom.com
Signed-off-by: Steve Rae s...@broadcom.com
---
- with the changes to boards.cfg, the board with this feature will be added
separately
Changes in v2:
- removed 'boards.cfg' from this commit
- (no other changes)
arch/arm/cpu/armv7/bcm281xx/Makefile| 1 +
arch/arm/cpu/armv7/bcm281xx/clk-bcm281xx.c | 34 +++
arch/arm/cpu/armv7/bcm281xx/clk-eth.c | 143
arch/arm/include/asm/arch-bcm281xx/sysmap.h | 3 +
4 files changed, 181 insertions(+)
create mode 100644 arch/arm/cpu/armv7/bcm281xx/clk-eth.c
diff --git a/arch/arm/cpu/armv7/bcm281xx/Makefile
b/arch/arm/cpu/armv7/bcm281xx/Makefile
index 98f5aa5..bd867a2 100644
--- a/arch/arm/cpu/armv7/bcm281xx/Makefile
+++ b/arch/arm/cpu/armv7/bcm281xx/Makefile
@@ -9,3 +9,4 @@ obj-y += clk-core.o
obj-y += clk-bcm281xx.o
obj-y += clk-sdio.o
obj-y += clk-bsc.o
+obj-$(CONFIG_BCM_SF2_ETH) += clk-eth.o
diff --git a/arch/arm/cpu/armv7/bcm281xx/clk-bcm281xx.c
b/arch/arm/cpu/armv7/bcm281xx/clk-bcm281xx.c
index bc8a170..d16b99f 100644
--- a/arch/arm/cpu/armv7/bcm281xx/clk-bcm281xx.c
+++ b/arch/arm/cpu/armv7/bcm281xx/clk-bcm281xx.c
@@ -118,6 +118,16 @@ unsigned long slave_apb_freq_tbl[8] = {
78 * CLOCK_1M
};
+unsigned long esub_freq_tbl[8] = {
+ 78 * CLOCK_1M,
+ 156 * CLOCK_1M,
+ 156 * CLOCK_1M,
+ 156 * CLOCK_1M,
+ 208 * CLOCK_1M,
+ 208 * CLOCK_1M,
+ 208 * CLOCK_1M
+};
+
static struct bus_clk_data bsc1_apb_data = {
.gate = HW_SW_GATE_AUTO(0x0458, 16, 0, 1),
};
@@ -295,6 +305,27 @@ static struct ccu_clock kps_ccu_clk = {
.freq_tbl = slave_axi_freq_tbl,
};
+#ifdef CONFIG_BCM_SF2_ETH
+static struct ccu_clock esub_ccu_clk = {
+ .clk = {
+ .name = esub_ccu_clk,
+ .ops = ccu_clk_ops,
+ .ccu_clk_mgr_base = ESUB_CLK_BASE_ADDR,
+ },
+ .num_policy_masks = 1,
+ .policy_freq_offset = 0x0008,
+ .freq_bit_shift = 8,
+ .policy_ctl_offset = 0x000c,
+ .policy0_mask_offset = 0x0010,
+ .policy1_mask_offset = 0x0014,
+ .policy2_mask_offset = 0x0018,
+ .policy3_mask_offset = 0x001c,
+ .lvm_en_offset = 0x0034,
+ .freq_id = 2,
+ .freq_tbl = esub_freq_tbl,
+};
+#endif
+
/*
* Bus clocks
*/
@@ -517,6 +548,9 @@ struct clk_lookup arch_clk_tbl[] = {
CLK_LK(bsc1_apb),
CLK_LK(bsc2_apb),
CLK_LK(bsc3_apb),
+#ifdef CONFIG_BCM_SF2_ETH
+ CLK_LK(esub_ccu),
+#endif
};
/* public array size */
diff --git a/arch/arm/cpu/armv7/bcm281xx/clk-eth.c
b/arch/arm/cpu/armv7/bcm281xx/clk-eth.c
new file mode 100644
index 000..b0b92b9
--- /dev/null
+++ b/arch/arm/cpu/armv7/bcm281xx/clk-eth.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright 2014 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/errno.h
+#include asm/arch/sysmap.h
+#include asm/kona-common/clk.h
+#include clk-core.h
+
+#define WR_ACCESS_ADDR ESUB_CLK_BASE_ADDR
+#define WR_ACCESS_PASSWORD 0xA5A500
+
+#define PLLE_POST_RESETB_ADDR (ESUB_CLK_BASE_ADDR + 0x0C00)
+
+#define PLLE_RESETB_ADDR (ESUB_CLK_BASE_ADDR + 0x0C58)
+#define PLLE_RESETB_I_PLL_RESETB_PLLE_MASK 0x0001
+#define PLLE_POST_RESETB_I_POST_RESETB_PLLE_MASK 0x0001
+
+#define PLL_LOCK_ADDR (ESUB_CLK_BASE_ADDR + 0x0C38)
+#define PLL_LOCK_PLL_LOCK_PLLE_MASK0x0001
+
+#define ESW_SYS_DIV_ADDR (ESUB_CLK_BASE_ADDR + 0x0A04)
+#define ESW_SYS_DIV_PLL_SELECT_MASK0x0300
+#define ESW_SYS_DIV_DIV_MASK 0x001C
+#define ESW_SYS_DIV_PLL_VAR_208M_CLK_SELECT0x0100
+#define ESW_SYS_DIV_DIV_SELECT 0x4
+#define ESW_SYS_DIV_TRIGGER_MASK 0x0001
+
+#define ESUB_AXI_DIV_DEBUG_ADDR(ESUB_CLK_BASE_ADDR +
0x0E04)
+#define ESUB_AXI_DIV_DEBUG_PLL_SELECT_MASK 0x001C
+#define ESUB_AXI_DIV_DEBUG_PLL_SELECT_OVERRIDE_MASK0x0040
+#define ESUB_AXI_DIV_DEBUG_PLL_VAR_208M_CLK_SELECT 0x0
+#define ESUB_AXI_DIV_DEBUG_TRIGGER_MASK0x0001
+
+#define PLL_MAX_RETRY 100
+
+/* Enable appropriate clocks for Ethernet */
+int clk_eth_enable(void)
+{
+ int rc = -1;
+ int retry_count = 0;
+ rc = clk_get_and_enable(esub_ccu_clk);
+
+ /* Enable Access to CCU registers */
+ writel((1 | WR_ACCESS_PASSWORD), WR_ACCESS_ADDR);
+
+ writel(readl(PLLE_POST_RESETB_ADDR)
+ ~PLLE_POST_RESETB_I_POST_RESETB_PLLE_MASK,
+ PLLE_POST_RESETB_ADDR);
+
+ /* Take PLL out of reset and put into
[U-Boot] [PATCH v2 2/3] arm: bcm281xx: net: Add Ethernet Driver
From: Jiandong Zheng jdzh...@broadcom.com
The Broadcom StarFighter2 Ethernet driver is used in multiple Broadcom
SoC(s) and:
- supports multiple MAC blocks,
- provides support for the Broadcom GMAC.
This driver requires MII and PHYLIB.
Signed-off-by: Jiandong Zheng jdzh...@broadcom.com
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v2:
- added Ethernet Driver
drivers/net/Makefile | 2 +
drivers/net/bcm-sf2-eth-gmac.c | 971 +
drivers/net/bcm-sf2-eth-gmac.h | 224 ++
drivers/net/bcm-sf2-eth.c | 268
drivers/net/bcm-sf2-eth.h | 70 +++
include/netdev.h | 1 +
6 files changed, 1536 insertions(+)
create mode 100644 drivers/net/bcm-sf2-eth-gmac.c
create mode 100644 drivers/net/bcm-sf2-eth-gmac.h
create mode 100644 drivers/net/bcm-sf2-eth.c
create mode 100644 drivers/net/bcm-sf2-eth.h
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7cc6b6f..14b5eb2 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -10,6 +10,8 @@ obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
+obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
+obj-$(CONFIG_BCM_SF2_ETH_GMAC) += bcm-sf2-eth-gmac.o
obj-$(CONFIG_BFIN_MAC) += bfin_mac.o
obj-$(CONFIG_CALXEDA_XGMAC) += calxedaxgmac.o
obj-$(CONFIG_CS8900) += cs8900.o
diff --git a/drivers/net/bcm-sf2-eth-gmac.c b/drivers/net/bcm-sf2-eth-gmac.c
new file mode 100644
index 000..977feec
--- /dev/null
+++ b/drivers/net/bcm-sf2-eth-gmac.c
@@ -0,0 +1,971 @@
+/*
+ * Copyright 2014 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifdef BCM_GMAC_DEBUG
+#ifndef DEBUG
+#define DEBUG
+#endif
+#endif
+
+#include config.h
+#include common.h
+#include malloc.h
+#include net.h
+#include asm/io.h
+#include phy.h
+
+#include bcm-sf2-eth.h
+#include bcm-sf2-eth-gmac.h
+
+#define SPINWAIT(exp, us) { \
+ uint countdown = (us) + 9; \
+ while ((exp) (countdown = 10)) {\
+ udelay(10); \
+ countdown -= 10; \
+ } \
+}
+
+static int gmac_disable_dma(struct eth_dma *dma, int dir);
+static int gmac_enable_dma(struct eth_dma *dma, int dir);
+
+/* DMA Descriptor */
+typedef struct {
+ /* misc control bits */
+ uint32_tctrl1;
+ /* buffer count and address extension */
+ uint32_tctrl2;
+ /* memory address of the date buffer, bits 31:0 */
+ uint32_taddrlow;
+ /* memory address of the date buffer, bits 63:32 */
+ uint32_taddrhigh;
+} dma64dd_t;
+
+uint32_t g_dmactrlflags;
+
+static uint32_t dma_ctrlflags(uint32_t mask, uint32_t flags)
+{
+ debug(%s enter\n, __func__);
+
+ g_dmactrlflags = ~mask;
+ g_dmactrlflags |= flags;
+
+ /* If trying to enable parity, check if parity is actually supported */
+ if (g_dmactrlflags DMA_CTRL_PEN) {
+ uint32_t control;
+
+ control = readl(GMAC0_DMA_TX_CTRL_ADDR);
+ writel(control | D64_XC_PD, GMAC0_DMA_TX_CTRL_ADDR);
+ if (readl(GMAC0_DMA_TX_CTRL_ADDR) D64_XC_PD) {
+ /*
+* We *can* disable it, therefore it is supported;
+* restore control register
+*/
+ writel(control, GMAC0_DMA_TX_CTRL_ADDR);
+ } else {
+ /* Not supported, don't allow it to be enabled */
+ g_dmactrlflags = ~DMA_CTRL_PEN;
+ }
+ }
+
+ return g_dmactrlflags;
+}
+
+static inline void reg32_clear_bits(uint32_t reg, uint32_t value)
+{
+ uint32_t v = readl(reg);
+ v = ~(value);
+ writel(v, reg);
+}
+
+static inline void reg32_set_bits(uint32_t reg, uint32_t value)
+{
+ uint32_t v = readl(reg);
+ v |= value;
+ writel(v, reg);
+}
+
+#ifdef BCM_GMAC_DEBUG
+static void dma_tx_dump(struct eth_dma *dma)
+{
+ dma64dd_t *descp = NULL;
+ uint8_t *bufp;
+ int i;
+
+ printf(TX DMA Register:\n);
+ printf(control:0x%x; ptr:0x%x; addrl:0x%x; addrh:0x%x; stat0:0x%x,
stat1:0x%x\n,
+ readl(GMAC0_DMA_TX_CTRL_ADDR),
+ readl(GMAC0_DMA_TX_PTR_ADDR),
+ readl(GMAC0_DMA_TX_ADDR_LOW_ADDR),
+ readl(GMAC0_DMA_TX_ADDR_HIGH_ADDR),
+ readl(GMAC0_DMA_TX_STATUS0_ADDR),
+ readl(GMAC0_DMA_TX_STATUS1_ADDR));
+
+ printf(TX Descriptors:\n);
+ for (i = 0; i TX_BUF_NUM; i++) {
+ descp = (dma64dd_t *)(dma-tx_desc_aligned) + i;
+ printf(ctrl1:0x%08x; ctrl2:0x%08x; addr:0x%x 0x%08x\n,
+ descp-ctrl1, descp-ctrl2,
+ descp-addrhigh, descp-addrlow);
+ }
+
+ printf(TX Buffers:\n);
+ /* Initialize TX DMA descriptor table */
+ for (i =
[U-Boot] [PATCH v2 3/3] arm: bcm281xx: add board with Ethernet capability
Add board which has Broadcom StarFighter2 Ethernet capability. Signed-off-by: Steve Rae s...@broadcom.com --- Changes in v2: - created from previous boards.cfg board/broadcom/bcm28155_w1d/MAINTAINERS | 6 ++ configs/bcm28155_w1d_defconfig | 3 +++ 2 files changed, 9 insertions(+) create mode 100644 board/broadcom/bcm28155_w1d/MAINTAINERS create mode 100644 configs/bcm28155_w1d_defconfig diff --git a/board/broadcom/bcm28155_w1d/MAINTAINERS b/board/broadcom/bcm28155_w1d/MAINTAINERS new file mode 100644 index 000..a436490 --- /dev/null +++ b/board/broadcom/bcm28155_w1d/MAINTAINERS @@ -0,0 +1,6 @@ +BCM28155_W1D BOARD +M: Steve Rae s...@broadcom.com +S: Maintained +F: board/broadcom/bcm28155_ap/ +F: include/configs/bcm28155_ap.h +F: configs/bcm28155_w1d_defconfig diff --git a/configs/bcm28155_w1d_defconfig b/configs/bcm28155_w1d_defconfig new file mode 100644 index 000..94b791c --- /dev/null +++ b/configs/bcm28155_w1d_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS=BCM_SF2_ETH,BCM_SF2_ETH_GMAC +CONFIG_ARM=y +CONFIG_TARGET_BCM28155_AP=y -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
