Re: [U-Boot] [PATCH 2/6 V2] EXYNOS5 : FDT: Add Aliases for I2C device
Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: This patch adds aliases for I2C. Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org --- Changes in V2: - None. board/samsung/dts/exynos5250-smdk5250.dts | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6 V2] EXYNOS5: FDT: Add I2C device node data
Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: Add I2C device node data for exynos Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org --- Changes in V2: Added Periph id to the I2C device node arch/arm/dts/exynos-periph-id.dtsi | 35 + arch/arm/dts/exynos5250.dtsi | 73 2 files changed, 108 insertions(+), 0 deletions(-) create mode 100644 arch/arm/dts/exynos-periph-id.dtsi Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6 V2] EXYNOS5: FDT: Add compatible string for I2C
Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: Add required compatible information for I2C driver. Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org --- Changes in V2: - None include/fdtdec.h |1 + lib/fdtdec.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6 V2] FDT: Api to find compatible id for a given node
Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: This patch adds api to find compatible id for a given FDT node Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org --- Changes in V2: - None include/fdtdec.h | 14 ++ lib/fdtdec.c | 12 2 files changed, 26 insertions(+), 0 deletions(-) Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6 V2] SMDK5250: Initialise I2C using FDT
Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: This patch initialises I2C using FDT. Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com --- Changes since V2: - board_i2c_init moved to driver in case of FDT. board/samsung/smdk5250/smdk5250.c | 20 +--- 1 files changed, 1 insertions(+), 19 deletions(-) Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 V2] I2C: Driver changes for FDT support
Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde:wrote Functions added to get the I2C bus number and reset I2C bus using FDT node. Signed-off-by: Simon Glasss...@chromium.org Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com --- Changes in V2: - Added periph id to I2C bus structure. - Modified i2c_get_bus_num_fdt function to compare with node. - Board i2c init moved to driver in case of FDT. drivers/i2c/s3c24x0_i2c.c | 90 - drivers/i2c/s3c24x0_i2c.h |8 include/i2c.h | 26 + 3 files changed, 123 insertions(+), 1 deletions(-) Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] Add README for the Falcon mode
Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de --- Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive doc/README.falcon | 173 + 1 file changed, 173 insertions(+) create mode 100644 doc/README.falcon diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 000..87279e4 --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,173 @@ +U-Boot Falcon Mode + + +Introduction + + +This document provides an overview how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot. + +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. + +Falcon Mode adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. In usual U-Boot systems, these parameters are +generated each time before loading the kernel, passing to Linux the address +in memory where the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel. + +To boot the kernel, these steps under a Falcon-aware U-Boot are required: + +1. Boot the board into U-Boot. +Use the spl export command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel. + +2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND). + +3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters area to the required address. + +It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image. + +The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. + +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start. + +Configuration + +CONFIG_CMD_SPL Enable the spl export command. + The command spl export is then available in U-Boot + mode +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + A board should implement the following functions: + +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is start_of_ram + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +Function that a board must implement + + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns 0 if SPL starts the kernel, 1 if U-Boot + must be started. + + +Using spl command +- + +spl - SPL configuration + +Usage: + +spl export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ] + +img: atags or fdt +kernel_addr: kernel is loaded as part of the boot process, but it is not started. + This is the address where a kernel image is stored. +initrd_addr: Address of initial ramdisk + can be set to - if fdt_addr without initrd img is used +fdt_addr : in case of fdt, the address of the device tree. + +The spl puts its result at a self gained position. The position is
[U-Boot] [PATCH v3 3/3] SPL: Change description for spl command
Add a more descriptive text to the help of the spl command. Signed-off-by: Stefano Babic sba...@denx.de --- common/cmd_spl.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/common/cmd_spl.c b/common/cmd_spl.c index 9ec054a..b21d41d 100644 --- a/common/cmd_spl.c +++ b/common/cmd_spl.c @@ -182,7 +182,11 @@ static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) U_BOOT_CMD( spl, 6 , 1, do_spl, SPL configuration, - export img=atags|fdt [kernel_addr] [initrd_addr] - [fdt_addr if img = fdt] - export a kernel parameter image\n - \t initrd_img can be set to \-\ if fdt_addr without initrd img is - used); + export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ]\n + \timg\t\t\atags\ or \fdt\\n + \tkernel_addr\taddress where a kernel image is stored.\n + \t\t\tkernel is loaded as part of the boot process, but it is not started.\n + \tinitrd_addr\tAddress of initial ramdisk\n + \t\t\tcan be set to \-\ if fdt_addr without initrd img is used\n + \tfdt_addr\tin case of fdt, the address of the device tree.\n + ); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define
CONFIG_SPL_OS_BOOT_KEY is used only in board files. It is
not required to have a general CONFIG_ option. Rename it and
define it in board directory.
Signed-off-by: Stefano Babic sba...@denx.de
---
board/technexion/twister/twister.c |8
board/technexion/twister/twister.h |2 ++
board/timll/devkit8000/devkit8000.c |8
board/timll/devkit8000/devkit8000.h |3 +++
include/configs/devkit8000.h|1 -
include/configs/twister.h |1 -
6 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/board/technexion/twister/twister.c
b/board/technexion/twister/twister.c
index 1471559..bbc29b7 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -161,10 +161,10 @@ void spl_board_prepare_for_linux(void)
int spl_start_uboot(void)
{
int val = 0;
- if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, U-Boot key)) {
- gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
- val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
- gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+ if (!gpio_request(SPL_OS_BOOT_KEY, U-Boot key)) {
+ gpio_direction_input(SPL_OS_BOOT_KEY);
+ val = gpio_get_value(SPL_OS_BOOT_KEY);
+ gpio_free(SPL_OS_BOOT_KEY);
}
return val;
}
diff --git a/board/technexion/twister/twister.h
b/board/technexion/twister/twister.h
index a2051c0..cff479c 100644
--- a/board/technexion/twister/twister.h
+++ b/board/technexion/twister/twister.h
@@ -38,6 +38,8 @@ const omap3_sysinfo sysinfo = {
#define XR16L2751_UART1_BASE 0x2100
#define XR16L2751_UART2_BASE 0x2300
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY55
/*
* IEN - Input Enable
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index 35f5e15..d8e7ebe 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -172,10 +172,10 @@ void spl_board_prepare_for_linux(void)
int spl_start_uboot(void)
{
int val = 0;
- if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, U-Boot key)) {
- gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
- val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
- gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+ if (!gpio_request(SPL_OS_BOOT_KEY, U-Boot key)) {
+ gpio_direction_input(SPL_OS_BOOT_KEY);
+ val = gpio_get_value(SPL_OS_BOOT_KEY);
+ gpio_free(SPL_OS_BOOT_KEY);
}
return !val;
}
diff --git a/board/timll/devkit8000/devkit8000.h
b/board/timll/devkit8000/devkit8000.h
index aa69e6c..c1965e2 100644
--- a/board/timll/devkit8000/devkit8000.h
+++ b/board/timll/devkit8000/devkit8000.h
@@ -32,6 +32,9 @@ const omap3_sysinfo sysinfo = {
NAND,
};
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY26
+
/*
* IEN - Input Enable
* IDIS - Input Disable
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index da3263f..54b5eeb 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -353,7 +353,6 @@
/* SPL OS boot options */
#define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 26
#define CONFIG_CMD_SPL
#define CONFIG_CMD_SPL_WRITE_SIZE 0x400 /* 1024 byte */
diff --git a/include/configs/twister.h b/include/configs/twister.h
index a852481..4205a11 100644
--- a/include/configs/twister.h
+++ b/include/configs/twister.h
@@ -58,7 +58,6 @@
#define CONFIG_CMD_SPL_NAND_OFS(CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x60)
#define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 55
#define CONFIG_SYS_SPL_ARGS_ADDR (PHYS_SDRAM_1 + 0x100)
#define CONFIG_SPL_BOARD_INIT
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] Add README for the Falcon mode
On Mon, Nov 19, 2012 at 7:11 AM, Stefano Babic sba...@denx.de wrote: ... +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. From the above text it seems the Falcon Mode is already available in SD-Card however this is not truth. Please rework this so it is clear what is already working and what needs to be done. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] SPL: Change description for spl command
Dear Stefano Babic, On 19.11.2012 10:11, Stefano Babic wrote: Add a more descriptive text to the help of the spl command. Signed-off-by: Stefano Babic sba...@denx.de --- common/cmd_spl.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/common/cmd_spl.c b/common/cmd_spl.c index 9ec054a..b21d41d 100644 --- a/common/cmd_spl.c +++ b/common/cmd_spl.c @@ -182,7 +182,11 @@ static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) U_BOOT_CMD( spl, 6 , 1, do_spl, SPL configuration, - export img=atags|fdt [kernel_addr] [initrd_addr] - [fdt_addr if img = fdt] - export a kernel parameter image\n - \t initrd_img can be set to \-\ if fdt_addr without initrd img is - used); + export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ]\n -^ unnecessary blank + \timg\t\t\atags\ or \fdt\\n + \tkernel_addr\taddress where a kernel image is stored.\n + \t\t\tkernel is loaded as part of the boot process, but it is not started.\n + \tinitrd_addr\tAddress of initial ramdisk\n ^ Capitalization should be uniform. Either change all other places to capital beginning or start here with small letters. + \t\t\tcan be set to \-\ if fdt_addr without initrd img is used\n --^ I think we should write here either 'initrd image'/'initial ramdisk image' or 'initrd_addr'. I know img is a well known abbreviation for image, but in a descriptive text we should IMHO not abbreviate. Additionally the sentence should stop with a full stop like the others do. + \tfdt_addr\tin case of fdt, the address of the device tree.\n + ); 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] [PATCH v3 1/3] Add README for the Falcon mode
Dear Stefano Babic, On 19.11.2012 10:11, Stefano Babic wrote: Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de despite a small change Acked-by: Andreas Bießmann andreas.de...@googlemail.com --- Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive snip +Configuration + +CONFIG_CMD_SPL Enable the spl export command. + The command spl export is then available in U-Boot + mode +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + A board should implement the following functions: + +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is start_of_ram + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZESize of the parameters area to be copied + +Function that a board must implement + + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns 0 if SPL starts the kernel, 1 if U-Boot + must be started. + + shouldn't we reorder that thing here (move CONFIG_SPL_OS_BOOT down to the functions)? 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] [PATCH v3 1/3] Add README for the Falcon mode
On 19/11/2012 11:14, Otavio Salvador wrote: On Mon, Nov 19, 2012 at 7:11 AM, Stefano Babic sba...@denx.de mailto:sba...@denx.de wrote: ... +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. From the above text it seems the Falcon Mode is already available in SD-Card however this is not truth. Please rework this so it is clear what is already working and what needs to be done. I reread the sentence, and I am really describing what SPL alone does, not Falcon mode. SPL is already available for different storage and there are some boards booting from SD. Check for CONFIG_SPL_MMC_SUPPORT in include/configs, there are plenty of boards using it. On the other side, Falcon Mode (SPL + CONFIG_SPL_OS_BOOT) is set only for two boards, twister and devkit8000, bpth booting from NAND. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] Add README for the Falcon mode
On 19/11/2012 11:21, Andreas Bießmann wrote: Dear Stefano Babic, On 19.11.2012 10:11, Stefano Babic wrote: Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de despite a small change Acked-by: Andreas Bießmann andreas.de...@googlemail.com --- Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive snip +Configuration + +CONFIG_CMD_SPL Enable the spl export command. +The command spl export is then available in U-Boot +mode +CONFIG_SPL_OS_BOOT Activate Falcon Mode. +A board should implement the following functions: + +CONFIG_SYS_SPL_ARGS_ADDRAddress in RAM where the parameters must be +copied by SPL. +In most cases, it is start_of_ram + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +Function that a board must implement + + +void spl_board_prepare_for_linux(void) : optional +Called from SPL before starting the kernel + +spl_start_uboot() : required +Returns 0 if SPL starts the kernel, 1 if U-Boot +must be started. + + shouldn't we reorder that thing here (move CONFIG_SPL_OS_BOOT down to the functions)? arghh..right, I missed this change - I will do in V4. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Hi:
Thanks, it can work now. BTW, one question whether the atmel' patch on
v2010.6 is merged int u-boot mainline?
At 2012-11-19 14:10:27,Bo Shen voice.s...@atmel.com wrote:
Hi Alex,
On 11/19/2012 13:40, alex wrote:
more information. samba script as below:
## Falshing binaries
puts -I- === Initialize the NAND access ===
NANDFLASH::Init
puts -I- === Enable PMECC OS Parameters ===
NANDFLASH::NandHeaderValue HEADER 0xc0c00405
puts -I- === Erase all the NAND flash blocs and test the erasing ===
NANDFLASH::EraseAllNandFlash
puts -I- === Load the bootstrap: nandflash_at91sam9-ek in the first
sector ===
NANDFLASH::SendBootFilePmeccCmd $bootstrapFile
puts -I- === Load the u-boot image ===
send_file {NandFlash} $ubootFile $ubootAddr 0
puts -I- === Load the u-boot env image ===
send_file {NandFlash} $ubootenvFile $ubootenvAddr 0
puts -I- === Load the Kernel image ===
send_file {NandFlash} $kernelFile $kernelAddr 0
puts -I- === Enable trimffs ===
NANDFLASH::NandSetTrimffs 1
puts -I- === Load the linux file system ===
send_file {NandFlash} $rootfsFile $rootfsAddr 0
puts -I- === DONE. ===
This is no help. Without any useful information.
At 2012-11-19 13:37:15,alex laub...@163.com wrote:
I use u-boot v2010.06 with atmel's patch. I give u-boot 512K size.
U-Boot 2010.06-2-gb006d3d-dirty (Nov 19 2012 - 09:53:38)
DRAM: 128 MiB
NAND: No NAND device found!!!
NAND Flash not found !
No NAND device found!!!
0 MiB
You should also provide bootstrap log info.
I think the code is get from www.at91.com/linux4sam.
Anyway, I assume that you use the source code and package get for the
upper website. If so, the u-boot environment you change is overlap with
u-boot. (If you write the u-boot at offset 0x4, the size is larger
than 256K, that means: u-boot offset + u-boot size 0x8). So, when
save environment, it will overwrite the u-boot, which cause this issue.
Please check it again. If all thing as I guess, you can change the
u-boot offset to 0x2, or change environment offset to 0xa. you
can choose which you prefer.
Best Regards,
Bo Shen
At 2012-11-19 11:19:25,Bo Shen voice.s...@atmel.com
mailto:voice.s...@atmel.com wrote:
Hi Alex,
On 11/19/2012 10:55, alex wrote:
Hi MAINTAINER:
Now I develop our product based on sam9x25 EVK, and redefine our
NAND
partitions. I set u-boot environment in flash address0x8.
if saveenv and reset, u-boot will print can't find NAND flash.
If
I set u-boot environment in the address 0xc as EVK board, it's
OK. I
cant' know the reason.
Which u-boot version do you use? Please also paste the u-boot boot log
here.
Please also check the u-boot file size, will the env overlap with it?
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Dear alex, On 19.11.2012 11:23, alex wrote: Hi: Thanks, it can work now. BTW, one question whether the atmel' patch on v2010.6 is merged int u-boot mainline? if you provide a rebased version on current HEAD we will do so. 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] [PATCH 03/11] arm: ks8695eth: Use MAC address from environment
On Fri, 26 Oct 2012 23:37:28 +0200
Albert ARIBAUD albert.u.b...@aribaud.net wrote:
Hi Yann,
On Fri, 19 Oct 2012 10:02:09 +0200, Yann Vernier
yann.vern...@orsoc.se wrote:
On Thu, 18 Oct 2012 15:55:31 -0500
Joe Hershberger joe.hershber...@gmail.com wrote:
Hi Yann,
On Fri, Oct 5, 2012 at 7:09 AM, Yann Vernier
yann.vern...@orsoc.se wrote:
Removed board specific MAC reading code from driver.
Should move the reading to the cm4008/cm41xx board code.
---
drivers/net/ks8695eth.c | 38
+- 1 file changed, 9
insertions(+), 29 deletions(-)
diff --git a/drivers/net/ks8695eth.c b/drivers/net/ks8695eth.c
index b4904b6..2dda7ab 100644
--- a/drivers/net/ks8695eth.c
+++ b/drivers/net/ks8695eth.c
@@ -71,30 +71,13 @@ volatile uint8_t
ks8695_bufs[BUFSIZE*(TXDESCS+RXDESCS)] __attribute__((aligned(2
//
-/*
- * Ideally we want to use the MAC address stored in flash.
- * But we do some sanity checks in case they are not
present
- * first.
- */
-unsigned char eth_mac[] = {
- 0x00, 0x13, 0xc6, 0x00, 0x00, 0x00
-};
-
-void ks8695_getmac(void)
+static int ks8695_set_mac_address(struct eth_device *dev)
{
- unsigned char *fp;
- int i;
-
- /* Check if flash MAC is valid */
- fp = (unsigned char *) 0x0201c000;
- for (i = 0; (i 6); i++) {
- if ((fp[i] != 0) (fp[i] != 0xff))
- break;
- }
-
- /* If we found a valid looking MAC address then use it
*/
- if (i 6)
- memcpy(eth_mac[0], fp, 6);
+ /* Set MAC address */
+ ks8695_write(KS8695_LAN_MAC_LOW, (dev-enetaddr[5] |
(dev-enetaddr[4] 8) |
+ (dev-enetaddr[3] 16) | (dev-enetaddr[2]
24)));
+ ks8695_write(KS8695_LAN_MAC_HIGH, (dev-enetaddr[1] |
(dev-enetaddr[0] 8)));
+ return 0;
}
//
@@ -109,12 +92,8 @@ static int ks8695_eth_init(struct eth_device
*dev, bd_t *bd) ks8695_write(KS8695_LAN_DMA_TX, 0x8000);
ks8695_write(KS8695_LAN_DMA_RX, 0x8000);
- ks8695_getmac();
-
/* Set MAC address */
- ks8695_write(KS8695_LAN_MAC_LOW, (eth_mac[5] |
(eth_mac[4] 8) |
- (eth_mac[3] 16) | (eth_mac[2] 24)));
- ks8695_write(KS8695_LAN_MAC_HIGH, (eth_mac[1] |
(eth_mac[0] 8)));
+ ks8695_set_mac_address(dev);
Why do you set the MAC address here? It should be set for you by
the network infrastructure without this call.
Simply because I was not aware of this at the time. Before the
changes here the generic infrastructure could not do it, as
write_hwaddr was unimplemented, and I was just trying to preserve
function. The main reason I started poking at the network driver
was that it loaded the MAC from a hardcoded address in ROM,
obviously board specific (this is the magic number in [PATCH 11/11]
arm: cm4008, cm41xx: read MAC address from flash). It also has a
bug where it stops working after one command (i.e. can't tftp
twice), which I have not tracked down as yet.
/* Turn the 4 port switch on */
i = ks8695_read(KS8695_SWITCH_CTRL0);
@@ -150,7 +129,7 @@ static int ks8695_eth_init(struct eth_device
*dev, bd_t *bd) ks8695_write(KS8695_LAN_DMA_RX, 0x71);
ks8695_write(KS8695_LAN_DMA_RX_START, 0x1);
- printf(KS8695 ETHERNET: %pM\n, eth_mac);
+ printf(KS8695 ETHERNET: %pM\n, dev-enetaddr);
return 0;
}
@@ -234,6 +213,7 @@ int ks8695_eth_initialize(void)
dev-halt = ks8695_eth_halt;
dev-send = ks8695_eth_send;
dev-recv = ks8695_eth_recv;
+ dev-write_hwaddr = ks8695_set_mac_address;
strcpy(dev-name, ks8695eth);
eth_register(dev);
--
1.7.10.4
-Joe
What is the status for this patch? Are you going to drop it or submit
a new version?
Amicalement,
After some testing, I can conclude that removing the call to
set_mac_address actually breaks this code. This is because the first
section of ks8695_eth_init sets a reset bit, which resets all register
values including the MAC address. The debug message shows that this has
at some point been in an eth_reset() subroutine. The same reset bit is
set in ks8695_eth_halt(), which is why Linux does not see the MAC
address set by u-boot.
At this point, I do not know of a better approach than the patch as
submitted. Advice is welcome.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: ks8695: more macros for register values
Adding macros for more configurable lowlevel_init code. Also cleanup of some typos. --- Changes for v2: - Add spaces for legibility - Correct multiple #include protection to specify device --- arch/arm/include/asm/arch-ks8695/platform.h | 55 - arch/arm/include/asm/arch-ks8695/regvalues.h | 112 ++ 2 files changed, 149 insertions(+), 18 deletions(-) create mode 100644 arch/arm/include/asm/arch-ks8695/regvalues.h diff --git a/arch/arm/include/asm/arch-ks8695/platform.h b/arch/arm/include/asm/arch-ks8695/platform.h index de20015..a78d312 100644 --- a/arch/arm/include/asm/arch-ks8695/platform.h +++ b/arch/arm/include/asm/arch-ks8695/platform.h @@ -13,8 +13,8 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifndef __address_h -#define __address_h1 +#ifndef __ASM_ARM_ARCH_KS8695_PLATFORM_H__ +#define __ASM_ARM_ARCH_KS8695_PLATFORM_H__ #define KS8695_SDRAM_START 0x #define KS8695_SDRAM_SIZE 0x0100 @@ -27,19 +27,19 @@ #define KS8695_IO_BASE 0x03FF #define KS8695_IO_SIZE 0x0001 -#define KS8695_SYSTEN_CONFIG 0x00 -#define KS8695_SYSTEN_BUS_CLOCK0x04 +#define KS8695_SYSTEM_CONFIG0x00 +#define KS8695_SYSTEM_BUS_CLOCK 0x04 #define KS8695_FLASH_START 0x0280 #define KS8695_FLASH_SIZE 0x0040 -/*i/o control registers offset difinitions*/ +/* i/o control register offset definitions */ #define KS8695_IO_CTRL00x4000 #define KS8695_IO_CTRL10x4004 #define KS8695_IO_CTRL20x4008 #define KS8695_IO_CTRL30x400C -/*memory control registers offset difinitions*/ +/* memory control register offset definitions */ #define KS8695_MEM_CTRL0 0x4010 #define KS8695_MEM_CTRL1 0x4014 #define KS8695_MEM_CTRL2 0x4018 @@ -51,7 +51,7 @@ #define KS8695_SDRAM_BUFFER0x403C #define KS8695_SDRAM_REFRESH 0x4040 -/*WAN control registers offset difinitions*/ +/* WAN control register offset definitions */ #define KS8695_WAN_DMA_TX 0x6000 #define KS8695_WAN_DMA_RX 0x6004 #define KS8695_WAN_DMA_TX_START0x6008 @@ -63,7 +63,7 @@ #define KS8695_WAN_MAC_ELOW0x6080 #define KS8695_WAN_MAC_EHIGH 0x6084 -/*LAN control registers offset difinitions*/ +/* LAN control register offset definitions */ #define KS8695_LAN_DMA_TX 0x8000 #define KS8695_LAN_DMA_RX 0x8004 #define KS8695_LAN_DMA_TX_START0x8008 @@ -75,7 +75,7 @@ #define KS8695_LAN_MAC_ELOW0X8080 #define KS8695_LAN_MAC_EHIGH 0X8084 -/*HPNA control registers offset difinitions*/ +/* HPNA control register offset definitions */ #define KS8695_HPNA_DMA_TX 0xA000 #define KS8695_HPNA_DMA_RX 0xA004 #define KS8695_HPNA_DMA_TX_START0xA008 @@ -87,7 +87,7 @@ #define KS8695_HPNA_MAC_ELOW 0xA080 #define KS8695_HPNA_MAC_EHIGH 0xA084 -/*UART control registers offset difinitions*/ +/* UART control register offset definitions */ #define KS8695_UART_RX_BUFFER 0xE000 #define KS8695_UART_TX_HOLDING 0xE004 @@ -133,7 +133,7 @@ #define KS8695_UART_DIVISOR0xE01C #define KS8695_UART_STATUS 0xE020 -/*Interrupt controlller registers offset difinitions*/ +/* Interrupt controller register offset definitions */ #define KS8695_INT_CONTL 0xE200 #define KS8695_INT_ENABLE 0xE204 #define KS8695_INT_ENABLE_MODEM0x0800 @@ -154,19 +154,19 @@ #define KS8695_FIQ_PEND_PRIORITY0xE230 #define KS8695_IRQ_PEND_PRIORITY0xE234 -/*timer registers offset difinitions*/ +/* timer register offset definitions */ #define KS8695_TIMER_CTRL 0xE400 #define KS8695_TIMER1 0xE404 #define KS8695_TIMER0 0xE408 #define KS8695_TIMER1_PCOUNT 0xE40C #define KS8695_TIMER0_PCOUNT 0xE410 -/*GPIO registers offset difinitions*/ +/* GPIO register offset definitions */ #define KS8695_GPIO_MODE 0xE600 #define KS8695_GPIO_CTRL 0xE604 #define KS8695_GPIO_DATA 0xE608 -/*SWITCH registers offset difinitions*/ +/* SWITCH register offset definitions */ #define KS8695_SWITCH_CTRL00xE800 #define KS8695_SWITCH_CTRL10xE804 #define KS8695_SWITCH_PORT10xE808 @@ -184,13 +184,13 @@ #define KS8695_SWITCH_LPPM12 0xE874 #define KS8695_SWITCH_LPPM34 0xE878 -/*host communication registers difinitions*/ +/* host communication register definitions */ #define KS8695_DSCP_HIGH 0xE834 #define KS8695_DSCP_LOW0xE838 #define KS8695_SWITCH_MAC_HIGH 0xE83C #define KS8695_SWITCH_MAC_LOW 0xE840 -/*miscellaneours registers difinitions*/ +/* miscellaneous register definitions */ #define
Re: [U-Boot] [PATCH] arm: ks8695: more macros for register values
Sorry! I didn't remember this patch (regvalues.h) is where a poorly named macro (comment on patch 7/11, SDRAM parameters) was defined. I will fix it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2] omap: Invalidate first page to avoid speculation
Albert Aribaud: To make this affect only some CPUs or even boards, you can define and use a weak function which would handle filling the page-table; the weak, default, function would fill table[0] like others, while OMAP5 would have a strong version which would clear table[0]. Hi Albert, Thank you very much for your comments. Here is v2 of the patch, reworked to follow your advice. Comments are welcome. I think it is now cleaner to split it in two patches: [PATCH 1/2] ARM: cache: introduce weak arm_setup_identity_mapping [PATCH 2/2] ARM: OMAP5: redefine arm_setup_identity_mapping I picked the 'arm_setup_identity_mapping' name more or less arbitrarily, please advise if not. I verified this patch series on an OMAP5 HS device (with security) and on a GP device (without security), and both work for me. Best regards, V. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: cache: introduce weak arm_setup_identity_mapping
Separate the MMU identity mapping for ARM in a weak function, to allow
redefinition with platform specific function.
This is motivated by the need to unmap the region near address zero on HS OMAP
devices, to avoid speculative accesses. Accessing this region causes security
violations, which we want to avoid.
Signed-off-by: Vincent Stehlé v-ste...@ti.com
---
arch/arm/lib/cache-cp15.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 939de10..886fe5c 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -40,6 +40,17 @@ void __arm_init_before_mmu(void)
void arm_init_before_mmu(void)
__attribute__((weak, alias(__arm_init_before_mmu)));
+void __arm_setup_identity_mapping(u32 *page_table)
+{
+ int i;
+
+ /* Set up an identity-mapping for all 4GB, rw for everyone */
+ for (i = 0; i 4096; i++)
+ page_table[i] = i 20 | (3 10) | 0x12;
+}
+void arm_setup_identity_mapping(u32 *page_table)
+ __attribute__((weak, alias(__arm_setup_identity_mapping)));
+
static void cp_delay (void)
{
volatile int i;
@@ -72,9 +83,10 @@ static inline void mmu_setup(void)
u32 reg;
arm_init_before_mmu();
- /* Set up an identity-mapping for all 4GB, rw for everyone */
- for (i = 0; i 4096; i++)
- page_table[i] = i 20 | (3 10) | 0x12;
+
+ /* Set up an identity-mapping. Default version maps all 4GB rw for
+* everyone */
+ arm_setup_identity_mapping(page_table);
for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
dram_bank_mmu_setup(i);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: OMAP5: redefine arm_setup_identity_mapping
We introduce an OMAP5 specific version of arm_setup_identity_mapping(), which
makes the first page of the identity mapping invalid.
We want to unmap the region near address zero on HS OMAP devices, to avoid
speculative accesses. Accessing this region causes security violations, which
we want to avoid.
Signed-off-by: Vincent Stehlé v-ste...@ti.com
---
arch/arm/cpu/armv7/omap5/Makefile |1 +
arch/arm/cpu/armv7/omap5/cache-cp15.c | 40 +
2 files changed, 41 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap5/cache-cp15.c
diff --git a/arch/arm/cpu/armv7/omap5/Makefile
b/arch/arm/cpu/armv7/omap5/Makefile
index 9b261c4..49c454c 100644
--- a/arch/arm/cpu/armv7/omap5/Makefile
+++ b/arch/arm/cpu/armv7/omap5/Makefile
@@ -29,6 +29,7 @@ COBJS += hwinit.o
COBJS += clocks.o
COBJS += emif.o
COBJS += sdram.o
+COBJS += cache-cp15.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/omap5/cache-cp15.c
b/arch/arm/cpu/armv7/omap5/cache-cp15.c
new file mode 100644
index 000..506cc00
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/cache-cp15.c
@@ -0,0 +1,40 @@
+/*
+ * (C) Copyright 2002
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2012
+ * Vincent Stehlé, Texas Instruments, v-ste...@ti.com.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+/* OMAP5 specific function to set up the identity mapping. */
+void arm_setup_identity_mapping(u32 *page_table)
+{
+ /* Perform default mapping, which sets up an identity-mapping for all
+* 4GB, rw for everyone */
+ __arm_setup_identity_mapping();
+
+ /* First page (starting at 0x0) is made invalid to avoid speculative
+* accesses in secure rom. TODO: use second level descriptors for finer
+* grained mapping. */
+ page_table[0] = 0;
+}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
That makes perfect sense - should have thought it through myself. I moved the pxa patch to before Simon's LCD patchset. Testing MAKEALL -a arm now; should have a new pull request in a few hours. Thanks, Tom On Fri, Nov 16, 2012 at 5:12 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Tom, On Fri, 16 Nov 2012 16:42:49 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, Please pull u-boot-tegra/master into ARM/master. The previously failing pxa boards are fixed with 'pxa: Disable dcache on palmld, palmtc, zipitz2'. Sorry to be a nuisance, but what I meant that I wanted all commits in the tegra pull req to succeed building if possible; with the added disable cache commit, the branch succeeds, but not all of its commits, which can hamper git bisects. Can the dcache disable patch actually appear before Simon's LCD commit? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6 V2] EXYNOS5: FDT: Add I2C device node data
Hi, On Mon, Nov 19, 2012 at 12:54 AM, Heiko Schocher h...@denx.de wrote: Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: Add I2C device node data for exynos Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org --- Changes in V2: Added Periph id to the I2C device node arch/arm/dts/exynos-periph-id.dtsi | 35 + arch/arm/dts/exynos5250.dtsi | 73 2 files changed, 108 insertions(+), 0 deletions(-) create mode 100644 arch/arm/dts/exynos-periph-id.dtsi Acked-by: Heiko Schocher h...@denx.de I'm sorry to say that there is one problem with this. It is using a non-standard dtc feature (Stephen Warren's symbolic work), so I think we should wait until Rajeshwari updates it to avoid that. I believe he will do that soon. Regards, Simon bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features
Hi Jerry, On Sat, Nov 17, 2012 at 5:35 PM, Jerry Van Baren gvb.ub...@gmail.com wrote: Dear Simon, Sorry for being so late on this (the patches were submitted before the merge window closed). I've applied the patches to the next branch in the u-boot-fdt repo. http://git.denx.de/?p=u-boot/u-boot-fdt.git;a=shortlog;h=refs/heads/next I'm assuming these are still valid (Simon) and eligible to be applied to the v2013.01 u-boot release (Tom). If so, I'll submit a pull request. Yes still valid thank you. The only question is around the GPIO patch (http://patchwork.ozlabs.org/patch/194340/) since as Stephen pointed out there is discussion on the kernel list of whether to keep the polarity bit. I suppose we can always address that later if they decide to replace it with something else. On 10/25/2012 10:30 PM, Simon Glass wrote: This series contains a number of features related to CONFIG_OF_CONTROL, such as: - reading fdt values - reading configuration from the fdt - allowing the fdt to specify a boot command [snip] README | 11 + common/cmd_bootm.c | 11 + common/image.c | 127 common/main.c | 102 +- include/fdtdec.h | 121 + include/image.h|1 + lib/fdtdec.c | 107 +--- 7 files changed, 472 insertions(+), 8 deletions(-) Again, my apologies, No problem, we all have plenty to do! gvb Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Albert, please pull u-boot-tegra/master into ARM/master. Thanks! 'pxa' patch moved to before Simon's LCD patchset; MAKEALL -a arm AOK. The following changes since commit 7a5337732e3e05b2b0de1b592fa031b2c7b4f632: Rajeshwari Shinde (1): EXYNOS5: Enable SPI booting. are available in the git repository at: git://git.denx.de/u-boot-tegra master Allen Martin (1): tegra: add CONSOLE_MUX support to tegra-kbc Mayuresh Kulkarni (1): tegra: Enable display/lcd support on Seaboard Simon Glass (17): pxa: Disable dcache on palmld, palmtc, zipitz2 tegra: Use const for pinmux_config_pingroup/table() tegra: Add display support to funcmux tegra: fdt: Add pwm binding and node tegra: fdt: Add LCD definitions for Tegra tegra: Add support for PWM tegra: Add LCD driver tegra: Add LCD support to Nvidia boards arm: Add control over cachability of memory regions lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment lcd: Add support for flushing LCD fb from dcache after update tegra: Align LCD frame buffer to section boundary tegra: Support control of cache settings for LCD tegra: fdt: Add LCD definitions for Seaboard lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console tegra: Remove unnecessary CONFIG_SYS_NAND_BASE tegra: config: seaboard: Move tegra-common-post to correct place Stephen Warren (4): ARM: tegra: TrimSlice: add support for USB1 port mmc: tegra: support 4-bit operation too on 8-bit slots ARM: tegra: enable 8-bit SD slots in board files tegra: use generic fs commands in BOOTCOMMAND Wei Ni (1): tegra: Add SOC support for display/lcd README | 16 + arch/arm/cpu/armv7/cache_v7.c | 11 + arch/arm/cpu/armv7/tegra20/Makefile|2 + arch/arm/cpu/armv7/tegra20/display.c | 409 ++ arch/arm/cpu/armv7/tegra20/pwm.c | 101 + arch/arm/cpu/tegra20-common/funcmux.c | 37 ++ arch/arm/cpu/tegra20-common/pinmux.c |4 +- arch/arm/dts/tegra20.dtsi | 105 + arch/arm/include/asm/arch-tegra20/dc.h | 545 arch/arm/include/asm/arch-tegra20/display.h| 152 +++ arch/arm/include/asm/arch-tegra20/pinmux.h |4 +- arch/arm/include/asm/arch-tegra20/pwm.h| 75 arch/arm/include/asm/system.h | 31 ++ arch/arm/lib/cache-cp15.c | 51 ++- board/compal/paz00/paz00.c |5 +- board/compulab/dts/tegra20-trimslice.dts |3 +- board/compulab/trimslice/trimslice.c |8 + board/nvidia/common/board.c| 24 + board/nvidia/dts/tegra20-seaboard.dts | 33 ++ board/nvidia/harmony/harmony.c |5 +- board/nvidia/seaboard/seaboard.c |5 +- common/lcd.c | 89 - common/main.c | 12 +- doc/device-tree-bindings/pwm/tegra20-pwm.txt | 18 + doc/device-tree-bindings/video/displaymode.txt | 42 ++ doc/device-tree-bindings/video/tegra20-dc.txt | 85 drivers/input/tegra-kbc.c | 18 +- drivers/mmc/tegra_mmc.c|7 +- drivers/video/Makefile |1 + drivers/video/tegra.c | 379 include/configs/harmony.h |4 +- include/configs/palmld.h |3 + include/configs/palmtc.h |3 + include/configs/paz00.h|3 + include/configs/seaboard.h | 20 +- include/configs/tec.h |1 - include/configs/tegra-common-post.h| 39 +- include/configs/tegra20-common.h |3 + include/configs/trimslice.h|4 + include/configs/ventana.h |3 + include/configs/whistler.h |3 + include/configs/zipitz2.h |3 + include/fdtdec.h |2 + include/lcd.h | 11 + lib/fdtdec.c |2 + 45 files changed, 2303 insertions(+), 78 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra20/display.c create mode 100644 arch/arm/cpu/armv7/tegra20/pwm.c create mode 100644 arch/arm/include/asm/arch-tegra20/dc.h create mode 100644 arch/arm/include/asm/arch-tegra20/display.h create mode 100644 arch/arm/include/asm/arch-tegra20/pwm.h create mode 100644 doc/device-tree-bindings/pwm/tegra20-pwm.txt create mode 100644 doc/device-tree-bindings/video/displaymode.txt create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txt create mode 100644 drivers/video/tegra.c On Mon, Nov 19, 2012
Re: [U-Boot] [PATCH v4 1/7] vsprintf:fix: Change type returned by ustrtoul
On 11/09/2012 02:22 AM, Piotr Wilczek wrote: From: Lukasz Majewski l.majew...@samsung.com The ustrtoul shall convert string defined size (e.g. 1GiB) to unsigned long type (as its name implies). Up till now it had returned int, which might cause problems with large numbers (GiB range), when interpreted as U2 signed numbers. Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/7] gpt:doc: GPT (GUID Partition Table) documentation
On 11/09/2012 02:22 AM, Piotr Wilczek wrote:
Documentation of the GPT format.
diff --git a/doc/README.gpt b/doc/README.gpt
+Introduction:
+=
+This document describes the GPT partition table format when used with u-boot.
Why when used with U-Boot; U-Boot shouldn't influence the GPT
structure at all.
+GPT for marking disks/partitions is using the UUID. It is supposed to be a
+globally unique value. A UUID is a 16-byte (128-bit) number. The number of
+theoretically possible UUIDs is therefore about 3 × 10^38.
+More often UUID is stored as 32 hexadecimal digits, displayed in 5 groups
I don't think stored is too likely; displayed is more likely.
+Example usage:
+==
I would change that headline to something like Creating GPTs in
U-Boot; all the text above describes the GPT format itself, whereas
this text describes the specifics of some U-Boot commands, and so is not
an example of the preceding text.
+To restore GUID partition table one needs to:
+1. at ./include/configs/{board}.h
I don't think at ./include/configs/{board}.h is correct; you need to
define the partitions variable in the environment. The config file is
one way you could do this. I would re-write this as:
1. Define partition layout in the environment.
./include/configs/{board}.h may provide a value that describes the
recommended layout if desired.
+ - define partitions= environment variable with format:
+ name=..,size=..,uuid=..;...
+ values for every key can be passed as text or environment variable
+ examples:
+ name=u-boot,size=60M;name=kernel,size=60M;name=platform,size=1G;
+ name=${uboot_name},size=${uboot_size},uuid=${uboot_uuid};...
+
+2. From u-boot prompt type:
+ gpt mmc 0
+ or
+ gpt mmc 0 partitions
Shouldn't that be ${partitions} not partitions?
+For emergency usage (or when list of UUIDs cannot be provided) the
internal
+GUID generator shall be used. It uses gd-start_addr_sp as a primary source
of
+UUID generator (16B).
What does (16B) mean here?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] part:efi: Move part_efi.h file to ./include
On 11/09/2012 02:22 AM, Piotr Wilczek wrote:
From: Lukasz Majewski l.majew...@samsung.com
This move is necessary to export gpt header and GPT partition entries to be
used with other commands or subsystems (like DFU in the future)
Additionally the part_efi.h file has been cleaned-up to supress checkpatch's
warnings.
{disk = include}/part_efi.h |0
I can understand the gpt command perhaps needing access to the
GPT-specific types, but I would hope that anything DFU-related would be
using types from include/part.h; I don't imagine that DFU would need to
know anything about GPT at all?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/7] gpt: The leXX_to_int() calls replaced with ones defined at compiler.h
On 11/09/2012 03:48 AM, Piotr Wilczek wrote:
Custom definitions of le_XX_to_int functions have been replaced with
standard ones, defined at compiler.h
Replacement of several GPT related structures members with ones
indicating its endianness and proper size.
diff --git a/disk/part_efi.c b/disk/part_efi.c
printf(%3d\t0x%08llx\t0x%08llx\t\%s\\n, (i + 1),
- le64_to_int(gpt_pte[i].starting_lba),
- le64_to_int(gpt_pte[i].ending_lba),
+ (u64) le64_to_cpu(gpt_pte[i].starting_lba),
+ (u64) le64_to_cpu(gpt_pte[i].ending_lba),
I don't think there should be a space after the cast. Why doesn't
le64_to_cpu() return a u64? The same comments apply to many diffs in
this patch.
- if (calc_crc32 != le32_to_int(crc32_backup)) {
+ if (calc_crc32 != le32_to_cpu(crc32_backup)) {
printf(GUID Partition Table Header CRC is wrong:
- 0x%08lX != 0x%08lX\n,
- le32_to_int(crc32_backup), calc_crc32);
+ 0x%x != 0x%x\n,
+(u32) le32_to_cpu(crc32_backup), calc_crc32);
Indentation looks wrong (some lines use spaces, some TABs).
- if (calc_crc32 != le32_to_int(pgpt_head-partition_entry_array_crc32)) {
+ if (calc_crc32 != le32_to_cpu(pgpt_head-partition_entry_array_crc32)) {
printf(GUID Partition Table Entry Array CRC is wrong:
- 0x%08lX != 0x%08lX\n,
- le32_to_int(pgpt_head-partition_entry_array_crc32),
+ 0x%x != 0x%x\n,
+(u32)le32_to_cpu(pgpt_head-partition_entry_array_crc32),
Same here.
Aside from that, briefly,
Reviewed-by: Stephen Warren swar...@nvidia.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nios/master
On Sat, Nov 10, 2012 at 08:09:58PM +0800, Thomas Chou wrote: Hi Tom, Please add these patches to fix the compilation error of nios2 arch after v2013.01-rc1. Best regards, Thomas The following changes since commit 59852d03867108217fe88e3bfc3e1e9cedfe63c5: Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2012-11-09 08:47:25 -0700) are available in the git repository at: git://git.denx.de/u-boot-nios.git master for you to fetch changes up to db71964235c1dfa13ec398da483b0bdbbf31d5b7: nios2: remove asm/status_led.h (2012-11-10 19:45:58 +0800) Thomas Chou (2): nios2: use builtin functions for control registers access nios2: remove asm/status_led.h arch/nios2/include/asm/status_led.h | 31 --- include/configs/PK1C20.h| 1 + include/configs/nios2-generic.h | 1 + include/nios2.h | 12 ++-- include/status_led.h| 3 --- 5 files changed, 4 insertions(+), 44 deletions(-) delete mode 100644 arch/nios2/include/asm/status_led.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-staging
On Wed, Nov 14, 2012 at 02:52:59PM +0100, Anatolij Gustschin wrote:
Hello Tom,
The following changes since commit 1cc619be8b73abbee2fd6faf2cd4ade27b516531:
Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-11-05
09:46:45 -0700)
are available in the git repository at:
git://git.denx.de/u-boot-staging.git ag...@denx.de
Alejandro Mery (1):
fs: zfs: fix illegal use of fp
Andreas Bießmann (2):
Makefile: silence 'make clean'
fs/fs.c: do_fsload: measure throughput
Jens Scharsig (BuS Elektronik) (1):
M68K: eb_cpu5282: general update and enhanced board support
Robert P. J. Day (1):
cmd_mmc.c: Fix typo, dislay - display
Scott Wood (1):
nand_spl: fix u-boot.lst breakage
Simon Glass (1):
patman: Issue empty change logs for unchanged patches
Stefan Roese (1):
MAKEALL: Add spear platform target to compile all SPEAr boards
Łukasz Majewski (26):
pmic:i2c: Handle PMIC I2C transmission comprising of two bytes
pmic:i2c: Add I2C sensor byte order (big/little) to PMIC framework
pmic:max8997: Switch the MAX8997 PMIC to be used with multibus I2C
pmic: Extend PMIC framework to support multiple instances of PMIC
devices
pmic: Introduce power_init_board() method at ./lib/board.c file
pmic: Enable power_board_init() support at TRATS
pmic:chrg: Common information about charger and battery (power_chrg.h)
pmic: Move pmic related code to ./drivers/power directory
pmic: Extend struct pmic to support battery and charger related
operations
pmic:battery: Support for Trats Battery at PMIC framework
pmic:muic: Support for MUIC built into MAX8997 device
pmic:fuel-gauge: Support for MAX17042 fuel-gauge
pmic:max8997: Function for calculating LDO internal register value
arm:trats:pmic: Default PMIC(MAX8997) initialization for Samsung's
TRATS board
arm:trats:pmic: Enable MUIC (MAX8997) at Samsung's TRATS board
arm:trats:pmic: Enable fuel-gauge (MAX17042) at Samsung's TRATS board
arm:trats:pmic: Enable battery support at Samsung's TRATS board
pmic:max8997: Support for MAX8997 internal charger control
arm:trats:pmic: Power consumption reduction state for Samsung's TRATS
board
arm:trats:pmic: Support for charging battery at Samsung's TRATS board
pmic: Extend PMIC framework to support battery related commands
power:pmic: Rename ./drivers/power/pmic_* to ./drivers/power/power_*
files
power:pmic: Rename CONFIG_PMIC* defines to CONFIG_POWER
power:pmic: Rename CONFIG_DIALOG_PMIC defines to CONFIG_DIALOG_POWER
arm:goni:pmic: Adjust GONI target platform board to new PMIC framework
arm:universal_c210:pmic: Adjust C210 Universal target platform board to
new PMIC framework
MAKEALL|6 +
Makefile |7 +-
arch/arm/lib/board.c |8 +
board/BuS/eb_cpu5282/Makefile |2 +-
board/BuS/eb_cpu5282/cfm_flash.c | 212 --
board/BuS/eb_cpu5282/cfm_flash.h | 40 --
board/BuS/eb_cpu5282/eb_cpu5282.c | 110 --
board/BuS/eb_cpu5282/flash.c | 415
board/davedenx/qong/qong.c | 12 +-
board/freescale/mx31pdk/mx31pdk.c | 12 +-
board/freescale/mx35pdk/mx35pdk.c | 14 +-
board/freescale/mx51evk/mx51evk.c | 12 +-
board/freescale/mx53evk/mx53evk.c | 12 +-
board/freescale/mx53loco/mx53loco.c| 21 +-
board/genesi/mx51_efikamx/efikamx.c| 12 +-
board/hale/tt01/tt01.c | 14 +-
board/samsung/goni/goni.c | 22 +-
board/samsung/trats/trats.c| 292 +-
board/samsung/universal_c210/universal.c | 27 +-
board/ttcontrol/vision2/vision2.c | 12 +-
boards.cfg |2 +-
common/cmd_mmc.c |2 +-
drivers/misc/Makefile |7 -
drivers/misc/pmic_core.c | 147 ---
drivers/power/Makefile | 12 +-
.../config.mk = drivers/power/battery/Makefile| 34 ++-
drivers/power/battery/bat_trats.c | 100 +
.../config.mk = drivers/power/fuel_gauge/Makefile | 34 ++-
drivers/power/fuel_gauge/fg_max17042.c | 250
drivers/power/pmic/Makefile| 49 +++
drivers/power/pmic/muic_max8997.c | 90 +
drivers/power/pmic/pmic_max8997.c | 123 ++
drivers/{misc =
Re: [U-Boot] Pull request: u-boot-video/master
On Wed, Nov 14, 2012 at 02:56:49PM +0100, Anatolij Gustschin wrote: Hello Tom, The following changes since commit 1cc619be8b73abbee2fd6faf2cd4ade27b516531: Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-11-05 09:46:45 -0700) are available in the git repository at: git://git.denx.de/u-boot-video.git master Bo Shen (1): video: atmel: implement lcd_setcolreg function Jens Scharsig (BuS Elektronik) (1): Video: fix compiler warnings in bus_vcxk Liu Ying (1): ipu common: reset ipuv3 correctly Stefan Reinauer (2): video: Provide an API to access video parameters video: Implement additional video API functions in cfb_console Tom Wai-Hong Tam (2): lcd: Fix BMP decode bug that skips the wrong padded row lcd: Implement RLE8 bitmap decoding Vadim Bendebury (2): lcd: Provide an API to access LCD parameters video: Skip bitmaps which do not fit into the screen in cfb_console Vikram Narayanan (2): mx51evk: Fix build error when CONFIG_VIDEO is disabled mx53loco: Fix build error when CONFIG_VIDEO is disabled README |5 + arch/arm/include/asm/imx-common/mx5_video.h | 21 +++ board/freescale/mx51evk/Makefile|4 +- board/freescale/mx51evk/mx51evk.c | 57 + board/freescale/mx51evk/mx51evk_video.c | 81 board/freescale/mx53loco/Makefile |4 +- board/freescale/mx53loco/mx53loco.c | 66 +-- board/freescale/mx53loco/mx53loco_video.c | 94 ++ common/cmd_bmp.c|5 +- common/lcd.c| 178 ++- drivers/video/atmel_hlcdfb.c| 12 ++ drivers/video/bus_vcxk.c|2 +- drivers/video/cfb_console.c | 49 drivers/video/ipu_common.c | 10 ++ include/atmel_hlcdc.h |7 + include/lcd.h | 36 ++ include/video.h | 48 +++ 17 files changed, 550 insertions(+), 129 deletions(-) create mode 100644 arch/arm/include/asm/imx-common/mx5_video.h create mode 100644 board/freescale/mx51evk/mx51evk_video.c create mode 100644 board/freescale/mx53loco/mx53loco_video.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Moschip ethernet adapter is not seen as ethernet device
Sorry for duplication previous post.
If this configuration doesn't work, could you instruct how to write a
driver for this dongle?
2012/11/18 valdez valdez valdez...@gmail.com:
Hello,
I tried use my USB ETH adapter. Following README files I addes into
beagle.h file (my board is beagleboard) this:
#define CONFIG_USB_HOST_ETHER/* Enable USB Ethernet adapters */
#define CONFIG_USB_ETHER_ASIX/* Asix, or whatever driver(s) you want */
#define CONFIG_CMD_NET
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
#define CONFIG_BOOTP_SUBNETMASK
#define CONFIG_BOOTP_GATEWAY
#define CONFIG_BOOTP_HOSTNAME
#define CONFIG_BOOTP_BOOTPATH
and into asix.c file this:
{ 0x9710, 0x7830, FLAG_TYPE_AX88172},
I based on what my host Linux showed to me:
Vendor specific, USB Revision 2.0
- Moschip Semiconductor UA0025C 6e003e8f
- Class: Vendor specific
- PacketSize: 64 Configurations: 1
- Vendor: 0x9710 Product 0x7830 Version 1.0
Configuration: 1
- Interfaces: 1 Bus Powered Remote Wakeup 500mA
Interface: 0
- Alternate Setting 0, Endpoints: 3
- Class Vendor specific
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512
- Endpoint 3 In Interrupt MaxPacket 16 Interval 1ms
But U-Boot don't see it as Ethernet Device, it only recognize it in tree:
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
OMAP3 beagleboard.org # usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Vendor specific (480 Mb/s, 500mA)
Moschip Semiconductor UA0025C 6e003e8f
Could you help me with this, please?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/7] gpt: Support for GPT (GUID Partition Table) restoration
On 11/09/2012 03:48 AM, Piotr Wilczek wrote:
The restoration of GPT table (both primary and secondary) is now possible.
Simple GUID generation is supported.
diff --git a/include/part.h b/include/part.h
+int set_gpt_table(block_dev_desc_t *dev_desc,
+ gpt_header *gpt_h, gpt_entry *gpt_e);
+void gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
+ disk_partition_t *partitions[], int parts);
+void gpt_fill_header(block_dev_desc_t *dev_desc, gpt_header *gpt_h);
+void gpt_fill(block_dev_desc_t *dev_desc, disk_partition_t *partitions[],
+ const int parts_count);
Why const?
Some documentation for these functions (particularly high-level
information such as which order you'd expect to call them and why/what
for) would be useful in the header rather than the .c file; the header
is where people would go to find out what functions they can call, so
making them also go look in the .c file would be a bit annoying.
diff --git a/disk/part_efi.c b/disk/part_efi.c
+static int set_protective_mbr(block_dev_desc_t *dev_desc);
+
+static void guid_dump(u8 *guid, int i);
+
+static void guid_gen(const u32 *pool, u8 *guid);
+
+static int convert_uuid(char *uuid, u8 *dst);
+
+static void set_part_name(efi_char16_t *part_name, char *name);
There probably should be a CONFIG_ option required to enable this new
feature, so people who don't want it don't suffer code bloat.
Do you really need the blank lines between prototypes?
I suspect you can re-order the functions so that none of the prototypes
are needed anyway.
+/**
+ * set_gpt_table() - Restore the GUID Partition Table
write would probably be better than set.
+ *
+ * @param dev_desc - block device descriptor
+ * @param parts - number of partitions
+ * @param size - pointer to array with each partition size
+ * @param name - pointer to array with each partition name
Those last 3 lines don't match the prototype.
+ * @return - zero on success, otherwise error
+ */
+int set_gpt_table(block_dev_desc_t *dev_desc,
+ gpt_header *gpt_h, gpt_entry *gpt_e)
Presumably the code assumes that gpt_e always has 128(?) entries.
Instead of taking a pointer, should the function take an array:
gpt_entry gpt_e[GPT_ENTRY_NUMBERS] to enforce this?
+{
+ const int pte_blk_num = (GPT_ENTRY_NUMBERS * sizeof(gpt_entry)) /
+ dev_desc-blksz;
Related, this hard-codes the number of ptes as GPT_ENTRY_NUMBERS,
whereas ...
+ u32 calc_crc32;
+ u64 val;
+
+ debug(max lba: %x\n, (u32) dev_desc-lba);
+ /* Setup the Protective MBR */
+ if (set_protective_mbr(dev_desc) 0)
+ goto err;
+
+ /* Generate CRC for the Primary GPT Header */
+ calc_crc32 = efi_crc32((const unsigned char *)gpt_e,
+ le32_to_cpu(gpt_h-num_partition_entries) *
+ le32_to_cpu(gpt_h-sizeof_partition_entry));
... here, gpt_h-num_partition_entries is used instead. Should both
places use the same size (entry count) definition?
+ if (dev_desc-block_write(dev_desc-dev, 2, pte_blk_num, gpt_e)
+ != pte_blk_num)
+ goto err;
Here, we assume GPT_ENTRY_NUMBERS entries in gpt_e. If the array isn't
that big, the block_write() above will read past the end of it.
+ puts(GPT successfully written to block device!\n);
Isn't that something that a command should be doing, not a utility
function? I'd rather have this function not print anything, except
perhaps on errors, just like typical Unix command-line applications.
+void gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
+ disk_partition_t *partitions[], int parts)
Why is partitions an array of pointers rather than an array of partitions?
+{
+ u32 offset = (u32) le32_to_cpu(gpt_h-first_usable_lba);
I don't think there should be a space after the cast. The same comment
probably applies elsewhere.
+ for (i = 0; i parts; i++) {
+ /* partition starting lba */
+ start = partitions[i]-start;
+ if (start (offset = start))
+ gpt_e[i].starting_lba = cpu_to_le32(start);
+ else
+ gpt_e[i].starting_lba = cpu_to_le32(offset);
That seems a little odd. The else branch seems fine when !start, but
what about when (start (offset start))? Shouldn't that be an error,
rather than just ignoring the requested start value?
Why can't partitions be out of order? IIRC, the GPT spec allows it.
+ /* partition ending lba */
+ if (i != parts - 1)
+ gpt_e[i].ending_lba =
+ cpu_to_le64(offset - 1);
+ else
+ gpt_e[i].ending_lba = gpt_h-last_usable_lba;
Why extend the last partition to fill the disk; why not simply always
use the requested size? If a fill to max size option is implemented,
the user might not want it to apply to the last partition, but perhaps
Re: [U-Boot] [U-Boot,2/3] nand: Fix nand_erase_opts() offset check
Dear Scott Wood, On Friday, November 16, 2012 1:23:20 AM, Scott Wood wrote: On Mon, Nov 05, 2012 at 10:16:15AM -, =?utf-8?q?Beno=C3=AEt_Th=C3=A9baudeau_=3Cbenoit=2Ethebaudeau=40advans?==?utf-8?q?ee=2Ecom=3E?= wrote: NAND Flash is erased by blocks, not by pages. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Scott Wood scottw...@freescale.com Applied to u-boot-nand-flash Thanks. I still don't see it on gitweb. Usually, this takes at most a few hours. Is there a mirror sync issue or something? Unless this is a manual operation for you? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] part:efi: Move part_efi.h file to ./include
On Mon, Nov 19, 2012 at 12:30:02PM -0700, Stephen Warren wrote:
On 11/09/2012 02:22 AM, Piotr Wilczek wrote:
From: Lukasz Majewski l.majew...@samsung.com
This move is necessary to export gpt header and GPT partition entries to be
used with other commands or subsystems (like DFU in the future)
Additionally the part_efi.h file has been cleaned-up to supress checkpatch's
warnings.
{disk = include}/part_efi.h |0
I can understand the gpt command perhaps needing access to the
GPT-specific types, but I would hope that anything DFU-related would be
using types from include/part.h; I don't imagine that DFU would need to
know anything about GPT at all?
Indeed. DFU must not get coupled to GPT (or for that matter,
partitions) in the general code. There should be DFU write to a
GPT-using backing store code, if that's needed. Not all eMMC would be
GPT-using, for example.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] gpt: GUID Partition Table (GPT) restoration
On Fri, Nov 09, 2012 at 10:22:11AM +0100, Piotr Wilczek wrote: This patch series provides a new command - gpt for eMMC partition table (in the GPT format) restoration. As a pre-work, some cleanup at the part_efi.c file was performed to remove custom macros and make GPT related structures more readable. Moreover the part_efi.h file has been moved to ./include directory to be easily available from other subsystems. The GPT detailed description has been written to README.gpt file. Please make sure that 0/7 of v5 includes the summary of changes from v4 (and from v3 and v2 and ...). patman helps you get this for free, btw :) Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: OMAP5: redefine arm_setup_identity_mapping
On Mon, Nov 19, 2012 at 03:59:34PM +0100, Vincent Stehlé wrote: We introduce an OMAP5 specific version of arm_setup_identity_mapping(), which makes the first page of the identity mapping invalid. We want to unmap the region near address zero on HS OMAP devices, to avoid speculative accesses. Accessing this region causes security violations, which we want to avoid. Signed-off-by: Vincent Stehlé v-ste...@ti.com [snip] + /* Perform default mapping, which sets up an identity-mapping for all + * 4GB, rw for everyone */ /* * Multi-line comments must all be like this. */ Aside from that (and the comment to 1/2) I think we're good here, including the naming of the function. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/3] nand: Fix nand_erase_opts() offset check
On 11/19/2012 02:40:31 PM, Benoît Thébaudeau wrote: Dear Scott Wood, On Friday, November 16, 2012 1:23:20 AM, Scott Wood wrote: On Mon, Nov 05, 2012 at 10:16:15AM -, =?utf-8?q?Beno=C3=AEt_Th=C3=A9baudeau_=3Cbenoit=2Ethebaudeau=40advans?==?utf-8?q?ee=2Ecom=3E?= wrote: NAND Flash is erased by blocks, not by pages. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Scott Wood scottw...@freescale.com Applied to u-boot-nand-flash Thanks. I still don't see it on gitweb. Usually, this takes at most a few hours. Is there a mirror sync issue or something? Unless this is a manual operation for you? I'm waiting to get an ack from Andy for the mpc85xx bits before I push my tree, lest I have history that needs changing. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/3] nand: Clean up nand_util
On Fri, Nov 16, 2012 at 08:20:50AM +0100, Andreas Bießmann wrote: Dear Scott Wood, On 16.11.12 01:29, Scott Wood wrote: On 11/15/2012 06:22:11 PM, Scott Wood wrote: On Mon, Nov 05, 2012 at 10:15:46AM -, =?utf-8?q?Beno=C3=AEt_Th=C3=A9baudeau_=3Cbenoit=2Ethebaudeau=40advans?==?utf-8?q?ee=2Ecom=3E?= wrote: Sigh, it looks like either patchwork is mangling the From address or mutt is failing to understand something valid (I assume the latter since git am didn't seem to have a problem with it)... I don't see this encoding in the original e-mail. patchwork has no influence her. AFAIK the mail header should only contain ASCII, therefore the 'From:' header content is itself encoded. This snippet manage to decode Benoîts name correctly: ---8--- perl -MEncode -e 'binmode(STDOUT, :utf8); print Encode::decode(MIME-Header, =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= benoit.thebaud...@advansee.com);' ---8--- git and even patchwork [1] can decode it, but it seems your mutt rule to setup the rely mail is broken. Maybe [2] can help here? I don't quite know what's going on here, but I also have this problem when replying to bundles from patchwork (which of course 'git am' fine) but not when replying to emails via IMAP. I've just been fixing this up by hand however (since it's correct in the email body). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: cache: introduce weak arm_setup_identity_mapping
On Mon, Nov 19, 2012 at 03:59:33PM +0100, Vincent Stehlé wrote:
Separate the MMU identity mapping for ARM in a weak function, to allow
redefinition with platform specific function.
This is motivated by the need to unmap the region near address zero on HS OMAP
devices, to avoid speculative accesses. Accessing this region causes security
violations, which we want to avoid.
Signed-off-by: Vincent Stehlé v-ste...@ti.com
---
arch/arm/lib/cache-cp15.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 939de10..886fe5c 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -40,6 +40,17 @@ void __arm_init_before_mmu(void)
void arm_init_before_mmu(void)
__attribute__((weak, alias(__arm_init_before_mmu)));
+void __arm_setup_identity_mapping(u32 *page_table)
+{
+ int i;
+
+ /* Set up an identity-mapping for all 4GB, rw for everyone */
+ for (i = 0; i 4096; i++)
+ page_table[i] = i 20 | (3 10) | 0x12;
+}
+void arm_setup_identity_mapping(u32 *page_table)
+ __attribute__((weak, alias(__arm_setup_identity_mapping)));
Please use __weak as found in linux/compiler.h, thanks.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/7] gpt: Support for new gpt command
On 11/09/2012 03:48 AM, Piotr Wilczek wrote:
New command - gpt is supported. It restores the GPT partition table.
It looks into the partitions environment variable for partitions definition.
It can be enabled at target configuration file with CONFIG_CMD_GPT.
Simple UUID generator has been implemented. It uses the the gd-start_addr_sp
for entrophy pool. Moreover the pool address is used as crc32 seed.
diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
+U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
+ GUID Partition Table,
+ interface dev partions list\n
+ partions list is in format: name=..,size=..,uuid=..;...\n
+ and can be passed as env or string ex.:\n
+ gpt mmc 0 partitions\n
I don't think that form makes sense. The user should just pass
${partitions} instead. The command can't know for certain whether the
user actually intended to pass the text partitions and made a mistake,
or whether they passed an environment variable. If you really want to be
able to pass an environment variable name, an explicit command-line
option such as:
gpt mmc 0 name=... # definition on cmd-line
gpt mmc 0 --from-environment partitions # definition in environment
seems best.
+ gpt mmc 0 \name=..,size=..;name=..,size=..;...\\n
+ gpt mmc 0 \name=${part1_name},size=..;name=..,size=..;...\\n
+ - GUID partition table restoration\n
+ Restore GPT information on a device connected\n
+ to interface\n
Is writing a GPT to a device the only thing the gpt command will ever
do. It seems best to require the user to write gpt write mmc 0 ...
from the very start, so that if e.g. gpt fix-crcs or gpt
interactive-edit or gpt delete-partition 5 are implemented in the
future, existing scripts won't have to change to add the write parameter.
+/**
+ * extract_env(): Convert string from '{env_name}' to 'env_name'
s//$/
It's doing more than that; it locates that syntax within an arbitrary
string and ignores anything before ${ or after }. Is that intentional?
+static int extract_env(char *p)
+ p1 = strstr(p, ${);
+ p2 = strstr(p, });
+
+ if (p1 p2) {
+ *p2 = '\0';
+ memmove(p, p+2, p2-p1-1);
s/-1/-2/ I think, since the length of ${ is 2 not 1.
Spaces around operators? s/p+2/p + 2/ for example.
+/**
+ * extract_val(): Extract value from a key=value pair
+ *
+ * @param p - pointer to string
Pointer to pointer to string, given its type?
+ * @param tab - table to store extracted value
+ * @param i - actual tab element to work on
Table? Why not just pass in char **tab and get rid of i.
+static int extract_val(char **p, char *tab[], int i, char *key)
+{
+ char *t, *e, *tok = *p;
+ char *k;
Those variable names are not exactly descriptive.
+ t = strsep(tok, ,);
+ k = t;
+ strsep(t, =);
+
+ if (key strcmp(k, key))
+ return -2;
+
+ if (extract_env(t) == 0) {
Hmm. That only allows key=${value}. What about key=text${envothertext or
key=${env1}foo${env2}? Isn't there some generic code that can already
expand environment variables within strings so we don't have to
re-invent it here?
+ tab[i] = calloc(strlen(t) + 1, 1);
+ if (tab[i] == NULL) {
+ printf(%s: calloc failed!\n, __func__);
+ return -1;
+ }
+ strcpy(tab[i], t);
Isn't strdup() available?
+static int set_gpt_info(block_dev_desc_t *dev_desc, char *str_part,
+ disk_partition_t *partitions[], const int parts_count)
+{
+ char *ps[parts_count];
Can we call this sizes? Can't we call strtoul() and store int sizes[]
rather than storing the strings first and then converting to integers in
a separate piece of disconnected code?
+ printf(PARTITIONS: %s\n, s);
Why print that?
+ ss = calloc(strlen(s) + 1, 1);
+ if (ss == NULL) {
+ printf(%s: calloc failed!\n, __func__);
+ return -1;
+ }
+ memcpy(ss, s, strlen(s) + 1);
Use strdup().
That duplicates the strdup() in do_gpt() some of the time.
+ for (i = 0, p = ss; i parts_count; i++) {
Why not calculate parts_count here, rather than splitting the parsing
logic between this function and gpt_mmc_default()?
+ tok = strsep(p, ;);
+ if (tok == NULL)
+ break;
+
+ if (extract_val(tok, name, i, name)) {
+ ret = -1;
+ goto err;
+ }
+
+ if (extract_val(tok, ps, i, size)) {
+ ret = -1;
+ free(name[i]);
+ goto err;
+ }
I think that requires the parameters to be passed in order
name=foo,size=5,uuid=xxx. That seems inflexible. The syntax may as well
just be value,value,value rather than key=value,key=value,key=value in
that case (although the keys are useful in order to understand the data,
so I'd prefer parsing flexibility rather than
Re: [U-Boot] common/xyzmodem.c, ymodem, slow behavior receiving bytes
Hi all, i finally found an issue in cache initialization for this cpu. Setting correct CACR / ACR regs solved the issue. Many thanks, Best Regards Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common/xyzmodem.c, ymodem, slow behavior receiving bytes
Dear Angelo, In message 20121119215454.GA7107@angel3 you wrote: i finally found an issue in cache initialization for this cpu. Setting correct CACR / ACR regs solved the issue. Ah! Thanks a lot for the feedback. I'm glad my initial suspicions were right. Can you please post some hints / patches what needs to be fixed, and where? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Do not underestimate the value of print statements for debugging. Don't have aesthetic convulsions when using them, either. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
Tom, please apply this onto u-boot/master ... I've been waiting for you to return with this pull. The following changes since commit 178d0cc1a4c73c3341afbeb2a93b172de8c96bd1: Merge branch 'master' of git://git.denx.de/u-boot-video (2012-11-19 09:28:04 -0700) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 7bae844f2dacd1b75f65e37624778a15e132f5e1: usb: r8a6659: Fix build by missing of parenthesis (2012-11-20 00:16:08 +0100) Allen Martin (4): USB: make usb_kbd obey USB DMA alignment requirements tegra: move TEGRA_DEVICE_SETTINGS to tegra-common-post.h tegra: Enable USB keyboard USB: add arrow key support to usb_kbd Ilya Yanok (13): linux/usb/ch9.h: update with the version from Linux tree usb: use linux/usb/ch9.h instead of usbdescriptors.h musb-new: port of Linux musb driver musb-new: dsps backend driver am33xx: init OTG hardware and new musb gadget driver am335x_evm: enable both musb gadget and host musb-new: am35x backend driver OMAP3: am35x_def.h: add USB defines OMAP3: am35x: add musb functions am3517_evm: switch to musb-new musb-new: omap2plus backend driver omap3_beagle: add musb-new init omap3_beagle: use new MUSB intstead of the old one Jeroen Hofstee (1): boards: remove the no longer used CONFIG_EHCI_DCACHE Nobuhiro Iwamatsu (2): usb: r8a66597: Switched from variable to only macro usb: r8a6659: Fix build by missing of parenthesis Makefile |1 + arch/arm/cpu/armv7/am33xx/board.c | 85 +++ arch/arm/cpu/armv7/am33xx/clock.c |8 + arch/arm/cpu/armv7/omap3/Makefile |1 + arch/arm/cpu/armv7/omap3/am35x_musb.c | 75 +++ arch/arm/include/asm/arch-am33xx/cpu.h| 11 +- arch/arm/include/asm/arch-am33xx/hardware.h |4 + arch/arm/include/asm/arch-omap3/am35x_def.h | 27 + arch/arm/include/asm/arch-omap3/musb.h| 28 + arch/arm/include/asm/omap_musb.h | 32 + arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c |2 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c |2 +- arch/powerpc/cpu/ppc4xx/usb_ohci.c|2 +- board/logicpd/am3517evm/am3517evm.c | 74 +++ board/ti/am335x/board.c | 23 +- board/ti/beagle/beagle.c | 43 ++ common/cmd_usb.c |2 +- common/usb.c |4 +- common/usb_kbd.c | 18 +- drivers/usb/gadget/config.c |1 - drivers/usb/gadget/epautoconf.c |1 - drivers/usb/gadget/ether.c|1 - drivers/usb/gadget/gadget_chips.h |4 +- drivers/usb/gadget/s3c_udc_otg.c |1 - drivers/usb/gadget/usbstring.c|1 - drivers/usb/host/ehci-hcd.c | 16 +- drivers/usb/host/isp116x-hcd.c|2 +- drivers/usb/host/ohci-hcd.c |2 +- drivers/usb/host/ohci-s3c24xx.c |2 +- drivers/usb/host/r8a66597-hcd.c | 17 +- drivers/usb/host/sl811-hcd.c |2 +- drivers/usb/musb-new/Makefile | 39 ++ drivers/usb/musb-new/am35x.c | 709 + drivers/usb/musb-new/linux-compat.h | 116 drivers/usb/musb-new/musb_core.c | 2497 ++ drivers/usb/musb-new/musb_core.h | 623 +++ drivers/usb/musb-new/musb_debug.h | 58 ++ drivers/usb/musb-new/musb_dma.h | 186 ++ drivers/usb/musb-new/musb_dsps.c | 771 +++ drivers/usb/musb-new/musb_gadget.c| 2333 + drivers/usb/musb-new/musb_gadget.h| 130 drivers/usb/musb-new/musb_gadget_ep0.c| 1089 drivers/usb/musb-new/musb_host.c | 2400 +++ drivers/usb/musb-new/musb_host.h | 114 drivers/usb/musb-new/musb_io.h| 146 + drivers/usb/musb-new/musb_regs.h | 645 +++ drivers/usb/musb-new/musb_uboot.c | 237 +++ drivers/usb/musb-new/omap2430.c | 626 +++ drivers/usb/musb-new/omap2430.h | 56 ++ drivers/usb/musb-new/usb-compat.h | 88 +++ drivers/usb/musb/musb_core.h |3 +- drivers/usb/musb/musb_hcd.c |5 +- include/configs/am335x_evm.h | 27 +
Re: [U-Boot] [PATCH 17/17] tpm: Add TPM stress test
Dear Simon Glass, Hi Wolfgang, On Sat, Nov 3, 2012 at 8:29 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1351902453-27956-18-git-send-email-...@chromium.org you wrote: From: Luigi Semenzato semenz...@chromium.org Add a simple command to stress-test a TPM (Trusted Platform Module). Signed-off-by: Luigi Semenzato semenz...@chromium.org Commit-Ready: Stefan Reinauer reina...@google.com Signed-off-by: Simon Glass s...@chromium.org --- common/cmd_tpm.c | 93 ++--- 1 files changed, 87 insertions(+), 6 deletions(-) See previous comments about TPM code. Please let's dump all this unused stuff. As mentioned, patches are pending to enable this for two boards (ARM and x86). Hm, does this TPM argument still go on? Actually, my position is I'd be all for dumping it right away (I even posted a patch some time ago), if it wasn't for SJG posting patches adding another TPM chip. Moreover, now I see there are patches for cmd_tpm.c . So I see a lot of effort invested into doing the TPM right. What is the actual problem with keeping this code in our codebase and patching it then? It's all used now, problem solved, or am I missing something? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] mx28evk: Configure CONFIG_BOOTDELAY to one second
Dear Stefano Babic, On 16/11/2012 16:09, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com One second is enough time for users to react in case they want to stop the booting process. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx28evk.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 2916c71..8b89b25 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -238,7 +238,7 @@ */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS -#define CONFIG_BOOTDELAY 3 +#define CONFIG_BOOTDELAY 1 #define CONFIG_BOOTFILEuImage #define CONFIG_LOADADDR0x4200 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR Applied (whole series) to u-boot-imx, thanks. What about making some generic ... config-mx28.h AND config-fsl.h ... and including those in board-specific configs? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ks8695: more macros for register values
Dear Yann Vernier, Sorry! I didn't remember this patch (regvalues.h) is where a poorly named macro (comment on patch 7/11, SDRAM parameters) was defined. I will fix it. Make sure to run checkpatch.pl on those patches before reposting please. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/17] tpm: Add TPM stress test
Hi, On Mon, Nov 19, 2012 at 3:50 PM, Marek Vasut ma...@denx.de wrote: Dear Simon Glass, Hi Wolfgang, On Sat, Nov 3, 2012 at 8:29 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1351902453-27956-18-git-send-email-...@chromium.org you wrote: From: Luigi Semenzato semenz...@chromium.org Add a simple command to stress-test a TPM (Trusted Platform Module). Signed-off-by: Luigi Semenzato semenz...@chromium.org Commit-Ready: Stefan Reinauer reina...@google.com Signed-off-by: Simon Glass s...@chromium.org --- common/cmd_tpm.c | 93 ++--- 1 files changed, 87 insertions(+), 6 deletions(-) See previous comments about TPM code. Please let's dump all this unused stuff. As mentioned, patches are pending to enable this for two boards (ARM and x86). Hm, does this TPM argument still go on? Actually, my position is I'd be all for dumping it right away (I even posted a patch some time ago), if it wasn't for SJG posting patches adding another TPM chip. Moreover, now I see there are patches for cmd_tpm.c . So I see a lot of effort invested into doing the TPM right. What is the actual problem with keeping this code in our codebase and patching it then? It's all used now, problem solved, or am I missing something? Yes there has been quite a bit of effort on this. I hope we can keep this code, and perhaps even others way wish to help. I am looking at how to create a very simple kernel verification method based around a FIT image. Best regards, Marek Vasut Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6 V2] EXYNOS5: FDT: Add I2C device node data
On 20/11/12 01:42, Simon Glass wrote: Hi, On Mon, Nov 19, 2012 at 12:54 AM, Heiko Schocher h...@denx.de wrote: Hello Rajeshwari, On 14.11.2012 10:11, Rajeshwari Shinde wrote: Add I2C device node data for exynos Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org --- Changes in V2: Added Periph id to the I2C device node arch/arm/dts/exynos-periph-id.dtsi | 35 + arch/arm/dts/exynos5250.dtsi | 73 2 files changed, 108 insertions(+), 0 deletions(-) create mode 100644 arch/arm/dts/exynos-periph-id.dtsi Acked-by: Heiko Schocher h...@denx.de I'm sorry to say that there is one problem with this. It is using a non-standard dtc feature (Stephen Warren's symbolic work), so I think we should wait until Rajeshwari updates it to avoid that. I believe he will do that soon. OK. Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-fdt
Dear Tom, Please pull u-boot-fdt. These are the patches submitted by Simon Glass and his compatriots prior to the v2013.01 merge window closing and are thus eligible for inclusion in the v2013.01 release. Thanks, gvb The following changes since commit 59852d03867108217fe88e3bfc3e1e9cedfe63c5: Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2012-11-09 08:47:25 -0700) are available in the git repository at: git://git.denx.de/u-boot-fdt.git master for you to fetch changes up to 008784765ab7f37fb355d5f7fb180661b94c42ab: fdt: Remove fdtdec_find_alias_node() function (2012-11-12 23:15:25 -0500) Abhilash Kesavan (2): fdt: Add function to get config int from device tree fdt: Add function for decoding multiple gpios globally available Che-Liang Chiou (2): fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property fdt: Load boot command from device tree Doug Anderson (1): fdt: Allow device tree to specify secure booting Gabe Black (3): fdt: Add function to read boolean property fdt: Tell the FDT library where the device tree is fdt: Add option to default to most compatible conf in a fit image Gerald Van Baren (1): fdt: Export fdtdec_lookup() and fix the name Sean Paul (1): fdt: Add polarity-aware gpio functions to fdtdec Simon Glass (4): fdt: Add function to get a config string from device tree fdt: Add fdtdec_decode_region() to decode memory region fdt: Set kernaddr if fdt indicates a kernel is present fdt: Remove fdtdec_find_alias_node() function README | 11 + common/cmd_bootm.c | 11 + common/image.c | 127 common/main.c | 102 - include/fdtdec.h | 112 + include/image.h|1 + lib/fdtdec.c | 125 --- 7 files changed, 461 insertions(+), 28 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Hi Alex, On 11/19/2012 18:23, alex wrote: Hi: Thanks, it can work now. BTW, one question whether the atmel' patch on v2010.6 is merged int u-boot mainline? The mainline for at91sam9x5ek is supported. You can find it on tag 2012.10 and after. But, one thing should keep in mind, it only supports mainline Linux kernel for at91sam9x5ek. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Hi Andreas, On 11/19/2012 19:22, Andreas Bießmann wrote: Dear alex, On 19.11.2012 11:23, alex wrote: Hi: Thanks, it can work now. BTW, one question whether the atmel' patch on v2010.6 is merged int u-boot mainline? if you provide a rebased version on current HEAD we will do so. What's your mean about this? What Alex ask has been merged into mainline. His issue is that he change the offset of the u-boot environment cause the overlap with u-boot. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/50] net: net subsystem ops cleanup
Hello Joe! On Wed, Nov 14, 2012 at 1:06 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Tomas, On Sat, Nov 3, 2012 at 6:23 PM, Tomas Hlavacek tmshl...@gmail.com wrote: Dear Wolfgang, On Sat, Nov 3, 2012 at 4:09 PM, Wolfgang Denk w...@denx.de wrote: Dear Tomas Hlavacek, In message 1351876722-5183-1-git-send-email-tmshl...@gmail.com you wrote: This patchset is a first stage of preparation of the net subsystem for the driver model. The idea of this patchset is: 1) Remove ops .init, .send, .recv and .halt from the eth_device struct. Add a sparate structure eth_ops which is ready for inclusion to DM core. 2) Replace dynamic init of ops function pointers by static struct. 3) Do minor style cleanup. Tomas Hlavacek (50): net: dm: Pull out ops from struct eth_device net: 4xx_enet: Pull out init of struct eth_ops net: altera_tse: Pull out init of struct eth_ops net: dm9000x: Pull out init of struct eth_ops net: armada100_fec: Pull out init of struct eth_ops Hm... looking at this patch series, I wonder if it is really bisectable? Can I really apply any number of these patches (the first N, with N 50) and expect the code to build and to work? It should be, because the first patch adds new struct eth_ops and changes all accesses to its' members in one step. Patches 2 .. 50 remove dynamic ops settings and add static initialization to each affected driver - one patch per driver. I would rather try that by compiling U-Boot with only 1/50 applied and after some random N, say 30/50 to be absolutely sure. Let me get back later when I have my MAKEALL results. Have you completed this bisectability test yet? How about run testing? What boards did you test this on? Yes. In fact I have found some problems during the process, so I have a new updated patch series almost ready. I will send it tomorrow. I tested it on all ARM, MIPS, PowerPC and x86 boards. I tried to verify cover of drivers by this tests by means of git grep but I have to admit that I may be still missing some boards hidden in boards/* or arch/* ... :-( Tomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/17] tpm: Add TPM stress test
Dear Simon Glass, [...] What is the actual problem with keeping this code in our codebase and patching it then? It's all used now, problem solved, or am I missing something? Yes there has been quite a bit of effort on this. I hope we can keep this code, and perhaps even others way wish to help. I'm not sure how many others have any interest in the TPM, it's chromebook-only thing so far ;-) I am looking at how to create a very simple kernel verification method based around a FIT image. I'd say all in due time. I'd say start a new thread about this and properly discuss it before implementing. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Can you tell me from which tag on mainline kernel can work with mainline u-boot? At 2012-11-20 09:55:35,Bo Shen voice.s...@atmel.com wrote: Hi Alex, On 11/19/2012 18:23, alex wrote: Hi: Thanks, it can work now. BTW, one question whether the atmel' patch on v2010.6 is merged int u-boot mainline? The mainline for at91sam9x5ek is supported. You can find it on tag 2012.10 and after. But, one thing should keep in mind, it only supports mainline Linux kernel for at91sam9x5ek. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Hi Alex, On 11/20/2012 11:11, alex wrote: Can you tell me from which tag on mainline kernel can work with mainline u-boot? When the mainline kernel support at91sam9x5ek, it can work with mainline u-boot. You can choose the kernel version as you prefer. Btw, this is u-boot ML. If you want to know much more about the Linux kernel for at91sam9x5ek. Please send e-mail to Linux kernel ML. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 51/57] nios2: Use generic global_data
On 11/17/2012 05:20 AM, Simon Glass wrote: Move nios2 over to use generic global_data. Hi Simon, Built and tested on nios2 board. Acked-by: Thomas Chou tho...@wytron.com.tw - Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Mon, 19 Nov 2012 10:12:52 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, please pull u-boot-tegra/master into ARM/master. Thanks! 'pxa' patch moved to before Simon's LCD patchset; MAKEALL -a arm AOK. The following changes since commit 7a5337732e3e05b2b0de1b592fa031b2c7b4f632: Rajeshwari Shinde (1): EXYNOS5: Enable SPI booting. are available in the git repository at: git://git.denx.de/u-boot-tegra master Allen Martin (1): tegra: add CONSOLE_MUX support to tegra-kbc Mayuresh Kulkarni (1): tegra: Enable display/lcd support on Seaboard Simon Glass (17): pxa: Disable dcache on palmld, palmtc, zipitz2 tegra: Use const for pinmux_config_pingroup/table() tegra: Add display support to funcmux tegra: fdt: Add pwm binding and node tegra: fdt: Add LCD definitions for Tegra tegra: Add support for PWM tegra: Add LCD driver tegra: Add LCD support to Nvidia boards arm: Add control over cachability of memory regions lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment lcd: Add support for flushing LCD fb from dcache after update tegra: Align LCD frame buffer to section boundary tegra: Support control of cache settings for LCD tegra: fdt: Add LCD definitions for Seaboard lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console tegra: Remove unnecessary CONFIG_SYS_NAND_BASE tegra: config: seaboard: Move tegra-common-post to correct place Stephen Warren (4): ARM: tegra: TrimSlice: add support for USB1 port mmc: tegra: support 4-bit operation too on 8-bit slots ARM: tegra: enable 8-bit SD slots in board files tegra: use generic fs commands in BOOTCOMMAND Wei Ni (1): tegra: Add SOC support for display/lcd README | 16 + arch/arm/cpu/armv7/cache_v7.c | 11 + arch/arm/cpu/armv7/tegra20/Makefile|2 + arch/arm/cpu/armv7/tegra20/display.c | 409 ++ arch/arm/cpu/armv7/tegra20/pwm.c | 101 + arch/arm/cpu/tegra20-common/funcmux.c | 37 ++ arch/arm/cpu/tegra20-common/pinmux.c |4 +- arch/arm/dts/tegra20.dtsi | 105 + arch/arm/include/asm/arch-tegra20/dc.h | 545 arch/arm/include/asm/arch-tegra20/display.h| 152 +++ arch/arm/include/asm/arch-tegra20/pinmux.h |4 +- arch/arm/include/asm/arch-tegra20/pwm.h| 75 arch/arm/include/asm/system.h | 31 ++ arch/arm/lib/cache-cp15.c | 51 ++- board/compal/paz00/paz00.c |5 +- board/compulab/dts/tegra20-trimslice.dts |3 +- board/compulab/trimslice/trimslice.c |8 + board/nvidia/common/board.c| 24 + board/nvidia/dts/tegra20-seaboard.dts | 33 ++ board/nvidia/harmony/harmony.c |5 +- board/nvidia/seaboard/seaboard.c |5 +- common/lcd.c | 89 - common/main.c | 12 +- doc/device-tree-bindings/pwm/tegra20-pwm.txt | 18 + doc/device-tree-bindings/video/displaymode.txt | 42 ++ doc/device-tree-bindings/video/tegra20-dc.txt | 85 drivers/input/tegra-kbc.c | 18 +- drivers/mmc/tegra_mmc.c|7 +- drivers/video/Makefile |1 + drivers/video/tegra.c | 379 include/configs/harmony.h |4 +- include/configs/palmld.h |3 + include/configs/palmtc.h |3 + include/configs/paz00.h|3 + include/configs/seaboard.h | 20 +- include/configs/tec.h |1 - include/configs/tegra-common-post.h| 39 +- include/configs/tegra20-common.h |3 + include/configs/trimslice.h|4 + include/configs/ventana.h |3 + include/configs/whistler.h |3 + include/configs/zipitz2.h |3 + include/fdtdec.h |2 + include/lcd.h | 11 + lib/fdtdec.c |2 + 45 files changed, 2303 insertions(+), 78 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra20/display.c create mode 100644 arch/arm/cpu/armv7/tegra20/pwm.c create mode 100644 arch/arm/include/asm/arch-tegra20/dc.h create mode 100644 arch/arm/include/asm/arch-tegra20/display.h create mode 100644 arch/arm/include/asm/arch-tegra20/pwm.h create mode 100644 doc/device-tree-bindings/pwm/tegra20-pwm.txt create
Re: [U-Boot] [PATCH v2 03/10] x86: Allow excluding reset vector code from u-boot
Dear Simon Glass, In message 1349910781-32088-4-git-send-email-...@chromium.org you wrote: From: Gabe Black gabebl...@chromium.org When running from coreboot we don't want this code. This version works by ifdef-ing out all of the code that would go into those sections and all the code that refers to it. The sections are then empty, and the linker will either leave them empty for the loader to ignore or remove them entirely. Signed-off-by: Gabe Black gabebl...@chromium.org Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Put CONFIG_NO_RESET_CODE into Makefile instead of source files What exactly is CONFIG_NO_RESET_CODE ? There is no documentation anywhere for such a config option as is mandatory when introducing it, nor is there any comment why it would be needed, nor are there any users for it. Makefile|7 +-- arch/x86/cpu/Makefile |5 - arch/x86/cpu/u-boot.lds |3 +++ 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 34d9075..6c2f357 100644 --- a/Makefile +++ b/Makefile @@ -212,9 +212,12 @@ endif # U-Boot objectsorder is important (i.e. start must be first) OBJS = $(CPUDIR)/start.o +OBJS = $(CPUDIR)/start.o ifeq ($(CPU),x86) -OBJS += $(CPUDIR)/start16.o -OBJS += $(CPUDIR)/resetvec.o + ifneq ($(CONFIG_NO_RESET_CODE),y) + OBJS += $(CPUDIR)/start16.o + OBJS += $(CPUDIR)/resetvec.o + endif NAK. Bad indentation, and please do without 'if's or the like. --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -28,7 +28,10 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(CPU).o -START= start.o start16.o resetvec.o +START= start.o +ifneq ($(CONFIG_NO_RESET_CODE),y) +START+= resetvec.o start16.o +endif Ditto. --- a/arch/x86/cpu/u-boot.lds +++ b/arch/x86/cpu/u-boot.lds @@ -85,6 +85,8 @@ SECTIONS __bios_start = LOADADDR(.bios); __bios_size = SIZEOF(.bios); +#ifndef CONFIG_NO_RESET_CODE Undocumented. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I can have honesty, it's easier to overlook mistakes. -- Kirk, Space Seed, stardate 3141.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/17] tpm: Add TPM stress test
Dear Simon, In message capnjgz1aa+ro+h1ci1m5guqjok-vtrs_oksmbgs4swinzzm...@mail.gmail.com you wrote: Yes there has been quite a bit of effort on this. I hope we can keep this code, and perhaps even others way wish to help. I am looking at how to create a very simple kernel verification method based around a FIT image. So far, and even after all our discussions, these are but announcements and half-baked promises. But there isno real progress visible in mainline code. Yes, there are bits and pieces thrown at us, but they are not really useful in mainline - you argument not yet, but my statement is as long as such code is not ready, we should not bother adding it here. And especially I do not want to see this dead body grow even more. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Backed up the system lately? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TPM: remove dead code
Dear Tom, In message 1351960246-31771-1-git-send-email...@denx.de you wrote: The TPM code was added more than a year or 4 releases ago. This was done under the proposition that board support that would actually use such code would be added soon. However, nothing happened since. The code has no users in mainline, and does not even get build for any configuration, so we cannot even tell if it compiles at all. Remove the unused code. In in some far future actual users show up, it can be re-added easily. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Vadim Bendebury vben...@chromium.org Cc: Simon Glass s...@chromium.org --- README| 10 - common/Makefile | 1 - common/cmd_tpm.c | 103 - doc/driver-model/UDM-tpm.txt | 48 drivers/tpm/Makefile | 43 drivers/tpm/generic_lpc_tpm.c | 495 -- include/tpm.h | 71 -- 7 files changed, 771 deletions(-) delete mode 100644 common/cmd_tpm.c delete mode 100644 doc/driver-model/UDM-tpm.txt delete mode 100644 drivers/tpm/Makefile delete mode 100644 drivers/tpm/generic_lpc_tpm.c delete mode 100644 include/tpm.h This was sent before end of the merge window, but has not been applied yet. Despite some discussion about why having TPM code is generally useful, there are still no actual users for it visible, so I really would like to see this patch applied. It is trivial to re-activate this code if actual users for it should be added some day to come. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this.- Emo Phillips ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure
Dear Simon Glass, In message 1353100842-20126-1-git-send-email-...@chromium.org you wrote: The previous generic board series hit a snag in that we needed generic code to access some of the architecture-specific fields in global_data. I missed that. Can you please summarize what exactly the problem was, and how this modification is supposed to fix it? The solution eventually arrived at was to move these fields into a separate structure, so that global_data has the generic fields, and within that there is an arch_global_data structure holding the architecture-specific ones. This series makes that change. Assuming this is reasonable, the next step is to bring back the generic board patches on top of this. This cover letter has a RFC in the subject,. but the following patch series does not. This is actually bad! General comments / questions: - We always attempted to keep global data as small as possible. What happens here appears to be a move in a totally wrong direction. Instead of simplyfiyng it (and moving stuff out of global data), we add more and more complexity to it. That's wrong. We should not do that. - The change makes the code less readable. Reading gd-arch. instead of plain gd- is no improvements, but rather vice versa. If we really go this way, this should be improved. - What exactly is the impact of this code changes on the memory footprint? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm what passes for a Unix guru in my office. This is a frightening concept. - Lee Ann Goldstein, in 3k55ba$c...@butch.lmsc.lockheed.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: serial_sh: bugfix: autoboot fails if serial console is not connected
On kzm9g board (rmobile SoC), autoboot fails if serial console cable is not
connected. When serial cable is not connected, serial error occurs and
some garbage comes in data register.
sh_serial_tstc() in serial_sh.c does not check error status and misunderstand
there is some input data. It is the reason that autoboot fails.
This patch adds checking error status in sh_serial_tstc().
This patch is based on v2013.01-rc1 tag of u-boot master git.
Signed-off-by: Tetsuyuki Kobayashi k...@kmckk.co.jp
---
Hello Iwamatsu-san,
I checked this patch only on kzm9g board. Other SH or rmobile SoC might
have the same problem.
drivers/serial/serial_sh.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 3c931d0..ee1f2d7 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -117,6 +117,14 @@ static int serial_rx_fifo_level(void)
return scif_rxfill(sh_sci);
}
+static void handle_error(void)
+{
+ sci_in(sh_sci, SCxSR);
+ sci_out(sh_sci, SCxSR, SCxSR_ERROR_CLEAR(sh_sci));
+ sci_in(sh_sci, SCLSR);
+ sci_out(sh_sci, SCLSR, 0x00);
+}
+
void serial_raw_putc(const char c)
{
while (1) {
@@ -138,16 +146,14 @@ static void sh_serial_putc(const char c)
static int sh_serial_tstc(void)
{
+ if (sci_in(sh_sci, SCxSR) SCIF_ERRORS) {
+ handle_error();
+ return 0;
+ }
+
return serial_rx_fifo_level() ? 1 : 0;
}
-void handle_error(void)
-{
- sci_in(sh_sci, SCxSR);
- sci_out(sh_sci, SCxSR, SCxSR_ERROR_CLEAR(sh_sci));
- sci_in(sh_sci, SCLSR);
- sci_out(sh_sci, SCLSR, 0x00);
-}
int serial_getc_check(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
