Re: [U-Boot] [PATCH 12/19] powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards
Hi Stefan, On 26 January 2015 at 06:17, Stefan Roese s...@denx.de wrote: On 15.12.2014 15:19, Simon Glass wrote: Enable CONFIG_OF_CONTROL so that U-Boot on these three boards uses a device tree for its configuration. Signed-off-by: Simon Glass s...@chromium.org This need further work on the ppc4xx platforms to get it booting from flash. As now the dtb is appended to the normal U-Boot image. And this image is fine-tuned to fit into currently 512KiB. With the last word (reset vector of the ppc4xx) located at 0x.fffc. So we need to include this dtb into the image this way: 0xfff8. U-Boot code / text etc ... dtb 0x.fffc reset vector Looking for the current options shows that perhaps CONFIG_OF_EMBED seems to be exactly what we are need. I'll got it working on Canyonlands after a bit of debugging. I'll post the necessary small patches soon... Sounds good, thanks! It almost feels like you should have a mkimage image for this, to create a 512KB blob from u-boot.bin and u-boot.dtb. There must be linker magic to make this all hold together. But yes the embed option will build it in, so avoiding that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support
Hi Marek, On Monday, January 26, 2015 at 09:38:28 AM, Lukasz Majewski wrote: Hi Marek, Hi! [...] No, unless there's a convincing technical argument that the currently mainline DWC2 gadget driver (the s3c one) can absolutelly not be used for the broadcom SoC, I want to avoid having two drivers for the same IP core in mainline, sorry. Maybe it is a highest time to think about renaming s3c_* to dwc2_* and avoid further confusion. The time was ripe for a while now ;-) Do you want to do it or shall I send a patch ? I do know that I will test it :-), so feel free to send the patch. Best regards, Marek Vasut -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI driver convert to Driver Model
Hi, On 25 January 2015 at 20:44, haikun.w...@freescale.com haikun.w...@freescale.com wrote: Hi, My driver should support ls1021aqds, ls1021atwr, mcf5445x, mcf5227x, mcf52x2. Please avoid top-posting. The first one at least supports generic board. It doesn't look like mcf5445x does though, so you should move that over ASAP (the deadline has actually passed). There may be pending patches I don't know about. Once you do that you can use drive model. For device tree you can see a PowerPC conversion at u-boot-dm branch ppc-working http://git.denx.de/?p=u-boot/u-boot-dm.git;a=shortlog;h=refs/heads/ppc-working This should help you get it running on m68k. Sorry there are several patches there that don't relate to this. These ones seem relevant. 1a83894 powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards d70d614 powerpc: ppc4xx: Allow the end of u-boot.bin to be found bfd89eb powerpc: ppc4xx: Call board_init_f_mem() for generic board 44c9942 powerpc: ppc4xx: dts: Bring in canyonlands device tree files 529e967 powerpc: ppc4xx: canyonlands: Move to generic board 3a17e68 powerpc: ppc4xx: Move CANYONLANDS/GLACIER/ARCHES to Kconfig 4bfa397 powerpc: Permit device tree control of U-Boot (CONFIG_OF_CONTROL) 4eda9b6 Introduce board_init_f_mem() to handle early memory layout You should be able to create simple files with just the SPI interfaces that you need. You can always expand them later. If I had a board I would be happy to help. Regards, Simon Best regards, Wang Haikun -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: Friday, January 23, 2015 6:36 AM To: Wang Haikun-B53464 Cc: U-Boot Mailing List Subject: Re: SPI driver convert to Driver Model (copying the list) Hi, On 19 January 2015 at 22:38, haikun.w...@freescale.com haikun.w...@freescale.com wrote: Hi Simon, I am working for converting my SPI driver to driver model. I encountered some problems. My driver need to support many old platforms, such as m68k serials and there is no DTS file for them in kernel now. It seems that compiling couldn’t be completed successfully with enable CONFIG_DM_SPI and disable CONFIG_OF_CONTROL because of some functions in file driver/spi/spi-uclass.c call DTS’s interfaces . So are you working for supporting SPI DM works correctly in some platforms without creating new DTS file for them such as m68k? Or can you give me some advice? One suggestion is to add a simple device tree for the platform. If you only need to support serial and SPI it might be quite simple. Specifically what boards are you supporting? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/19] dm: powerpc: ppc4xx: Move glacier to use driver model for serial
Hi Stefan, On 26 January 2015 at 02:35, Stefan Roese s...@denx.de wrote: On 26.01.2015 10:23, Stefan Roese wrote: diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index 0fc6877..cbc5ff9 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -29,4 +29,13 @@ config ARCHES endchoice +config DM + default y + +config DM_SERIAL + default y + +config SYS_MALLOC_F_LEN + default 0x400 + Hmmm. This does not seem to work. With your patch series applied on current top-of-tree I get this error (for glacier_ramboot or canyonlands): $ make -s -j10 board/amcc/canyonlands/Kconfig:38:warning: config symbol defined without type drivers/serial/serial-uclass.c:29:2: error: #error Serial is required before relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work make[1]: *** [drivers/serial/serial-uclass.o] Error 1 Somehow the CONFIG_SYS_MALLOC_F_LEN define is not available in the .config used. Do you have any idea why it might be missing? Okay. Found it. Its the missing type here. I'll send some follow-up patches once I have all tested on canyonlands here. OK good. Also see u-boot-dm branch ppc-working if you need more context. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Export redesign
Dear Simon, In message 1422279795-3052-1-git-send-email-...@chromium.org you wrote: From: Martin Dorwig dor...@tetronik.com this is an atempt to make the export of functions typesafe. I replaced the jumptable void ** by a struct (jt_funcs) with function pointers. The EXPORT_FUNC macro now has 3 fixed parameters and one variadic parameter The first is the name of the exported function, the rest of the parameters are used to format a functionpointer in the jumptable, the EXPORT_FUNC macros are expanded three times, 1. to declare the members of the struct 2. to initialize the structmember pointers 3. to call the functions in stubs.c Signed-off-by: Martin Dorwig dor...@tetronik.com Acked-by: Simon Glass s...@chromium.org Signed-off-by: Simon Glass s...@chromium.org (resending to the list since my tweaks are not quite trivial) Is this a 100% binary compatible change? If not, should we not also increment XF_VERSION ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Where people stand is not as important as which way they face. - Terry Pratchett Stephen Briggs, _The Discworld Companion_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add Linksprite_pcDuino3_Nano board / defconfig
Hi, On 25-01-15 16:24, Adam Sampson wrote: This is a low-cost Allwinner A20 board with Arduino-style GPIO headers; it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro USB socket for OTG and another for power in, HDMI, SATA, 5V power for SATA devices, gigabit Ethernet, an IR receiver, 3.5mm audio out and a MIPI camera connector. For more details, see: http://linux-sunxi.org/LinkSprite_pcDuino3_Nano Signed-off-by: Adam Sampson a...@offog.org Thanks, I've queued this up for merging in u-boot-sunxi/next Regards, Hans --- board/sunxi/MAINTAINERS|5 + configs/Linksprite_pcDuino3_Nano_defconfig | 11 +++ 2 files changed, 16 insertions(+) create mode 100644 configs/Linksprite_pcDuino3_Nano_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 743e7f5..479d147 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -100,3 +100,8 @@ MELE M5 BOARD M:Ian Campbell i...@hellion.org.uk S:Maintained F:configs/Mele_M5_defconfig + +LINKSPRITE-PCDUINO3-NANO BOARD +M: Adam Sampson a...@offog.org +S: Maintained +F: configs/Linksprite_pcDuino3_Nano_defconfig diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig b/configs/Linksprite_pcDuino3_Nano_defconfig new file mode 100644 index 000..22435eb --- /dev/null +++ b/configs/Linksprite_pcDuino3_Nano_defconfig @@ -0,0 +1,11 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI +CONFIG_FDTFILE=sun7i-a20-pcduino3-nano.dtb +CONFIG_USB1_VBUS_PIN=PH11 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_TARGET_PCDUINO3_NANO=y ++S:CONFIG_DRAM_CLK=408 ++S:CONFIG_DRAM_ZQ=122 ++S:CONFIG_DRAM_EMR1=4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] fastboot: handle flash write to GPT partitions
On Fri, Jan 23, 2015 at 4:40 PM, Steve Rae s...@broadcom.com wrote: On 15-01-23 09:38 AM, Rob Herring wrote: On Fri, Dec 12, 2014 at 5:51 PM, Steve Rae s...@broadcom.com wrote: Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. I've been looking at how to do the same thing here. This is an area that suffers from each vendor doing whatever they want. Using vendor download/flash tools here is painful. They are all different because that is where the value add is. ;) What tool do you use on the host side to create the image? I have seen some vendor code to do it, or you could use parted plus a disk file and extract the partition table from it. I find either method a bit fragile and non-standard IMHO. We use an internal tool -- however, I also note that ALL of the source code for our tool is GPL-2.0+ (expect for one file which is Public Domain) Is U-Boot (Denx) interested in supporting a host tool? The 2 options I've come up with are 1) enable USB MS and use whatever host side tool you like or 2) use the existing gpt write command in u-boot and tie that into fastboot oem format command. The advantage and disadvantage of the latter is that it hides the partitioning details in u-boot from the user, but requires changing the u-boot env to change partition layout. The partitioning requirements are pretty SOC specific it seems. We also have code which creates the GPT tables from a fastboot oem format command, and (if I understand correctly) we have code that implements a gpt command line, which creates the GPT tables from env variables... If there is interest here, I could investigate further. I have patches I'm working on to do this. I hope to get them sent out soon. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/19] powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards
On 15.12.2014 15:19, Simon Glass wrote: Enable CONFIG_OF_CONTROL so that U-Boot on these three boards uses a device tree for its configuration. Signed-off-by: Simon Glass s...@chromium.org This need further work on the ppc4xx platforms to get it booting from flash. As now the dtb is appended to the normal U-Boot image. And this image is fine-tuned to fit into currently 512KiB. With the last word (reset vector of the ppc4xx) located at 0x.fffc. So we need to include this dtb into the image this way: 0xfff8. U-Boot code / text etc ... dtb 0x.fffc reset vector Looking for the current options shows that perhaps CONFIG_OF_EMBED seems to be exactly what we are need. I'll got it working on Canyonlands after a bit of debugging. I'll post the necessary small patches soon... Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10][v6] DM: crypto/rsa_mod_exp: Add rsa Modular Exponentiation DM driver
Hi Ruchika, On 26 January 2015 at 06:39, Simon Glass s...@chromium.org wrote: Hi Ruchika, On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Add a new rsa uclass for performing modular exponentiation and implement the software driver basing on this uclass. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: Changed UCLASS name to UCLASS_MOD_EXP Changes in v4: Removed Kconfig option for DM_RSA Corrected driver name for sw rsa driver Updated the rsa_mod_exp operation to have output length Changes in v3: New patch with driver model for RSA UCLASS drivers/crypto/Makefile | 1 + drivers/crypto/rsa_mod_exp/Kconfig | 5 drivers/crypto/rsa_mod_exp/Makefile | 7 ++ drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 39 + drivers/crypto/rsa_mod_exp/mod_exp_uclass.c | 31 +++ include/dm/uclass-id.h | 1 + include/u-boot/rsa-mod-exp.h| 34 - 7 files changed, 117 insertions(+), 1 deletion(-) create mode 100644 drivers/crypto/rsa_mod_exp/Kconfig create mode 100644 drivers/crypto/rsa_mod_exp/Makefile create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_sw.c create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_uclass.c Acked-by: Simon Glass s...@chromium.org Just in case there is a v7: +++ b/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c @@ -0,0 +1,31 @@ +/* + * (C) Copyright 2014 Freescale Semiconductor, Inc + * Author: Ruchika Gupta ruchika.gu...@freescale.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include common.h +#include dm.h +#include u-boot/rsa-mod-exp.h +#include errno.h +#include fdtdec.h +#include malloc.h +#include asm/io.h +#include linux/list.h + You can trim headers here. There are a few nits I mentioned in your patches. To avoid further delay and testing I would like to pick these patches up as is, but if you like you could send a follow-on patch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] powerpc: ppc4xx: Add missing type for SYS_MALLOC_F_LEN in Kconfig
Otherwise this symbol will not be created in the .config. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- board/amcc/canyonlands/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index bfdf17a..97df3f8 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -36,6 +36,7 @@ config DM_SERIAL default y config SYS_MALLOC_F_LEN + hex Size of the malloc() pool for use before relocation. default 0x400 config DEBUG_UART_BASE -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] powerpc: ppc4xx: Change from OF_SEPARATE to OF_EMBED
This is necessary, as ppc4xx has the reset vector located at the end of the U-Boot image. This needs to be flashed to the end of the NOR flash. Adding the dtb to the main U-Boot image will break booting on ppc4xx. This patch now embeds the dtb in the U-Boot image instead. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- configs/canyonlands_defconfig | 2 +- configs/glacier_defconfig | 2 +- configs/glacier_ramboot_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/canyonlands_defconfig b/configs/canyonlands_defconfig index 6f6cf14..44d4fbd 100644 --- a/configs/canyonlands_defconfig +++ b/configs/canyonlands_defconfig @@ -4,4 +4,4 @@ CONFIG_TARGET_CANYONLANDS=y CONFIG_CANYONLANDS=y CONFIG_DEFAULT_DEVICE_TREE=canyonlands CONFIG_OF_CONTROL=y -CONFIG_OF_SEPARATE=y +CONFIG_OF_EMBED=y diff --git a/configs/glacier_defconfig b/configs/glacier_defconfig index e67fa32..d318f82 100644 --- a/configs/glacier_defconfig +++ b/configs/glacier_defconfig @@ -4,4 +4,4 @@ CONFIG_TARGET_CANYONLANDS=y CONFIG_GLACIER=y CONFIG_DEFAULT_DEVICE_TREE=glacier CONFIG_OF_CONTROL=y -CONFIG_OF_SEPARATE=y +CONFIG_OF_EMBED=y diff --git a/configs/glacier_ramboot_defconfig b/configs/glacier_ramboot_defconfig index e5b402e..f8363b2 100644 --- a/configs/glacier_ramboot_defconfig +++ b/configs/glacier_ramboot_defconfig @@ -5,4 +5,4 @@ CONFIG_TARGET_CANYONLANDS=y CONFIG_GLACIER=y CONFIG_DEFAULT_DEVICE_TREE=glacier CONFIG_OF_CONTROL=y -CONFIG_OF_SEPARATE=y +CONFIG_OF_EMBED=y -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] powerpc: ppc4xx: Enable CONFIG_DISPLAY_BOARDINFO
This also displays the Board: line in the bootup text with the generic board support code. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- board/amcc/canyonlands/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index 97df3f8..3dc76ae 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -29,6 +29,10 @@ config ARCHES endchoice +config DISPLAY_BOARDINFO + bool + default y + config DM default y -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] powerpc: ppc4xx: Add defaults for DT based booting to really work
These additional nodes need to be provided to get U-Boot to boot correctly
on the Canyonlands / Glacier board:
- chosen path to the console-uart
- reg-shift set to 0 in the uart device nodes
Signed-off-by: Stefan Roese s...@denx.de
Cc: Simon Glass s...@chromium.org
---
arch/powerpc/dts/canyonlands.dts | 6 ++
arch/powerpc/dts/glacier.dts | 3 +++
2 files changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/canyonlands.dts b/arch/powerpc/dts/canyonlands.dts
index 2ec9762..0a2f5d7 100644
--- a/arch/powerpc/dts/canyonlands.dts
+++ b/arch/powerpc/dts/canyonlands.dts
@@ -22,6 +22,10 @@
serial1 = UART1;
};
+ chosen {
+ stdout-path = UART0;
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
@@ -280,6 +284,7 @@
UART0: serial@ef600300 {
device_type = serial;
+ reg-shift = 0;
compatible = ns16550;
reg = 0xef600300 0x0008;
virtual-reg = 0xef600300;
@@ -291,6 +296,7 @@
UART1: serial@ef600400 {
device_type = serial;
+ reg-shift = 0;
compatible = ns16550;
reg = 0xef600400 0x0008;
virtual-reg = 0xef600400;
diff --git a/arch/powerpc/dts/glacier.dts b/arch/powerpc/dts/glacier.dts
index 3e7ce2c..bb4e819 100644
--- a/arch/powerpc/dts/glacier.dts
+++ b/arch/powerpc/dts/glacier.dts
@@ -251,6 +251,7 @@
UART1: serial@ef600400 {
device_type = serial;
+ reg-shift = 0;
compatible = ns16550;
reg = 0xef600400 0x0008;
virtual-reg = 0xef600400;
@@ -262,6 +263,7 @@
UART2: serial@ef600500 {
device_type = serial;
+ reg-shift = 0;
compatible = ns16550;
reg = 0xef600500 0x0008;
virtual-reg = 0xef600500;
@@ -273,6 +275,7 @@
UART3: serial@ef600600 {
device_type = serial;
+ reg-shift = 0;
compatible = ns16550;
reg = 0xef600600 0x0008;
virtual-reg = 0xef600600;
--
2.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] Export redesign
From: Martin Dorwig dor...@tetronik.com
this is an atempt to make the export of functions typesafe.
I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
The EXPORT_FUNC macro now has 3 fixed parameters and one
variadic parameter
The first is the name of the exported function,
the rest of the parameters are used to format a functionpointer
in the jumptable,
the EXPORT_FUNC macros are expanded three times,
1. to declare the members of the struct
2. to initialize the structmember pointers
3. to call the functions in stubs.c
Signed-off-by: Martin Dorwig dor...@tetronik.com
Acked-by: Simon Glass s...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
(resending to the list since my tweaks are not quite trivial)
---
Changes in v5:
- Update to deal with I2C moving to driver model
arch/blackfin/cpu/cpu.c | 3 +-
board/BuS/eb_cpux9k2/cpux9k2.c| 2 +-
common/cmd_load.c | 2 +-
common/console.c | 20
common/exports.c | 29 ++--
doc/README.standalone | 41 +++-
examples/standalone/stubs.c | 64 +
include/_exports.h| 99 +++
include/asm-generic/global_data.h | 2 +-
include/exports.h | 20
10 files changed, 162 insertions(+), 120 deletions(-)
diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index b7f1188..91aa5cc 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -24,6 +24,7 @@
#include cpu.h
#include initcode.h
+#include exports.h
ulong bfin_poweron_retx;
DECLARE_GLOBAL_DATA_PTR;
@@ -121,7 +122,7 @@ static void display_global_data(void)
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( |-jt(%p): %p\n, gd-jt, gd-jt-get_version);
printf( \\-bd: %p\n, gd-bd);
printf( |-bi_boot_params: %lx\n, bd-bi_boot_params);
printf( |-bi_memstart: %lx\n, bd-bi_memstart);
diff --git a/board/BuS/eb_cpux9k2/cpux9k2.c b/board/BuS/eb_cpux9k2/cpux9k2.c
index 5e4778e..76ad7c4 100644
--- a/board/BuS/eb_cpux9k2/cpux9k2.c
+++ b/board/BuS/eb_cpux9k2/cpux9k2.c
@@ -98,7 +98,7 @@ int misc_init_r(void)
puts(Error: invalid MAC at EEPROM\n);
}
}
- gd-jt[XF_do_reset] = (void *) do_reset;
+ gd-jt-do_reset = do_reset;
#ifdef CONFIG_STATUS_LED
status_led_set(STATUS_LED_BOOT, STATUS_LED_BLINKING);
diff --git a/common/cmd_load.c b/common/cmd_load.c
index f6e522c..d043e6d 100644
--- a/common/cmd_load.c
+++ b/common/cmd_load.c
@@ -222,7 +222,7 @@ static int read_record(char *buf, ulong len)
}
/* Check for the console hangup (if any different from serial) */
- if (gd-jt[XF_getc] != getc) {
+ if (gd-jt-getc != getc) {
if (ctrlc()) {
return (-1);
}
diff --git a/common/console.c b/common/console.c
index fc1963b..3f25e76 100644
--- a/common/console.c
+++ b/common/console.c
@@ -125,13 +125,13 @@ static int console_setfile(int file, struct stdio_dev *
dev)
*/
switch (file) {
case stdin:
- gd-jt[XF_getc] = getc;
- gd-jt[XF_tstc] = tstc;
+ gd-jt-getc = getc;
+ gd-jt-tstc = tstc;
break;
case stdout:
- gd-jt[XF_putc] = putc;
- gd-jt[XF_puts] = puts;
- gd-jt[XF_printf] = printf;
+ gd-jt-putc = putc;
+ gd-jt-puts = puts;
+ gd-jt-printf = printf;
break;
}
break;
@@ -758,11 +758,11 @@ int console_init_r(void)
#endif
/* set default handlers at first */
- gd-jt[XF_getc] = serial_getc;
- gd-jt[XF_tstc] = serial_tstc;
- gd-jt[XF_putc] = serial_putc;
- gd-jt[XF_puts] = serial_puts;
- gd-jt[XF_printf] = serial_printf;
+ gd-jt-getc = serial_getc;
+ gd-jt-tstc = serial_tstc;
+ gd-jt-putc = serial_putc;
+ gd-jt-puts = serial_puts;
+ gd-jt-printf = serial_printf;
/* stdin stdout and stderr are in environment */
/* scan for it */
diff --git a/common/exports.c b/common/exports.c
index 459e18c..333107c 100644
--- a/common/exports.c
+++ b/common/exports.c
@@ -1,6 +1,7 @@
#include common.h
#include exports.h
#include spi.h
+#include i2c.h
DECLARE_GLOBAL_DATA_PTR;
@@ -13,34 +14,10 @@ unsigned long get_version(void)
return XF_VERSION;
}
-/* Reuse _exports.h with a little trickery to avoid bitrot */
-#define EXPORT_FUNC(sym) gd-jt[XF_##sym] = (void *)sym;
-
Re: [U-Boot] [PATCH 01/10][v6] rsa: Split the rsa-verify to separate the modular exponentiation
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Public exponentiation which is required in rsa verify functionality is tightly integrated with verification code in rsa_verify.c. The patch splits the file into twp separating the modular exponentiation. 1. rsa-verify.c - The file parses device tree keys node to fill a keyprop structure. The keyprop structure can then be converted to implementation specific format. (struct rsa_pub_key for sw implementation) - The parsed device tree node is then passed to a generic rsa_mod_exp function. 2. rsa-mod-exp.c Move the software specific functions related to modular exponentiation from rsa-verify.c to this file. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No changes Changes in v5: Reverted change in rsa_mod_exp_sw function to add pointer to output length Addressed other comments by Simon Changes in v4: Modified rsa_mod_exp_sw function to add pointer to output length Changes in v3: Kconfig moved to separate patch. This patch just splits the file now Changes in v2: Addressed few of Simon Glass's comments: - Kconfig option added for RSA - Comments added for new keyprop struct include/u-boot/rsa-mod-exp.h | 43 ++ lib/rsa/Makefile | 2 +- lib/rsa/rsa-mod-exp.c| 303 +++ lib/rsa/rsa-verify.c | 329 --- tools/Makefile | 3 +- 5 files changed, 404 insertions(+), 276 deletions(-) create mode 100644 include/u-boot/rsa-mod-exp.h create mode 100644 lib/rsa/rsa-mod-exp.c Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/19] dm: powerpc: ppc4xx: Move glacier to use driver model for serial
Hi Simon, On 26.01.2015 14:33, Simon Glass wrote: Hmmm. This does not seem to work. With your patch series applied on current top-of-tree I get this error (for glacier_ramboot or canyonlands): $ make -s -j10 board/amcc/canyonlands/Kconfig:38:warning: config symbol defined without type drivers/serial/serial-uclass.c:29:2: error: #error Serial is required before relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work make[1]: *** [drivers/serial/serial-uclass.o] Error 1 Somehow the CONFIG_SYS_MALLOC_F_LEN define is not available in the .config used. Do you have any idea why it might be missing? Okay. Found it. Its the missing type here. I'll send some follow-up patches once I have all tested on canyonlands here. OK good. Also see u-boot-dm branch ppc-working if you need more context. I just posted 4 patches that are needed on top of your patchset from mid December. Please either include them in your next patchset or fold them into your patches. With these patches on top I can boot Canyonlands from NOR flash. So for the complete patch series: Tested-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] dm:gpio:mxc add DT support
Hi Peng,
On 24 January 2015 at 07:34, Peng Fan b51...@freescale.com wrote:
Hi Simon,
On 1/23/2015 5:26 AM, Simon Glass wrote:
Hi Peng,
On 21 January 2015 at 04:09, Peng Fan peng@freescale.com wrote:
This patch add DT support for mxc gpio driver.
There are one place using CONFIG_OF_CONTROL macro.
1. The U_BOOT_DEVICES and mxc_plat array are complied out. To DT,
platdata is alloced using calloc, so there is no need to use
mxc_plat.
The following situations are tested, and all work fine:
1. with DM, without DT
2. with DM and DT
3. without DM
Since device tree has not been upstreamed, if want to test this patch.
The followings need to be done.
+ pieces of code does not gpio_request when using gpio_direction_xxx
and
etc, need to request gpio.
+ move the gpio settings from board_early_init_f to board_init
+ define CONFIG_DM ,CONFIG_DM_GPIO and CONFIG_OF_CONTROL
+ Add device tree file and do related configuration in
`make ARCH=arm menuconfig`
These will be done in future patches by step.
Signed-off-by: Peng Fan peng@freescale.com
---
drivers/gpio/mxc_gpio.c | 69
+
1 file changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index c52dd19..0766b78 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -151,6 +151,9 @@ int gpio_direction_output(unsigned gpio, int value)
#endif
#ifdef CONFIG_DM_GPIO
+#include fdtdec.h
+DECLARE_GLOBAL_DATA_PTR;
+
static int mxc_gpio_is_output(struct gpio_regs *regs, int offset)
{
u32 val;
@@ -259,23 +262,6 @@ static const struct dm_gpio_ops gpio_mxc_ops = {
.get_function = mxc_gpio_get_function,
};
-static const struct mxc_gpio_plat mxc_plat[] = {
- { 0, (struct gpio_regs *)GPIO1_BASE_ADDR },
- { 1, (struct gpio_regs *)GPIO2_BASE_ADDR },
- { 2, (struct gpio_regs *)GPIO3_BASE_ADDR },
-#if defined(CONFIG_MX25) || defined(CONFIG_MX27) || defined(CONFIG_MX51)
|| \
- defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { 3, (struct gpio_regs *)GPIO4_BASE_ADDR },
-#endif
-#if defined(CONFIG_MX27) || defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { 4, (struct gpio_regs *)GPIO5_BASE_ADDR },
- { 5, (struct gpio_regs *)GPIO6_BASE_ADDR },
-#endif
-#if defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { 6, (struct gpio_regs *)GPIO7_BASE_ADDR },
-#endif
-};
-
static int mxc_gpio_probe(struct udevice *dev)
{
struct mxc_bank_info *bank = dev_get_priv(dev);
@@ -296,12 +282,60 @@ static int mxc_gpio_probe(struct udevice *dev)
return 0;
}
+static int mxc_gpio_bind(struct udevice *device)
s/device/dev/ as that is the convention.
Will fix this.
+{
+ struct mxc_gpio_plat *plat = device-platdata;
+ struct gpio_regs *regs;
+
+ if (plat)
+ return 0;
Please add a comment as to why.
Ok.
+
+ regs = dev_get_addr(device);
+ if (!regs)
+ return -ENXIO;
-ENODEV I think?
Yeah. Right.
+
+ plat = calloc(1, sizeof(*plat));
+ if (!plat)
+ return -ENOMEM;
Can you use the auto-alloc feature instead? Trying to keep memory
allocations out of drivers unless it is for buffers, etc.
I want the DM code can support DT and no DT. To no DT, platdata is defined
in U_BOOT_DEVICES.
If using auto-alloc feature, but DT is not supported, is it conflict with
platdata in U_BOOT_DEVICES?
Yes it will. But please add a TODO in the code to remove this when
every board is converted to driver model and you don't need this.
+
+ plat-regs = regs;
+ plat-bank_index = device-req_seq;
Why store this? You can access it anytime using the device pointer.
To no DT, bank_index is statically intialized in mxc_plat array. I do not
want to introudce `#ifdef CONFIG_OF_CONTROL` in probe function and introudce
`if (dev-of_offset == -1)`, so
store it to bank_index.
To no DT, `if(plat) return 0;` will return. So plat-bank_index =
device-req_seq will only effects for DT.
Just want to support DT and no DT.
OK I think I understand.
+ device-platdata = plat;
+
+ return 0;
+}
+
+static const struct udevice_id mxc_gpio_ids[] = {
+ { .compatible = fsl,imx35-gpio },
+ { }
+};
+
U_BOOT_DRIVER(gpio_mxc) = {
.name = gpio_mxc,
.id = UCLASS_GPIO,
.ops= gpio_mxc_ops,
.probe = mxc_gpio_probe,
.priv_auto_alloc_size = sizeof(struct mxc_bank_info),
+ .of_match = mxc_gpio_ids,
Masahiro added a function for this.:
.of_match = of_match_ptr(mxc_gpio_ids),
But I'm not completely sure if this is wanted, since you include this
information even when not using device tree.
Thanks,I'll try this. I am not sure whether using of_match_ptr will make
compiler complain mxc_gpio_ids
Re: [U-Boot] [RFC PATCH 03/21] ARM: at91: collect SoC sources into mach-at91
Dear Masahiro Yamada, On 01/25/2015 07:11 AM, Masahiro Yamada wrote: This commit moves source files as follows: arch/arm/cpu/arm920t/at91/* - arch/arm/mach-at91/arm920t/* arch/arm/cpu/arm926ejs/at91/* - arch/arm/mach-at91/arm926ejs/* arch/arm/cpu/armv7/at91/* - arch/arm/mach-at91/armv7/* arch/arm/cpu/at91-common/*- arch/arm/mach-at91/* Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Andreas Bießmann andreas.de...@googlemail.com Acked-by: Andreas Bießmann andreas.de...@googlemail.com I should have read this mail first ;) Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 07/21] ARM: kirkwood: move SOC sources to mach-kirkwood
On 25.01.2015 07:11, Masahiro Yamada wrote: Move arch/arm/cpu/arm926ejs/kirkwood/* - arch/arm/mach-kirkwood/* Note: Perhaps, can we merge arch/arm/mach-kirkwood and arch/arm/mvebu-common into arch/arm/mach-mvebu, like Linux? Yes. This might need a bit work but definitely should be done. And at some time also move orion over to mach-mvebu as well. Thanks for this work. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Luka Perkov luka.per...@sartura.hr Cc: Stefan Roese s...@denx.de Acked-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 01/21] ARM: at91: move board select menu and common settings
On 01/25/2015 07:11 AM, Masahiro Yamada wrote:
The board select menu in arch/arm/Kconfig is still big.
To slim down it, this commit moves AT91 boards to
arch/arm/mach-at91/Kconfig.
Also, consolidate config SYS_SOC in each board Kconfig.
The Kconfig files under board/ directory were modified with the
following command:
find board -name Kconfig | xargs sed -i -e '
/config SYS_SOC/ {
N
/default at91/ {
N
d
}
}
'
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Acked-by: Andreas Bießmann andreas.de...@googlemail.co
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Dallas 1-wire support in u-boot
Dear u-boot developers, I'm looking for support of 1-wire protocol in this bootloader, without luck up until now I already search list archive with gmane and found only this old reference http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/117292 I also found some board implementation, not as a generic driver but as simple routines inside board file to read a thermal chip (unfortunately I've missed the reference now). Is there any staging patch or RFC for this protocol support in our beloved embedded bootloader? Currently I'm implementing this feature into an old 2013.10 version but I think it should be easy to adapt this kind of drivers between different u-boot releases. Best Regards and TIA, -- Andrea SCIAN DAVE Embedded Systems ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fix ARM DCC support for ARMv7 based cores (e.g. CortexA)
Signed-off-by: Alexander Merkle alexander.mer...@lauterbach.com --- drivers/serial/arm_dcc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c index 5dfb02f..e37 100644 --- a/drivers/serial/arm_dcc.c +++ b/drivers/serial/arm_dcc.c @@ -29,9 +29,9 @@ #include common.h #include serial.h -#if defined(CONFIG_CPU_V6) +#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7) /* - * ARMV6 + * ARMV6 ARMV7 */ #define DCC_RBIT (1 30) #define DCC_WBIT (1 29) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] fix ARM DCC support for ARMv7 based cores (e.g. CortexA)
arm_dcc.c supported ARMv4 (ARM7) to ARMv6 (ARM11) correctly. All recent CortexA/ARMv7 based cores share the mrc/mcr coprocessor calls of ARMv6. Due to the missing #ifdef the ARM7/ARMv4 calls are used as soon as CONFIG_CPU_V7 is defined. This results in an undefined instruction exception. Alexander Merkle (1): fix ARM DCC support for ARMv7 based cores (e.g. CortexA) drivers/serial/arm_dcc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/19] powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards
Hi Simon, On Mon, Jan 26, 2015 at 9:31 PM, Simon Glass s...@chromium.org wrote: Hi Stefan, On 26 January 2015 at 06:17, Stefan Roese s...@denx.de wrote: On 15.12.2014 15:19, Simon Glass wrote: Enable CONFIG_OF_CONTROL so that U-Boot on these three boards uses a device tree for its configuration. Signed-off-by: Simon Glass s...@chromium.org This need further work on the ppc4xx platforms to get it booting from flash. As now the dtb is appended to the normal U-Boot image. And this image is fine-tuned to fit into currently 512KiB. With the last word (reset vector of the ppc4xx) located at 0x.fffc. So we need to include this dtb into the image this way: 0xfff8. U-Boot code / text etc ... dtb 0x.fffc reset vector Looking for the current options shows that perhaps CONFIG_OF_EMBED seems to be exactly what we are need. I'll got it working on Canyonlands after a bit of debugging. I'll post the necessary small patches soon... Sounds good, thanks! We need do the same for Freescale BookE powerpc series too. It almost feels like you should have a mkimage image for this, to create a 512KB blob from u-boot.bin and u-boot.dtb. There must be linker magic to make this all hold together. But yes the embed option will build it in, so avoiding that. Or maybe we can extend x86 solution (like ifdtool) to non-x86 architectures like BookE powerpc? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10][v6] Use hash.c in mkimage
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: Fixed compilation error in this file for tools when FIT_SIGNATURE not enabled Changes in v5: New patch based on WIP patch by Simon. common/hash.c | 81 +- include/hash.h | 34 tools/Makefile | 1 + 3 files changed, 65 insertions(+), 51 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10][v6] rsa: Use checksum algorithms from struct hash_algo
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Currently the hash functions used in RSA are called directly from the sha1 and sha256 libraries. Change the RSA checksum library to use the progressive hash API's registered with struct hash_algo. This will allow the checksum library to use the hardware accelerated progressive hash API's once available. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: Removed changes in ls1021aqds.h accidently included in this patch Changes in v5: Both tools and uboot use the same code in rsa-checksum.c Changes in v4: No changes in this patch. Still under discussion Changes in v3: Modified rsa-verify to check for return from checksum function Changes in v2: Added generic function hash_calculate. Pass an additional argument as name of algorithm. common/image-sig.c| 6 +++--- include/image.h | 5 +++-- include/u-boot/rsa-checksum.h | 17 +++ lib/rsa/rsa-checksum.c| 50 ++- lib/rsa/rsa-verify.c | 7 +- 5 files changed, 55 insertions(+), 30 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10][v6] lib/rsa: Modify rsa to use DM driver
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Modify rsa_verify to use the rsa driver of DM library .The tools will continue to use the same RSA sw library. CONFIG_RSA is now dependent on CONFIG_DM. All configurations which enable FIT based signatures have been modified to enable CONFIG_DM by default. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: Added signature option in am335x_boneblack_vboot_defconfig Made changes in rsa-verify.c as suggested by Simon Changes in v4: Make CONFIG_RSA always depenedent on Driver Model. Add CONFIG_DM in defconfigs of the platforms which enable CONFIG_FIT_SIGNATURE Changes in v3: New patch README | 7 ++- configs/am335x_boneblack_vboot_defconfig | 4 configs/ids8313_defconfig| 1 + configs/sandbox_defconfig| 1 + configs/zynq_microzed_defconfig | 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + configs/zynq_zybo_defconfig | 1 + include/configs/am335x_evm.h | 6 ++ include/configs/sandbox.h| 1 - lib/rsa/rsa-verify.c | 14 ++ 14 files changed, 35 insertions(+), 6 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10][v6] lib/rsa: Add Kconfig for devices supporting RSA Modular Exponentiation
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Kconfig option added for devices which support RSA Verification. 1. RSA_SOFTWARE_EXP Enables driver for supporting RSA Modular Exponentiation in Software 2. RSA_FREESCALE_EXP Enables driver for supporting RSA Modular Exponentiation using Freescale specific driver The above drivers use RSA uclass Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: No changes Changes in v4: Introduced 2 options when CONFIG_RSA is selected: RSA_SOFTWARE_EXP RSA_FREESCALE_EXP Removed RSA_HW. Changes the name pf RSA_SW to RSA_SOFTWARE_EXP Changes in v3: New patch lib/Kconfig | 7 +-- lib/rsa/Kconfig | 28 2 files changed, 29 insertions(+), 6 deletions(-) create mode 100644 lib/rsa/Kconfig Acked-by: Simon Glass s...@chromium.org (note the duplicated line in your Kconfig if you issue a new version, but I can clean that up when applying it) +++ b/lib/rsa/Kconfig @@ -0,0 +1,28 @@ +config RSA + bool Use RSA Library + select RSA_FREESCALE_EXP if FSL_CAAM + select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP + help + RSA support. This enables the RSA algorithm used for FIT image + verification in U-Boot. + See doc/uImage.FIT/signature.txt for more details. + See doc/uImage.FIT/signature.txt for more details. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10][v6] DM: crypto/fsl - Add Freescale rsa DM driver
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Driver added for RSA Modular Exponentiation using Freescale Hardware Accelerator CAAM. The driver uses UCLASS_MOD_EXP Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: Reverted mod_exp not to use output length Changes in v4: Modified for the changes in op function of rsa class mod_exp Changes in v3: Moved to integrate with RSA UCLASS drivers/crypto/Kconfig| 1 + drivers/crypto/fsl/Kconfig| 6 + drivers/crypto/fsl/Makefile | 1 + drivers/crypto/fsl/fsl_rsa.c | 60 +++ drivers/crypto/fsl/jobdesc.c | 28 drivers/crypto/fsl/jobdesc.h | 5 drivers/crypto/fsl/rsa_caam.h | 28 7 files changed, 129 insertions(+) create mode 100644 drivers/crypto/fsl/Kconfig create mode 100644 drivers/crypto/fsl/fsl_rsa.c create mode 100644 drivers/crypto/fsl/rsa_caam.h I don't see what you want inline functions in jobdesc.h, but I suppose that is your business. Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10][v6] DM: crypto/rsa_mod_exp: Add rsa Modular Exponentiation DM driver
Hi Ruchika, On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: Add a new rsa uclass for performing modular exponentiation and implement the software driver basing on this uclass. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: Changed UCLASS name to UCLASS_MOD_EXP Changes in v4: Removed Kconfig option for DM_RSA Corrected driver name for sw rsa driver Updated the rsa_mod_exp operation to have output length Changes in v3: New patch with driver model for RSA UCLASS drivers/crypto/Makefile | 1 + drivers/crypto/rsa_mod_exp/Kconfig | 5 drivers/crypto/rsa_mod_exp/Makefile | 7 ++ drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 39 + drivers/crypto/rsa_mod_exp/mod_exp_uclass.c | 31 +++ include/dm/uclass-id.h | 1 + include/u-boot/rsa-mod-exp.h| 34 - 7 files changed, 117 insertions(+), 1 deletion(-) create mode 100644 drivers/crypto/rsa_mod_exp/Kconfig create mode 100644 drivers/crypto/rsa_mod_exp/Makefile create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_sw.c create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_uclass.c Acked-by: Simon Glass s...@chromium.org Just in case there is a v7: +++ b/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c @@ -0,0 +1,31 @@ +/* + * (C) Copyright 2014 Freescale Semiconductor, Inc + * Author: Ruchika Gupta ruchika.gu...@freescale.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include common.h +#include dm.h +#include u-boot/rsa-mod-exp.h +#include errno.h +#include fdtdec.h +#include malloc.h +#include asm/io.h +#include linux/list.h + You can trim headers here. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10][v6] hash: Add function to find hash_algo struct with progressive hash
On 23 January 2015 at 03:31, Ruchika Gupta ruchika.gu...@freescale.com wrote: The hash_algo structure has some implementations in which progressive hash API's are not defined. These are basically the hardware based implementations of SHA. An API is added to find the algo which has progressive hash API's defined. This can then be integrated with RSA checksum library which uses Progressive Hash API's. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: None Changes in v4: Few cosmetic changes. Currently I have not replaced CONFIG_SHA1 with CONFIG_CMD_SHA1SUM. Waiting for reply from Simon and Denx for the same. Changes in v3 : Corrected ifdef for SHA1 Changes in v2 : Added commit message common/hash.c | 33 - include/hash.h | 14 ++ 2 files changed, 38 insertions(+), 9 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] MIPS: unify cache initialization code
The mips32 mips64 cache initialization code differs only in that the
mips32 code supports reading the cache size from coprocessor 0 registers
at runtime. Move the more developed mips32 version to a common
arch/mips/lib/cache_init.S remove the now-redundant mips64 version in
order to reduce duplication. The temporary registers used are shuffled
slightly in order to work for both mips32 mips64 builds. The RA
register is defined differently to suit mips32 mips64, but will be
removed by a later commit in the series after further cleanup.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/cpu/mips32/Makefile | 3 +-
arch/mips/cpu/mips64/Makefile | 2 +-
arch/mips/cpu/mips64/cache.S | 213 -
arch/mips/lib/Makefile | 1 +
arch/mips/{cpu/mips32/cache.S = lib/cache_init.S} | 20 +-
5 files changed, 15 insertions(+), 224 deletions(-)
delete mode 100644 arch/mips/cpu/mips64/cache.S
rename arch/mips/{cpu/mips32/cache.S = lib/cache_init.S} (96%)
diff --git a/arch/mips/cpu/mips32/Makefile b/arch/mips/cpu/mips32/Makefile
index fa82dd3..19d316a 100644
--- a/arch/mips/cpu/mips32/Makefile
+++ b/arch/mips/cpu/mips32/Makefile
@@ -6,7 +6,6 @@
#
extra-y= start.o
-obj-y = cache.o
-obj-y += cpu.o interrupts.o time.o
+obj-y = cpu.o interrupts.o time.o
obj-$(CONFIG_SOC_AU1X00) += au1x00/
diff --git a/arch/mips/cpu/mips64/Makefile b/arch/mips/cpu/mips64/Makefile
index 899c319..cb4db9c 100644
--- a/arch/mips/cpu/mips64/Makefile
+++ b/arch/mips/cpu/mips64/Makefile
@@ -6,4 +6,4 @@
#
extra-y= start.o
-obj-y = cpu.o interrupts.o time.o cache.o
+obj-y = cpu.o interrupts.o time.o
diff --git a/arch/mips/cpu/mips64/cache.S b/arch/mips/cpu/mips64/cache.S
deleted file mode 100644
index 36d8688..000
--- a/arch/mips/cpu/mips64/cache.S
+++ /dev/null
@@ -1,213 +0,0 @@
-/*
- * Cache-handling routined for MIPS CPUs
- *
- * Copyright (c) 2003 Wolfgang Denk w...@denx.de
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include asm-offsets.h
-#include config.h
-#include asm/asm.h
-#include asm/regdef.h
-#include asm/mipsregs.h
-#include asm/addrspace.h
-#include asm/cacheops.h
-
-#define RA t9
-
-/*
- * 16kB is the maximum size of instruction and data caches on MIPS 4K,
- * 64kB is on 4KE, 24K, 5K, etc. Set bigger size for convenience.
- *
- * Note that the above size is the maximum size of primary cache. U-Boot
- * doesn't have L2 cache support for now.
- */
-#define MIPS_MAX_CACHE_SIZE0x1
-
-#define INDEX_BASE CKSEG0
-
- .macro cache_op op addr
- .setpush
- .setnoreorder
- .setmips3
- cache \op, 0(\addr)
- .setpop
- .endm
-
- .macro f_fill64 dst, offset, val
- LONG_S \val, (\offset + 0 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 1 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 2 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 3 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 4 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 5 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 6 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 7 * LONGSIZE)(\dst)
-#if LONGSIZE == 4
- LONG_S \val, (\offset + 8 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 9 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 10 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 11 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 12 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 13 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 14 * LONGSIZE)(\dst)
- LONG_S \val, (\offset + 15 * LONGSIZE)(\dst)
-#endif
- .endm
-
-/*
- * mips_init_icache(uint PRId, ulong icache_size, unchar icache_linesz)
- */
-LEAF(mips_init_icache)
- bleza1, 9f
- mtc0zero, CP0_TAGLO
- /* clear tag to invalidate */
- PTR_LI t0, INDEX_BASE
- PTR_ADDUt1, t0, a1
-1: cache_opINDEX_STORE_TAG_I t0
- PTR_ADDUt0, a2
- bne t0, t1, 1b
- /* fill once, so data field parity is correct */
- PTR_LI t0, INDEX_BASE
-2: cache_opFILL t0
- PTR_ADDUt0, a2
- bne t0, t1, 2b
- /* invalidate again - prudent but not strictly neccessary */
- PTR_LI t0, INDEX_BASE
-1: cache_opINDEX_STORE_TAG_I t0
- PTR_ADDUt0, a2
- bne t0, t1, 1b
-9: jr ra
- END(mips_init_icache)
-
-/*
- * mips_init_dcache(uint PRId, ulong dcache_size, unchar dcache_linesz)
- */
-LEAF(mips_init_dcache)
- bleza1, 9f
- mtc0zero, CP0_TAGLO
- /* clear all tags */
- PTR_LI t0, INDEX_BASE
- PTR_ADDUt1, t0, a1
-1: cache_opINDEX_STORE_TAG_D t0
-
Re: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S
On Fri, Jan 23, 2015 at 09:54:12AM +0100, Hans de Goede wrote: Hi, On 22-01-15 22:03, Tom Rini wrote: On Thu, Jan 22, 2015 at 08:10:06PM +0100, Hans de Goede wrote: Hi, On 22-01-15 17:20, Tom Rini wrote: On Wed, Jan 21, 2015 at 09:03:25PM +0100, Hans de Goede wrote: On some SoCs / ARMv7 CPU cores we need to do some setup before enabling the icache, etc. Add a soc_init hook with a weak default which just calls cpu_init_cp15. This way different implementations can be provided to do some extra work before or after cpu_init_cp15, or completely replacing cpu_init_cp15. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/cpu/armv7/start.S | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index fdc05b9..9882b20 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -64,7 +64,7 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT - bl cpu_init_cp15 + bl soc_init bl cpu_init_crit #endif I like the direction here. And I want to make sure I get the sunxi direction right here too (as I agree with the need / desire for boot0 + U-Boot to be a valid combination). I think we can take this a step farther. cpu_init_crit (on armv7) is basically a call to s_init(). For am33xx (and I bet but need to do and test omap3+) we can, with Simon's patch to let us move stack to DDR a tiny bit later, in the SPL case make s_init empty, which just leaves us with (with your patch) soc_init. Is there some way we can put all of this together in a function? You mean essentially call s_init here and have s_init call cpu_init_cp15 I guess we could do that, but it would require auditing all existing armv7 users of s_init. This may require me to rethink how / when I do timer gpio init etc. for u-boot.bin on sunxi, but that should not be a (big) problem. Basically. From my first pass audit of s_init, it's either empty (Kona), sunxi, or omap/etc so I get to deal with it. And the default soc_init would just be the call to cpu_init_cp15 as you have it and we drop the lowlevel_init hurdles. Ok, so what you're suggesting is a patch which: 1) Changes: #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 bl cpu_init_crit #endif Into: #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl lowlevel_init #endif Which will setup the stack and then call the s_init C function 2) Adds a weak default s_init which calls cpu_init_cp15 3) Patch all existing s_init functions to call cpu_init_cp15 before doing anything else. Pretty close. Simon's SPL DM series and related clean-ups got me thinking that yes, seemingly too much got shoved into s_init that really could have been done using an existing hook done slightly later. And then in follow up patches we can: 4) Drop cpu_init_crit 5) Cleanup some s_init functions (this will be left to the individual SoC maintainers) I think that is a good idea, Albert what do you think about this ? So I'd like to see 5 done soon afterwards as it's me (omap*) and sunxi. I think we can simplfy the call sequence too, to roughly: #ifndef CONFIG_SKIP_LOWLEVEL_INIT ... Set up stack for C, it's just a few instrs bl lowlevel_init #endif bl _main __weak asm lowlevel_init: bl cpu_init_cp15 return to caller And comment that anything called via lowlevel_init must be C-callable. I hope that once #5 is done no one actually has a lowlevel_init that's done in C but we've kept the door open should it be needed down the road (as I _think_ we can shuffle both the omap* and sunxi stuff to do their inits as needed in both SPL and full U-Boot from an early hook in board_init_r, top of my head is board_init calls some_other_func() in full U-Boot to ensure GPIOs, etc, on sunxi and spl_board_init() calls same func in SPL, and we can consolidate again further down the road as we get SPL and full U-Boot more in sync on the call chain). -- 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 0/8] MIPS cache code cleanup
This series cleans up the MIPS cache code somewhat, and unifies the
mips32 mips64 implementations of it. This is largely in preparation
for further patches adding L2 cache support. The final patch of this
series fixes a bug encountered with recent cores on Malta boards.
Paul Burton (8):
MIPS: avoid .set ISA for cache operations
MIPS: unify cache maintenance functions
MIPS: unify cache initialization code
MIPS: refactor L1 cache config reads to a macro
MIPS: refactor cache loops to a macro
MIPS: inline mips_init_[id]cache functions
MIPS: allow systems to skip loads during cache init
MIPS: clear TagLo select 2 during cache init
arch/mips/Kconfig | 6 +
arch/mips/cpu/mips32/Makefile | 3 +-
arch/mips/cpu/mips32/cpu.c | 119 ---
arch/mips/cpu/mips64/Makefile | 2 +-
arch/mips/cpu/mips64/cache.S | 213
arch/mips/cpu/mips64/cpu.c | 58 --
arch/mips/include/asm/cacheops.h | 7 +
arch/mips/lib/Makefile | 2 +
arch/mips/lib/cache.c | 118 +++
arch/mips/{cpu/mips32/cache.S = lib/cache_init.S} | 222 +
10 files changed, 226 insertions(+), 524 deletions(-)
delete mode 100644 arch/mips/cpu/mips64/cache.S
create mode 100644 arch/mips/lib/cache.c
rename arch/mips/{cpu/mips32/cache.S = lib/cache_init.S} (59%)
--
2.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] MIPS: avoid .set ISA for cache operations
As a step towards unifying the cache maintenance code for mips32
mips64 CPUs, stop using .set ISA directives in the more developed
mips32 version of the code. Instead, when present make use of the GCC
builtin for emitting a cache instruction. When not present, simply don't
bother with the .set directives since U-boot always builds with
-march=mips32 or higher anyway.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/cpu/mips32/cache.S | 18 +-
arch/mips/cpu/mips32/cpu.c | 40 +++-
arch/mips/include/asm/cacheops.h | 7 +++
3 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/arch/mips/cpu/mips32/cache.S b/arch/mips/cpu/mips32/cache.S
index 22bd844..fb1d84b 100644
--- a/arch/mips/cpu/mips32/cache.S
+++ b/arch/mips/cpu/mips32/cache.S
@@ -22,14 +22,6 @@
#define INDEX_BASE CKSEG0
- .macro cache_op op addr
- .setpush
- .setnoreorder
- .setmips3
- cache \op, 0(\addr)
- .setpop
- .endm
-
.macro f_fill64 dst, offset, val
LONG_S \val, (\offset + 0 * LONGSIZE)(\dst)
LONG_S \val, (\offset + 1 * LONGSIZE)(\dst)
@@ -60,17 +52,17 @@ LEAF(mips_init_icache)
/* clear tag to invalidate */
PTR_LI t0, INDEX_BASE
PTR_ADDUt1, t0, a1
-1: cache_opINDEX_STORE_TAG_I t0
+1: cache INDEX_STORE_TAG_I, 0(t0)
PTR_ADDUt0, a2
bne t0, t1, 1b
/* fill once, so data field parity is correct */
PTR_LI t0, INDEX_BASE
-2: cache_opFILL t0
+2: cache FILL, 0(t0)
PTR_ADDUt0, a2
bne t0, t1, 2b
/* invalidate again - prudent but not strictly neccessary */
PTR_LI t0, INDEX_BASE
-1: cache_opINDEX_STORE_TAG_I t0
+1: cache INDEX_STORE_TAG_I, 0(t0)
PTR_ADDUt0, a2
bne t0, t1, 1b
9: jr ra
@@ -85,7 +77,7 @@ LEAF(mips_init_dcache)
/* clear all tags */
PTR_LI t0, INDEX_BASE
PTR_ADDUt1, t0, a1
-1: cache_opINDEX_STORE_TAG_D t0
+1: cache INDEX_STORE_TAG_D, 0(t0)
PTR_ADDUt0, a2
bne t0, t1, 1b
/* load from each line (in cached space) */
@@ -95,7 +87,7 @@ LEAF(mips_init_dcache)
bne t0, t1, 2b
/* clear all tags */
PTR_LI t0, INDEX_BASE
-1: cache_opINDEX_STORE_TAG_D t0
+1: cache INDEX_STORE_TAG_D, 0(t0)
PTR_ADDUt0, a2
bne t0, t1, 1b
9: jr ra
diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
index 278865b..3f247fb 100644
--- a/arch/mips/cpu/mips32/cpu.c
+++ b/arch/mips/cpu/mips32/cpu.c
@@ -12,16 +12,6 @@
#include asm/cacheops.h
#include asm/reboot.h
-#define cache_op(op,addr) \
- __asm__ __volatile__( \
- .setpush\n \
- .setnoreorder \n \
- .setmips3\n\t \n \
- cache %0, %1 \n \
- .setpop \n \
- : \
- : i (op), R (*(unsigned char *)(addr)))
-
void __attribute__((weak)) _machine_restart(void)
{
}
@@ -74,20 +64,20 @@ void flush_cache(ulong start_addr, ulong size)
{
unsigned long ilsize = icache_line_size();
unsigned long dlsize = dcache_line_size();
- unsigned long addr, aend;
+ const volatile void *addr, *aend;
/* aend will be miscalculated when size is zero, so we return here */
if (size == 0)
return;
- addr = start_addr ~(dlsize - 1);
- aend = (start_addr + size - 1) ~(dlsize - 1);
+ addr = (void *)(start_addr ~(dlsize - 1));
+ aend = (void *)((start_addr + size - 1) ~(dlsize - 1));
if (ilsize == dlsize) {
/* flush I-cache D-cache simultaneously */
while (1) {
- cache_op(HIT_WRITEBACK_INV_D, addr);
- cache_op(HIT_INVALIDATE_I, addr);
+ mips_cache(HIT_WRITEBACK_INV_D, addr);
+ mips_cache(HIT_INVALIDATE_I, addr);
if (addr == aend)
break;
addr += dlsize;
@@ -97,17 +87,17 @@ void flush_cache(ulong start_addr, ulong size)
/* flush D-cache */
while (1) {
- cache_op(HIT_WRITEBACK_INV_D, addr);
+
[U-Boot] [PATCH 2/8] MIPS: unify cache maintenance functions
Move the more developed mips32 version of the cache maintenance
functions to a common arch/mips/lib/cache.c, in order to reduce
duplication between mips32 mips64.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/cpu/mips32/cpu.c | 109 -
arch/mips/cpu/mips64/cpu.c | 58 --
arch/mips/lib/Makefile | 1 +
arch/mips/lib/cache.c | 118 +
4 files changed, 119 insertions(+), 167 deletions(-)
create mode 100644 arch/mips/lib/cache.c
diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
index 3f247fb..8e1cc4e 100644
--- a/arch/mips/cpu/mips32/cpu.c
+++ b/arch/mips/cpu/mips32/cpu.c
@@ -9,7 +9,6 @@
#include command.h
#include netdev.h
#include asm/mipsregs.h
-#include asm/cacheops.h
#include asm/reboot.h
void __attribute__((weak)) _machine_restart(void)
@@ -24,114 +23,6 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
return 0;
}
-#ifdef CONFIG_SYS_CACHELINE_SIZE
-
-static inline unsigned long icache_line_size(void)
-{
- return CONFIG_SYS_CACHELINE_SIZE;
-}
-
-static inline unsigned long dcache_line_size(void)
-{
- return CONFIG_SYS_CACHELINE_SIZE;
-}
-
-#else /* !CONFIG_SYS_CACHELINE_SIZE */
-
-static inline unsigned long icache_line_size(void)
-{
- unsigned long conf1, il;
- conf1 = read_c0_config1();
- il = (conf1 MIPS_CONF1_IL) MIPS_CONF1_IL_SHIFT;
- if (!il)
- return 0;
- return 2 il;
-}
-
-static inline unsigned long dcache_line_size(void)
-{
- unsigned long conf1, dl;
- conf1 = read_c0_config1();
- dl = (conf1 MIPS_CONF1_DL) MIPS_CONF1_DL_SHIFT;
- if (!dl)
- return 0;
- return 2 dl;
-}
-
-#endif /* !CONFIG_SYS_CACHELINE_SIZE */
-
-void flush_cache(ulong start_addr, ulong size)
-{
- unsigned long ilsize = icache_line_size();
- unsigned long dlsize = dcache_line_size();
- const volatile void *addr, *aend;
-
- /* aend will be miscalculated when size is zero, so we return here */
- if (size == 0)
- return;
-
- addr = (void *)(start_addr ~(dlsize - 1));
- aend = (void *)((start_addr + size - 1) ~(dlsize - 1));
-
- if (ilsize == dlsize) {
- /* flush I-cache D-cache simultaneously */
- while (1) {
- mips_cache(HIT_WRITEBACK_INV_D, addr);
- mips_cache(HIT_INVALIDATE_I, addr);
- if (addr == aend)
- break;
- addr += dlsize;
- }
- return;
- }
-
- /* flush D-cache */
- while (1) {
- mips_cache(HIT_WRITEBACK_INV_D, addr);
- if (addr == aend)
- break;
- addr += dlsize;
- }
-
- /* flush I-cache */
- addr = (void *)(start_addr ~(ilsize - 1));
- aend = (void *)((start_addr + size - 1) ~(ilsize - 1));
- while (1) {
- mips_cache(HIT_INVALIDATE_I, addr);
- if (addr == aend)
- break;
- addr += ilsize;
- }
-}
-
-void flush_dcache_range(ulong start_addr, ulong stop)
-{
- unsigned long lsize = dcache_line_size();
- const volatile void *addr = (void *)(start_addr ~(lsize - 1));
- const volatile void *aend = (void *)((stop - 1) ~(lsize - 1));
-
- while (1) {
- mips_cache(HIT_WRITEBACK_INV_D, addr);
- if (addr == aend)
- break;
- addr += lsize;
- }
-}
-
-void invalidate_dcache_range(ulong start_addr, ulong stop)
-{
- unsigned long lsize = dcache_line_size();
- const volatile void *addr = (void *)(start_addr ~(lsize - 1));
- const volatile void *aend = (void *)((stop - 1) ~(lsize - 1));
-
- while (1) {
- mips_cache(HIT_INVALIDATE_D, addr);
- if (addr == aend)
- break;
- addr += lsize;
- }
-}
-
void write_one_tlb(int index, u32 pagemask, u32 hi, u32 low0, u32 low1)
{
write_c0_entrylo0(low0);
diff --git a/arch/mips/cpu/mips64/cpu.c b/arch/mips/cpu/mips64/cpu.c
index 9f45cfc..1d32705 100644
--- a/arch/mips/cpu/mips64/cpu.c
+++ b/arch/mips/cpu/mips64/cpu.c
@@ -9,19 +9,8 @@
#include command.h
#include netdev.h
#include asm/mipsregs.h
-#include asm/cacheops.h
#include asm/reboot.h
-#define cache_op(op, addr) \
- __asm__ __volatile__( \
- .setpush\n \
- .setnoreorder\n\
- .setmips64\n \
- cache %0, %1\n
Re: [U-Boot] usb flash boot on am335x machines
Date: Mon, 26 Jan 2015 08:35:51 +0200 From: matti kaasinen matti.kaasi...@gmail.com To: u-boot@lists.denx.de u-boot@lists.denx.de Subject: [U-Boot] usb flash boot on am335x machines Message-ID: cadnuhn33oo-vguofkoq0-7r0dztaohboocrx2qzsa9lt1sv...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi! I have tried to find solution to get am335x based Silica/Pengwyn board booting from usb flash. U-boot on that board is based on u-boot 2013.10. I flashed it with similar configuration as mmc flash, but I did not find combination of configuration variables to get proper spl code generated. I studied codes and it seemed like am33x devices were left out from usb spl generation parts. Is there some kind of fundamental reason to prevent am335x devices not to boot from usb flash. If not, would anyone know the configuration combination for this set-up. If you read the TRM carefully (26.1.8.6 USB Boot Procedure), you'll find out that the 335x doesn't support usb flash drive boot at the hardware level. The USB boot option that is available creates a RNDIS ip connection with a computer and then it does a network boot. I'll agree that this wasn't what I was expecting when I saw USB boot. The only way to support a USB flash boot would be if the SPL was loaded some other means (NOR, NAND, MMC, etc) and it mounted the flash drive and booted from it. In fact, I found more than three years old patch that seems to make usb boot set-up for am335x devices: https://gitorious.org/rowboat/u-boot/commit/aaa9d5c083252218fd89afa68161f96bb7daa04c However, it seems that these changed have somehow not been included in the mainline codes. Is there specific reason for this? Sorry if this doesn't correctly link to original post. I'm unsure how I'm supposed to reply to an email in a mailing list digest. -- Jonathan Cormier CriticalLink ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000.c: fix compile warning under 64bit mode
On 01/21/2015 11:21 PM, Minghuan Lian wrote:
Fix this:
warning: cast from pointer to integer of different size
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
drivers/net/e1000.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 6531030..cd44222 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4927,22 +4927,23 @@ void
fill_rx(struct e1000_hw *hw)
{
struct e1000_rx_desc *rd;
- uint32_t flush_start, flush_end;
+ unsigned long flush_start, flush_end;
rx_last = rx_tail;
rd = rx_base + rx_tail;
rx_tail = (rx_tail + 1) % 8;
memset(rd, 0, 16);
- rd-buffer_addr = cpu_to_le64((u32)packet);
+ rd-buffer_addr = cpu_to_le64((unsigned long)packet);
/*
* Make sure there are no stale data in WB over this area, which
* might get written into the memory while the e1000 also writes
* into the same memory area.
*/
- invalidate_dcache_range((u32)packet, (u32)packet + 4096);
+ invalidate_dcache_range((unsigned long)packet,
+ (unsigned long)packet + 4096);
/* Dump the DMA descriptor into RAM. */
- flush_start = ((u32)rd) ~(ARCH_DMA_MINALIGN - 1);
+ flush_start = ((unsigned long)rd) ~(ARCH_DMA_MINALIGN - 1);
flush_end = flush_start + roundup(sizeof(*rd), ARCH_DMA_MINALIGN);
flush_dcache_range(flush_start, flush_end);
@@ -4963,7 +4964,7 @@ e1000_configure_tx(struct e1000_hw *hw)
unsigned long tipg, tarc;
uint32_t ipgr1, ipgr2;
- E1000_WRITE_REG(hw, TDBAL, (u32) tx_base);
+ E1000_WRITE_REG(hw, TDBAL, (unsigned long)tx_base);
E1000_WRITE_REG(hw, TDBAH, 0);
E1000_WRITE_REG(hw, TDLEN, 128);
@@ -5107,7 +5108,7 @@ e1000_configure_rx(struct e1000_hw *hw)
E1000_WRITE_FLUSH(hw);
}
/* Setup the Base and Length of the Rx Descriptor Ring */
- E1000_WRITE_REG(hw, RDBAL, (u32) rx_base);
+ E1000_WRITE_REG(hw, RDBAL, (unsigned long)rx_base);
E1000_WRITE_REG(hw, RDBAH, 0);
E1000_WRITE_REG(hw, RDLEN, 128);
@@ -5138,14 +5139,14 @@ e1000_poll(struct eth_device *nic)
{
struct e1000_hw *hw = nic-priv;
struct e1000_rx_desc *rd;
- uint32_t inval_start, inval_end;
+ unsigned long inval_start, inval_end;
uint32_t len;
/* return true if there's an ethernet packet ready to read */
rd = rx_base + rx_last;
/* Re-load the descriptor from RAM. */
- inval_start = ((u32)rd) ~(ARCH_DMA_MINALIGN - 1);
+ inval_start = ((unsigned long)rd) ~(ARCH_DMA_MINALIGN - 1);
inval_end = inval_start + roundup(sizeof(*rd), ARCH_DMA_MINALIGN);
invalidate_dcache_range(inval_start, inval_end);
@@ -5154,8 +5155,9 @@ e1000_poll(struct eth_device *nic)
/*DEBUGOUT(recv: packet len=%d \n, rd-length); */
/* Packet received, make sure the data are re-loaded from RAM. */
len = le32_to_cpu(rd-length);
- invalidate_dcache_range((u32)packet,
- (u32)packet + roundup(len, ARCH_DMA_MINALIGN));
+ invalidate_dcache_range((unsigned long)packet,
+ (unsigned long)packet +
+ roundup(len, ARCH_DMA_MINALIGN));
NetReceive((uchar *)packet, len);
fill_rx(hw);
return 1;
@@ -5170,7 +5172,7 @@ static int e1000_transmit(struct eth_device *nic, void
*txpacket, int length)
struct e1000_hw *hw = nic-priv;
struct e1000_tx_desc *txp;
int i = 0;
- uint32_t flush_start, flush_end;
+ unsigned long flush_start, flush_end;
txp = tx_base + tx_tail;
tx_tail = (tx_tail + 1) % 8;
@@ -5180,10 +5182,11 @@ static int e1000_transmit(struct eth_device *nic,
void *txpacket, int length)
txp-upper.data = 0;
/* Dump the packet into RAM so e1000 can pick them. */
- flush_dcache_range((u32)nv_packet,
-(u32)nv_packet + roundup(length, ARCH_DMA_MINALIGN));
+ flush_dcache_range((unsigned long)nv_packet,
+(unsigned long)nv_packet +
+roundup(length, ARCH_DMA_MINALIGN));
/* Dump the descriptor into RAM as well. */
- flush_start = ((u32)txp) ~(ARCH_DMA_MINALIGN - 1);
+ flush_start = ((unsigned long)txp) ~(ARCH_DMA_MINALIGN - 1);
flush_end = flush_start + roundup(sizeof(*txp), ARCH_DMA_MINALIGN);
flush_dcache_range(flush_start, flush_end);
Please consider phys_addr_t and phys_size_t.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] powerpc: ppc4xx: Add missing type for SYS_MALLOC_F_LEN in Kconfig
Hi Stefan, On 26 January 2015 at 06:35, Stefan Roese s...@denx.de wrote: Otherwise this symbol will not be created in the .config. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- board/amcc/canyonlands/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index bfdf17a..97df3f8 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -36,6 +36,7 @@ config DM_SERIAL default y config SYS_MALLOC_F_LEN + hex Size of the malloc() pool for use before relocation. default 0x400 config DEBUG_UART_BASE Reviewed-by: Simon Glass s...@chromium.org I need to respin the series that added this option, so that this patch isn't needed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] powerpc: ppc4xx: Change from OF_SEPARATE to OF_EMBED
On 26 January 2015 at 06:35, Stefan Roese s...@denx.de wrote: This is necessary, as ppc4xx has the reset vector located at the end of the U-Boot image. This needs to be flashed to the end of the NOR flash. Adding the dtb to the main U-Boot image will break booting on ppc4xx. This patch now embeds the dtb in the U-Boot image instead. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- configs/canyonlands_defconfig | 2 +- configs/glacier_defconfig | 2 +- configs/glacier_ramboot_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add Linksprite_pcDuino3_Nano board / defconfig
Hi Hans, On 26 January 2015 at 00:44, Hans de Goede hdego...@redhat.com wrote: Hi, On 26-01-15 04:30, Simon Glass wrote: Hi Adam, On 25 January 2015 at 08:24, Adam Sampson a...@offog.org wrote: This is a low-cost Allwinner A20 board with Arduino-style GPIO headers; it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro USB socket for OTG and another for power in, HDMI, SATA, 5V power for SATA devices, gigabit Ethernet, an IR receiver, 3.5mm audio out and a MIPI camera connector. For more details, see: http://linux-sunxi.org/LinkSprite_pcDuino3_Nano Signed-off-by: Adam Sampson a...@offog.org --- board/sunxi/MAINTAINERS|5 + configs/Linksprite_pcDuino3_Nano_defconfig | 11 +++ 2 files changed, 16 insertions(+) create mode 100644 configs/Linksprite_pcDuino3_Nano_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 743e7f5..479d147 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -100,3 +100,8 @@ MELE M5 BOARD M: Ian Campbell i...@hellion.org.uk S: Maintained F: configs/Mele_M5_defconfig + +LINKSPRITE-PCDUINO3-NANO BOARD +M: Adam Sampson a...@offog.org +S: Maintained +F: configs/Linksprite_pcDuino3_Nano_defconfig diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig b/configs/Linksprite_pcDuino3_Nano_defconfig new file mode 100644 index 000..22435eb --- /dev/null +++ b/configs/Linksprite_pcDuino3_Nano_defconfig @@ -0,0 +1,11 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI +CONFIG_FDTFILE=sun7i-a20-pcduino3-nano.dtb +CONFIG_USB1_VBUS_PIN=PH11 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_TARGET_PCDUINO3_NANO=y ++S:CONFIG_DRAM_CLK=408 ++S:CONFIG_DRAM_ZQ=122 ++S:CONFIG_DRAM_EMR1=4 Since this is a new board, could it follow along ith the Linksprice pcDuino3 and support driver rmodel / device tree? That is a good idea, I think we should be slowly moving over all sunxi boards to this. Note I'll merge this version as is for now, lets wait with the devicetree version till the dts is accepted in the upstream kernel (*). While on this subject I do want to move to devicetree everywhere, but I don't want 2 configs per board like with the Linksprite_pcDuino3 from an end user pov the resulting u-boot-sunxi-with-spl.bin works identical, and that is what we tell sunxi users to use. So my plan is to just drop the non fdt version of the Linksprite_pcDuino3 config and drop the _fdt suffix on the fdt version, any objections against that ? Fair enough, it was just an example... Regards, Hans *) Once we've gone all devicetree we need to revisit this as I don't want new board additions be blocked on this Yes and often U-Boot will have support before Linux. One option is to merge an initial FDT and resync with Linux later. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] MIPS: allow systems to skip loads during cache init
Current MIPS systems do not require that loads be performed to force the parity of cache lines, a simple invalidate by clearing the tag for each line will suffice. Thus this patch makes the loads subsequent second invalidation conditional upon the CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD option, and defines that for existing mips32 targets. Exceptions are malta where this is known to be unnecessary, and qemu-mips where caches are not implemented. Signed-off-by: Paul Burton paul.bur...@imgtec.com Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/Kconfig | 6 ++ arch/mips/lib/cache_init.S | 19 +-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index ef78929..bc4283d 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -36,6 +36,7 @@ config TARGET_VCT select SUPPORTS_BIG_ENDIAN select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 + select SYS_MIPS_CACHE_INIT_RAM_LOAD config TARGET_DBAU1X00 bool Support dbau1x00 @@ -43,12 +44,14 @@ config TARGET_DBAU1X00 select SUPPORTS_LITTLE_ENDIAN select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 + select SYS_MIPS_CACHE_INIT_RAM_LOAD config TARGET_PB1X00 bool Support pb1x00 select SUPPORTS_LITTLE_ENDIAN select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 + select SYS_MIPS_CACHE_INIT_RAM_LOAD endchoice @@ -185,6 +188,9 @@ config 64BIT config SWAP_IO_SPACE bool +config SYS_MIPS_CACHE_INIT_RAM_LOAD + bool + endif endmenu diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index cbd04bd..04a36b2 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -113,6 +113,8 @@ LEAF(mips_cache_reset) l1_info t3, t9, MIPS_CONF1_DA_SHIFT #endif +#ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD + /* Determine the largest L1 cache size */ #if defined(CONFIG_SYS_ICACHE_SIZE) defined(CONFIG_SYS_DCACHE_SIZE) #if CONFIG_SYS_ICACHE_SIZE CONFIG_SYS_DCACHE_SIZE @@ -134,14 +136,15 @@ LEAF(mips_cache_reset) f_fill64a0, -64, zero bne a0, a1, 2b - /* -* The caches are probably in an indeterminate state, -* so we force good parity into them by doing an -* invalidate, load/fill, invalidate for each line. -*/ +#endif /* CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD */ /* -* Assume bottom of RAM will generate good parity for the cache. +* The caches are probably in an indeterminate state, so we force good +* parity into them by doing an invalidate for each line. If +* CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD is set then we'll proceed to +* perform a load/fill a further invalidate for each line, assuming +* that the bottom of RAM (having just been cleared) will generate good +* parity for the cache. */ /* @@ -153,12 +156,14 @@ LEAF(mips_cache_reset) PTR_ADDUt1, t0, t2 /* clear tag to invalidate */ cache_loop t0, t1, t8, INDEX_STORE_TAG_I +#ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD /* fill once, so data field parity is correct */ PTR_LI t0, INDEX_BASE cache_loop t0, t1, t8, FILL /* invalidate again - prudent but not strictly neccessary */ PTR_LI t0, INDEX_BASE cache_loop t0, t1, t8, INDEX_STORE_TAG_I +#endif /* * then initialize D-cache. @@ -169,6 +174,7 @@ LEAF(mips_cache_reset) PTR_ADDUt1, t0, t3 /* clear all tags */ cache_loop t0, t1, t9, INDEX_STORE_TAG_D +#ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD /* load from each line (in cached space) */ PTR_LI t0, INDEX_BASE 2: LONG_L zero, 0(t0) @@ -177,6 +183,7 @@ LEAF(mips_cache_reset) /* clear all tags */ PTR_LI t0, INDEX_BASE cache_loop t0, t1, t9, INDEX_STORE_TAG_D +#endif 3: jr ra END(mips_cache_reset) -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] exynos: enable dm i2c
Hello Simon, On 01/26/2015 04:21 PM, Przemyslaw Marczak wrote: This patchset adds support to driver model i2c api for Exynos i2c driver. Few boards are using this driver, but the board peripherals are not ported to the new api yet. So the CONFIG_DM_I2C_COMPAT is enabled. Switch to dm i2c is currentlly not possible for the few devices like Trats2, Universal C210, S5P Goni, because ir require soft i2c support. For Odroid U3, the compatiblility layer is enabled, because it uses only one pmic driver, which soon is going to be moved to dm i2c with the dm pmic framework. The i2c dm compatibility layer is also enabled for Exynos5 boards, which should be removed after moving the i2c drivers to driver model. Commits with the test code, from the previous patch set, are removed. Przemyslaw Marczak (10): arndale: config: disable max77686 support exynos5250: config: disable max77686 driver smdk5250: config: enable max77686 driver support exynos4: dts: add missing i2c properties arndale: dts: add missing i2c aliases exynos5: pinmux: check flag for i2c config dm: i2c: s3c24x0: adjust to dm-i2c api odroid u3: dts: add missing i2c aliases odroid u3: enable dm i2c support exynos5: enable dm i2c arch/arm/cpu/armv7/exynos/pinmux.c | 27 ++-- arch/arm/dts/exynos4.dtsi | 24 ++-- arch/arm/dts/exynos4412-odroid.dts | 7 + arch/arm/dts/exynos5250-arndale.dts | 8 ++ board/samsung/odroid/odroid.c | 14 +- drivers/i2c/s3c24x0_i2c.c | 275 ++-- include/configs/arndale.h | 2 - include/configs/exynos5-common.h| 7 +- include/configs/exynos5250-common.h | 3 - include/configs/odroid.h| 5 +- include/configs/smdk5250.h | 2 + 11 files changed, 291 insertions(+), 83 deletions(-) The patchset is rebased on the top of the u-boot-dm/master, and is available also on github: https://github.com/bobenstein/u-boot/tree/dm-i2c-exynos_v2 Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] gpt: fix error reporting on partition table write failures
The gpt command always reports success even if writing the partition table failed. Propagate the return value of gpt_restore so we get proper status reported. Signed-off-by: Rob Herring r...@kernel.org --- common/cmd_gpt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c index e38422d..75df3fe 100644 --- a/common/cmd_gpt.c +++ b/common/cmd_gpt.c @@ -281,11 +281,11 @@ static int gpt_default(block_dev_desc_t *blk_dev_desc, const char *str_part) } /* save partitions layout to disk */ - gpt_restore(blk_dev_desc, str_disk_guid, partitions, part_count); + ret = gpt_restore(blk_dev_desc, str_disk_guid, partitions, part_count); free(str_disk_guid); free(partitions); - return 0; + return ret; } /** -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: ppc4xx: Enable CONFIG_DISPLAY_BOARDINFO
On 26 January 2015 at 06:35, Stefan Roese s...@denx.de wrote: This also displays the Board: line in the bootup text with the generic board support code. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- board/amcc/canyonlands/Kconfig | 4 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass s...@chromium.org Is there another patch which adds this in the top level Kconfig? - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] powerpc: ppc4xx: Add defaults for DT based booting to really work
On 26 January 2015 at 06:35, Stefan Roese s...@denx.de wrote: These additional nodes need to be provided to get U-Boot to boot correctly on the Canyonlands / Glacier board: - chosen path to the console-uart - reg-shift set to 0 in the uart device nodes Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- arch/powerpc/dts/canyonlands.dts | 6 ++ arch/powerpc/dts/glacier.dts | 3 +++ 2 files changed, 9 insertions(+) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 00/10] exynos: enable dm i2c
This patchset adds support to driver model i2c api for Exynos i2c driver. Few boards are using this driver, but the board peripherals are not ported to the new api yet. So the CONFIG_DM_I2C_COMPAT is enabled. Switch to dm i2c is currentlly not possible for the few devices like Trats2, Universal C210, S5P Goni, because ir require soft i2c support. For Odroid U3, the compatiblility layer is enabled, because it uses only one pmic driver, which soon is going to be moved to dm i2c with the dm pmic framework. The i2c dm compatibility layer is also enabled for Exynos5 boards, which should be removed after moving the i2c drivers to driver model. Commits with the test code, from the previous patch set, are removed. Przemyslaw Marczak (10): arndale: config: disable max77686 support exynos5250: config: disable max77686 driver smdk5250: config: enable max77686 driver support exynos4: dts: add missing i2c properties arndale: dts: add missing i2c aliases exynos5: pinmux: check flag for i2c config dm: i2c: s3c24x0: adjust to dm-i2c api odroid u3: dts: add missing i2c aliases odroid u3: enable dm i2c support exynos5: enable dm i2c arch/arm/cpu/armv7/exynos/pinmux.c | 27 ++-- arch/arm/dts/exynos4.dtsi | 24 ++-- arch/arm/dts/exynos4412-odroid.dts | 7 + arch/arm/dts/exynos5250-arndale.dts | 8 ++ board/samsung/odroid/odroid.c | 14 +- drivers/i2c/s3c24x0_i2c.c | 275 ++-- include/configs/arndale.h | 2 - include/configs/exynos5-common.h| 7 +- include/configs/exynos5250-common.h | 3 - include/configs/odroid.h| 5 +- include/configs/smdk5250.h | 2 + 11 files changed, 291 insertions(+), 83 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/10] exynos5250: config: disable max77686 driver
This PMIC is not common for all Exynos5250 based boards, so should be romoved from common config. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/exynos5250-common.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/configs/exynos5250-common.h b/include/configs/exynos5250-common.h index 6714313..ae0e5ff 100644 --- a/include/configs/exynos5250-common.h +++ b/include/configs/exynos5250-common.h @@ -28,9 +28,6 @@ #define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK -/* PMIC */ -#define CONFIG_POWER_MAX77686 - /* Sound */ #define CONFIG_CMD_SOUND #ifdef CONFIG_CMD_SOUND -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/10] arndale: config: disable max77686 support
There is no MAX77686 pmic on this board, so the driver support should be removed. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/arndale.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index d68993b..3ad4a9b 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -51,8 +51,6 @@ /* PMIC */ #define CONFIG_PMIC #define CONFIG_POWER_I2C -#define CONFIG_POWER_MAX77686 - #define CONFIG_PREBOOT -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 05/10] arndale: dts: add missing i2c aliases
Without this alias setting, the seq numbers
of the i2c devices are wrong.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
---
arch/arm/dts/exynos5250-arndale.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/exynos5250-arndale.dts
b/arch/arm/dts/exynos5250-arndale.dts
index 202f2ea..21c0a21 100644
--- a/arch/arm/dts/exynos5250-arndale.dts
+++ b/arch/arm/dts/exynos5250-arndale.dts
@@ -15,6 +15,14 @@
compatible = samsung,arndale, samsung,exynos5250;
aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
serial0 = /serial@12C2;
console = /serial@12C2;
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 06/10] exynos5: pinmux: check flag for i2c config
Some versions of Exynos5 supports High-Speed I2C,
on few interfaces, this change allows support this.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Akshay Saraswat aksha...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
arch/arm/cpu/armv7/exynos/pinmux.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 94d0297..b2c5494 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -266,22 +266,33 @@ static void exynos5_sromc_config(int flags)
static void exynos5_i2c_config(int peripheral, int flags)
{
+ int func01, func23;
+
+/* flags only for High-Speed I2C */
+ if (flags) {
+ func01 = 4;
+ func23 = 4;
+ } else {
+ func01 = 2;
+ func23 = 3;
+ }
+
switch (peripheral) {
case PERIPH_ID_I2C0:
- gpio_cfg_pin(EXYNOS5_GPIO_B30, S5P_GPIO_FUNC(0x2));
- gpio_cfg_pin(EXYNOS5_GPIO_B31, S5P_GPIO_FUNC(0x2));
+ gpio_cfg_pin(EXYNOS5_GPIO_B30, S5P_GPIO_FUNC(func01));
+ gpio_cfg_pin(EXYNOS5_GPIO_B31, S5P_GPIO_FUNC(func01));
break;
case PERIPH_ID_I2C1:
- gpio_cfg_pin(EXYNOS5_GPIO_B32, S5P_GPIO_FUNC(0x2));
- gpio_cfg_pin(EXYNOS5_GPIO_B33, S5P_GPIO_FUNC(0x2));
+ gpio_cfg_pin(EXYNOS5_GPIO_B32, S5P_GPIO_FUNC(func01));
+ gpio_cfg_pin(EXYNOS5_GPIO_B33, S5P_GPIO_FUNC(func01));
break;
case PERIPH_ID_I2C2:
- gpio_cfg_pin(EXYNOS5_GPIO_A06, S5P_GPIO_FUNC(0x3));
- gpio_cfg_pin(EXYNOS5_GPIO_A07, S5P_GPIO_FUNC(0x3));
+ gpio_cfg_pin(EXYNOS5_GPIO_A06, S5P_GPIO_FUNC(func23));
+ gpio_cfg_pin(EXYNOS5_GPIO_A07, S5P_GPIO_FUNC(func23));
break;
case PERIPH_ID_I2C3:
- gpio_cfg_pin(EXYNOS5_GPIO_A12, S5P_GPIO_FUNC(0x3));
- gpio_cfg_pin(EXYNOS5_GPIO_A13, S5P_GPIO_FUNC(0x3));
+ gpio_cfg_pin(EXYNOS5_GPIO_A12, S5P_GPIO_FUNC(func23));
+ gpio_cfg_pin(EXYNOS5_GPIO_A13, S5P_GPIO_FUNC(func23));
break;
case PERIPH_ID_I2C4:
gpio_cfg_pin(EXYNOS5_GPIO_A20, S5P_GPIO_FUNC(0x3));
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq SoC changes
On 23 Jan 2015, mon...@monstr.eu wrote: On 01/23/2015 02:05 AM, Tom Rini wrote: I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. I think you can add something like, .fpu neon-vfpv4 # or whatever FPU is appropriate. to the lowlevel_init.S and then you can use the 'fmxr' instruction even without compiler flags (and of course gas needs to know about it). It makes sense if the platform turns on floating point by default and you need to disable it in lowlevel_init.S and don't want anyone else to be using floating point. ... but I am not sure what exactly is going on so maybe it is not a good fit here? Fwiw, Bill Pringlemeir. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/10] dm: i2c: s3c24x0: adjust to dm-i2c api
This commit adjusts the s3c24x0 driver to new i2c api
based on driver-model. The driver supports standard
and high-speed i2c as previous.
Tested on Trats2, Odroid U3, Arndale, Odroid XU3
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Heiko Schocher h...@denx.de
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes v2:
- use consistent return values on errors
- decrease transaction status timeout, because the previous one was too big
---
drivers/i2c/s3c24x0_i2c.c | 275 +++---
1 file changed, 233 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index fd328f0..c82640d 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -9,8 +9,9 @@
* as they seem to have the same I2C controller inside.
* The different address mapping is handled by the s3c24xx.h files below.
*/
-
#include common.h
+#include errno.h
+#include dm.h
#include fdtdec.h
#if (defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
#include asm/arch/clk.h
@@ -111,9 +112,9 @@
#define I2C_START_STOP 0x20/* START / STOP */
#define I2C_TXRX_ENA 0x10/* I2C Tx/Rx enable */
-#define I2C_TIMEOUT_MS 1000/* 1 second */
+#define I2C_TIMEOUT_MS 10 /* 10 ms */
-#defineHSI2C_TIMEOUT_US 10 /* 100 ms, finer granularity */
+#defineHSI2C_TIMEOUT_US 1 /* 10 ms, finer granularity */
/* To support VCMA9 boards and other who dont define max_i2c_num */
@@ -121,13 +122,23 @@
#define CONFIG_MAX_I2C_NUM 1
#endif
+DECLARE_GLOBAL_DATA_PTR;
+
/*
* For SPL boot some boards need i2c before SDRAM is initialised so force
* variables to live in SRAM
*/
+#ifdef CONFIG_SYS_I2C
static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(.data)));
+#endif
+
+enum exynos_i2c_type {
+ EXYNOS_I2C_STD,
+ EXYNOS_I2C_HS,
+};
+#ifdef CONFIG_SYS_I2C
/**
* Get a pointer to the given bus index
*
@@ -147,6 +158,7 @@ static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
debug(Undefined bus: %d\n, bus_idx);
return NULL;
}
+#endif
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
static int GetI2CSDA(void)
@@ -251,6 +263,7 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
writel(readl(i2c-iiccon) ~I2CCON_IRPND, i2c-iiccon);
}
+#ifdef CONFIG_SYS_I2C
static struct s3c24x0_i2c *get_base_i2c(int bus)
{
#ifdef CONFIG_EXYNOS4
@@ -267,6 +280,7 @@ static struct s3c24x0_i2c *get_base_i2c(int bus)
return s3c24x0_get_base_i2c();
#endif
}
+#endif
static void i2c_ch_init(struct s3c24x0_i2c *i2c, int speed, int slaveadd)
{
@@ -326,7 +340,7 @@ static int hsi2c_get_clk_details(struct s3c24x0_i2c_bus
*i2c_bus)
return 0;
}
}
- return -1;
+ return -EINVAL;
}
static void hsi2c_ch_init(struct s3c24x0_i2c_bus *i2c_bus)
@@ -398,18 +412,20 @@ static void exynos5_i2c_reset(struct s3c24x0_i2c_bus
*i2c_bus)
hsi2c_ch_init(i2c_bus);
}
+#ifdef CONFIG_SYS_I2C
static void s3c24x0_i2c_init(struct i2c_adapter *adap, int speed, int slaveadd)
{
struct s3c24x0_i2c *i2c;
struct s3c24x0_i2c_bus *bus;
-
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
#endif
ulong start_time = get_timer(0);
- /* By default i2c channel 0 is the current bus */
i2c = get_base_i2c(adap-hwadapnr);
+ bus = i2c_bus[adap-hwadapnr];
+ if (!bus)
+ return;
/*
* In case the previous transfer is still going, wait to give it a
@@ -470,12 +486,13 @@ static void s3c24x0_i2c_init(struct i2c_adapter *adap,
int speed, int slaveadd)
#endif
}
#endif /* #if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5) */
+
i2c_ch_init(i2c, speed, slaveadd);
- bus = i2c_bus[adap-hwadapnr];
bus-active = true;
bus-regs = i2c;
}
+#endif /* CONFIG_SYS_I2C */
/*
* Poll the appropriate bit of the fifo status register until the interface is
@@ -698,40 +715,40 @@ static int hsi2c_read(struct exynos5_hsi2c *i2c,
return rv;
}
+#ifdef CONFIG_SYS_I2C
static unsigned int s3c24x0_i2c_set_bus_speed(struct i2c_adapter *adap,
- unsigned int speed)
+ unsigned int speed)
+#else
+static int s3c24x0_i2c_set_bus_speed(struct udevice *dev, unsigned int speed)
+#endif
{
struct s3c24x0_i2c_bus *i2c_bus;
+#ifdef CONFIG_SYS_I2C
i2c_bus = get_bus(adap-hwadapnr);
+#else
+ if (!dev)
+ return -ENODEV;
+
+ i2c_bus = dev_get_priv(dev);
+#endif
if (!i2c_bus)
- return -1;
+ return -EFAULT;
i2c_bus-clock_frequency = speed;
if (i2c_bus-is_highspeed) {
if
[U-Boot] [PATCH v2 10/10] exynos5: enable dm i2c
This patch enables CONFIG_DM_I2C and also CONFIG_DM_I2C_COMPAT. The last one should be removed when all the i2c peripheral drivers will use dm i2c framework. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Akshay Saraswat aksha...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Simon Glass s...@chromium.org --- Changes v2: - new patch --- include/configs/exynos5-common.h | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index ad63f3c..0ba39a2 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -126,12 +126,11 @@ #define SPI_FLASH_UBOOT_POS(CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE) /* I2C */ -#define CONFIG_SYS_I2C_INIT_BOARD -#define CONFIG_SYS_I2C +#define CONFIG_DM_I2C +#define CONFIG_DM_I2C_COMPAT #define CONFIG_CMD_I2C -#define CONFIG_SYS_I2C_S3C24X0_SPEED 10 /* 100 Kbps */ #define CONFIG_SYS_I2C_S3C24X0 -#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_I2C_S3C24X0_SPEED 10 /* 100 Kbps */ #define CONFIG_SYS_I2C_S3C24X0_SLAVE0x0 #define CONFIG_I2C_EDID -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/10] odroid u3: dts: add missing i2c aliases
This change fixes i2c bus numbering for Odroid U3.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes v2:
- new patch
---
arch/arm/dts/exynos4412-odroid.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 29ad6ab..00a2917 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -16,6 +16,13 @@
aliases {
i2c0 = /i2c@1386;
+ i2c1 = /i2c@1387;
+ i2c2 = /i2c@1388;
+ i2c3 = /i2c@1389;
+ i2c4 = /i2c@138a;
+ i2c5 = /i2c@138b;
+ i2c6 = /i2c@138c;
+ i2c7 = /i2c@138d;
serial0 = /serial@1380;
console = /serial@1381;
mmc2 = sdhci@1253;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 03/10] smdk5250: config: enable max77686 driver support
This commit enable support for the above driver, which was disabled in common config. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/smdk5250.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 8395372..3b06d30 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -18,6 +18,8 @@ #include configs/exynos5250-common.h +/* PMIC */ +#define CONFIG_POWER_MAX77686 #define CONFIG_BOARD_COMMON #define CONFIG_ARCH_EARLY_INIT_R -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 09/10] odroid u3: enable dm i2c support
This patch enables CONFIG_DM_I2C and also CONFIG_DM_I2C_COMPAT.
The last one should be removed when the dm pmic framework will
be finished.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes v2:
- new patch
---
board/samsung/odroid/odroid.c | 14 +-
include/configs/odroid.h | 5 ++---
2 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index b7d2381..e3517f2 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -415,15 +415,6 @@ static int pmic_init_max77686(void)
return 0;
}
-#ifdef CONFIG_SYS_I2C_INIT_BOARD
-static void board_init_i2c(void)
-{
- /* I2C_0 */
- if (exynos_pinmux_config(PERIPH_ID_I2C0, PINMUX_FLAG_NONE))
- debug(I2C%d not configured\n, (I2C_0));
-}
-#endif
-
int exynos_early_init_f(void)
{
board_clock_init();
@@ -444,10 +435,7 @@ int exynos_init(void)
int exynos_power_init(void)
{
-#ifdef CONFIG_SYS_I2C_INIT_BOARD
- board_init_i2c();
-#endif
- pmic_init(I2C_0);
+ pmic_init(0);
pmic_init_max77686();
return 0;
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 807e96b..9d5dbdc 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -177,12 +177,11 @@
/* I2C */
#define CONFIG_CMD_I2C
-#define CONFIG_SYS_I2C
+#define CONFIG_DM_I2C
+#define CONFIG_DM_I2C_COMPAT
#define CONFIG_SYS_I2C_S3C24X0
#define CONFIG_SYS_I2C_S3C24X0_SPEED 10
#define CONFIG_SYS_I2C_S3C24X0_SLAVE 0
-#define CONFIG_MAX_I2C_NUM 8
-#define CONFIG_SYS_I2C_INIT_BOARD
/* POWER */
#define CONFIG_POWER
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/10] exynos4: dts: add missing i2c properties
This patch modify i2c nodes in exynos4.dtsi with:
- adding proper interrupts arrays for each i2c node,
which allows to decode periph id
- add reg address for each i2c node for i2c driver internal use
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
arch/arm/dts/exynos4.dtsi | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/exynos4.dtsi b/arch/arm/dts/exynos4.dtsi
index 3c983ed..7de227c 100644
--- a/arch/arm/dts/exynos4.dtsi
+++ b/arch/arm/dts/exynos4.dtsi
@@ -51,56 +51,64 @@
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 0 0 0;
+ reg = 0x1386 0x100;
+ interrupts = 0 56 0;
};
i2c@1387 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 1 1 0;
+ reg = 0x1387 0x100;
+ interrupts = 1 57 0;
};
i2c@1388 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 2 2 0;
+ reg = 0x1388 0x100;
+ interrupts = 2 58 0;
};
i2c@1389 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 3 3 0;
+ reg = 0x1389 0x100;
+ interrupts = 3 59 0;
};
i2c@138a {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 4 4 0;
+ reg = 0x138a 0x100;
+ interrupts = 4 60 0;
};
i2c@138b {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 5 5 0;
+ reg = 0x138b 0x100;
+ interrupts = 5 61 0;
};
i2c@138c {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 6 6 0;
+ reg = 0x138c 0x100;
+ interrupts = 6 62 0;
};
i2c@138d {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
- interrupts = 7 7 0;
+ reg = 0x138d 0x100;
+ interrupts = 7 63 0;
};
sdhci@1251 {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Export redesign
Hi Wolfgang, On 26 January 2015 at 07:45, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message 1422279795-3052-1-git-send-email-...@chromium.org you wrote: From: Martin Dorwig dor...@tetronik.com this is an atempt to make the export of functions typesafe. I replaced the jumptable void ** by a struct (jt_funcs) with function pointers. The EXPORT_FUNC macro now has 3 fixed parameters and one variadic parameter The first is the name of the exported function, the rest of the parameters are used to format a functionpointer in the jumptable, the EXPORT_FUNC macros are expanded three times, 1. to declare the members of the struct 2. to initialize the structmember pointers 3. to call the functions in stubs.c Signed-off-by: Martin Dorwig dor...@tetronik.com Acked-by: Simon Glass s...@chromium.org Signed-off-by: Simon Glass s...@chromium.org (resending to the list since my tweaks are not quite trivial) Is this a 100% binary compatible change? If not, should we not also increment XF_VERSION ? If a board has move to driver model and doesn't use CONFIG_DM_I2C_COMPAT (and this should ideally not be used) then the I2C functions are not present. I tested the compatibility to a basic degree. Perhaps we should increment it anyway, given it is such a major code change? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] gpt: support random UUIDs without setting environment variables
Currently, an environment variable must be used to store the randomly
generated UUID for each partition. This is not necessary, so make storing
the UUID optional. Now passing uuid_disk and uuid are optional when random
UUIDs are enabled.
Signed-off-by: Rob Herring r...@kernel.org
---
common/cmd_gpt.c | 48 ++--
doc/README.gpt | 8 +---
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
index 75df3fe..c56fe15 100644
--- a/common/cmd_gpt.c
+++ b/common/cmd_gpt.c
@@ -154,17 +154,24 @@ static int set_gpt_info(block_dev_desc_t *dev_desc,
/* extract disk guid */
s = str;
- tok = strsep(s, ;);
- val = extract_val(tok, uuid_disk);
+ val = extract_val(str, uuid_disk);
if (!val) {
+#ifdef CONFIG_RANDOM_UUID
+ *str_disk_guid = malloc(UUID_STR_LEN + 1);
+ gen_rand_uuid_str(*str_disk_guid, UUID_STR_FORMAT_STD);
+#else
free(str);
return -2;
+#endif
+ } else {
+ val = strsep(val, ;);
+ if (extract_env(val, p))
+ p = val;
+ *str_disk_guid = strdup(p);
+ free(val);
+ /* Move s to first partition */
+ strsep(s, ;);
}
- if (extract_env(val, p))
- p = val;
- *str_disk_guid = strdup(p);
- free(val);
-
if (strlen(s) == 0)
return -3;
@@ -192,20 +199,25 @@ static int set_gpt_info(block_dev_desc_t *dev_desc,
/* uuid */
val = extract_val(tok, uuid);
- if (!val) { /* 'uuid' is mandatory */
- errno = -4;
- goto err;
- }
- if (extract_env(val, p))
- p = val;
- if (strlen(p) = sizeof(parts[i].uuid)) {
- printf(Wrong uuid format for partition %d\n, i);
+ if (!val) {
+ /* 'uuid' is optional if random uuid's are enabled */
+#ifdef CONFIG_RANDOM_UUID
+ gen_rand_uuid_str(parts[i].uuid, UUID_STR_FORMAT_STD);
+#else
errno = -4;
goto err;
+#endif
+ } else {
+ if (extract_env(val, p))
+ p = val;
+ if (strlen(p) = sizeof(parts[i].uuid)) {
+ printf(Wrong uuid format for partition %d\n,
i);
+ errno = -4;
+ goto err;
+ }
+ strcpy((char *)parts[i].uuid, p);
+ free(val);
}
- strcpy((char *)parts[i].uuid, p);
- free(val);
-
/* name */
val = extract_val(tok, name);
if (!val) { /* name is mandatory */
diff --git a/doc/README.gpt b/doc/README.gpt
index ec0156d..59fdeeb 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -157,11 +157,13 @@ To restore GUID partition table one needs to:
partitions=uuid_disk=${uuid_gpt_disk};name=${uboot_name},
size=${uboot_size},uuid=${uboot_uuid};
- Fields 'name', 'size' and 'uuid' are mandatory for every partition.
+ The fields 'name' and 'size' are mandatory for every partition.
The field 'start' is optional.
- option: CONFIG_RANDOM_UUID
- If any partition UUID no exists then it is randomly generated.
+ The fields 'uuid' and 'uuid_disk' are optional if CONFIG_RANDOM_UUID is
+ enabled. A random uuid will be used if omitted or they point to an empty/
+ non-existent environment variable. The environment variable will be set to
+ the generated UUID.
2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT'
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: ppc4xx: Enable CONFIG_DISPLAY_BOARDINFO
On 26.01.2015 17:09, Simon Glass wrote: On 26 January 2015 at 06:35, Stefan Roese s...@denx.de wrote: This also displays the Board: line in the bootup text with the generic board support code. Signed-off-by: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org --- board/amcc/canyonlands/Kconfig | 4 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass s...@chromium.org Is there another patch which adds this in the top level Kconfig? No, not yet. At least not to my knowledge. Sorry, I missed adding it there. I'm still not used to adding the options correctly to Kconfig. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] MIPS: refactor L1 cache config reads to a macro
Reduce duplication between reading the configuration of the L1 dcache icache by performing both using a macro which calculates the appropriate line cache sizes from the coprocessor 0 Config1 register. Signed-off-by: Paul Burton paul.bur...@imgtec.com Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/lib/cache_init.S | 97 -- 1 file changed, 41 insertions(+), 56 deletions(-) diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index 6c02bf9..2e036d9 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -97,6 +97,43 @@ LEAF(mips_init_dcache) 9: jr ra END(mips_init_dcache) + .macro l1_info sz, line_sz, off + .setpush + .setnoat + + mfc0$1, CP0_CONFIG, 1 + + /* detect line size */ + srl \line_sz, $1, \off + MIPS_CONF1_DL_SHIFT - MIPS_CONF1_DA_SHIFT + andi\line_sz, \line_sz, (MIPS_CONF1_DL MIPS_CONF1_DL_SHIFT) + move\sz, zero + beqz\line_sz, 10f + li \sz, 2 + sllv\line_sz, \sz, \line_sz + + /* detect associativity */ + srl \sz, $1, \off + MIPS_CONF1_DA_SHIFT - MIPS_CONF1_DA_SHIFT + andi\sz, \sz, (MIPS_CONF1_DA MIPS_CONF1_DA_SHIFT) + addi\sz, \sz, 1 + + /* sz *= line_sz */ + mul \sz, \sz, \line_sz + + /* detect log32(sets) */ + srl $1, $1, \off + MIPS_CONF1_DS_SHIFT - MIPS_CONF1_DA_SHIFT + andi$1, $1, (MIPS_CONF1_DS MIPS_CONF1_DS_SHIFT) + addiu $1, $1, 1 + andi$1, $1, 0x7 + + /* sz = log32(sets) */ + sllv\sz, \sz, $1 + + /* sz *= 32 */ + li $1, 32 + mul \sz, \sz, $1 +10: + .setpop + .endm /* * mips_cache_reset - low level initialisation of the primary caches * @@ -114,70 +151,18 @@ LEAF(mips_init_dcache) NESTED(mips_cache_reset, 0, ra) moveRA, ra -#if !defined(CONFIG_SYS_ICACHE_SIZE) || !defined(CONFIG_SYS_DCACHE_SIZE) || \ -!defined(CONFIG_SYS_CACHELINE_SIZE) - /* read Config1 for use below */ - mfc0t5, CP0_CONFIG, 1 -#endif - -#ifdef CONFIG_SYS_CACHELINE_SIZE - li t9, CONFIG_SYS_CACHELINE_SIZE - li t8, CONFIG_SYS_CACHELINE_SIZE -#else - /* Detect I-cache line size. */ - srl t8, t5, MIPS_CONF1_IL_SHIFT - andit8, t8, (MIPS_CONF1_IL MIPS_CONF1_IL_SHIFT) - beqzt8, 1f - li t6, 2 - sllvt8, t6, t8 - -1: /* Detect D-cache line size. */ - srl t9, t5, MIPS_CONF1_DL_SHIFT - andit9, t9, (MIPS_CONF1_DL MIPS_CONF1_DL_SHIFT) - beqzt9, 1f - li t6, 2 - sllvt9, t6, t9 -1: -#endif - #ifdef CONFIG_SYS_ICACHE_SIZE li t2, CONFIG_SYS_ICACHE_SIZE + li t8, CONFIG_SYS_CACHELINE_SIZE #else - /* Detect I-cache size. */ - srl t6, t5, MIPS_CONF1_IS_SHIFT - andit6, t6, (MIPS_CONF1_IS MIPS_CONF1_IS_SHIFT) - li t4, 32 - xorit2, t6, 0x7 - beqzt2, 1f - addit6, t6, 1 - sllvt4, t4, t6 -1: /* At this point t4 == I-cache sets. */ - mul t2, t4, t8 - srl t6, t5, MIPS_CONF1_IA_SHIFT - andit6, t6, (MIPS_CONF1_IA MIPS_CONF1_IA_SHIFT) - addit6, t6, 1 - /* At this point t6 == I-cache ways. */ - mul t2, t2, t6 + l1_info t2, t8, MIPS_CONF1_IA_SHIFT #endif #ifdef CONFIG_SYS_DCACHE_SIZE li t3, CONFIG_SYS_DCACHE_SIZE + li t9, CONFIG_SYS_CACHELINE_SIZE #else - /* Detect D-cache size. */ - srl t6, t5, MIPS_CONF1_DS_SHIFT - andit6, t6, (MIPS_CONF1_DS MIPS_CONF1_DS_SHIFT) - li t4, 32 - xorit3, t6, 0x7 - beqzt3, 1f - addit6, t6, 1 - sllvt4, t4, t6 -1: /* At this point t4 == I-cache sets. */ - mul t3, t4, t9 - srl t6, t5, MIPS_CONF1_DA_SHIFT - andit6, t6, (MIPS_CONF1_DA MIPS_CONF1_DA_SHIFT) - addit6, t6, 1 - /* At this point t6 == I-cache ways. */ - mul t3, t3, t6 + l1_info t3, t9, MIPS_CONF1_DA_SHIFT #endif /* Determine the largest L1 cache size */ -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/21] ARM: tegra: collect SoC sources into mach-tegra
Hi Masahiro, On 24 January 2015 at 23:11, Masahiro Yamada yamad...@jp.panasonic.com wrote: This commit moves files as follows: arch/arm/cpu/arm720t/tegra20/* - arch/arm/mach-tegra/tegra20/* arch/arm/cpu/arm720t/tegra30/* - arch/arm/mach-tegra/tegra30/* arch/arm/cpu/arm720t/tegra114/* - arch/arm/mach-tegra/tegra114/* arch/arm/cpu/arm720t/tegra124* - arch/arm/mach-tegra/tegra124/* arch/arm/cpu/arm720t/tegra-common/* - arch/arm/mach-tegra/* arch/arm/cpu/armv7/tegra20/*- arch/arm/mach-tegra/tegra20/* arch/arm/cpu/armv7/tegra30/*- arch/arm/mach-tegra/tegra30/* arch/arm/cpu/armv7/tegra114/* - arch/arm/mach-tegra/tegra114/* arch/arm/cpu/armv7/tegra124/* - arch/arm/mach-tegra/tegra124/* arch/arm/cpu/armv7/tegra-common/* - arch/arm/mach-tegra/* arch/arm/cpu/tegra20-common/* - arch/arm/mach-tegra/tegra20/* arch/arm/cpu/tegra30-common/* - arch/arm/mach-tegra/tegra30/* arch/arm/cpu/tegra114-common/* - arch/arm/mach-tegra/tegra114/* arch/arm/cpu/tegra124-common/* - arch/arm/mach-tegra/tegra124/* arch/arm/cpu/tegra-common/* - arch/arm/mach-tegra/* Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Stephen Warren swar...@nvidia.com Cc: Tom Warren twar...@nvidia.com Cc: Simon Glass s...@chromium.org Tested on nyan-big (yes I know this is just a build change but I couldn't resist) Tested-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] MIPS: clear TagLo select 2 during cache init
Current MIPS cores from Imagination Technologies use TagLo select 2 for the data cache. The architecture requires that it is safe for software to write to this register even if it isn't present, so take the trivial option of clearing both selects 0 2. Signed-off-by: Paul Burton paul.bur...@imgtec.com Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/lib/cache_init.S | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index 04a36b2..137d728 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -139,6 +139,14 @@ LEAF(mips_cache_reset) #endif /* CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD */ /* +* The TagLo registers used depend upon the CPU implementation, but the +* architecture requires that it is safe for software to write to both +* TagLo selects 0 2 covering supported cases. +*/ + mtc0zero, CP0_TAGLO + mtc0zero, CP0_TAGLO, 2 + + /* * The caches are probably in an indeterminate state, so we force good * parity into them by doing an invalidate for each line. If * CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD is set then we'll proceed to @@ -151,7 +159,6 @@ LEAF(mips_cache_reset) * Initialize the I-cache first, */ blezt2, 1f - mtc0zero, CP0_TAGLO PTR_LI t0, INDEX_BASE PTR_ADDUt1, t0, t2 /* clear tag to invalidate */ @@ -169,7 +176,6 @@ LEAF(mips_cache_reset) * then initialize D-cache. */ 1: blezt3, 3f - mtc0zero, CP0_TAGLO PTR_LI t0, INDEX_BASE PTR_ADDUt1, t0, t3 /* clear all tags */ -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8] MIPS: inline mips_init_[id]cache functions
The mips_init_[id]cache functions are small only called once from a single callsite. Inlining them allows mips_cache_reset to avoid having to bother moving arguments around leaves it a leaf function which is thus able to simply keep the return address live in the ra register throughout, simplifying the code. Signed-off-by: Paul Burton paul.bur...@imgtec.com Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/lib/cache_init.S | 86 +++--- 1 file changed, 28 insertions(+), 58 deletions(-) diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index dc207a6..cbd04bd 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -18,12 +18,6 @@ #define CONFIG_SYS_MIPS_CACHE_MODE CONF_CM_CACHABLE_NONCOHERENT #endif -#ifdef CONFIG_64BIT -# define RAta3 -#else -# define RAt7 -#endif - #define INDEX_BASE CKSEG0 .macro f_fill64 dst, offset, val @@ -53,46 +47,6 @@ bne \curr, \end, 10b .endm -/* - * mips_init_icache(uint PRId, ulong icache_size, unchar icache_linesz) - */ -LEAF(mips_init_icache) - bleza1, 9f - mtc0zero, CP0_TAGLO - PTR_LI t0, INDEX_BASE - PTR_ADDUt1, t0, a1 - /* clear tag to invalidate */ - cache_loop t0, t1, a2, INDEX_STORE_TAG_I - /* fill once, so data field parity is correct */ - PTR_LI t0, INDEX_BASE - cache_loop t0, t1, a2, FILL - /* invalidate again - prudent but not strictly neccessary */ - PTR_LI t0, INDEX_BASE - cache_loop t0, t1, a2, INDEX_STORE_TAG_I -9: jr ra - END(mips_init_icache) - -/* - * mips_init_dcache(uint PRId, ulong dcache_size, unchar dcache_linesz) - */ -LEAF(mips_init_dcache) - bleza1, 9f - mtc0zero, CP0_TAGLO - PTR_LI t0, INDEX_BASE - PTR_ADDUt1, t0, a1 - /* clear all tags */ - cache_loop t0, t1, a2, INDEX_STORE_TAG_D - /* load from each line (in cached space) */ - PTR_LI t0, INDEX_BASE -2: LONG_L zero, 0(t0) - PTR_ADDUt0, a2 - bne t0, t1, 2b - /* clear all tags */ - PTR_LI t0, INDEX_BASE - cache_loop t0, t1, a2, INDEX_STORE_TAG_D -9: jr ra - END(mips_init_dcache) - .macro l1_info sz, line_sz, off .setpush .setnoat @@ -144,9 +98,7 @@ LEAF(mips_init_dcache) * RETURNS: N/A * */ -NESTED(mips_cache_reset, 0, ra) - moveRA, ra - +LEAF(mips_cache_reset) #ifdef CONFIG_SYS_ICACHE_SIZE li t2, CONFIG_SYS_ICACHE_SIZE li t8, CONFIG_SYS_CACHELINE_SIZE @@ -195,20 +147,38 @@ NESTED(mips_cache_reset, 0, ra) /* * Initialize the I-cache first, */ - movea1, t2 - movea2, t8 - PTR_LA v1, mips_init_icache - jalrv1 + blezt2, 1f + mtc0zero, CP0_TAGLO + PTR_LI t0, INDEX_BASE + PTR_ADDUt1, t0, t2 + /* clear tag to invalidate */ + cache_loop t0, t1, t8, INDEX_STORE_TAG_I + /* fill once, so data field parity is correct */ + PTR_LI t0, INDEX_BASE + cache_loop t0, t1, t8, FILL + /* invalidate again - prudent but not strictly neccessary */ + PTR_LI t0, INDEX_BASE + cache_loop t0, t1, t8, INDEX_STORE_TAG_I /* * then initialize D-cache. */ - movea1, t3 - movea2, t9 - PTR_LA v1, mips_init_dcache - jalrv1 +1: blezt3, 3f + mtc0zero, CP0_TAGLO + PTR_LI t0, INDEX_BASE + PTR_ADDUt1, t0, t3 + /* clear all tags */ + cache_loop t0, t1, t9, INDEX_STORE_TAG_D + /* load from each line (in cached space) */ + PTR_LI t0, INDEX_BASE +2: LONG_L zero, 0(t0) + PTR_ADDUt0, t9 + bne t0, t1, 2b + /* clear all tags */ + PTR_LI t0, INDEX_BASE + cache_loop t0, t1, t9, INDEX_STORE_TAG_D - jr RA +3: jr ra END(mips_cache_reset) /* -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8] MIPS: refactor cache loops to a macro
Reduce duplication by performing loops through cache tags using an assembler macro. Signed-off-by: Paul Burton paul.bur...@imgtec.com Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/lib/cache_init.S | 30 +- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index 2e036d9..dc207a6 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -47,28 +47,28 @@ #endif .endm + .macro cache_loop curr, end, line_sz, op +10:cache \op, 0(\curr) + PTR_ADDU\curr, \curr, \line_sz + bne \curr, \end, 10b + .endm + /* * mips_init_icache(uint PRId, ulong icache_size, unchar icache_linesz) */ LEAF(mips_init_icache) bleza1, 9f mtc0zero, CP0_TAGLO - /* clear tag to invalidate */ PTR_LI t0, INDEX_BASE PTR_ADDUt1, t0, a1 -1: cache INDEX_STORE_TAG_I, 0(t0) - PTR_ADDUt0, a2 - bne t0, t1, 1b + /* clear tag to invalidate */ + cache_loop t0, t1, a2, INDEX_STORE_TAG_I /* fill once, so data field parity is correct */ PTR_LI t0, INDEX_BASE -2: cache FILL, 0(t0) - PTR_ADDUt0, a2 - bne t0, t1, 2b + cache_loop t0, t1, a2, FILL /* invalidate again - prudent but not strictly neccessary */ PTR_LI t0, INDEX_BASE -1: cache INDEX_STORE_TAG_I, 0(t0) - PTR_ADDUt0, a2 - bne t0, t1, 1b + cache_loop t0, t1, a2, INDEX_STORE_TAG_I 9: jr ra END(mips_init_icache) @@ -78,12 +78,10 @@ LEAF(mips_init_icache) LEAF(mips_init_dcache) bleza1, 9f mtc0zero, CP0_TAGLO - /* clear all tags */ PTR_LI t0, INDEX_BASE PTR_ADDUt1, t0, a1 -1: cache INDEX_STORE_TAG_D, 0(t0) - PTR_ADDUt0, a2 - bne t0, t1, 1b + /* clear all tags */ + cache_loop t0, t1, a2, INDEX_STORE_TAG_D /* load from each line (in cached space) */ PTR_LI t0, INDEX_BASE 2: LONG_L zero, 0(t0) @@ -91,9 +89,7 @@ LEAF(mips_init_dcache) bne t0, t1, 2b /* clear all tags */ PTR_LI t0, INDEX_BASE -1: cache INDEX_STORE_TAG_D, 0(t0) - PTR_ADDUt0, a2 - bne t0, t1, 1b + cache_loop t0, t1, a2, INDEX_STORE_TAG_D 9: jr ra END(mips_init_dcache) -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm: spl: Allow board_init_r() to run with a larger stack
At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: Execution starts with start.S. Two main functions can be provided by the board implementation. The purpose and limitations of each is described below. After that, the common board_init_r() is called to perform the SPL task. lowlevel_init(): - purpose: essential init to permit execution to reach board_init_f() - no global_data, but there is a stack - must not set up SDRAM or use console - must only do the bare minimum to allow execution to continue to board_init_f() - this is almost never needed - return normally from this function board_init_f(): - purpose: set up the machine ready for running board_init_r(): i.e. SDRAM and serial UART - global_data is available - preloader_console_init() can be called here in extremis - stack is in SRAM - should set up SDRAM, and anything needed to make the UART work - these is no need to clear BSS, it will be done by crt0.S - must return normally from this function (don't call board_init_r() directly) Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point the stack and global_data are relocated to below that address. board_init_r(): - purpose: main execution, common code - global_data is available - SDRAM is available - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and points into SDRAM - preloader_console_init() can be called here - typically this is done by defining CONFIG_SPL_BOARD_INIT and then supplying a spl_board_init() function containing this call - loads U-Boot or (in falcon mode) Linux Signed-off-by: Simon Glass s...@chromium.org For version 1: Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Reviewed-by: Stefan Roese s...@denx.de Tested-by: Bo Shen voice.s...@atmel.com Acked-by: Bo Shen voice.s...@atmel.com Acked-by: Heiko Schocher h...@denx.de Tested-by: Heiko Schocher h...@denx.de --- Changes in v2: - Move docs to top-level README file and expand them to cover U-Boot proper - Add Kconfig settings Kconfig | 18 ++ README | 68 + arch/arm/lib/crt0.S | 13 +++--- common/spl/spl.c| 35 +++ 4 files changed, 131 insertions(+), 3 deletions(-) diff --git a/Kconfig b/Kconfig index 4157da3..8398bcd 100644 --- a/Kconfig +++ b/Kconfig @@ -92,6 +92,24 @@ config SPL help If you want to build SPL as well as the normal image, say Y. +config CONFIG_SPL_STACK_R + depends on SPL + bool Enable SDRAM location for SPL stack + help + SPL starts off execution in SRAM and thus typically has only a small + stack available. Since SPL sets up DRAM while in its board_init_f() + function, it is possible for the stack to move there before + board_init_r() is reached. This option enables a special SDRAM + location for the SPL stack. U-Boot SPL switches to this after + board_init_f() completes, and before board_init_r() starts. + +config CONFIG_SPL_STACK_R_ADDR + depends on CONFIG_SPL_STACK_R + hex SDRAM location for SPL stack + help + Specify the address in SDRAM for the SPL stack. This will be set up + before board_init_r() is called. + config TPL bool depends on SPL SUPPORT_TPL diff --git a/README b/README index fefa71c..7b48cda 100644 --- a/README +++ b/README @@ -273,6 +273,74 @@ run some of U-Boot's tests. See board/sandbox/README.sandbox for more details. +Board Initialisation Flow: +-- + +This is the intended start-up flow for boards. This should apply for both +SPL and U-Boot proper (i.e. they both follow the same rules). At present SPL +mostly uses a separate code path, but the funtion names and roles of each +function are the same. Some boards or architectures may not conform to this. +At least most ARM boards which use CONFIG_SPL_FRAMEWORK conform to this. + +Execution starts with
Re: [U-Boot] [PATCH] sunxi: Add Linksprite_pcDuino3_Nano board / defconfig
Le lundi 26 janvier 2015 13:14:31 UTC+1, Adam Sampson a écrit : This is a low-cost Allwinner A20 board with Arduino-style GPIO headers; it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro USB socket for OTG and another for power in, HDMI, SATA, 5V power for SATA devices, gigabit Ethernet, an IR receiver, 3.5mm audio out and a MIPI camera connector. For more details, see: http://linux-sunxi.org/LinkSprite_pcDuino3_Nano Signed-off-by: Adam Sampson a...@offog.org --- board/sunxi/MAINTAINERS|5 + configs/Linksprite_pcDuino3_Nano_defconfig | 11 +++ 2 files changed, 16 insertions(+) create mode 100644 configs/Linksprite_pcDuino3_Nano_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 743e7f5..479d147 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -100,3 +100,8 @@ MELE M5 BOARD M: Ian Campbell i...@hellion.org.uk S: Maintained F: configs/Mele_M5_defconfig + +LINKSPRITE-PCDUINO3-NANO BOARD +M: Adam Sampson a...@offog.org +S: Maintained +F: configs/Linksprite_pcDuino3_Nano_defconfig diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig b/configs/Linksprite_pcDuino3_Nano_defconfig new file mode 100644 index 000..22435eb --- /dev/null +++ b/configs/Linksprite_pcDuino3_Nano_defconfig @@ -0,0 +1,11 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI +CONFIG_FDTFILE=sun7i-a20-pcduino3-nano.dtb +CONFIG_USB1_VBUS_PIN=PH11 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_TARGET_PCDUINO3_NANO=y ++S:CONFIG_DRAM_CLK=408 ++S:CONFIG_DRAM_ZQ=122 ++S:CONFIG_DRAM_EMR1=4 -- 1.7.10.4 Hello Adam, What do you think about adding RGMII in the CONFIG_SYS_EXTRA_OPTIONS like other gigabit A20 board ? ps : thank you for your pcduino3 Nano contribution, i miss some time to do it :) Regards, KrissFR___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Export redesign
Am Montag, 26. Januar 2015, 15:45:31 schrieb Wolfgang Denk: Is this a 100% binary compatible change? If not, should we not also increment XF_VERSION ? Yes it is . The function pointers declared in _export.h are in the same sequence as they were before. Regards Martin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/26] dm: Don't run tests if U-Boot cannot be built
On 25 January 2015 at 08:26, Simon Glass s...@chromium.org wrote: There is no point in running the tests if U-Boot cannot be built. Abort in this case. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None test/dm/test-dm.sh | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/26] dm: core: Set device tree node for root device
On 25 January 2015 at 08:26, Simon Glass s...@chromium.org wrote: The root device corresponds to the root device tree node, so set this up. Also add a few notes to the documentation. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None doc/driver-model/README.txt | 4 drivers/core/root.c | 3 +++ 2 files changed, 7 insertions(+) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/26] dm: core: Tidy up error handling in device_bind()
On 25 January 2015 at 08:26, Simon Glass s...@chromium.org wrote: Make the error handling more standard to make it easier to build on top of it. Also correct a bug in the error path where there is no parent. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v3: None Changes in v2: None drivers/core/device.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/26] dm: core: Improve comments for uclass_first/next_device()
On 25 January 2015 at 08:26, Simon Glass s...@chromium.org wrote: Mention that the devices are probed ready for use. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None include/dm/uclass.h | 4 1 file changed, 4 insertions(+) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/26] dm: core: Add a post_bind method for parents
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: Allow parent drivers to be called when a new child is bound to them. This allows a bus to set up information it needs for that child. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v3: None Changes in v2: None drivers/core/device.c | 12 include/dm/device.h | 2 ++ test/dm/bus.c | 35 +++ 3 files changed, 49 insertions(+) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/26] dm: core: Allow uclasses to specify platdata for a device's children
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: In many cases the child platform data for a device's children is defined by the uclass rather than the individual devices. For example, a SPI bus needs to know the chip select and speed for each of its children. It makes sense to allow this information to be defined the SPI uclass rather than each individual driver. If the device provides a size value for its child platdata, then use it. Failng that, fall back to that provided by the uclass. Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Signed-off-by: Simon Glass s...@chromium.org Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/26] dm: core: Allow uclasses to specify private data for a device's children
On 25 January 2015 at 19:00, Masahiro Yamada yamad...@jp.panasonic.com wrote: On Sun, 25 Jan 2015 08:27:06 -0700 Simon Glass s...@chromium.org wrote: In many cases the per-child private data for a device's children is defined by the uclass rather than the individual driver. For example, a SPI bus needs to store information about each of its children, but all SPI drivers store the same information. It makes sense to allow the uclass to define this data. If the driver provides a size value for its per-child private data, then use it. Failng that, fall back to that provided by the uclass. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Fix typo in commit subject Changes in v2: None Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/26] dm: spi: Move the per-child data size to the uclass
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: This is common to all SPI drivers and specifies a structure used by the uclass. It makes more sense to define it in the uclass. Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None drivers/spi/cadence_qspi.c | 1 - drivers/spi/designware_spi.c | 1 - drivers/spi/exynos_spi.c | 1 - drivers/spi/sandbox_spi.c| 1 - drivers/spi/soft_spi.c | 1 - drivers/spi/spi-uclass.c | 1 + drivers/spi/tegra114_spi.c | 1 - drivers/spi/tegra20_sflash.c | 1 - drivers/spi/tegra20_slink.c | 1 - 9 files changed, 1 insertion(+), 8 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S
Hi, On 26-01-15 16:18, Tom Rini wrote: On Fri, Jan 23, 2015 at 09:54:12AM +0100, Hans de Goede wrote: Hi, On 22-01-15 22:03, Tom Rini wrote: On Thu, Jan 22, 2015 at 08:10:06PM +0100, Hans de Goede wrote: Hi, On 22-01-15 17:20, Tom Rini wrote: On Wed, Jan 21, 2015 at 09:03:25PM +0100, Hans de Goede wrote: On some SoCs / ARMv7 CPU cores we need to do some setup before enabling the icache, etc. Add a soc_init hook with a weak default which just calls cpu_init_cp15. This way different implementations can be provided to do some extra work before or after cpu_init_cp15, or completely replacing cpu_init_cp15. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/cpu/armv7/start.S | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index fdc05b9..9882b20 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -64,7 +64,7 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT - bl cpu_init_cp15 + bl soc_init bl cpu_init_crit #endif I like the direction here. And I want to make sure I get the sunxi direction right here too (as I agree with the need / desire for boot0 + U-Boot to be a valid combination). I think we can take this a step farther. cpu_init_crit (on armv7) is basically a call to s_init(). For am33xx (and I bet but need to do and test omap3+) we can, with Simon's patch to let us move stack to DDR a tiny bit later, in the SPL case make s_init empty, which just leaves us with (with your patch) soc_init. Is there some way we can put all of this together in a function? You mean essentially call s_init here and have s_init call cpu_init_cp15 I guess we could do that, but it would require auditing all existing armv7 users of s_init. This may require me to rethink how / when I do timer gpio init etc. for u-boot.bin on sunxi, but that should not be a (big) problem. Basically. From my first pass audit of s_init, it's either empty (Kona), sunxi, or omap/etc so I get to deal with it. And the default soc_init would just be the call to cpu_init_cp15 as you have it and we drop the lowlevel_init hurdles. Ok, so what you're suggesting is a patch which: 1) Changes: #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 bl cpu_init_crit #endif Into: #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl lowlevel_init #endif Which will setup the stack and then call the s_init C function 2) Adds a weak default s_init which calls cpu_init_cp15 3) Patch all existing s_init functions to call cpu_init_cp15 before doing anything else. Pretty close. Simon's SPL DM series and related clean-ups got me thinking that yes, seemingly too much got shoved into s_init that really could have been done using an existing hook done slightly later. And then in follow up patches we can: 4) Drop cpu_init_crit 5) Cleanup some s_init functions (this will be left to the individual SoC maintainers) I think that is a good idea, Albert what do you think about this ? So I'd like to see 5 done soon afterwards as it's me (omap*) and sunxi. I think we can simplfy the call sequence too, to roughly: #ifndef CONFIG_SKIP_LOWLEVEL_INIT ... Set up stack for C, it's just a few instrs bl lowlevel_init #endif bl _main __weak asm lowlevel_init: bl cpu_init_cp15 return to caller And comment that anything called via lowlevel_init must be C-callable. I hope that once #5 is done no one actually has a lowlevel_init that's done in C but we've kept the door open should it be needed down the road (as I _think_ we can shuffle both the omap* and sunxi stuff to do their inits as needed in both SPL and full U-Boot from an early hook in board_init_r, top of my head is board_init calls some_other_func() in full U-Boot to ensure GPIOs, etc, on sunxi and spl_board_init() calls same func in SPL, and we can consolidate again further down the road as we get SPL and full U-Boot more in sync on the call chain). Sounds good to me, and I'm fine with working the sunxi side of things. Since you seem to have this all in your head can you do a patch for this replacing my patchset ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/26] dm: i2c: Provide an offset length parameter where needed
On 25 January 2015 at 08:26, Simon Glass s...@chromium.org wrote: Rather than assuming that the chip offset length is 1, allow it to be provided. This allows chips that don't use the default offset length to be used (at present they are only supported by the command line 'i2c' command which sets the offset length explicitly). Signed-off-by: Simon Glass s...@chromium.org Acked-by: Heiko Schocher h...@denx.de Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 26/26] dm: Update documentation for new bus features
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: Now that we have new bus features, update README.txt and the SPI docs to explain these. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Drop RFC prefix since this series has been properly tested now - Update commit message to describe immuatable platform data - Update the spi-howto docs doc/driver-model/README.txt| 36 ++-- doc/driver-model/spi-howto.txt | 40 +--- 2 files changed, 63 insertions(+), 13 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 25/26] dm: cros_ec_spi: Remove old pre-driver-model code
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: This is no-longer needed since all platforms use SPI for cros_ec. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Add patches to tidy up cros_ec using new I2C/SPI features drivers/misc/cros_ec_spi.c | 51 ++ 1 file changed, 2 insertions(+), 49 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Writing u-boot to NAND from U-Boot results in ecc unrecoverable error
Hello everyone,
I have a Gumstix Overo (OMAP3) COM here that I am evaluating BCH8 ECC
scheme on boot-loader (2014.10) and the kernel (3.17.7).
Traditionally the board has been configured with 1 bit HAM, as are other
OMAP3 boards.
I have these changes in my board config:
+#define CONFIG_BCH
+#define CONFIG_SYS_NAND_MAX_ECCPOS 56
+#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, \
+ 13, 14, 16, 17, 18, 19, 20, 21, 22, \
+ 23, 24, 25, 26, 27, 28, 30, 31, 32, \
+ 33, 34, 35, 36, 37, 38, 39, 40, 41, \
+ 42, 44, 45, 46, 47, 48, 49, 50, 51, \
+ 52, 53, 54, 55, 56}
+#define CONFIG_SYS_NAND_ECCBYTES 13
+#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+#define CONFIG_SPL_MAX_SIZE(58 * 1024)
And other than MLO, I make sure 'nandecc sw' before I do any NAND
write/read.
Now the first problem occurs after MLO executes and before U-Boot is
loaded. I get a whole bunch of ecc unrecoverable error from
`nand_spl_load_image` calls. Weird thing is that U-Boot image eventually
gets loaded after a couple hundred lines of these error messages.
This problem however does not occur when I write the U-Boot image from the
Kernel using flash_erase and nandwrite tools (my DTS has ti,nand-ecc-opt =
bch8; .
Any pointers would be greatly appreciated,
Adam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/26] dm: core: Allow the uclass to set up a device's child after binding
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: For buses, after a child is bound, allow the uclass to perform some processing. This can be used to figure out the address of the child (e.g. the chip select for SPI slaves) so that it is ready to be probed. This avoids bus drivers having to repeat the same process, which really should be done by the uclass, since it is common. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v3: - Change variable name from parent_drv to uc_drv Changes in v2: None drivers/core/uclass.c | 21 - include/dm/uclass.h | 2 ++ test/dm/bus.c | 26 ++ 3 files changed, 44 insertions(+), 5 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/26] dm: spi: Set up the spi_slave device pointer in child_pre_probe()
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: At present we use struct spi_slave as our device pointer in a lot of places to avoid changing the old SPI API. At some point this will go away. But for now, it is better if the SPI uclass sets up this pointer, rather than relying on passing it into the device when it is probed. We can use the new uclass child_pre_probe() method to do this. Signed-off-by: Simon Glass s...@chromium.org Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Export redesign
Dear Simon, In message CAPnjgZ1wzmspVjB8dqDJBZDu2Dpu+JLSS=cmaddpkhptyrh...@mail.gmail.com you wrote: Is this a 100% binary compatible change? If not, should we not also increment XF_VERSION ? If a board has move to driver model and doesn't use CONFIG_DM_I2C_COMPAT (and this should ideally not be used) then the I2C functions are not present. I tested the compatibility to a basic degree. Maybe I'm misreading the code, but would an old standalone application image, compiled for the old jumptable format, really still run on a system with your patch applied? Only in this case we can leave the version unchanged. Perhaps we should increment it anyway, given it is such a major code change? It would not hurt, ideed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The manager will be continually amazed that policies he took for com- mon knowledge are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86
Hi Tom, The following changes since commit 37b608a52dcb13312a4f7ccea199cd6bac76d298: powerpc: remove icecube_5200, Lite5200, cpci5200, mecp5200, pf5200 (2015-01-23 16:56:09 -0500) are available in the git repository at: http://git.denx.de/u-boot-x86.git for you to fetch changes up to e43ade3749ff10bc313f33bf23705465e4163896: x86: config: chromebook_link: Enable environment (2015-01-24 06:13:46 -0700) Bin Meng (5): x86: ahci: Make sure interface is not busy after enabling the port x86: Add missing DECLARE_GLOBAL_DATA_PTR for mtrr.c x86: Save mtrr support flag in global data x86: Test mtrr support flag before accessing mtrr msr x86: Fix various code format issues in start16.S Sebastien Ronsse (1): x86: Fix out of bounds irq handlers access Simon Glass (22): bios_emulator: Fix an #ifdef typo in the header file x86: Correct endianness isues in pci_rom x86: Support ROMs on other archs bios_emulator: Don't display error when emulator terminates bios_emulator: Add some VESA interface debugging x86: pci: Don't stop when we get a vendor/device mismatch x86: Add a VESA video driver x86: Drop the x86_fb driver x86: Access the VGA ROM when needed x86: video: Add support for CONFIG_CONSOLE_SCROLL_LINES x86: config: Always scroll the display by 5 lines, for speed x86: dts: Add compatible string for Intel ICH9 SPI controller net: Add a separate file for IP checksumming x86: Use ipchecksum from net/ x86: rtc: mc146818: Add helpers to read/write CMOS RAM x86: spi: Add device tree support Allow architecture-specific memory reservation x86: dts: Add SPI flash MRC details for chromebook_link x86: Implement a cache for Memory Reference Code parameters x86: config: Enable hook for saving MRC configuration x86: ivybridge: Drop the Kconfig MRC cache information x86: config: chromebook_link: Enable environment Sjoerd Simons (1): pci: tegra: Fix port information parsing arch/x86/cpu/coreboot/Makefile | 1 - arch/x86/cpu/coreboot/coreboot.c| 5 arch/x86/cpu/coreboot/ipchecksum.c | 55 -- arch/x86/cpu/coreboot/tables.c | 8 ++--- arch/x86/cpu/cpu.c | 7 + arch/x86/cpu/ivybridge/Kconfig | 28 - arch/x86/cpu/ivybridge/Makefile | 1 + arch/x86/cpu/ivybridge/mrccache.c | 156 +++ arch/x86/cpu/ivybridge/sdram.c | 253 ++ arch/x86/cpu/mtrr.c | 14 + arch/x86/cpu/start16.S | 20 ++--- arch/x86/dts/chromebook_link.dts| 15 +- arch/x86/include/asm/arch-coreboot/ipchecksum.h | 37 --- arch/x86/include/asm/arch-ivybridge/mrccache.h | 51 +++ arch/x86/include/asm/global_data.h | 16 ++ arch/x86/include/asm/mtrr.h | 5 +++- arch/x86/include/asm/u-boot-x86.h | 2 ++ arch/x86/lib/init_helpers.c | 4 ++- arch/x86/lib/interrupts.c | 2 +- common/board_f.c| 7 + configs/chromebook_link_defconfig | 2 +- drivers/bios_emulator/atibios.c | 161 +- drivers/bios_emulator/include/x86emu/debug.h| 2 +- drivers/bios_emulator/x86emu/ops.c | 2 +- drivers/block/ahci.c| 20 - drivers/pci/pci_auto.c | 28 - drivers/pci/pci_rom.c | 40 + drivers/pci/pci_tegra.c | 5 ++-- drivers/rtc/mc146818.c | 121 -- drivers/spi/ich.c | 7 + drivers/video/Kconfig | 7 +++-- drivers/video/Makefile | 2 +- drivers/video/cfb_console.c | 26 ++-- drivers/video/vesa_fb.c | 64 +++ drivers/video/x86_fb.c | 38 --- include/configs/chromebook_link.h | 8 + include/configs/x86-common.h| 2 ++ include/fdtdec.h
Re: [U-Boot] [PATCH v3 11/26] dm: core: Add a flag to control sequence numbering
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/26] dm: core: Add a function to get a device's uclass ID
On 25 January 2015 at 18:58, Masahiro Yamada yamad...@jp.panasonic.com wrote: On Sun, 25 Jan 2015 08:27:04 -0700 Simon Glass s...@chromium.org wrote: This is useful to check which uclass a device is in. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/26] dm: core: Allocate platform data when binding a device
On 25 January 2015 at 18:57, Masahiro Yamada yamad...@jp.panasonic.com wrote: On Sun, 25 Jan 2015 08:27:00 -0700 Simon Glass s...@chromium.org wrote: When using allocated platform data, allocate it when we bind the device. This makes it possible to fill in this information before the device is probed. This fits with the platform data model (when not using device tree), since platform data exists at bind-time. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Fix stale comment in device_probe_child() Changes in v2: None Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/26] dm: core: Allow parents to have platform data for their children
On 25 January 2015 at 18:56, Masahiro Yamada yamad...@jp.panasonic.com wrote: On Sun, 25 Jan 2015 08:27:01 -0700 Simon Glass s...@chromium.org wrote: For buses it is common for parents to need to know the address of the child on the bus, the bus speed to use for that child, and other information. This can be provided in platform data attached to each child. Add driver model support for this, including auto-allocation which can be requested using a new property to specify the size of the data. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 24/26] dm: cros_ec: Move cros_ec_i2c over to driver model
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: Update the driver model support, and remove the old code. Change snow to use this new support. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Add patches to tidy up cros_ec using new I2C/SPI features drivers/misc/cros_ec_i2c.c | 107 + include/configs/snow.h | 5 +++ 2 files changed, 45 insertions(+), 67 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 23/26] dm: cros_ec: Don't require protocol 3 support
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: I2C is now deprecated on ARM platforms and there are no devices that use it with the v3 protocol. We can't require v3 support if we want to support I2C. Adjust the error handling to suit. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Add patches to tidy up cros_ec using new I2C/SPI features drivers/misc/cros_ec.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 22/26] dm: core: Ignore disabled devices when binding
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: We don't want to bind devices which should never be used. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v3: None Changes in v2: - Add patches to tidy up cros_ec using new I2C/SPI features drivers/core/root.c | 5 + 1 file changed, 5 insertions(+) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Export redesign
Hi Wolfgang, On 26 January 2015 at 11:55, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message CAPnjgZ1wzmspVjB8dqDJBZDu2Dpu+JLSS=cmaddpkhptyrh...@mail.gmail.com you wrote: Is this a 100% binary compatible change? If not, should we not also increment XF_VERSION ? If a board has move to driver model and doesn't use CONFIG_DM_I2C_COMPAT (and this should ideally not be used) then the I2C functions are not present. I tested the compatibility to a basic degree. Maybe I'm misreading the code, but would an old standalone application image, compiled for the old jumptable format, really still run on a system with your patch applied? Only in this case we can leave the version unchanged. Perhaps we should increment it anyway, given it is such a major code change? It would not hurt, ideed. OK I'll do that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/26] dm: sandbox: sf: Tidy up the error handling in sandbox_sf_probe()
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: Use a single exit point when we have an error and add debugging there. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None drivers/mtd/spi/sandbox.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/26] dm: core: Allow uclass to set up a device's child before it is probed
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: Some buses need to set up their devices before they can be used. This setup may well be common to all buses in a particular uclass. Support a common pre-probe method for the uclass, called before any bus devices are probed. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 18/26] dm: spi: Move slave details to child platdata
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: At present we go through various contortions to store the SPI slave's chip select in its private data. This only exists when the slave is active so must be set up when it is probed. Until the device is probed we don't actually know what chip select it will appear on. However, now that we can support per-child platform data, we can use that instead. This allows us to set up the chip select when the child is bound, and avoid the messy contortions. Unfortunately this is a fairly large change and it seems to be difficult to break it down further. Signed-off-by: Simon Glass s...@chromium.org Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 20/26] dm: tegra: Drop unused COMPAT features for I2C, SPI
On 25 January 2015 at 08:27, Simon Glass s...@chromium.org wrote: These have moved to driver model so we don't need the fdtdec support. Signed-off-by: Simon Glass s...@chromium.org Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 21/26] dm: exynos: Drop unused COMPAT features for SPI
On 25 January 2015 at 23:53, Minkyu Kang mk7.k...@samsung.com wrote:
On 26/01/15 00:27, Simon Glass wrote:
This has moved to driver model so we don't need the fdtdec support.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
include/fdtdec.h | 1 -
lib/fdtdec.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 094a8e3..4cc69de 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -134,7 +134,6 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
COMPAT_SAMSUNG_EXYNOS5_SOUND, /* Exynos Sound */
COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
- COMPAT_SAMSUNG_EXYNOS_SPI, /* Exynos SPI */
COMPAT_GOOGLE_CROS_EC, /* Google CROS_EC Protocol */
COMPAT_GOOGLE_CROS_EC_KEYB, /* Google CROS_EC Keyboard */
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5c79afd..7509cd6 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -42,7 +42,6 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
COMPAT(SAMSUNG_EXYNOS5_SOUND, samsung,exynos-sound),
COMPAT(WOLFSON_WM8994_CODEC, wolfson,wm8994-codec),
- COMPAT(SAMSUNG_EXYNOS_SPI, samsung,exynos-spi),
COMPAT(GOOGLE_CROS_EC, google,cros-ec),
COMPAT(GOOGLE_CROS_EC_KEYB, google,cros-ec-keyb),
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
Acked-by: Minkyu Kang mk7.k...@samsung.com
Applied to -u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/26] dm: i2c: Move slave details to child platdata
On 25 January 2015 at 19:05, Masahiro Yamada yamad...@jp.panasonic.com wrote: On Sun, 25 Jan 2015 08:27:13 -0700 Simon Glass s...@chromium.org wrote: At present we go through various contortions to store the I2C's chip address in its private data. This only exists when the chip is active so must be set up when it is probed. Until the device is probed we don't actually record what address it will appear on. However, now that we can support per-child platform data, we can use that instead. This allows us to set up the address when the child is bound, and avoid the messy contortions. Unfortunately this is a fairly large change and it seems to be difficult to break it down further. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add missing 'static' to two functions - Remove unnecessary per_child_auto_alloc_size value I tested this series on my board. I am OK with the change in the UniPhier I2C driver area. Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to -u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
