Re: [U-Boot] [PATCH 0/2 V2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B
Dear Rajeshwari and Simon, On 12/03/13 15:13, Rajeshwari Birje wrote: Hi Minkyu, Yes it is based on the following patches submitted by Simon Glass and link for the same. sf: Add spi_flash_alloc() to create a new SPI flash struct http://patchwork.ozlabs.org/patch/208228/ sf: Use spi_flash_alloc() in each SPI flash driver: http://patchwork.ozlabs.org/patch/226582/ Those patches are merged? Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] MMC: EXYNOS: Added call back function for clock get
Dear Amar, On 27/03/13 14:38, Amarendra Reddy wrote: Dear Minkyu, Please refer to the latest version of emmc patchset, which is V7 patchset. The function definition 'exynos_dwmci_init()' has been changed when compared to V1 patchset. It means.. should I ignore this patchset? Here is the URL for latest version. http://www.mail-archive.com/u-boot@lists.denx.de/msg107511.html Thanks Regards Amarendra Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS5: Add L2 Cache Support.
On 30/11/12 15:29, Rajeshwari Shinde wrote: This patch set adds L2 Cache Support to EXYNOS. Signed-off-by: Arun Mankuzhi aru...@samsung.com Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- arch/arm/cpu/armv7/exynos/soc.c | 37 + 1 files changed, 37 insertions(+), 0 deletions(-) Sorry! too late. appiled to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] MMC: EXYNOS: Added call back function for clock get
Dear Minkyu, Yes, the patchset you referred needs to be ignored as it is V1 patchset. You need to refer to V7 patchset present at the URL http://www.mail-archive.com/u-boot@lists.denx.de/msg107511.html Thanks Regards Amarendra On 27 March 2013 13:10, Minkyu Kang mk7.k...@samsung.com wrote: Dear Amar, On 27/03/13 14:38, Amarendra Reddy wrote: Dear Minkyu, Please refer to the latest version of emmc patchset, which is V7 patchset. The function definition 'exynos_dwmci_init()' has been changed when compared to V1 patchset. It means.. should I ignore this patchset? Here is the URL for latest version. http://www.mail-archive.com/u-boot@lists.denx.de/msg107511.html Thanks Regards Amarendra Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix the reading of CPU revision
On 26.03.2013 18:04, Fabio Estevam wrote: Hi Dirk, On Tue, Mar 26, 2013 at 12:43 PM, Dirk Behme dirk.be...@de.bosch.com wrote: Hi Fabio, On 26.03.2013 13:54, Fabio Estevam wrote: Currently when booting a mx6 solo processor get_cpu_rev() returns 0x62xxx, which is an invalid mx6 CPU revision. Do you have somewhere a list of valid CPU revisions? From two points of view: a) the i.MX6 hardware spec b) the VPU library Sorry, I don't. I am basing the CPU revision numbers from FSL U-boot: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/common/fsl_sys_rev.c?h=imx_v2009.08_3.0.0 Adding Jason, in case he could clarify it. You remove Troy's code here introduced with http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=20332a066aff98f39419495821e14edd10b2a3f8 Troy's detection you remove here intentionally distinguishes between DualLite and Solo. You now re-introduce a common DL_S, again. Additionally, you completely seem to drop checking for scu-config. I've already seen some (broken?) i.MX6Solo where this check was essential. I can't talk about the problems when trying to use VPU library in the kernel (btw, which problems?) and the invalid 0x62xxx, but we used Troy's version of the detection successfully. Passing 0x62xxx as cpu_rev on a mx6solo caused the VPU issues described here: https://community.freescale.com/thread/305396 Which cpu_rev value is returned with your mx6solo? Are you able to use VPU lib? I'll check this. Rethinking about the issue here, my recent understanding is: a) We have a VPU library which only understands 0x63 (Quad) and 0x61 (DualLite/Solo) b) We have Troy's existing get_cpu_rev() [1] which seems to correctly decode the CPU revision (at least this is my impression from testing ;) ). But reports 0x62 for the Solo which then isn't understood by the VPU library (to be checked). I wonder if we could find a way to combine both parts without breaking the other? I.e. using Troy's get_cpu_rev() to correctly report the CPU revision (in U-Boot), but let the VPU library get the revision it understands? Best regards Dirk [1] http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=20332a066aff98f39419495821e14edd10b2a3f8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos5: clock: Update the equation to calculate PLL output frequency
On Fri, Mar 22, 2013 at 5:26 AM, Akshay Saraswat aksha...@samsung.com wrote:
According to the latest exynos5 user manual, the equation for
calculating PLL output was changed to
FOUT= MDIV x FIN/(PDIV x 2^SDIV)
earlier it was
FOUT= MDIV x FIN/(PDIV x 2^(SDIV -1))
So updating the clock code accordingly.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
I think this is EVT1 silicon, right?
Yes, this is for evt1 silicon.
---
arch/arm/cpu/armv7/exynos/clock.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 956427c..5299bc7 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -73,10 +73,8 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r,
unsigned int k)
/* FOUT = (MDIV + K / 1024) * FIN / (PDIV * 2^SDIV) */
fout = (m + k / 1024) * (freq / (p * (1 s)));
} else {
- if (s 1)
- s = 1;
- /* FOUT = MDIV * FIN / (PDIV * 2^(SDIV - 1)) */
- fout = m * (freq / (p * (1 (s - 1;
+ /* FOUT = MDIV * FIN / (PDIV * 2^SDIV) */
+ fout = m * (freq / (p * (1 s)));
}
return fout;
--
1.8.0
Regards,
Akshay Saraswat
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: exynos: make spl_boot common for all exynos based platforms
Dear Minkyu,
Please let me know if you have any comments for this patch.
With Regards,
Inder
On 16 March 2013 14:16, Inderpal Singh inderpal.si...@linaro.org wrote:
The spl_boot.c which copies the u-boot from the booting device to ram
is made common for all the exynos based platforms. To do so:
1. Moved smdk5250/spl_boot.c to common armv7/exynos folder and updated
to make it common for exynos4 and exynos5
2. Introduced a CONFIG_SPL_BOOTING option as only exynos5250 supports
booting from SPI device
3. Renamed some config options to make them common between exynos5250,
origen and smdkv310.
SD/MMC booting: tested on exynos4210 based origen, exynos5250 based Arndale
and SMDK5250 boards.
SPI booting: tested on SMDK5250 board
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
It depends on the patchset at [1] as it provides the infrastructure to
detect the SOC type and revision in spl at runtime.
[1] http://www.mail-archive.com/u-boot@lists.denx.de/msg108301.html
arch/arm/cpu/armv7/exynos/Makefile |4 ++
.../arm/cpu/armv7/exynos}/spl_boot.c | 33 +++
board/samsung/origen/Makefile |4 --
board/samsung/origen/mmc_boot.c| 58 ---
board/samsung/smdk5250/Makefile|4 --
board/samsung/smdkv310/Makefile|4 --
board/samsung/smdkv310/mmc_boot.c | 60
include/configs/exynos5250-dt.h| 10 ++--
include/configs/origen.h | 21 +++
include/configs/smdkv310.h | 21 +++
10 files changed, 54 insertions(+), 165 deletions(-)
rename {board/samsung/smdk5250 = arch/arm/cpu/armv7/exynos}/spl_boot.c (73%)
delete mode 100644 board/samsung/origen/mmc_boot.c
delete mode 100644 board/samsung/smdkv310/mmc_boot.c
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index b9cf921..c507608 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -24,6 +24,10 @@ LIB = $(obj)lib$(SOC).o
COBJS += clock.o power.o soc.o system.o pinmux.o tzpc_init.o
+ifdef CONFIG_SPL_BUILD
+COBJS += spl_boot.o
+endif
+
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/board/samsung/smdk5250/spl_boot.c
b/arch/arm/cpu/armv7/exynos/spl_boot.c
similarity index 73%
rename from board/samsung/smdk5250/spl_boot.c
rename to arch/arm/cpu/armv7/exynos/spl_boot.c
index d8f3c1e..e970ff6 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -23,6 +23,8 @@
#includecommon.h
#includeconfig.h
+#define OM_STAT(0x1f 1)
+
enum boot_mode {
BOOT_MODE_MMC = 4,
BOOT_MODE_SERIAL = 20,
@@ -31,8 +33,6 @@ enum boot_mode {
BOOT_MODE_USB, /* Boot using USB download */
};
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
-
/*
* Copy U-boot from mmc to RAM:
* COPY_BL2_FNPTR_ADDR: Address in iRAM, which Contains
@@ -40,26 +40,37 @@ enum boot_mode {
*/
void copy_uboot_to_ram(void)
{
- spi_copy_func_t spi_copy;
enum boot_mode bootmode;
- u32 (*copy_bl2)(u32, u32, u32);
+ u32 (*copy_bl2)(u32, u32, u32) = NULL;
+ u32 offset = 0, size = 0;
- bootmode = readl(EXYNOS5_POWER_BASE) OM_STAT;
+ bootmode = readl(samsung_get_base_power()) OM_STAT;
switch (bootmode) {
+#ifdef CONFIG_SPI_BOOTING
case BOOT_MODE_SERIAL:
- spi_copy = *(spi_copy_func_t *)EXYNOS_COPY_SPI_FNPTR_ADDR;
- spi_copy(SPI_FLASH_UBOOT_POS, CONFIG_BL2_SIZE,
- CONFIG_SYS_TEXT_BASE);
+ offset = CONFIG_BL2_OFFSET - CONFIG_RES_BLOCK_SIZE;
+ size = CONFIG_BL2_SIZE;
+ copy_bl2 = (void *) *(u32 *)EXYNOS_COPY_SPI_FNPTR_ADDR;
break;
+#endif
case BOOT_MODE_MMC:
- copy_bl2 = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
- copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
- CONFIG_SYS_TEXT_BASE);
+ offset = CONFIG_BL2_BLOCK_OFFSET;
+ size = CONFIG_BL2_SIZE_BLOCK_COUNT;
+
+ /* Only SMDKv310 EVT0 directly jumps to BootROM copy function
*/
+ if (s5p_get_cpu_rev())
+ copy_bl2 = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
+ else
+ copy_bl2 = (void *) COPY_BL2_FNPTR_ADDR;
+
break;
default:
break;
}
+
+ if (copy_bl2)
+ copy_bl2(offset, size, CONFIG_SYS_TEXT_BASE);
}
void board_init_f(unsigned long bootflag)
diff --git a/board/samsung/origen/Makefile
Re: [U-Boot] [PATCH v2 0/3] Make tzpc initialization common for exynos4 and exynos5
Dear Minkyu, Let me know your view about this patchset. With Regards, Inder On 15 March 2013 11:53, Inderpal Singh inderpal.si...@linaro.org wrote: The first patch moves the tzpc_init file from smdk5250 to armv7/exynos. The second makes tzpc_init common for exynos4 and exynos5. And the third makes necessary changes to exynos4 based origen and smdkv310 boards. The patchset has been tested on exynos4 based origen and exynos5 based Arndale board. Changes in v2: - removed uninitialised warning for start and end variables - corrected the SPL_TEXT_BASE for origen and smdkv310 - Added Chander's Acked-by Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc_init to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init arch/arm/cpu/armv7/exynos/Makefile |2 +- arch/arm/cpu/armv7/exynos/tzpc_init.c | 57 + arch/arm/cpu/armv7/s5p-common/Makefile |2 ++ arch/arm/include/asm/arch-exynos/tzpc.h | 28 +++ board/samsung/origen/lowlevel_init.S| 44 ++- board/samsung/origen/origen_setup.h | 25 - board/samsung/smdk5250/Makefile |1 - board/samsung/smdk5250/lowlevel_init.S |2 ++ board/samsung/smdk5250/setup.h | 25 - board/samsung/smdk5250/tzpc_init.c | 48 - board/samsung/smdkv310/lowlevel_init.S | 60 ++- include/configs/exynos5250-dt.h |2 -- include/configs/origen.h|2 ++ include/configs/smdkv310.h |2 ++ spl/Makefile|4 +++ 15 files changed, 102 insertions(+), 202 deletions(-) create mode 100644 arch/arm/cpu/armv7/exynos/tzpc_init.c delete mode 100644 board/samsung/smdk5250/tzpc_init.c -- 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] mx6: Fix the reading of CPU revision
On 27.03.2013 09:02, Dirk Behme wrote: On 26.03.2013 18:04, Fabio Estevam wrote: Hi Dirk, On Tue, Mar 26, 2013 at 12:43 PM, Dirk Behme dirk.be...@de.bosch.com wrote: Hi Fabio, On 26.03.2013 13:54, Fabio Estevam wrote: Currently when booting a mx6 solo processor get_cpu_rev() returns 0x62xxx, which is an invalid mx6 CPU revision. Do you have somewhere a list of valid CPU revisions? From two points of view: a) the i.MX6 hardware spec b) the VPU library Sorry, I don't. I am basing the CPU revision numbers from FSL U-boot: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/common/fsl_sys_rev.c?h=imx_v2009.08_3.0.0 Adding Jason, in case he could clarify it. You remove Troy's code here introduced with http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=20332a066aff98f39419495821e14edd10b2a3f8 Troy's detection you remove here intentionally distinguishes between DualLite and Solo. You now re-introduce a common DL_S, again. Additionally, you completely seem to drop checking for scu-config. I've already seen some (broken?) i.MX6Solo where this check was essential. I can't talk about the problems when trying to use VPU library in the kernel (btw, which problems?) and the invalid 0x62xxx, but we used Troy's version of the detection successfully. Passing 0x62xxx as cpu_rev on a mx6solo caused the VPU issues described here: https://community.freescale.com/thread/305396 Which cpu_rev value is returned with your mx6solo? Are you able to use VPU lib? I'll check this. Rethinking about the issue here, my recent understanding is: a) We have a VPU library which only understands 0x63 (Quad) and 0x61 (DualLite/Solo) b) We have Troy's existing get_cpu_rev() [1] which seems to correctly decode the CPU revision (at least this is my impression from testing ;) ). But reports 0x62 for the Solo which then isn't understood by the VPU library (to be checked). Some additional rethinking: I missed that we have a Linux kernel, too ;) c) It's the job of the Linux kernel to export the CPU revision to the VPU library. In case the Linux kernel completely ignores what we are doing in U-Boot and calculates the CPU revision itself (*), e.g. by something like http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60 we can do anything in U-Boot. Independent of the VPU library. In this case I'd propose to just keep Troy's version of get_cpu_rev() as it is [1]. Sorry for the confusion, hopefully this is correct now ;) Best regards Dirk (*) There might be U-Boot/Kernel combinations out there, where U-Boot exports the CPU revision via ATAGs to the kernel. But hopefully this doesn't affect us here (?) I wonder if we could find a way to combine both parts without breaking the other? I.e. using Troy's get_cpu_rev() to correctly report the CPU revision (in U-Boot), but let the VPU library get the revision it understands? Best regards Dirk [1] http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=20332a066aff98f39419495821e14edd10b2a3f8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Displaying characters on the display in u-boot
Hi All I have been able to display a splash screen in u-boot by converting the splash image to a header (using GIMP) and loading it into a GFX register (OMAP 4470). Now I have to display text(character) on the display. I read about CONFIG_CFB_CONSOLE in the u-boot documentation. How exactly does it work, is it the right method to display characters on the screen ? Please give me some direction with this issue.. Kind regards Bhargav SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On Wed, Mar 27, 2013 at 5:50 AM, Manfred Huber man.hu...@arcor.de wrote:
Please test the Patch. It is very simple on a Beagleboard. I guess you
have flashed the actual SPL and u-boot and Beagleboard boots correctly.
Now press and hold 'User' button and connect power. SPL should hang.
You can see some symbols on the console from the ROM code.
Hi Manfred,
I don't have access to my IGEP board right now but I'll test your
patch as soon as posible.
Install the Patch, compile it and flash the NAND. Beagleboard still
boots correctly. Now press and hold 'User' button again and Beagleboard
should also boot correctly. The Patch works.
I suspect the IGEP board has the same bug. If so, the Patch should work
on this board too and we don't need CONFIG_SYS_NS16550_BROKEN_TEMT
anymore.
I still think that we should keep CONFIG_SYS_NS16550_BROKEN_TEMT or
something similar instead of just checking for CONFIG_OMAP34XX. Since
we don't know if this problem is also present on other TI OMAP
platforms (or any other platform). I would just change
CONFIG_SYS_NS16550_BROKEN_TEMT semantics once is confirmed that this
also fixes the issue on IGEP boards.
Also, if you are removing CONFIG_SYS_NS16550_BROKEN_TEMT then you have
to update the README too since it is explained there what this config
option does.
If you don't want a patch for this bug please let me know. I will not
bother you again.
Thanks a lot for working on this. Some people work on mainline U-Boot
on their free time (like myself) so it can take a few days until you
get a response about a patch. Please be patient :-)
Best regards,
Manfred
Thank a lot and best regards,
Javier
On 2013-03-25 23:02, Manfred Huber wrote:
From: Manfred Huber
Due to a Bug in the ROM code of some OMAP3 devices, the TEMT bit is not
set if UART3 is configured before (only THRE is set). Reason is the
disabling of UART3 even though the Transmitter is not empty. Enabling
UART3 allows the Transmitter to be empty.
Signed-off-by: Manfred Huber man.hu...@arcor.de
---
drivers/serial/ns16550.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index b2da8b3..24ff84f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,10 +36,18 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
-#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
+#if (defined(CONFIG_SPL_BUILD) defined(CONFIG_OMAP34XX))
+if ((serial_in(com_port-lsr) (UART_LSR_TEMT | UART_LSR_THRE))
== UART_LSR_THRE) {
+serial_out(UART_LCR_DLAB, com_port-lcr);
+serial_out(baud_divisor 0xff, com_port-dll);
+serial_out((baud_divisor 8) 0xff, com_port-dlm);
+serial_out(UART_LCRVAL, com_port-lcr);
+serial_out(0, com_port-mdr1);
+}
+#endif
+
while (!(serial_in(com_port-lsr) UART_LSR_TEMT))
;
-#endif
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/tools/pblimage: use SYS_TEXT_BASE instead of hardcoded value
That the pblimage can be built according to the SYS_TEXT_BASE, then building a different size of pblimage is available. Signed-off-by: Shaohui Xie shaohui@freescale.com --- tools/pblimage.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/pblimage.c b/tools/pblimage.c index 508a747..60277a4 100644 --- a/tools/pblimage.c +++ b/tools/pblimage.c @@ -29,10 +29,9 @@ * The PBL can load up to 64 bytes at a time, so we split the U-Boot * image into 64 byte chunks. PBL needs a command for each piece, of * the form 81xx, where xx is the offset. SYS_TEXT_BASE - * is 0xFFF8 for PBL boot, and PBL only cares about low 24-bit, - * so it starts from 0x81F8. + * is the start offset and PBL only cares about low 24-bit. */ -static uint32_t next_pbl_cmd = 0x81F8; +static uint32_t next_pbl_cmd = 0x8100 | (CONFIG_SYS_TEXT_BASE 0xFF); /* * need to store all bytes in memory for calculating crc32, then write the * bytes to image file for PBL boot. -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] usb: ss: Some fixes and cleanup for USB super-speed support
Based on 'u-boot-usb' master branch. This patch-series includes majorly some clean-up, few fixes and then some basic super-speed usb infrastructure addition, to help put support for XHCI in near future. Few patches here have been pulled from patch-series sent long back for XHCI support: [RFC PATCH 0/2] USB: XHCI: Add xHCI host controller stack driver We plan to send further the xHCI controller's stack driver in near future. Vivek Gautam (7): USB: Some cleanup prior to USB 3.0 interface addition usb: hub: Conditionally power on usb's root-hub ports usb: Update device class in usb device's descriptor usb: hub: Fix enumration timeout usb: hub: Increase device enumeration timeout for broken drives USB: SS: Add support for Super Speed USB interface usb: eth: Fix for updated usb interface descriptor structure common/cmd_usb.c |6 +++- common/usb.c | 34 ++- common/usb_hub.c | 54 +++ common/usb_storage.c | 30 +--- drivers/usb/eth/asix.c | 14 ++- drivers/usb/eth/smsc95xx.c | 24 +- include/usb.h | 12 +- include/usb_defs.h | 26 +++- 8 files changed, 142 insertions(+), 58 deletions(-) -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] USB: Some cleanup prior to USB 3.0 interface addition
Some cleanup in usb framework, nothing much on feature side.
Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
common/usb.c | 18 ++
common/usb_storage.c | 30 --
include/usb_defs.h |2 +-
3 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 6fc0fc1..40c1547 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -360,6 +360,7 @@ static int usb_parse_config(struct usb_device *dev,
int index, ifno, epno, curr_if_num;
int i;
u16 ep_wMaxPacketSize;
+ struct usb_interface *if_desc = NULL;
ifno = -1;
epno = -1;
@@ -387,23 +388,24 @@ static int usb_parse_config(struct usb_device *dev,
buffer[index])-bInterfaceNumber != curr_if_num) {
/* this is a new interface, copy new desc */
ifno = dev-config.no_of_if;
+ if_desc = dev-config.if_desc[ifno];
dev-config.no_of_if++;
- memcpy(dev-config.if_desc[ifno],
- buffer[index], buffer[index]);
- dev-config.if_desc[ifno].no_of_ep = 0;
- dev-config.if_desc[ifno].num_altsetting = 1;
+ memcpy(if_desc, buffer[index], buffer[index]);
+ if_desc-no_of_ep = 0;
+ if_desc-num_altsetting = 1;
curr_if_num =
-
dev-config.if_desc[ifno].desc.bInterfaceNumber;
+if_desc-desc.bInterfaceNumber;
} else {
/* found alternate setting for the interface */
- dev-config.if_desc[ifno].num_altsetting++;
+ if_desc-num_altsetting++;
}
break;
case USB_DT_ENDPOINT:
epno = dev-config.if_desc[ifno].no_of_ep;
+ if_desc = dev-config.if_desc[ifno];
/* found an endpoint */
- dev-config.if_desc[ifno].no_of_ep++;
- memcpy(dev-config.if_desc[ifno].ep_desc[epno],
+ if_desc-no_of_ep++;
+ memcpy(if_desc-ep_desc[epno],
buffer[index], buffer[index]);
ep_wMaxPacketSize = get_unaligned(dev-config.\
if_desc[ifno].\
diff --git a/common/usb_storage.c b/common/usb_storage.c
index fb322b4..475c218 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -278,10 +278,10 @@ int usb_stor_scan(int mode)
lun++) {
usb_dev_desc[usb_max_devs].lun = lun;
if (usb_stor_get_info(dev, usb_stor[start],
-
usb_dev_desc[usb_max_devs]) == 1) {
- usb_max_devs++;
- }
+ usb_dev_desc[usb_max_devs]) == 1)
+ usb_max_devs++;
}
+
}
/* if storage device */
if (usb_max_devs == USB_MAX_STOR_DEV) {
@@ -511,7 +511,7 @@ static int usb_stor_BBB_comdat(ccb *srb, struct us_data *us)
dir_in = US_DIRECTION(srb-cmd[0]);
#ifdef BBB_COMDAT_TRACE
- printf(dir %d lun %d cmdlen %d cmd %p datalen %d pdata %p\n,
+ printf(dir %d lun %d cmdlen %d cmd %p datalen %lu pdata %p\n,
dir_in, srb-lun, srb-cmdlen, srb-cmd, srb-datalen,
srb-pdata);
if (srb-cmdlen) {
@@ -1218,6 +1218,7 @@ int usb_storage_probe(struct usb_device *dev, unsigned
int ifnum,
{
struct usb_interface *iface;
int i;
+ struct usb_endpoint_descriptor *ep_desc;
unsigned int flags = 0;
int protocol = 0;
@@ -1300,24 +1301,25 @@ int usb_storage_probe(struct usb_device *dev, unsigned
int ifnum,
* We will ignore any others.
*/
for (i = 0; i iface-desc.bNumEndpoints; i++) {
+ ep_desc = iface-ep_desc[i];
/* is it an BULK endpoint? */
- if ((iface-ep_desc[i].bmAttributes
+ if ((ep_desc-bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
- if (iface-ep_desc[i].bEndpointAddress USB_DIR_IN)
- ss-ep_in = iface-ep_desc[i].bEndpointAddress
- USB_ENDPOINT_NUMBER_MASK;
+ if (ep_desc-bEndpointAddress USB_DIR_IN)
+
[U-Boot] [PATCH 2/7] usb: hub: Conditionally power on usb's root-hub ports
Power on root hubs' ports only when they are not yet powered on.
Its seen with USB 3.0 ports that they are powered on after
a H/W reset, as also reflected in XHCI spec (sec 4.3):
After a Chip Hardware Reset, HCRST, or commanded to the
PLS = RxDetect state, all Root Hub ports shall be in Disconnected
state, i.e. the port is powered on (PP = 1)
Signed-off-by: Amar amarendra...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
common/usb_hub.c | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index b5eeb62..0677004 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -111,13 +111,29 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
int i;
struct usb_device *dev;
unsigned pgood_delay = hub-desc.bPwrOn2PwrGood * 2;
+ ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
+ unsigned short portstatus;
+ int ret;
dev = hub-pusb_dev;
- /* Enable power to the ports */
+
+ /* Enable power to ports whose power is not yet on */
USB_HUB_PRINTF(enabling power on all ports\n);
for (i = 0; i dev-maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
- USB_HUB_PRINTF(port %d returns %lX\n, i + 1, dev-status);
+ ret = usb_get_port_status(dev, i + 1, portsts);
+ if (ret 0) {
+ USB_HUB_PRINTF(port %d: get_port_status failed\n,
+ i + 1);
+ return;
+ }
+
+ portstatus = le16_to_cpu(portsts-wPortStatus);
+
+ if (!(portstatus (USB_PORT_STAT_POWER 1))) {
+ usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
+ USB_HUB_PRINTF(port %d returns %lX\n, i + 1,
+ dev-status);
+ }
}
/* Wait at least 100 msec for power to become stable */
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] usb: Update device class in usb device's descriptor
Fetch the device class into usb device's dwcriptors,
so that the host controller's driver can use this info
to differentiate between HUB and DEVICE.
Signed-off-by: Amar amarendra...@samsung.com
---
common/usb.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 40c1547..39fcedd 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -888,6 +888,11 @@ int usb_new_device(struct usb_device *dev)
dev-descriptor.bMaxPacketSize0 = desc-bMaxPacketSize0;
+ /* Fetch the device class, driver can use this info
+* to differentiate between HUB and DEVICE.
+*/
+ dev-descriptor.bDeviceClass = desc-bDeviceClass;
+
/* find the port number we're at */
if (parent) {
int j;
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout
Patch b6d7852c increases timeout for enumeration, taking worst case to be 10 sec. get_timer() api returns timestamp in micro-seconds, which is what we are checking in the do-while() loop in usb_hub_configure() (get_timer(start) CONFIG_SYS_HZ * 10). This should give us a required check for 10 seconds, and thereby we don't need to add additional mdelay of 100 microseconds in each cycle. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Vipin Kumar vipin.ku...@st.com --- common/usb_hub.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/common/usb_hub.c b/common/usb_hub.c index 0677004..d77f98d 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -439,7 +439,6 @@ static int usb_hub_configure(struct usb_device *dev) (portstatus USB_PORT_STAT_CONNECTION)) break; - mdelay(100); } while (get_timer(start) CONFIG_SYS_HZ * 10); if (ret 0) -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] usb: hub: Increase device enumeration timeout for broken drives
Few broken usb mass storage devices can take some time to set
Current Connect Status (CCS) and Connect Status Change (CSC) in
Port status register after an attach.
So increasing some timeout when both CCS and CSC bits are not set.
Signed-off-by: Amar amarendra...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
common/usb_hub.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index d77f98d..8ba7a0d 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -416,6 +416,7 @@ static int usb_hub_configure(struct usb_device *dev)
unsigned short portstatus, portchange;
int ret;
ulong start = get_timer(0);
+ ulong ts = 0;
/*
* Wait for (whichever finishes first)
@@ -436,9 +437,23 @@ static int usb_hub_configure(struct usb_device *dev)
portchange = le16_to_cpu(portsts-wPortChange);
if ((portchange USB_PORT_STAT_C_CONNECTION) ==
- (portstatus USB_PORT_STAT_CONNECTION))
- break;
-
+ (portstatus USB_PORT_STAT_CONNECTION)) {
+ /*
+* Few brokern pen drives can take some
+* time to even report CSC or CCS state after
+* an attach. So giving this time lag so that
+* the CCS or CSC state can be changed and
+* reflected in Port status register.
+* XXX: This approach however has a drawback,
+* with this we are going to wait for 1 sec
+* even for ports on which nothing is connected.
+*/
+ if (ts == 0)
+ ts = get_timer(0);
+ if ((portchange USB_PORT_STAT_C_CONNECTION) ||
+ (get_timer(ts) CONFIG_SYS_HZ * 1))
+ break;
+ }
} while (get_timer(start) CONFIG_SYS_HZ * 10);
if (ret 0)
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] USB: SS: Add support for Super Speed USB interface
This adds usb framework support for super-speed usb, which will
further facilitate to add stack support for xHCI.
Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
common/cmd_usb.c |6 --
common/usb.c | 11 ---
common/usb_hub.c | 10 +++---
common/usb_storage.c |2 +-
include/usb.h| 12 +++-
include/usb_defs.h | 24 +++-
6 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index dacdc2d..90c2cf1 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -262,7 +262,7 @@ static void usb_display_config(struct usb_device *dev)
ifdesc = config-if_desc[i];
usb_display_if_desc(ifdesc-desc, dev);
for (ii = 0; ii ifdesc-no_of_ep; ii++) {
- epdesc = ifdesc-ep_desc[ii];
+ epdesc = ifdesc-ep_desc[ii].ep_desc;
usb_display_ep_desc(epdesc);
}
}
@@ -271,7 +271,9 @@ static void usb_display_config(struct usb_device *dev)
static inline char *portspeed(int speed)
{
- if (speed == USB_SPEED_HIGH)
+ if (speed == USB_SPEED_SUPER)
+ return 5 Gb/s;
+ else if (speed == USB_SPEED_HIGH)
return 480 Mb/s;
else if (speed == USB_SPEED_LOW)
return 1.5 Mb/s;
diff --git a/common/usb.c b/common/usb.c
index 39fcedd..a5b915e 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -304,7 +304,7 @@ usb_set_maxpacket_ep(struct usb_device *dev, int if_idx,
int ep_idx)
struct usb_endpoint_descriptor *ep;
u16 ep_wMaxPacketSize;
- ep = dev-config.if_desc[if_idx].ep_desc[ep_idx];
+ ep = dev-config.if_desc[if_idx].ep_desc[ep_idx].ep_desc;
b = ep-bEndpointAddress USB_ENDPOINT_NUMBER_MASK;
ep_wMaxPacketSize = get_unaligned(ep-wMaxPacketSize);
@@ -410,14 +410,19 @@ static int usb_parse_config(struct usb_device *dev,
ep_wMaxPacketSize = get_unaligned(dev-config.\
if_desc[ifno].\
ep_desc[epno].\
- wMaxPacketSize);
+ ep_desc.wMaxPacketSize);
put_unaligned(le16_to_cpu(ep_wMaxPacketSize),
dev-config.\
if_desc[ifno].\
ep_desc[epno].\
- wMaxPacketSize);
+ ep_desc.wMaxPacketSize);
USB_PRINTF(if %d, ep %d\n, ifno, epno);
break;
+ case USB_DT_SS_ENDPOINT_COMP:
+ if_desc = dev-config.if_desc[ifno];
+ memcpy((if_desc-ep_desc[epno].ss_ep_comp),
+ buffer[index], buffer[index]);
+ break;
default:
if (head-bLength == 0)
return 1;
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 8ba7a0d..9acaede 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -158,7 +158,9 @@ static struct usb_hub_device *usb_hub_allocate(void)
static inline char *portspeed(int portstatus)
{
- if (portstatus (1 USB_PORT_FEAT_HIGHSPEED))
+ if (portstatus (1 USB_PORT_FEAT_SUPERSPEED))
+ return 5 Gb/s;
+ else if (portstatus (1 USB_PORT_FEAT_HIGHSPEED))
return 480 Mb/s;
else if (portstatus (1 USB_PORT_FEAT_LOWSPEED))
return 1.5 Mb/s;
@@ -262,7 +264,9 @@ void usb_hub_port_connect_change(struct usb_device *dev,
int port)
/* Allocate a new device struct for it */
usb = usb_alloc_new_device(dev-controller);
- if (portstatus USB_PORT_STAT_HIGH_SPEED)
+ if (portstatus USB_PORT_STAT_SUPER_SPEED)
+ usb-speed = USB_SPEED_SUPER;
+ else if (portstatus USB_PORT_STAT_HIGH_SPEED)
usb-speed = USB_SPEED_HIGH;
else if (portstatus USB_PORT_STAT_LOW_SPEED)
usb-speed = USB_SPEED_LOW;
@@ -525,7 +529,7 @@ int usb_hub_probe(struct usb_device *dev, int ifnum)
/* Multiple endpoints? What kind of mutant ninja-hub is this? */
if (iface-desc.bNumEndpoints != 1)
return 0;
- ep = iface-ep_desc[0];
+ ep = iface-ep_desc[0].ep_desc;
/* Output endpoint? Curiousier and curiousier.. */
if (!(ep-bEndpointAddress USB_DIR_IN))
return 0;
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 475c218..c48da43 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -1301,7 +1301,7 @@ int usb_storage_probe(struct usb_device *dev, unsigned
int
[U-Boot] [PATCH 7/7] usb: eth: Fix for updated usb interface descriptor structure
Now usb interface structure doesn't contain the Ep descriptor directly,
in fact it contains a pointer to 'usb_ep_desc' structure which
contains the Ep descriptor.
So updating the usb-eth drivers accordingly.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/eth/asix.c | 14 --
drivers/usb/eth/smsc95xx.c | 24
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index 75ec8f7..42e98f1 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -611,6 +611,7 @@ int asix_eth_probe(struct usb_device *dev, unsigned int
ifnum,
{
struct usb_interface *iface;
struct usb_interface_descriptor *iface_desc;
+ struct usb_endpoint_descriptor *ep_desc;
int ep_in_found = 0, ep_out_found = 0;
int i;
@@ -652,10 +653,11 @@ int asix_eth_probe(struct usb_device *dev, unsigned int
ifnum,
* int. We will ignore any others.
*/
for (i = 0; i iface_desc-bNumEndpoints; i++) {
+ ep_desc = iface-ep_desc[i].ep_desc;
/* is it an BULK endpoint? */
- if ((iface-ep_desc[i].bmAttributes
+ if ((ep_desc-bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
- u8 ep_addr = iface-ep_desc[i].bEndpointAddress;
+ u8 ep_addr = ep_desc-bEndpointAddress;
if (ep_addr USB_DIR_IN) {
if (!ep_in_found) {
ss-ep_in = ep_addr
@@ -672,11 +674,11 @@ int asix_eth_probe(struct usb_device *dev, unsigned int
ifnum,
}
/* is it an interrupt endpoint? */
- if ((iface-ep_desc[i].bmAttributes
+ if ((ep_desc-bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
- ss-ep_int = iface-ep_desc[i].bEndpointAddress
- USB_ENDPOINT_NUMBER_MASK;
- ss-irqinterval = iface-ep_desc[i].bInterval;
+ ss-ep_int = ep_desc-bEndpointAddress
+ USB_ENDPOINT_NUMBER_MASK;
+ ss-irqinterval = ep_desc-bInterval;
}
}
debug(Endpoints In %d Out %d Int %d\n,
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index fd8f8a7..3f58c89 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -807,6 +807,7 @@ int smsc95xx_eth_probe(struct usb_device *dev, unsigned int
ifnum,
{
struct usb_interface *iface;
struct usb_interface_descriptor *iface_desc;
+ struct usb_endpoint_descriptor *ep_desc;
int i;
/* let's examine the device now */
@@ -837,25 +838,24 @@ int smsc95xx_eth_probe(struct usb_device *dev, unsigned
int ifnum,
* We will ignore any others.
*/
for (i = 0; i iface_desc-bNumEndpoints; i++) {
+ ep_desc = iface-ep_desc[i].ep_desc;
/* is it an BULK endpoint? */
- if ((iface-ep_desc[i].bmAttributes
+ if ((ep_desc-bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
- if (iface-ep_desc[i].bEndpointAddress USB_DIR_IN)
- ss-ep_in =
- iface-ep_desc[i].bEndpointAddress
- USB_ENDPOINT_NUMBER_MASK;
+ if (ep_desc-bEndpointAddress USB_DIR_IN)
+ ss-ep_in = ep_desc-bEndpointAddress
+ USB_ENDPOINT_NUMBER_MASK;
else
- ss-ep_out =
- iface-ep_desc[i].bEndpointAddress
- USB_ENDPOINT_NUMBER_MASK;
+ ss-ep_out = ep_desc-bEndpointAddress
+ USB_ENDPOINT_NUMBER_MASK;
}
/* is it an interrupt endpoint? */
- if ((iface-ep_desc[i].bmAttributes
+ if ((ep_desc-bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
- ss-ep_int = iface-ep_desc[i].bEndpointAddress
- USB_ENDPOINT_NUMBER_MASK;
- ss-irqinterval = iface-ep_desc[i].bInterval;
+ ss-ep_int = ep_desc-bEndpointAddress
+ USB_ENDPOINT_NUMBER_MASK;
+ ss-irqinterval = ep_desc-bInterval;
}
}
debug(Endpoints In %d Out %d Int %d\n,
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH] EXYNOS: SPL: Add a custom spi copy function
This CL implements a custom spi_copy funtion to copy u-boot from SF to
RAM. This is faster then iROM spi_copy funtion as this runs spi at 50Mhz
and also in WORD mode of operation.
Changed a printf in pimux.c to debug just to avoid the the compilation
error in SPL.
Removed the enum for boot mode from spl_boot.c as it was already define in spl.h
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Tom Wai-Hong Tam waih...@chromium.org
Signe-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/pinmux.c |2 +-
arch/arm/include/asm/arch-exynos/spi.h |2 +
board/samsung/smdk5250/spl_boot.c | 126 +---
include/configs/exynos5250-dt.h|3 +
spl/Makefile |4 +
5 files changed, 124 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 1e7d14c..445f6fa 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -399,7 +399,7 @@ static int exynos4_pinmux_config(int peripheral, int flags)
case PERIPH_ID_SDMMC1:
case PERIPH_ID_SDMMC3:
case PERIPH_ID_SDMMC4:
- printf(SDMMC device %d not implemented\n, peripheral);
+ debug(SDMMC device %d not implemented\n, peripheral);
return -1;
default:
debug(%s: invalid peripheral %d, __func__, peripheral);
diff --git a/arch/arm/include/asm/arch-exynos/spi.h
b/arch/arm/include/asm/arch-exynos/spi.h
index e67ad27..3430ac1 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -43,6 +43,8 @@ struct exynos_spi {
#define SPI_TIMEOUT_MS 10
+#define SF_READ_DATA_CMD 0x3
+
/* SPI_CHCFG */
#define SPI_CH_HS_EN (1 6)
#define SPI_CH_RST (1 5)
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index d8f3c1e..9e99512 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -22,16 +22,119 @@
#includecommon.h
#includeconfig.h
+#include spi.h
+#include asm/arch/clk.h
+#include asm/arch/spi.h
+#include asm/arch/pinmux.h
+#include asm/arch/periph.h
+#include asm/arch/spl.h
-enum boot_mode {
- BOOT_MODE_MMC = 4,
- BOOT_MODE_SERIAL = 20,
- /* Boot based on Operating Mode pin settings */
- BOOT_MODE_OM = 32,
- BOOT_MODE_USB, /* Boot using USB download */
-};
+static void spi_rx_tx(struct exynos_spi *regs, int todo,
+ void *dinp, void const *doutp, int i)
+{
+ uint *rxp = (uint *)(dinp + (i * (32 * 1024)));
+ int rx_lvl, tx_lvl;
+ uint out_bytes, in_bytes;
+
+ out_bytes = in_bytes = todo;
+ setbits_le32(regs-ch_cfg, SPI_CH_RST);
+ clrbits_le32(regs-ch_cfg, SPI_CH_RST);
+ writel(((todo * 8) / 32) | SPI_PACKET_CNT_EN, regs-pkt_cnt);
+
+ while (in_bytes) {
+ uint32_t spi_sts;
+ int temp;
+
+ spi_sts = readl(regs-spi_sts);
+ rx_lvl = ((spi_sts 15) 0x7f);
+ tx_lvl = ((spi_sts 6) 0x7f);
+ while (tx_lvl 32 out_bytes) {
+ temp = 0x;
+ writel(temp, regs-tx_data);
+ out_bytes -= 4;
+ tx_lvl += 4;
+ }
+ while (rx_lvl = 4 in_bytes) {
+ temp = readl(regs-rx_data);
+ if (rxp)
+ *rxp++ = temp;
+ in_bytes -= 4;
+ rx_lvl -= 4;
+ }
+ }
+}
+
+/**
+ * Copy uboot from spi flash to RAM
+ *
+ * @parma uboot_size size of u-boot to copy
+ * @param uboot_addr address of u-boot to copy
+ */
+static void exynos_spi_copy(unsigned int uboot_size, unsigned int uboot_addr)
+{
+ int upto, todo;
+ int i;
+ struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
+
+ set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
+ /* set the spi1 GPIO */
+ exynos_pinmux_config(PERIPH_ID_SPI1, PINMUX_FLAG_NONE);
+
+ /* set pktcnt and enable it */
+ writel(4 | SPI_PACKET_CNT_EN, regs-pkt_cnt);
+ /* set FB_CLK_SEL */
+ writel(SPI_FB_DELAY_180, regs-fb_clk);
+ /* set CH_WIDTH and BUS_WIDTH as word */
+ setbits_le32(regs-mode_cfg, SPI_MODE_CH_WIDTH_WORD |
+ SPI_MODE_BUS_WIDTH_WORD);
+ clrbits_le32(regs-ch_cfg, SPI_CH_CPOL_L); /* CPOL: active high */
+
+ /* clear rx and tx channel if set priveously */
+ clrbits_le32(regs-ch_cfg, SPI_RX_CH_ON | SPI_TX_CH_ON);
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+ setbits_le32(regs-swap_cfg, SPI_RX_SWAP_EN |
+ SPI_RX_BYTE_SWAP |
+ SPI_RX_HWORD_SWAP);
+
+ /* do a
Re: [U-Boot] [PATCH v2 0/3] Make tzpc initialization common for exynos4 and exynos5
On 27/03/13 17:46, Inderpal Singh wrote: Dear Minkyu, Let me know your view about this patchset. With Regards, Inder On 15 March 2013 11:53, Inderpal Singh inderpal.si...@linaro.org wrote: The first patch moves the tzpc_init file from smdk5250 to armv7/exynos. The second makes tzpc_init common for exynos4 and exynos5. And the third makes necessary changes to exynos4 based origen and smdkv310 boards. The patchset has been tested on exynos4 based origen and exynos5 based Arndale board. Changes in v2: - removed uninitialised warning for start and end variables - corrected the SPL_TEXT_BASE for origen and smdkv310 - Added Chander's Acked-by Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc_init to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init arch/arm/cpu/armv7/exynos/Makefile |2 +- arch/arm/cpu/armv7/exynos/tzpc_init.c | 57 + arch/arm/cpu/armv7/s5p-common/Makefile |2 ++ arch/arm/include/asm/arch-exynos/tzpc.h | 28 +++ board/samsung/origen/lowlevel_init.S| 44 ++- board/samsung/origen/origen_setup.h | 25 - board/samsung/smdk5250/Makefile |1 - board/samsung/smdk5250/lowlevel_init.S |2 ++ board/samsung/smdk5250/setup.h | 25 - board/samsung/smdk5250/tzpc_init.c | 48 - board/samsung/smdkv310/lowlevel_init.S | 60 ++- include/configs/exynos5250-dt.h |2 -- include/configs/origen.h|2 ++ include/configs/smdkv310.h |2 ++ spl/Makefile|4 +++ 15 files changed, 102 insertions(+), 202 deletions(-) create mode 100644 arch/arm/cpu/armv7/exynos/tzpc_init.c delete mode 100644 board/samsung/smdk5250/tzpc_init.c -- 1.7.9.5 listed in my queue. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] mtd: cfi_flash: Fix CFI flash driver for 8-bit bus support
Hi,
Any update on this.
Thanks,
Jagan.
-Original Message-
From: Jagannadha Sutradharudu Teki [mailto:jagannadha.sutradharudu-
t...@xilinx.com]
Sent: 03 March 2013 16:45
To: u-boot@lists.denx.de
Cc: Stefan Roese; Aaron Williams; Luka Perkov; mon...@monstr.eu;
Jagannadha Sutradharudu Teki
Subject: [PATCH v7] mtd: cfi_flash: Fix CFI flash driver for 8-bit bus support
From: aaron.willi...@caviumnetworks.com
This commit is based on that patch from
aaron.willi...@caviumnetworks.com with same commit title. pulled the
same code changes into current u-boot tree.
http://patchwork.ozlabs.org/patch/140863/
http://lists.denx.de/pipermail/u-boot/2011-April/089606.html
This patch corrects the addresses used when working with Spansion/AMD
FLASH chips.
Addressing for 8 and 16 bits is almost identical except in the 16-bit case the
LSB of the address is always 0. The confusion arose because the addresses in
the datasheet for 16-bit mode are word addresses but this code assumed it
was byte addresses.
I have only been able to test this on our Octeon boards which use either an
8-bit or 16-bit bus. I have not tested the case where there's an 8-bit part
on
a 16-bit bus.
This patch also adds some delays as suggested by Spansion.
If a part can be both 8 and 16-bits, it forces it to work in 8-bit mode if an
8-
bit bus is detected.
Apart from the pulled changes, fixed few minor code cleanups and tested on
256M29EW, 512M29EW flashes.
Before this fix:
---
Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors
AMD Standard command set, Manufacturer ID: 0xFF, Device ID: 0xFF
Erase timeout: 4096 ms, write timeout: 2 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
After this fix:
--
Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors
AMD Standard command set, Manufacturer ID: 0x89, Device ID: 0x7E2301
Erase timeout: 4096 ms, write timeout: 2 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
Signed-off-by: Aaron Williams aaron.willi...@caviumnetworks.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Tested-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v3:
- Fixed few minor code cleanups
Changes for v4:
- Updated the S-o-b for original authors Changes for v5:
- Collect all S-o-b together
Changes for v6:
- Preserving author details
Changes for v7:
- Remove Luka Perkov from T-b
drivers/mtd/cfi_flash.c | 78 +---
---
include/mtd/cfi_flash.h | 41
2 files changed, 76 insertions(+), 43 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index
60dbb78..6b9fc1a 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -210,9 +210,11 @@ unsigned long flash_sector_size(flash_info_t *info,
flash_sect_t sect) static inline void * flash_map (flash_info_t * info,
flash_sect_t sect, uint offset) {
- unsigned int byte_offset = offset * info-portwidth;
+ unsigned int byte_offset = offset * info-portwidth / info-chipwidth;
+ unsigned int addr = (info-start[sect] + byte_offset);
+ unsigned int mask = 0x (info-portwidth - 1);
- return (void *)(info-start[sect] + byte_offset);
+ return (void *)(addr mask);
}
static inline void flash_unmap(flash_info_t *info, flash_sect_t sect, @@ -
398,6 +400,8 @@ void flash_write_cmd (flash_info_t * info, flash_sect_t
sect, #endif
flash_write64(cword.ll, addr);
break;
+ default:
+ printf(fwc: Unknown port width %d\n, info-portwidth);
}
/* Ensure all the instructions are fully finished */ @@ -585,7 +589,6
@@ static int flash_status_check (flash_info_t * info, flash_sect_t sector,
prompt, info-start[sector],
flash_read_long (info, sector, 0));
flash_write_cmd (info, sector, 0, info-cmd_reset);
- udelay(1);
return ERR_TIMOUT;
}
udelay (1); /* also triggers watchdog */
@@ -753,12 +756,8 @@ static void flash_add_byte (flash_info_t * info,
cfiword_t * cword, uchar c) static flash_sect_t find_sector (flash_info_t *
info, ulong addr) {
static flash_sect_t saved_sector; /* previously found sector */
- static flash_info_t *saved_info; /* previously used flash bank */
flash_sect_t sector = saved_sector;
- if ((info != saved_info) || (sector = info-sector_count))
- sector = 0;
-
while ((info-start[sector] addr)
(sector info-sector_count - 1))
sector++;
@@ -770,7 +769,6 @@ static flash_sect_t find_sector (flash_info_t * info,
ulong addr)
sector--;
saved_sector = sector;
- saved_info = info;
[U-Boot] [PATCH 1/1] USB: EHCI: Add weak functions to support new chip
Add ehci_get_port_speed() and ehci_set_usbmode() weak functions
for platform driver to support new chip.
Signed-off-by: Jim Lin ji...@nvidia.com
---
drivers/usb/host/ehci-hcd.c | 40
1 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c816878..6a55cd2 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -122,6 +122,31 @@ static struct descriptor {
#define ehci_is_TDI() (0)
#endif
+int __ehci_get_port_speed(struct ehci_hcor *hcor, uint32_t reg)
+{
+ return PORTSC_PSPD(reg);
+}
+
+int ehci_get_port_speed(struct ehci_hcor *hcor, uint32_t reg)
+ __attribute__((weak, alias(__ehci_get_port_speed)));
+
+void __ehci_set_usbmode(int index)
+{
+ uint32_t tmp;
+ uint32_t *reg_ptr;
+
+ reg_ptr = (uint32_t *)((u8 *)ehcic[index].hcor-or_usbcmd + USBMODE);
+ tmp = ehci_readl(reg_ptr);
+ tmp |= USBMODE_CM_HC;
+#if defined(CONFIG_EHCI_MMIO_BIG_ENDIAN)
+ tmp |= USBMODE_BE;
+#endif
+ ehci_writel(reg_ptr, tmp);
+}
+
+void ehci_set_usbmode(int index)
+ __attribute__((weak, alias(__ehci_set_usbmode)));
+
void __ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
{
mdelay(50);
@@ -149,8 +174,6 @@ static int handshake(uint32_t *ptr, uint32_t mask, uint32_t
done, int usec)
static int ehci_reset(int index)
{
uint32_t cmd;
- uint32_t tmp;
- uint32_t *reg_ptr;
int ret = 0;
cmd = ehci_readl(ehcic[index].hcor-or_usbcmd);
@@ -163,15 +186,8 @@ static int ehci_reset(int index)
goto out;
}
- if (ehci_is_TDI()) {
- reg_ptr = (uint32_t *)((u8 *)ehcic[index].hcor + USBMODE);
- tmp = ehci_readl(reg_ptr);
- tmp |= USBMODE_CM_HC;
-#if defined(CONFIG_EHCI_MMIO_BIG_ENDIAN)
- tmp |= USBMODE_BE;
-#endif
- ehci_writel(reg_ptr, tmp);
- }
+ if (ehci_is_TDI())
+ ehci_set_usbmode(index);
#ifdef CONFIG_USB_EHCI_TXFIFO_THRESH
cmd = ehci_readl(ehcic[index].hcor-or_txfilltuning);
@@ -711,7 +727,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
tmpbuf[1] |= USB_PORT_STAT_POWER 8;
if (ehci_is_TDI()) {
- switch (PORTSC_PSPD(reg)) {
+ switch (ehci_get_port_speed(ctrl-hcor, reg)) {
case PORTSC_PSPD_FS:
break;
case PORTSC_PSPD_LS:
--
1.7.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displaying characters on the display in u-boot
Hi, On Wed, 27 Mar 2013 13:57:38 +0530 Bhargav A K bhargav...@sasken.com wrote: Hi All I have been able to display a splash screen in u-boot by converting the splash image to a header (using GIMP) and loading it into a GFX register (OMAP 4470). There is no need to embed the image data in the U-Boot binary. You can also use the bmp command or splashimage environment variable. Now I have to display text(character) on the display. I read about CONFIG_CFB_CONSOLE in the u-boot documentation. How exactly does it work, is it the right method to display characters on the screen ? First, when defining CONFIG_CFB_CONSOLE in the config file you additionally have to provide video_hw_init() function which returns an initialised GraphicDevice structure for your device. Also set stdout and stderr environment variables to vga and use printf() to display characters. You can use available drivers, i.e. drivers/video/omap3_dss.c, as reference. SASKEN BUSINESS DISCLAIMER: This message may contain... ... please avoid such disclaimers when posting to a public mainling list. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] video: exynos: Add DT support for exynos_fb and exynos_dp drivers
On 22/02/13 18:52, Ajay Kumar wrote: Ajay Kumar (13): [PATCH 01/13] video: exynos_fb: Remove callbacks from the driver [PATCH 02/13] video: exynos_dp: Remove callbacks from the driver [PATCH 03/13] video: exynos_fb: Make fimd_ctrl global [PATCH 04/13] EXYNOS: FDT: Add compatible strings for FIMD [PATCH 05/13] video: exynos_fb: add DT support for FIMD driver [PATCH 06/13] EXYNOS5: Add device node for FIMD [PATCH 07/13] SMDK5250: Add device node for FIMD [PATCH 08/13] video: exynos_dp: Make dp_regs global [PATCH 09/13] EXYNOS5: FDT: Add compatible strings for FIMD [PATCH 10/13] video: exynos_dp: Add function to parse DP DT node [PATCH 11/13] EXYNOS5: Add device node for DP [PATCH 12/13] SMDK5250: Add device node for DP [PATCH 13/13] SMDK5250: Use statically defined structures only in non DT case arch/arm/dts/exynos5250.dtsi | 13 ++ arch/arm/include/asm/arch-exynos/dp_info.h | 1 - board/samsung/dts/exynos5250-smdk5250.dts| 40 + board/samsung/smdk5250/smdk5250.c| 16 +- board/samsung/trats/trats.c | 6 +- board/samsung/universal_c210/universal.c | 23 +-- doc/device-tree-bindings/video/exynos-dp.txt | 69 doc/device-tree-bindings/video/exynos-fb.txt | 92 +++ drivers/video/exynos_dp.c| 76 - drivers/video/exynos_dp_lowlevel.c | 69 +++- drivers/video/exynos_dp_lowlevel.h | 1 + drivers/video/exynos_fb.c| 230 +-- drivers/video/exynos_fimd.c | 44 +++-- include/fdtdec.h | 2 + include/lcd.h| 9 -- lib/fdtdec.c | 2 + 16 files changed, 574 insertions(+), 119 deletions(-) create mode 100644 doc/device-tree-bindings/video/exynos-dp.txt create mode 100644 doc/device-tree-bindings/video/exynos-fb.txt applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix the reading of CPU revision
On Wed, Mar 27, 2013 at 5:02 AM, Dirk Behme dirk.be...@de.bosch.com wrote: I'll check this. Rethinking about the issue here, my recent understanding is: a) We have a VPU library which only understands 0x63 (Quad) and 0x61 (DualLite/Solo) Correct. b) We have Troy's existing get_cpu_rev() [1] which seems to correctly decode the CPU revision (at least this is my impression from testing ;) ). But reports 0x62 for the Solo which then isn't understood by the VPU library (to be checked). Correct. I wonder if we could find a way to combine both parts without breaking the other? I.e. using Troy's get_cpu_rev() to correctly report the CPU revision (in U-Boot), but let the VPU library get the revision it understands? Yes, this could be possible. The original patch in this thread fixes the returned value by get_cpu_rev(), so that we can have mainline U-boot to boot a system that can use VPU on a mx6solo. It is still possible to report the CPU revisions (Quad/Dual-lite/Solo/Solo-lite) strings in boot time. We would need to add a custom mx6 code for printing the strings. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
Dear Manfred Huber,
---8---
abiessmann@punisher % pwclient get 230994
Saved patch to
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
abiessmann@punisher % git am
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
Patch does not have a valid e-mail address.
abiessmann@punisher % ./tools/checkpatch.pl
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
ERROR: trailing whitespace
#39: FILE: drivers/serial/ns16550.c:40:
+^Iif ((serial_in(com_port-lsr) (UART_LSR_TEMT | UART_LSR_THRE)) == $
ERROR: patch seems to be corrupt (line wrapped?)
#40: FILE: drivers/serial/ns16550.c:40:
UART_LSR_THRE) {
total: 2 errors, 0 warnings, 20 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---8---
Can you please fix these errors?
On 03/25/2013 11:02 PM, Manfred Huber wrote:
From: Manfred Huber
Due to a Bug in the ROM code of some OMAP3 devices, the TEMT bit is not
set if UART3 is configured before (only THRE is set). Reason is the
disabling of UART3 even though the Transmitter is not empty. Enabling
UART3 allows the Transmitter to be empty.
Signed-off-by: Manfred Huber man.hu...@arcor.de
---
drivers/serial/ns16550.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index b2da8b3..24ff84f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,10 +36,18 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
-#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
+#if (defined(CONFIG_SPL_BUILD) defined(CONFIG_OMAP34XX))
I think a comment here would be good.
+if ((serial_in(com_port-lsr) (UART_LSR_TEMT | UART_LSR_THRE))
== UART_LSR_THRE) {
The patch is broken here, even if you fix the wrapping you will get an
'over 80 char' error here.
+serial_out(UART_LCR_DLAB, com_port-lcr);
+serial_out(baud_divisor 0xff, com_port-dll);
+serial_out((baud_divisor 8) 0xff, com_port-dlm);
+serial_out(UART_LCRVAL, com_port-lcr);
+serial_out(0, com_port-mdr1);
Do we need to setup baud a.s.o. here? Isn't it enough to issue an soft
reset of the UART? I'm not in this material, I just wonder if we can
omit some of the lines here cause we set e.g. the BAUD later on.
+}
+#endif
+
while (!(serial_in(com_port-lsr) UART_LSR_TEMT))
;
-#endif
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
I managed to apply your patch anyhow. A short test on a tricorder board
showed no harm to the boot process. So please get your patch clean and
resend, then I will add my tested-by.
As Javier pointed out please think about using the
CONFIG_SYS_NS16550_BROKEN_TEMT instead of SPL OMAP34XX.
Another solution could be to have this TEMT | THRE check in
unconditionally, this however would require a lot more testing.
Especially with the release date in mind.
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] mx6: Fix the reading of CPU revision
On Wed, Mar 27, 2013 at 5:57 AM, Dirk Behme dirk.be...@de.bosch.com wrote: Some additional rethinking: I missed that we have a Linux kernel, too ;) c) It's the job of the Linux kernel to export the CPU revision to the VPU library. In case the Linux kernel completely ignores what we are doing in U-Boot and calculates the CPU revision itself (*), e.g. by something like http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60 we can do anything in U-Boot. Independent of the VPU library. Unfortunately VPU library relies on the bootloader to pass the correct silicon revision. Eric's tested passing 0 as get_cpu_rev and showed that VPU simply cannot work on this case. In this case I'd propose to just keep Troy's version of get_cpu_rev() as it is [1]. This is proven to not to work with mx6solo and VPU, so we need the fix I proposed. Here is what I am planning to do: 1. Send a v2 of this patch with the small correction pointed out by Eric 2. Include a weak function to pass get_cpu_rev in common mx6 code Then on top of that, one can send a patch that prints the mx6 silicon strings by differentiating between a mx6dual-lite and mx6solo, if it is worth. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fpga parallel flash loader
Hello everybody, I have got the Spartan 3E Smple Pack with Intel Parallel Flash. I would like to load the parallel flash with the design I synthesized with ISE. So i need some kind of loader for the parallel flash which will run on the fpga. Can this be done with U-Boot? Regards, Klemen___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix the reading of CPU revision
On 27.03.2013 14:37, Fabio Estevam wrote: On Wed, Mar 27, 2013 at 5:57 AM, Dirk Behme dirk.be...@de.bosch.com wrote: Some additional rethinking: I missed that we have a Linux kernel, too ;) c) It's the job of the Linux kernel to export the CPU revision to the VPU library. In case the Linux kernel completely ignores what we are doing in U-Boot and calculates the CPU revision itself (*), e.g. by something like http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60 we can do anything in U-Boot. Independent of the VPU library. Unfortunately VPU library relies on the bootloader to pass the correct silicon revision. I don't think so, at least this depends on the kernel. To my understanding the VPU library relies on the kernel to pass the correct silicon revision. And where the kernel gets this information from seems to depend on the kernel version: a) get it from U-Boot via ATAGs b) calculate the value in the kernel independent of U-Boot About which kernel are you talking? To my understanding, using a recent kernel with device tree there is no revision information passed from the boot loader to the kernel? Instead of hacking U-Boot for these (old) kernels, I'd propose to fix the kernel to pass the 0x61/0x63 correctly to the VPU library. Or as Wolfgang mentioned, even better, fix the VPU library. I really like Troys existing code and see no reason to change it just due to the VPU library. Do the change in the kernel or the VPU library. Best regards Dirk Eric's tested passing 0 as get_cpu_rev and showed that VPU simply cannot work on this case. In this case I'd propose to just keep Troy's version of get_cpu_rev() as it is [1]. This is proven to not to work with mx6solo and VPU, so we need the fix I proposed. Here is what I am planning to do: 1. Send a v2 of this patch with the small correction pointed out by Eric 2. Include a weak function to pass get_cpu_rev in common mx6 code Then on top of that, one can send a patch that prints the mx6 silicon strings by differentiating between a mx6dual-lite and mx6solo, if it is worth. Regards, Fabio Estevam -- == Dirk Behme Robert Bosch Car Multimedia GmbH CM-AI/PJ-CF32 Phone: +49 5121 49-3274 Dirk Behme Fax: +49 711 811 5053274 PO Box 77 77 77 mailto:dirk.be...@de.bosch.com D-31132 Hildesheim - Germany Bosch Group, Car Multimedia (CM) Automotive Navigation and Infotainment Systems (AI) ProJect - CoreFunctions (PJ-CF) Robert Bosch Car Multimedia GmbH - Ein Unternehmen der Bosch Gruppe Sitz: Hildesheim Registergericht: Amtsgericht Hildesheim HRB 201334 Aufsichtsratsvorsitzender: Volkmar Denner Geschäftsführung: Uwe Thomas, Michael Bolle, Robby Drave, Egbert Hellwig == ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On Wed, Mar 27, 2013 at 10:29:00AM +0100, Javier Martinez Canillas wrote: On Wed, Mar 27, 2013 at 5:50 AM, Manfred Huber man.hu...@arcor.de wrote: Please test the Patch. It is very simple on a Beagleboard. I guess you have flashed the actual SPL and u-boot and Beagleboard boots correctly. Now press and hold 'User' button and connect power. SPL should hang. You can see some symbols on the console from the ROM code. Hi Manfred, I don't have access to my IGEP board right now but I'll test your patch as soon as posible. Install the Patch, compile it and flash the NAND. Beagleboard still boots correctly. Now press and hold 'User' button again and Beagleboard should also boot correctly. The Patch works. I suspect the IGEP board has the same bug. If so, the Patch should work on this board too and we don't need CONFIG_SYS_NS16550_BROKEN_TEMT anymore. I still think that we should keep CONFIG_SYS_NS16550_BROKEN_TEMT or something similar instead of just checking for CONFIG_OMAP34XX. Since we don't know if this problem is also present on other TI OMAP platforms (or any other platform). I would just change CONFIG_SYS_NS16550_BROKEN_TEMT semantics once is confirmed that this also fixes the issue on IGEP boards. I'm attempting to see if this ROM bug is (a) known and (b) is or was fixed at some point. Based on what I know (or at least think I know) of how the ROM code lived for OMAP3, given that you're seeing this on beagle and igep, it's a valid assumption that OMAP34XX is buggy. The question I have (and hope for resolution on) is if it's a problem on am335x/omap4 or later as well. If I follow how to reproduce this issue (and I think I do), assuming I can I'll setup an am335x platform in a similar position. If you don't want a patch for this bug please let me know. I will not bother you again. Thanks a lot for working on this. Some people work on mainline U-Boot on their free time (like myself) so it can take a few days until you get a response about a patch. Please be patient :-) Yes, thanks for working this issue through, I also appreciate it! -- 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] mx6: Fix the reading of CPU revision
Hi Fabio,
On 03/27/2013 06:37 AM, Fabio Estevam wrote:
On Wed, Mar 27, 2013 at 5:57 AM, Dirk Behme dirk.be...@de.bosch.com wrote:
Some additional rethinking: I missed that we have a Linux kernel, too ;)
c) It's the job of the Linux kernel to export the CPU revision to the VPU
library. In case the Linux kernel completely ignores what we are doing in
U-Boot and calculates the CPU revision itself (*), e.g. by something like
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60
we can do anything in U-Boot. Independent of the VPU library.
Unfortunately VPU library relies on the bootloader to pass the correct
silicon revision.
The VPU library relies on the output of /proc/cpuinfo (specifically
the line beginning with Revision.
The snippet (from vpu_io.h) is:
tmp = strstr(buf, Revision);
if (tmp != NULL) {
rev = index(tmp, ':');
if (rev != NULL) {
rev++;
system_rev = strtoul(rev, NULL, 16);
ret = 0;
}
}
This code should really be changed, so we don't have to carry this
data all the way from boot loader to /proc/cpuinfo.
Similar (but different) code is present in mxc_ipu_hl_lib.c
for the IPU.
In the case of the VPU library, it seems more sane to have the
VPU driver expose the particular IP revision present on the
system.
Eric's tested passing 0 as get_cpu_rev and showed that VPU simply
cannot work on this case.
In this case I'd propose to just keep Troy's version of get_cpu_rev() as it
is [1].
This is proven to not to work with mx6solo and VPU, so we need the fix
I proposed.
Here is what I am planning to do:
1. Send a v2 of this patch with the small correction pointed out by Eric
2. Include a weak function to pass get_cpu_rev in common mx6 code
Then on top of that, one can send a patch that prints the mx6 silicon
strings by differentiating between a mx6dual-lite and mx6solo, if it
is worth.
It seems a reasonable interim solution to provide backward
compatibility until the kernel driver(s) and userspace can be
fixed.
Another way of doing this that prevents get_cpu_rev() from
hiding the precise CPU is to do this in the weak version
of get_board_rev().
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displaying characters on the display in u-boot
Hi, please keep the U-Boot list address on Cc, other users may find the discussion helpful. On Wed, 27 Mar 2013 19:40:33 +0530 Bhargav A K bhargav...@sasken.com wrote: ... Now I will have to define video_set_lut() also, isn't it ? It depends. What U-Boot version do you use? If you use mainline U-Boot recent versions like v2013.01.01, then this function already exists as a week default empty function. You do not always need video_set_lut() functionality unless you want to use a frame buffer configuration with 8 bits per pixel colour depth. Can I please get more information on what I have to handle inside the function ? This video_set_lut() function is only needed if you use 8 bits per pixel frame buffer. I doubt that you want to use it since the splash screen quality will be really bad in this color depth mode. If you want to use this depth, then this function should fill the color palette (look up table) of the display controller using the index argument of the function as an index into look-up table and using other arguments as values for the look-up table entries under that index. Also, Is there any place where I can of getting more information on the structure members of struct GraphicDevice ? the needed struct members are more or less self-explanatory, so these are not documented anywhere, I think. You need to init only: winSizeX - the width of the display in pixels winSizeY - the height of the display in pixels gdfBytesPP - frame buffer color depth in bytes per pixel gdfIndex - graphics data format of the frame buffer, it is one of GDF__8BIT_INDEX GDF_15BIT_555RGB GDF_16BIT_565RGB GDF_32BIT_X888RGB GDF_24BIT_888RGB GDF__8BIT_332RGB frameAdrs - the starting frame buffer address in the video ram You do not need to initialise other members. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix the reading of CPU revision
Hi Eric,
On 27.03.2013 15:00, Eric Nelson wrote:
Hi Fabio,
On 03/27/2013 06:37 AM, Fabio Estevam wrote:
On Wed, Mar 27, 2013 at 5:57 AM, Dirk Behme dirk.be...@de.bosch.com wrote:
Some additional rethinking: I missed that we have a Linux kernel, too ;)
c) It's the job of the Linux kernel to export the CPU revision to the VPU
library. In case the Linux kernel completely ignores what we are doing in
U-Boot and calculates the CPU revision itself (*), e.g. by something like
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60
we can do anything in U-Boot. Independent of the VPU library.
Unfortunately VPU library relies on the bootloader to pass the correct
silicon revision.
The VPU library relies on the output of /proc/cpuinfo (specifically
the line beginning with Revision.
The snippet (from vpu_io.h) is:
tmp = strstr(buf, Revision);
if (tmp != NULL) {
rev = index(tmp, ':');
if (rev != NULL) {
rev++;
system_rev = strtoul(rev, NULL, 16);
ret = 0;
}
}
This code should really be changed,
Yes :)
so we don't have to carry this
data all the way from boot loader to /proc/cpuinfo.
As mentioned in my previous mail, I have some doubts that *all* kernels
pick the version from the boot loader. It's my understanding that this
strongly depends on the kernel? I.e. there are kernels which get the
version from the boot loader, e.g. via ATAGs. But there are kernels
which are independent from the boot loader and calculate it on their
own? E.g.
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60
?
Best regards
Dirk
Similar (but different) code is present in mxc_ipu_hl_lib.c
for the IPU.
In the case of the VPU library, it seems more sane to have the
VPU driver expose the particular IP revision present on the
system.
Eric's tested passing 0 as get_cpu_rev and showed that VPU simply
cannot work on this case.
In this case I'd propose to just keep Troy's version of get_cpu_rev() as it
is [1].
This is proven to not to work with mx6solo and VPU, so we need the fix
I proposed.
Here is what I am planning to do:
1. Send a v2 of this patch with the small correction pointed out by Eric
2. Include a weak function to pass get_cpu_rev in common mx6 code
Then on top of that, one can send a patch that prints the mx6 silicon
strings by differentiating between a mx6dual-lite and mx6solo, if it
is worth.
It seems a reasonable interim solution to provide backward
compatibility until the kernel driver(s) and userspace can be
fixed.
Another way of doing this that prevents get_cpu_rev() from
hiding the precise CPU is to do this in the weak version
of get_board_rev().
Regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix the reading of CPU revision
Hi Dirk,
On 03/27/2013 08:06 AM, Dirk Behme wrote:
Hi Eric,
On 27.03.2013 15:00, Eric Nelson wrote:
Hi Fabio,
On 03/27/2013 06:37 AM, Fabio Estevam wrote:
On Wed, Mar 27, 2013 at 5:57 AM, Dirk Behme dirk.be...@de.bosch.com
wrote:
snip
The VPU library relies on the output of /proc/cpuinfo (specifically
the line beginning with Revision.
The snippet (from vpu_io.h) is:
tmp = strstr(buf, Revision);
if (tmp != NULL) {
rev = index(tmp, ':');
snip
This code should really be changed,
Yes :)
And this whole thing is really off-topic on the U-Boot list
except as a weak requirement on U-Boot.
so we don't have to carry this
data all the way from boot loader to /proc/cpuinfo.
As mentioned in my previous mail, I have some doubts that *all* kernels
pick the version from the boot loader. It's my understanding that this
strongly depends on the kernel? I.e. there are kernels which get the
version from the boot loader, e.g. via ATAGs. But there are kernels
which are independent from the boot loader and calculate it on their
own? E.g.
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_1.1.0id=207f80453c77bc32e04b5fef863f6fe50a7fd1a8#n60
You're right of course. I believe only non-DT kernels are at issue here,
and it's just the ATAG callback get_board_rev() is at issue, not
get_cpu_rev().
Note that this is supposed to carry **board** revision, which lends
more weight to fixing it.
The kernel knows the proper CPU revision in all cases but publishes
the content of ATAG_REVISION in /proc/cpuinfo
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/kernel/setup.c?h=imx_3.0.35_1.1.0#n655
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/kernel/setup.c?h=imx_3.0.35_1.1.0#n1041
It seems straightforward to simply over-write 'system_rev' on those
kernels which need the hack.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displaying characters on the display in u-boot
Hi Anatolij Thank you very much for Ur guidance What U-Boot version do you use? U-Boot 1.1.4-geb3fa991 (Feb 21 2013 - 10:11:04) (output of version command) This video_set_lut() function is only needed if you use 8 bits per pixel frame buffer. So can I comment it out, (or) just make a dummy call and dummy return from it. It wont affect my character(text) rendering on the display, correct ? My last question, the board_video_init() function just initializes the board in display/video mode. For example if I have a GPIO to switch b/w command and video modes and a GPIO to switch on the LCD, etc., I'll have to do all such functions in it. But if all of those are already done, I can just return a dummy from the function ? Kind regards Bhargav From: Anatolij Gustschin [ag...@denx.de] Sent: Wednesday, March 27, 2013 8:30 PM To: Bhargav A K Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Displaying characters on the display in u-boot Hi, please keep the U-Boot list address on Cc, other users may find the discussion helpful. On Wed, 27 Mar 2013 19:40:33 +0530 Bhargav A K bhargav...@sasken.com wrote: ... Now I will have to define video_set_lut() also, isn't it ? It depends. What U-Boot version do you use? If you use mainline U-Boot recent versions like v2013.01.01, then this function already exists as a week default empty function. You do not always need video_set_lut() functionality unless you want to use a frame buffer configuration with 8 bits per pixel colour depth. Can I please get more information on what I have to handle inside the function ? This video_set_lut() function is only needed if you use 8 bits per pixel frame buffer. I doubt that you want to use it since the splash screen quality will be really bad in this color depth mode. If you want to use this depth, then this function should fill the color palette (look up table) of the display controller using the index argument of the function as an index into look-up table and using other arguments as values for the look-up table entries under that index. Also, Is there any place where I can of getting more information on the structure members of struct GraphicDevice ? the needed struct members are more or less self-explanatory, so these are not documented anywhere, I think. You need to init only: winSizeX - the width of the display in pixels winSizeY - the height of the display in pixels gdfBytesPP - frame buffer color depth in bytes per pixel gdfIndex - graphics data format of the frame buffer, it is one of GDF__8BIT_INDEX GDF_15BIT_555RGB GDF_16BIT_565RGB GDF_32BIT_X888RGB GDF_24BIT_888RGB GDF__8BIT_332RGB frameAdrs - the starting frame buffer address in the video ram You do not need to initialise other members. Thanks, Anatolij SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] USB: EHCI: Add weak functions to support new chip
On 03/27/2013 04:52 AM, Jim Lin wrote: Add ehci_get_port_speed() and ehci_set_usbmode() weak functions for platform driver to support new chip. Jim, you really need to send this as part of a complete patch series that demonstrates the need for this feature. At least explain the need in the commit description. Also, you didn't Cc the USB maintainer for review. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
On Tue, Mar 26, 2013 at 09:57:35AM +0530, Sricharan R wrote:
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
[snip]
@@ -153,7 +155,9 @@
mmcargs=setenv bootargs console=${console} \
vram=${vram} \
root=${mmcroot} \
- rootfstype=${mmcrootfstype}\0 \
+ rootfstype=${mmcrootfstype}; \
+ run findfdt; \
+ fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0 \
I missed this part before, sorry. What we do on am335x_evm to allow
for easier overrides is:
- bootcmd runs findfdt (since we'll need it in all cases).
- Enable CONFIG_CMD_FS_GENERIC
- Add a 'loadfdt' command that can be called out ala loaduimage
- Use 'load' in loadfdt/loaduimage so that we don't care what the
underlying filesystem type is.
- Use bootdir to help with overrides as well:
loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
So that we can easily grab from the first partition (FAT) or another
partition (ext3/4/etc).
--
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] Displaying characters on the display in u-boot
Hi, On Wed, 27 Mar 2013 21:05:55 +0530 Bhargav A K bhargav...@sasken.com wrote: ... What U-Boot version do you use? U-Boot 1.1.4-geb3fa991 (Feb 21 2013 - 10:11:04) (output of version command) Very old, ;-). This video_set_lut() function is only needed if you use 8 bits per pixel frame buffer. So can I comment it out, (or) just make a dummy call and dummy return from it. It wont affect my character(text) rendering on the display, correct ? yes, just provide a dummy video_set_lut(). If you do not use the GDF__8BIT_INDEX framebuffer format, the rendering will work. My last question, the board_video_init() function just initializes the board in display/video mode. For example if I have a GPIO to switch b/w command and video modes and a GPIO to switch on the LCD, etc., I'll have to do all such functions in it. But if all of those are already done, I can just return a dummy from the function ? Yes. If board specific video initialisation is done elsewhere the board_video_init() can be a dummy function. Some video drivers expect board_video_init() to return frame buffer base address but i.e. in omap3 driver it returns 0 for successful video init or an error code in case the board specific video init fails, thus preventing further initialisation in the cfb_console driver. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displaying characters on the display in u-boot
Anatolij, Thank you very very much, I will implement this very soon. If I face any issues, which I won't after such excellent tutoring from you, can I revert back to you ? Thanks again :)... Yes. If board specific video initialization is done elsewhere the board_video_init() can be a dummy function. I shall make it a dummy, and I have to make sure it return success, as I have done it elsewhere. Kind regards Bhargav From: Anatolij Gustschin [ag...@denx.de] Sent: Wednesday, March 27, 2013 9:57 PM To: Bhargav A K Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Displaying characters on the display in u-boot Hi, On Wed, 27 Mar 2013 21:05:55 +0530 Bhargav A K bhargav...@sasken.com wrote: ... What U-Boot version do you use? U-Boot 1.1.4-geb3fa991 (Feb 21 2013 - 10:11:04) (output of version command) Very old, ;-). This video_set_lut() function is only needed if you use 8 bits per pixel frame buffer. So can I comment it out, (or) just make a dummy call and dummy return from it. It wont affect my character(text) rendering on the display, correct ? yes, just provide a dummy video_set_lut(). If you do not use the GDF__8BIT_INDEX framebuffer format, the rendering will work. My last question, the board_video_init() function just initializes the board in display/video mode. For example if I have a GPIO to switch b/w command and video modes and a GPIO to switch on the LCD, etc., I'll have to do all such functions in it. But if all of those are already done, I can just return a dummy from the function ? Yes. If board specific video initialisation is done elsewhere the board_video_init() can be a dummy function. Some video drivers expect board_video_init() to return frame buffer base address but i.e. in omap3 driver it returns 0 for successful video init or an error code in case the board specific video init fails, thus preventing further initialisation in the cfb_console driver. Thanks, Anatolij SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6: Fix get_board_rev() for the mx6 solo case
When booting a Freescale kernel 3.0.35 on a Wandboard solo, the get_board_rev()
returns 0x62xxx, which is not a value understood by the VPU
(Video Processing Unit) library in the kernel and causes the video playback to
fail.
The expected values for get_board_rev are:
0x63xxx: For mx6quad/dual
0x61xxx: For mx6dual-lite/solo
So adjust get_board_rev() accordingly and make it as weak function, so that we
do not need to define it in every mx6 board file.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 12
board/boundary/nitrogen6x/nitrogen6x.c|5 -
board/freescale/mx6qsabrelite/mx6qsabrelite.c |5 -
board/freescale/mx6qsabresd/mx6qsabresd.c |5 -
board/wandboard/wandboard.c |5 -
5 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 193ba12..4f3cd14 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -61,6 +61,18 @@ u32 get_cpu_rev(void)
return (type 12) | (reg + 0x10);
}
+#ifdef CONFIG_REVISION_TAG
+u32 __weak get_board_rev(void)
+{
+ u32 cpurev = get_cpu_rev();
+ u32 type = ((cpurev 12) 0xff);
+ if (type == MXC_CPU_MX6SOLO)
+ cpurev = (MXC_CPU_MX6DL) 12 | (get_cpu_rev() 0xFFF);
+
+ return cpurev;
+}
+#endif
+
void init_aips(void)
{
struct aipstz_regs *aips1, *aips2;
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 229c237..1b1bedf 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -328,11 +328,6 @@ int board_mmc_init(bd_t *bis)
}
#endif
-u32 get_board_rev(void)
-{
- return 0x63000;
-}
-
#ifdef CONFIG_MXC_SPI
iomux_v3_cfg_t const ecspi1_pads[] = {
/* SS1 */
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 5b69a6d..782e5ba 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -298,11 +298,6 @@ int board_mmc_init(bd_t *bis)
}
#endif
-u32 get_board_rev(void)
-{
- return 0x63000 ;
-}
-
#ifdef CONFIG_MXC_SPI
iomux_v3_cfg_t const ecspi1_pads[] = {
/* SS1 */
diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c
b/board/freescale/mx6qsabresd/mx6qsabresd.c
index 2b3926a..806769f 100644
--- a/board/freescale/mx6qsabresd/mx6qsabresd.c
+++ b/board/freescale/mx6qsabresd/mx6qsabresd.c
@@ -239,11 +239,6 @@ int board_eth_init(bd_t *bis)
return 0;
}
-u32 get_board_rev(void)
-{
- return 0x63000;
-}
-
int board_early_init_f(void)
{
setup_iomux_uart();
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index d95189f..1e379fb 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -168,11 +168,6 @@ int board_init(void)
return 0;
}
-u32 get_board_rev(void)
-{
- return get_cpu_rev();
-}
-
int checkboard(void)
{
puts(Board: Wandboard\n);
--
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 0/2 V2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B
Hi Minkyu, On Tue, Mar 26, 2013 at 11:38 PM, Minkyu Kang mk7.k...@samsung.com wrote: Dear Rajeshwari and Simon, On 12/03/13 15:13, Rajeshwari Birje wrote: Hi Minkyu, Yes it is based on the following patches submitted by Simon Glass and link for the same. sf: Add spi_flash_alloc() to create a new SPI flash struct http://patchwork.ozlabs.org/patch/208228/ sf: Use spi_flash_alloc() in each SPI flash driver: http://patchwork.ozlabs.org/patch/226582/ Those patches are merged? Yes they are in mainline now. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On Wed, Mar 27, 2013 at 2:37 PM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Dear Manfred Huber,
---8---
abiessmann@punisher % pwclient get 230994
Saved patch to
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
abiessmann@punisher % git am
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
Patch does not have a valid e-mail address.
abiessmann@punisher % ./tools/checkpatch.pl
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
ERROR: trailing whitespace
#39: FILE: drivers/serial/ns16550.c:40:
+^Iif ((serial_in(com_port-lsr) (UART_LSR_TEMT | UART_LSR_THRE)) == $
ERROR: patch seems to be corrupt (line wrapped?)
#40: FILE: drivers/serial/ns16550.c:40:
UART_LSR_THRE) {
total: 2 errors, 0 warnings, 20 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE
U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---8---
Can you please fix these errors?
On 03/25/2013 11:02 PM, Manfred Huber wrote:
From: Manfred Huber
Due to a Bug in the ROM code of some OMAP3 devices, the TEMT bit is not
set if UART3 is configured before (only THRE is set). Reason is the
disabling of UART3 even though the Transmitter is not empty. Enabling
UART3 allows the Transmitter to be empty.
Signed-off-by: Manfred Huber man.hu...@arcor.de
---
drivers/serial/ns16550.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index b2da8b3..24ff84f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,10 +36,18 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
-#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
+#if (defined(CONFIG_SPL_BUILD) defined(CONFIG_OMAP34XX))
I think a comment here would be good.
+if ((serial_in(com_port-lsr) (UART_LSR_TEMT | UART_LSR_THRE))
== UART_LSR_THRE) {
The patch is broken here, even if you fix the wrapping you will get an
'over 80 char' error here.
+serial_out(UART_LCR_DLAB, com_port-lcr);
+serial_out(baud_divisor 0xff, com_port-dll);
+serial_out((baud_divisor 8) 0xff, com_port-dlm);
+serial_out(UART_LCRVAL, com_port-lcr);
+serial_out(0, com_port-mdr1);
Do we need to setup baud a.s.o. here? Isn't it enough to issue an soft
reset of the UART? I'm not in this material, I just wonder if we can
omit some of the lines here cause we set e.g. the BAUD later on.
+}
+#endif
+
while (!(serial_in(com_port-lsr) UART_LSR_TEMT))
;
-#endif
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
I managed to apply your patch anyhow. A short test on a tricorder board
showed no harm to the boot process. So please get your patch clean and
resend, then I will add my tested-by.
As Javier pointed out please think about using the
CONFIG_SYS_NS16550_BROKEN_TEMT instead of SPL OMAP34XX.
Another solution could be to have this TEMT | THRE check in
unconditionally, this however would require a lot more testing.
Especially with the release date in mind.
Best regards
Andreas Bießmann
Hi Manfred,
I just tested your patch and my IGEPv2 boots correctly.
So, after addressing the issues pointed out by Andreas feel free to
add my Tested-by too.
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx6: Fix get_board_rev() for the mx6 solo case
When booting a Freescale kernel 3.0.35 on a Wandboard solo, the get_board_rev()
returns 0x62xxx, which is not a value understood by the VPU
(Video Processing Unit) library in the kernel and causes the video playback to
fail.
The expected values for get_board_rev are:
0x63xxx: For mx6quad/dual
0x61xxx: For mx6dual-lite/solo
So adjust get_board_rev() accordingly and make it as weak function, so that we
do not need to define it in every mx6 board file.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Avoid extra call to get_cpu_rev()
arch/arm/cpu/armv7/mx6/soc.c | 12
board/boundary/nitrogen6x/nitrogen6x.c|5 -
board/freescale/mx6qsabrelite/mx6qsabrelite.c |5 -
board/freescale/mx6qsabresd/mx6qsabresd.c |5 -
board/wandboard/wandboard.c |5 -
5 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 193ba12..4f3cd14 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -61,6 +61,18 @@ u32 get_cpu_rev(void)
return (type 12) | (reg + 0x10);
}
+#ifdef CONFIG_REVISION_TAG
+u32 __weak get_board_rev(void)
+{
+ u32 cpurev = get_cpu_rev();
+ u32 type = ((cpurev 12) 0xff);
+ if (type == MXC_CPU_MX6SOLO)
+ cpurev = (MXC_CPU_MX6DL) 12 | (cpurev 0xFFF);
+
+ return cpurev;
+}
+#endif
+
void init_aips(void)
{
struct aipstz_regs *aips1, *aips2;
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 229c237..1b1bedf 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -328,11 +328,6 @@ int board_mmc_init(bd_t *bis)
}
#endif
-u32 get_board_rev(void)
-{
- return 0x63000;
-}
-
#ifdef CONFIG_MXC_SPI
iomux_v3_cfg_t const ecspi1_pads[] = {
/* SS1 */
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 5b69a6d..782e5ba 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -298,11 +298,6 @@ int board_mmc_init(bd_t *bis)
}
#endif
-u32 get_board_rev(void)
-{
- return 0x63000 ;
-}
-
#ifdef CONFIG_MXC_SPI
iomux_v3_cfg_t const ecspi1_pads[] = {
/* SS1 */
diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c
b/board/freescale/mx6qsabresd/mx6qsabresd.c
index 2b3926a..806769f 100644
--- a/board/freescale/mx6qsabresd/mx6qsabresd.c
+++ b/board/freescale/mx6qsabresd/mx6qsabresd.c
@@ -239,11 +239,6 @@ int board_eth_init(bd_t *bis)
return 0;
}
-u32 get_board_rev(void)
-{
- return 0x63000;
-}
-
int board_early_init_f(void)
{
setup_iomux_uart();
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index d95189f..1e379fb 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -168,11 +168,6 @@ int board_init(void)
return 0;
}
-u32 get_board_rev(void)
-{
- return get_cpu_rev();
-}
-
int checkboard(void)
{
puts(Board: Wandboard\n);
--
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] mx6: Fix get_board_rev() for the mx6 solo case
On 3/27/2013 9:36 AM, Fabio Estevam wrote:
When booting a Freescale kernel 3.0.35 on a Wandboard solo, the get_board_rev()
returns 0x62xxx, which is not a value understood by the VPU
(Video Processing Unit) library in the kernel and causes the video playback to
fail.
The expected values for get_board_rev are:
0x63xxx: For mx6quad/dual
0x61xxx: For mx6dual-lite/solo
So adjust get_board_rev() accordingly and make it as weak function, so that we
do not need to define it in every mx6 board file.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 12
board/boundary/nitrogen6x/nitrogen6x.c|5 -
board/freescale/mx6qsabrelite/mx6qsabrelite.c |5 -
board/freescale/mx6qsabresd/mx6qsabresd.c |5 -
board/wandboard/wandboard.c |5 -
5 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 193ba12..4f3cd14 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -61,6 +61,18 @@ u32 get_cpu_rev(void)
return (type 12) | (reg + 0x10);
}
+#ifdef CONFIG_REVISION_TAG
+u32 __weak get_board_rev(void)
+{
+ u32 cpurev = get_cpu_rev();
+ u32 type = ((cpurev 12) 0xff);
+ if (type == MXC_CPU_MX6SOLO)
+ cpurev = (MXC_CPU_MX6DL) 12 | (get_cpu_rev() 0xFFF);
Why call get_cpu_rev again?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAKEALL: Fix case substitution for old bash
On Fri, Mar 22, 2013 at 10:37:03AM -0700, York Sun wrote:
Bash ver 3.x doesn't support the parameter expansion with case
substitution. Use tr instead.
Signed-off-by: York Sun york...@freescale.com
Acked-by: Allen Martin amar...@nvidia.com
---
Removed RFC from subject line.
MAKEALL |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAKEALL b/MAKEALL
index c1d8957..ac92ef6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -664,7 +664,7 @@ build_target() {
export BUILD_DIR=${output_dir}
target_arch=$(get_target_arch ${target})
- eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
+ eval cross_toolchain=\$CROSS_COMPILE_`echo $target_arch | tr
'[:lower:]' '[:upper:]'`
if [ ${cross_toolchain} ] ; then
MAKE=make CROSS_COMPILE=${cross_toolchain}
elif [ ${CROSS_COMPILE} ] ; then
--
1.7.9.5
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] MAKEALL: allow regex matches for -s option
From: Stephen Warren swar...@nvidia.com
This allows:
MAKEALL -s tegra
to replace:
MAKEALL -s tegra20 -s tegra30 -s tegra114
The following also works:
MAKEALL -s tegra -s omap
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2: Modified the commit description marginally to s/tegra*/tegra/ in the
first example MAKEALL command; it's a regex match so a substring, so the
* isn't needed. Also add the dual tegra/omap example command.
MAKEALL |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index c1d8957..91fa495 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -104,9 +104,9 @@ while true ; do
-s|--soc)
# echo Option SoC: argument \`$2'
if [ $opt_s ] ; then
- opt_s=${opt_s%)} || \$6 == \$2\)
+ opt_s=${opt_s%)} || \$6 == \$2\ || \$6 ~ /$2/)
else
- opt_s=(\$6 == \$2\)
+ opt_s=(\$6 == \$2\ || \$6 ~ /$2/)
fi
SELECTED='y'
shift 2 ;;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] unaligned access in part_efi.c
On 03/26/2013 02:42 PM, Marc Dietrich wrote: Hi, access to part-start_sect in pmbr_part_valid() (form disk/part_efi.c) and propably other positions/fields causes an unaligned access on ARM (tegra in my case) and a uboot crash. This was introduced by commit fae2bf22 [1] which changed le32_to_int (which is a byte access) to le32_to_cpu (which is a 32bit access). I can't reproduce this with latest u-boot-arm/master, which includes that commit. Both mmc dev N; mmc rescan ; mmcinfo and part list mmc N work fine for me with both DOS PT and GPT. I did test this on a Tegra Seaboard which isn't identical to the AC100, but the only practical difference is 512M vs 1G RAM, which seems unlikely to cause this. It'd help if you pointed out exactly which access causes the issue; which piece of code is failing. The most likely issue is that some memory buffer is assumed to be aligned to 4-bytes, but actually isn't. To track that down, we'd need to know which code and which buffer. Also, a disassembly of the problematic function would be useful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] apx4devkit: change maintainer
On Wed, Mar 20, 2013 at 09:08:10AM -, Veli-Pekka Peltola wrote: As I am no longer working for Bluegiga I will pass apx4devkit maintenance to Lauri. Signed-off-by: Veli-Pekka Peltola veli-pekka.pelt...@iki.fi Acked-by: Lauri Hintsala lauri.hints...@bluegiga.com 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] [PATCH V2] MAKEALL: allow regex matches for -s option
On Wed, Mar 27, 2013 at 11:51:25AM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This allows: MAKEALL -s tegra to replace: MAKEALL -s tegra20 -s tegra30 -s tegra114 The following also works: MAKEALL -s tegra -s omap Signed-off-by: Stephen Warren swar...@nvidia.com --- v2: Modified the commit description marginally to s/tegra*/tegra/ in the first example MAKEALL command; it's a regex match so a substring, so the * isn't needed. Also add the dual tegra/omap example command. 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] [U-Boot, 1/2] env_callback: Mark find_env_callback as static
On Tue, Mar 12, 2013 at 06:16:50AM -, Tom Rini wrote: This is not called outside of env_callback.c so mark static, remove from env_callback.h Cc: Joe Hershberger joe.hershber...@ni.com Signed-off-by: Tom Rini tr...@ti.com Acked-by: Joe Hershberger joe.hershber...@ni.com 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] checkpatch.pl: Add 'debug' to the list of logFunctions
On Thu, Mar 14, 2013 at 05:36:13AM -, Tom Rini wrote: While the kernel mainly uses pr_debug(...), etc, for debug messages, we use debug(...). Add this to the list of logFunctions so that they are correctly checked (and not warned against) for long string literals. Signed-off-by: Tom Rini tr...@ti.com 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] .checkpatch.conf: ignore udelay-usleep_range warnings
On Fri, Mar 15, 2013 at 10:43:48AM -, Matt Porter wrote: usleep_range() is a Linux facility, ignore it when udelay() is encountered. Signed-off-by: Matt Porter mpor...@ti.com 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] [U-Boot,v2] image: Add support for Plan 9
On Wed, Mar 20, 2013 at 06:31:35AM -, Steven Stallion wrote: Signed-off-by: Steven Stallion sstall...@gmail.com Cc: Tom Rini tr...@ti.com Reviewed-by: Tom Rini tr...@ti.com 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] cmd_ext4: BREAK and correct ext4write parameter order
On Wed, Mar 20, 2013 at 04:21:38AM -, Tom Rini wrote: The ext4write command was taking the in-memory address and filename path in reverse order from the rest of the filesystem read and write commands. This corrects the order to be the same as fatload, etc. Signed-off-by: Tom Rini tr...@ti.com 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] [PATCH v2] mx6: Fix get_board_rev() for the mx6 solo case
Hi Fabio,
On 27.03.2013 18:36, Fabio Estevam wrote:
When booting a Freescale kernel 3.0.35 on a Wandboard solo, the get_board_rev()
returns 0x62xxx, which is not a value understood by the VPU
(Video Processing Unit) library in the kernel and causes the video playback to
fail.
The expected values for get_board_rev are:
0x63xxx: For mx6quad/dual
0x61xxx: For mx6dual-lite/solo
So adjust get_board_rev() accordingly and make it as weak function, so that we
do not need to define it in every mx6 board file.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Avoid extra call to get_cpu_rev()
arch/arm/cpu/armv7/mx6/soc.c | 12
board/boundary/nitrogen6x/nitrogen6x.c|5 -
board/freescale/mx6qsabrelite/mx6qsabrelite.c |5 -
board/freescale/mx6qsabresd/mx6qsabresd.c |5 -
board/wandboard/wandboard.c |5 -
5 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 193ba12..4f3cd14 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -61,6 +61,18 @@ u32 get_cpu_rev(void)
return (type 12) | (reg + 0x10);
}
+#ifdef CONFIG_REVISION_TAG
+u32 __weak get_board_rev(void)
+{
+ u32 cpurev = get_cpu_rev();
+ u32 type = ((cpurev 12) 0xff);
+ if (type == MXC_CPU_MX6SOLO)
+ cpurev = (MXC_CPU_MX6DL) 12 | (cpurev 0xFFF);
+
+ return cpurev;
+}
+#endif
This is much better than changing Troy's get_cpu_rev(). Thanks :)
But what's about to add this code to
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/kernel/setup.c?h=imx_3.0.35_1.1.0#n655
?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6: Fix get_board_rev() for the mx6 solo case
Hi Dirk, On Wed, Mar 27, 2013 at 3:56 PM, Dirk Behme dirk.be...@gmail.com wrote: This is much better than changing Troy's get_cpu_rev(). Thanks :) I am glad you like it :-) But what's about to add this code to http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/kernel/setup.c?h=imx_3.0.35_1.1.0#n655 Because I cannot post a patch in the U-boot list to fix an internal FSL kernel :-) I can certainly suggest this (and yes, I fully agree that the kernel should handle the CPU detection without relying at the bootloader at all), but from a U-boot perspective we cannot really know which kernel version the user will deploy. If we want mainline U-boot to work with this particular kernel version on mx6 solo, then we need to adjust ATAGS as proposed by my patch. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: tegra: support T33 SKU of Tegra30
From: Stephen Warren swar...@nvidia.com
Make U-Boot aware of the T33 SKU of Tegra30, and treat it identically
to any other Tegra30.
An alternative would be to simply remove the SKU checking from
tegra_get_chip_type(); most use of the value most likely simply wants
to know the current chip, not the specific SKU. Or, the function could
be split into separate tegra_get_chip() and tegra_get_sku() for the
cases where differentiation really is required.
I wonder whether tegra_get_chip_type() should printf() whenever any
unkown chip/SKU is found, although perhaps the function is called so
early that the printf() wouldn't actually make it to the UART anyway.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/cpu/tegra-common/ap.c |1 +
arch/arm/include/asm/arch-tegra/tegra.h |1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c
index 236cda8..3f30805 100644
--- a/arch/arm/cpu/tegra-common/ap.c
+++ b/arch/arm/cpu/tegra-common/ap.c
@@ -65,6 +65,7 @@ int tegra_get_chip_type(void)
break;
case CHIPID_TEGRA30:
switch (tegra_sku_id) {
+ case SKU_ID_T33:
case SKU_ID_T30:
return TEGRA_SOC_T30;
}
diff --git a/arch/arm/include/asm/arch-tegra/tegra.h
b/arch/arm/include/asm/arch-tegra/tegra.h
index bf7229d..3e642e9 100644
--- a/arch/arm/include/asm/arch-tegra/tegra.h
+++ b/arch/arm/include/asm/arch-tegra/tegra.h
@@ -78,6 +78,7 @@ enum {
SKU_ID_T25 = 0x18,
SKU_ID_AP25E= 0x1b,
SKU_ID_T25E = 0x1c,
+ SKU_ID_T33 = 0x80,
SKU_ID_T30 = 0x81, /* Cardhu value */
SKU_ID_T114_ENG = 0x00, /* Dalmore value, unfused */
};
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] RFC: am335x: enable falcon boot mode for mmc (raw and fat)
On Sun, Mar 24, 2013 at 10:51:33PM +0100, Peter Korsgaard wrote: Jump into full u-boot mode if a 'c' character is received on the uart. We need to adjust the spl bss/malloc area to not overlap with the loadaddr of the kernel (sdram + 32k), so move it past u-boot instead. Signed-off-by: Peter Korsgaard peter.korsga...@barco.com [snip] +/* raw mmc */ +#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 0xa00 /* address 0xa */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR0x8 /* address 0x1000 */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 8 /* 4KB */ Did you also test raw mode? Also, why 0xa00? U-Boot is 0x300 - 0x500, and one might say throw a redundant copy at 0x500 - 0x700. But we don't do 4 copy redundancy in U-Boot, just 2 usually. +/* dummy defines to keep spl_nand.c happy */ +#define CONFIG_CMD_SPL_NAND_OFS 0 +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0 +#define CONFIG_CMD_SPL_WRITE_SIZE0 We should do some real defines here while at it, since the GP EVM has NAND :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6: Fix get_board_rev() for the mx6 solo case
Am 27.03.2013 20:36, schrieb Fabio Estevam: Hi Dirk, On Wed, Mar 27, 2013 at 3:56 PM, Dirk Behme dirk.be...@gmail.com wrote: This is much better than changing Troy's get_cpu_rev(). Thanks :) I am glad you like it :-) But what's about to add this code to http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/kernel/setup.c?h=imx_3.0.35_1.1.0#n655 Because I cannot post a patch in the U-boot list to fix an internal FSL kernel :-) I can certainly suggest this (and yes, I fully agree that the kernel should handle the CPU detection without relying at the bootloader at all), but from a U-boot perspective we cannot really know which kernel version the user will deploy. If we want mainline U-boot to work with this particular kernel version on mx6 solo, then we need to adjust ATAGS as proposed by my patch. Ok, sounds reasonable, agreed. Even if someone might complain that this is off-topic here, again ( ;) ): Do you like to check if the recent _mainline_ kernel wants something similar? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] MAKEALL: Fix case substitution for old bash
On Thu, Mar 21, 2013 at 01:38:37PM -0700, York Sun wrote: On 03/21/2013 01:28 PM, Allen Martin wrote: [snip] PS: What happened with your bool fixup patch? I'm a big fan of that patch :^) Tom asked on March 4th. I think he will accept it. I never got the expected acks on v7 that I thought would be forthcoming. -- 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 6/6] RFC: am335x: enable falcon boot mode for mmc (raw and fat)
Tom == Tom Rini tr...@ti.com writes: Tom On Sun, Mar 24, 2013 at 10:51:33PM +0100, Peter Korsgaard wrote: Jump into full u-boot mode if a 'c' character is received on the uart. We need to adjust the spl bss/malloc area to not overlap with the loadaddr of the kernel (sdram + 32k), so move it past u-boot instead. Signed-off-by: Peter Korsgaard peter.korsga...@barco.com Tom [snip] +/* raw mmc */ +#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0xa00 /* address 0xa */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x8 /* address 0x1000 */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 8 /* 4KB */ Tom Did you also test raw mode? Yes, I did. I'm personally most interested in raw mode because of the 4x redundant MLO handling. Tom Also, why 0xa00? U-Boot is 0x300 - 0x500, Tom and one might say throw a redundant copy at 0x500 - 0x700. But we Tom don't do 4 copy redundancy in U-Boot, just 2 usually. No particular reason, 0x700 should work as well. As mentioned, this was just a proof of concept to be able to test it. +/* dummy defines to keep spl_nand.c happy */ +#define CONFIG_CMD_SPL_NAND_OFS0 +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0 +#define CONFIG_CMD_SPL_WRITE_SIZE 0 Tom We should do some real defines here while at it, since the GP EVM has Tom NAND :) Yes. It's a bit unfortunate that CONFIG_SPL_OS_BOOT is a global setting, so you need all the various falcon boot related defines even if you don't plan on using them. I can try to come up with sensible NAND values, but I don't have a EVM to test. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README: document the requirements for CONFIG_SYS_HZ
On Fri, Mar 22, 2013 at 10:41:53PM +0100, Wolfgang Denk wrote: Dear Stephen Warren, In message 514ccaae.6020...@wwwdotorg.org you wrote: +The frequency of the timer returned by get_timer(). This value +MUST be 1000. This is misleading, or even incorrect. If I read this, I would expect that get_timer() returns 1000. Obviously, this is incorrect. Instead, get_timer() returns timestamp information in millisecond resolution. That is not what that sentence means. Yes, I know. But it can be easily misinterpreted. How about: The frequency of the timer returned by get_timer(). get_timer() must operate in milliseconds and this CONFIG option must be set to 1000. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6: Fix get_board_rev() for the mx6 solo case
Hi Dirk, On 03/27/2013 12:47 PM, Dirk Behme wrote: Am 27.03.2013 20:36, schrieb Fabio Estevam: Hi Dirk, On Wed, Mar 27, 2013 at 3:56 PM, Dirk Behme dirk.be...@gmail.com wrote: This is much better than changing Troy's get_cpu_rev(). Thanks :) I am glad you like it :-) But what's about to add this code to http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/kernel/setup.c?h=imx_3.0.35_1.1.0#n655 Because I cannot post a patch in the U-boot list to fix an internal FSL kernel :-) I can certainly suggest this (and yes, I fully agree that the kernel should handle the CPU detection without relying at the bootloader at all), but from a U-boot perspective we cannot really know which kernel version the user will deploy. If we want mainline U-boot to work with this particular kernel version on mx6 solo, then we need to adjust ATAGS as proposed by my patch. Ok, sounds reasonable, agreed. Even if someone might complain that this is off-topic here, again ( ;) ): Do you like to check if the recent _mainline_ kernel wants something similar? It wasn't a complaint from me, but I can assure you that the offending bit of code that I found (in imx-lib) won't function against a main-line kernel without some serious re-work. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] RFC: am335x: enable falcon boot mode for mmc (raw and fat)
On Wed, Mar 27, 2013 at 08:57:05PM +0100, Peter Korsgaard wrote: Tom == Tom Rini tr...@ti.com writes: Tom On Sun, Mar 24, 2013 at 10:51:33PM +0100, Peter Korsgaard wrote: Jump into full u-boot mode if a 'c' character is received on the uart. We need to adjust the spl bss/malloc area to not overlap with the loadaddr of the kernel (sdram + 32k), so move it past u-boot instead. Signed-off-by: Peter Korsgaard peter.korsga...@barco.com Tom [snip] +/* raw mmc */ +#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 0xa00 /* address 0xa */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR0x8 /* address 0x1000 */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 8 /* 4KB */ Tom Did you also test raw mode? Yes, I did. I'm personally most interested in raw mode because of the 4x redundant MLO handling. Note that you only get 3 on RAW mode because we place U-Boot (by default) in the fourth slot. I noticed this recently but was hesitant to break possible deployed setups (in beagle land). RAW mode isnt' well documented, but it is in a few places. For your device I imagine you could fix things however. Tom Also, why 0xa00? U-Boot is 0x300 - 0x500, Tom and one might say throw a redundant copy at 0x500 - 0x700. But we Tom don't do 4 copy redundancy in U-Boot, just 2 usually. No particular reason, 0x700 should work as well. As mentioned, this was just a proof of concept to be able to test it. Right. And I'd love to see bootcount or similar updated so that we can try redundant copies of U-Boot. +/* dummy defines to keep spl_nand.c happy */ +#define CONFIG_CMD_SPL_NAND_OFS 0 +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0 +#define CONFIG_CMD_SPL_WRITE_SIZE0 Tom We should do some real defines here while at it, since the GP EVM has Tom NAND :) Yes. It's a bit unfortunate that CONFIG_SPL_OS_BOOT is a global setting, so you need all the various falcon boot related defines even if you don't plan on using them. I can try to come up with sensible NAND values, but I don't have a EVM to test. Well, CONFIG_SYS_NAND_SPL_KERNEL_OFFS would be where we say nandimgsrc is in env. Stefano, looking at twister, the spl export looks like it goes right at the start of the rootfs, isn't that bad? Or at least, luck? -- 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 6/6] RFC: am335x: enable falcon boot mode for mmc (raw and fat)
Tom == Tom Rini tr...@ti.com writes: Hi, Yes, I did. I'm personally most interested in raw mode because of the 4x redundant MLO handling. Tom Note that you only get 3 on RAW mode because we place U-Boot (by Tom default) in the fourth slot. I noticed this recently but was hesitant Tom to break possible deployed setups (in beagle land). RAW mode isnt' well Tom documented, but it is in a few places. For your device I imagine you Tom could fix things however. And you possibly lose the first if you need a DOS style MBR, but that's OK, I just want to be able to field upgrade the MLO without risks, so 2 is enough. No particular reason, 0x700 should work as well. As mentioned, this was just a proof of concept to be able to test it. Tom Right. And I'd love to see bootcount or similar updated so that Tom we can try redundant copies of U-Boot. Me too. I'll do some work on it in the relatively near future. I haven't looked enough into it yet to know if bootcount is enough, or if I would need custom SPL logic (basically a platform specific spl board_init_r). The behaviour I would like to have is: - eMMC split in two parts, and everything (u-boot/linux/rootfs) doubled - SPL reads a flag somewhere (probably a raw eMMC sector) to decide if it should boot low or high uImage / u-boot - On error (reset because of watchdog, bootcount, ..?) it falls back to the other part - On upgrades the currently unused part is written and the boot flag changed. That's AFAIK currently not possible to do with SPL, as the boot addresses are build time defines. I can try to come up with sensible NAND values, but I don't have a EVM to test. Tom Well, CONFIG_SYS_NAND_SPL_KERNEL_OFFS would be where we say nandimgsrc Tom is in env. Stefano, looking at twister, the spl export looks like it Tom goes right at the start of the rootfs, isn't that bad? Or at least, Tom luck? You mean nandsrcaddr, right? CONFIG_CMD_SPL_NAND_OFS just need to be somewhere unused on the nand. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] unaligned access in part_efi.c
On Wednesday 27 March 2013 12:23:22 Stephen Warren wrote: On 03/26/2013 02:42 PM, Marc Dietrich wrote: Hi, access to part-start_sect in pmbr_part_valid() (form disk/part_efi.c) and propably other positions/fields causes an unaligned access on ARM (tegra in my case) and a uboot crash. This was introduced by commit fae2bf22 [1] which changed le32_to_int (which is a byte access) to le32_to_cpu (which is a 32bit access). I can't reproduce this with latest u-boot-arm/master, which includes that commit. Both mmc dev N; mmc rescan ; mmcinfo and part list mmc N work fine for me with both DOS PT and GPT. I did test this on a Tegra Seaboard which isn't identical to the AC100, but the only practical difference is 512M vs 1G RAM, which seems unlikely to cause this. It'd help if you pointed out exactly which access causes the issue; which piece of code is failing. The most likely issue is that some memory buffer is assumed to be aligned to 4-bytes, but actually isn't. To track that down, we'd need to know which code and which buffer. Also, a disassembly of the problematic function would be useful. As discussed on IRC, this only happens with gcc 4.7 or patched gcc 4.6 (e.g. from linaro) which has -maligned-access as default enabled. I added -mno- aligned-access to the disk/Makefile and now it boots, but I doubt that this is the best solution. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:trats: change auto-booting to boot kernel with separate device tree blob
Dear Arkadiusz Wlodarczyk,
On 01/03/13 18:41, Arek Wlodarczyk wrote:
From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes:
Modify autoboot scripts that are included in environment variables of default
environment in order to load device tree to memory prior to booting and to
pass device tree address to mboot command.
Switch on dft library, that is necessary for mboot command to pass the device
tree address in memory to kernel.
Added device tree file entry in DFU items table in order to facilitate
uploading the device tree blob file on a target.
---
include/configs/trats.h | 16
1 files changed, 12 insertions(+), 4 deletions(-)
please fix this warning.
WARNING: line over 80 characters
#71: FILE: include/configs/trats.h:192:
+ loaddtb=ext4load mmc ${mmcdev}:${mmcbootpart} ${fdtaddr} ${fdtfile}\0
\
total: 0 errors, 1 warnings, 50 lines checked
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] build: Fix make errors generated when building 'distclean'
It was noticed that when `make distclean' is run, the make process terminates with error reporting something like: rm: cannot remove '/tmp/foobar/': Is a directory make: *** [clobber] Error 1 The problem is that the list of files targeted for removal includes a directory in case CONFIG_SPL_TARGET is not set. The fix has been tested as follows: Ran several times the following sequence of commands: CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make O=/tmp/foobar smdk5250_config CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make O=/tmp/foobar distclean it did not cause an error, it used to before this change. Signed-off-by: Vadim Bendebury vben...@chromium.org --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 12763ce..23f266a 100644 --- a/Makefile +++ b/Makefile @@ -406,8 +406,10 @@ ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map ALL-$(CONFIG_NAND_U_BOOT) += $(obj)u-boot-nand.bin ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin -ALL-$(CONFIG_SPL) += $(obj)$(subst ,,$(CONFIG_SPL_TARGET)) ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin +ifneq ($(CONFIG_SPL_TARGET),) +ALL-$(CONFIG_SPL) += $(obj)$(subst ,,$(CONFIG_SPL_TARGET)) +endif # enable combined SPL/u-boot/dtb rules for tegra ifneq ($(CONFIG_TEGRA),) -- 1.8.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] README: document the requirements for CONFIG_SYS_HZ
CONFIG_SYS_HZ must be 1000, and get_timer() must therefore return ms. Document this. README text provided by Tom Rini. Signed-off-by: Stephen Warren swar...@wwwdotorg.org --- v2: Reworded the README text. --- README |7 +++ 1 file changed, 7 insertions(+) diff --git a/README b/README index 7f2506a..efb8cc6 100644 --- a/README +++ b/README @@ -495,6 +495,13 @@ The following options need to be configured: exists, unlike the similar options in the Linux kernel. Do not set these options unless they apply! +- CPU timer options: + CONFIG_SYS_HZ + + The frequency of the timer returned by get_timer(). + get_timer() must operate in milliseconds and this CONFIG + option must be set to 1000. + - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] usb: hub: Fix enumration timeout
On 3/27/2013 2:59 PM, Vivek Gautam wrote: Patch b6d7852c increases timeout for enumeration, taking worst case to be 10 sec. get_timer() api returns timestamp in micro-seconds, which is what we are checking in the do-while() loop in usb_hub_configure() (get_timer(start) CONFIG_SYS_HZ * 10). This should give us a required check for 10 seconds, and thereby we don't need to add additional mdelay of 100 microseconds in each cycle. Signed-off-by: Vivek Gautamgautam.vi...@samsung.com CC: Vipin Kumarvipin.ku...@st.com --- common/usb_hub.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/common/usb_hub.c b/common/usb_hub.c index 0677004..d77f98d 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -439,7 +439,6 @@ static int usb_hub_configure(struct usb_device *dev) (portstatus USB_PORT_STAT_CONNECTION)) break; - mdelay(100); } while (get_timer(start) CONFIG_SYS_HZ * 10); if (ret 0) With this change, we are continuously reading the uhb status. Although this is also OK, but I feel 100 ms delay is better Still, there is no harm even if this patch is added. So, Reviewed-by: Vipin Kumar vipin.ku...@st.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ARM: bcm2835: fix get_timer() to return ms
Apparently, CONFIG_SYS_HZ must be 1000. Change this, and fix the timer
driver to conform to this.
Have the timer implementation export a custom API get_timer_us() for use
by the BCM2835 MMC API, which needs us resolution for a HW workaround.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v2: Export custom API get_timer_us() to allow the MMC driver to maintain
its current workaround implementation.
---
arch/arm/cpu/arm1176/bcm2835/timer.c | 14 +++---
arch/arm/include/asm/arch-bcm2835/timer.h |2 ++
drivers/mmc/bcm2835_sdhci.c |5 +++--
include/configs/rpi_b.h |2 +-
4 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm1176/bcm2835/timer.c
b/arch/arm/cpu/arm1176/bcm2835/timer.c
index d232d7e..2edd671 100644
--- a/arch/arm/cpu/arm1176/bcm2835/timer.c
+++ b/arch/arm/cpu/arm1176/bcm2835/timer.c
@@ -23,7 +23,7 @@ int timer_init(void)
return 0;
}
-ulong get_timer(ulong base)
+ulong get_timer_us(ulong base)
{
struct bcm2835_timer_regs *regs =
(struct bcm2835_timer_regs *)BCM2835_TIMER_PHYSADDR;
@@ -31,6 +31,14 @@ ulong get_timer(ulong base)
return readl(regs-clo) - base;
}
+ulong get_timer(ulong base)
+{
+ ulong us = get_timer_us(0);
+ us /= (100 / CONFIG_SYS_HZ);
+ us -= base;
+ return us;
+}
+
unsigned long long get_ticks(void)
{
return get_timer(0);
@@ -46,10 +54,10 @@ void __udelay(unsigned long usec)
ulong endtime;
signed long diff;
- endtime = get_timer(0) + usec;
+ endtime = get_timer_us(0) + usec;
do {
- ulong now = get_timer(0);
+ ulong now = get_timer_us(0);
diff = endtime - now;
} while (diff = 0);
}
diff --git a/arch/arm/include/asm/arch-bcm2835/timer.h
b/arch/arm/include/asm/arch-bcm2835/timer.h
index 30c70e0..c2001b6 100644
--- a/arch/arm/include/asm/arch-bcm2835/timer.h
+++ b/arch/arm/include/asm/arch-bcm2835/timer.h
@@ -34,4 +34,6 @@ struct bcm2835_timer_regs {
#define BCM2835_TIMER_CS_M1(1 1)
#define BCM2835_TIMER_CS_M0(1 0)
+extern ulong get_timer_us(ulong base);
+
#endif
diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index b0afc3c..54cfabf 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -39,6 +39,7 @@
#include common.h
#include malloc.h
#include sdhci.h
+#include asm/arch/timer.h
/* 400KHz is max freq for card ID etc. Use that as min */
#define MIN_FREQ 40
@@ -67,11 +68,11 @@ static inline void bcm2835_sdhci_raw_writel(struct
sdhci_host *host, u32 val,
* (Which is just as well - otherwise we'd have to nobble the DMA engine
* too)
*/
- while (get_timer(bcm_host-last_write) bcm_host-twoticks_delay)
+ while (get_timer_us(bcm_host-last_write) bcm_host-twoticks_delay)
;
writel(val, host-ioaddr + reg);
- bcm_host-last_write = get_timer(0);
+ bcm_host-last_write = get_timer_us(0);
}
static inline u32 bcm2835_sdhci_raw_readl(struct sdhci_host *host, int reg)
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index 3d55d36..c18b35b 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -31,7 +31,7 @@
#define CONFIG_MACH_TYPE MACH_TYPE_BCM2708
/* Timer */
-#define CONFIG_SYS_HZ 100
+#define CONFIG_SYS_HZ 1000
/* Memory layout */
#define CONFIG_NR_DRAM_BANKS 1
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 v2] Exynos: Change get_timer() to work correctly
Dear Akshay,
On 28/02/13 19:59, Akshay Saraswat wrote:
At present get_timer() does not return sane values. It should count up
smoothly in milliscond intervals.
We can change the PWM to count down at 1MHz, providing a resolution
of 1us and a range of about an hour between required get_timer() calls.
Test with command sf probe 1:0; time sf read 40008000 0 1000.
Try with different numbers of bytes and see that sane values are obtained
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by: Simon Glass.
arch/arm/cpu/armv7/s5p-common/pwm.c | 6 ++
arch/arm/cpu/armv7/s5p-common/timer.c | 100
+-
2 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 44d7bc3..3147f59 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -174,6 +174,12 @@ int pwm_init(int pwm_id, int div, int invert)
/* set count value */
offset = pwm_id * 3;
+
+ /*
+ * TODO(sjg): Use this as a countdown timer for now. We count down
+ * from the maximum value to 0, then reset.
+ */
+ timer_rate_hz = -1;
is it workaround?
writel(timer_rate_hz, pwm-tcntb0 + offset);
val = readl(pwm-tcon) ~(0xf TCON_OFFSET(pwm_id));
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index e78c716..c48a297 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -39,13 +39,33 @@ static inline struct s5p_timer *s5p_get_base_timer(void)
return (struct s5p_timer *)samsung_get_base_timer();
}
+/**
+ * Read the countdown timer.
+ *
+ * This operates at 1MHz and counts downwards. It will wrap about every
+ * hour (2^32 microseconds).
+ *
+ * @return current value of timer
+ */
+static unsigned long timer_get_us_down(void)
+{
+ struct s5p_timer *const timer = s5p_get_base_timer();
+
+ return readl(timer-tcnto4);
+}
+
int timer_init(void)
{
/* PWM Timer 4 */
- pwm_init(4, MUX_DIV_2, 0);
+ pwm_init(4, MUX_DIV_4, 0);
There are special reason to change the div value?
Please let me know.
pwm_config(4, 0, 0);
pwm_enable(4);
+ /* Use this as the current monotonic time in us */
+ gd-arch.timer_reset_value = 0;
+
+ /* Use this as the last timer value we saw */
+ gd-arch.lastinc = timer_get_us_down();
reset_timer_masked();
return 0;
@@ -56,48 +76,28 @@ int timer_init(void)
*/
unsigned long get_timer(unsigned long base)
{
- return get_timer_masked() - base;
+ ulong now = timer_get_us_down();
+
+ /*
+ * Increment the time by the amount elapsed since the last read.
+ * The timer may have wrapped around, but it makes no difference to
+ * our arithmetic here.
+ */
+ gd-arch.timer_reset_value += gd-arch.lastinc - now;
+ gd-arch.lastinc = now;
+
+ /* Divide by 1000 to convert from us to ms */
+ return gd-arch.timer_reset_value / 1000 - base;
}
/* delay x useconds */
void __udelay(unsigned long usec)
{
- struct s5p_timer *const timer = s5p_get_base_timer();
- unsigned long tmo, tmp, count_value;
-
- count_value = readl(timer-tcntb4);
-
- if (usec = 1000) {
- /*
- * if big number, spread normalization
- * to seconds
- * 1. start to normalize for usec to ticks per sec
- * 2. find number of ticks to wait to achieve target
- * 3. finish normalize.
- */
- tmo = usec / 1000;
- tmo *= (CONFIG_SYS_HZ * count_value);
- tmo /= 1000;
- } else {
- /* else small number, don't kill it prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ * count_value;
- tmo /= (1000 * 1000);
- }
-
- /* get current timestamp */
- tmp = get_current_tick();
-
- /* if setting this fordward will roll time stamp */
- /* reset advancing timestamp to 0, set lastinc value */
- /* else, set advancing stamp wake up time */
- if ((tmo + tmp + 1) tmp)
- reset_timer_masked();
- else
- tmo += tmp;
-
- /* loop till event */
- while (get_current_tick() tmo)
- ; /* nop */
+ unsigned long count_value;
+
+ count_value = timer_get_us_down();
+ while ((int)(count_value - timer_get_us_down()) (int)usec)
why convert to int?
+ ;
}
void reset_timer_masked(void)
@@ -109,30 +109,6 @@ void reset_timer_masked(void)
gd-arch.tbl = 0;
}
-unsigned long get_timer_masked(void)
-{
- struct s5p_timer *const timer = s5p_get_base_timer();
-
Re: [U-Boot] [PATCH 7/9 v2] Exynos: clock: Add generic api to get the clk freq
On 28/02/13 19:59, Akshay Saraswat wrote:
Add generic api to get the frequency of the required peripherial. This
typo.
peripherial - peripheral
API gets the source clock frequency and returns the required frequency
by dividing with first and second dividers based on the requirement.
Test with command sf probe 1:0; time sf read 40008000 0 1000.
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Fixed few nits.
arch/arm/cpu/armv7/exynos/clock.c | 138
+
arch/arm/include/asm/arch-exynos/clk.h | 17
2 files changed, 155 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 956427c..cc101c2 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -27,6 +27,49 @@
#include asm/arch/clk.h
#include asm/arch/periph.h
+/* *
+ * This structure is to store the src bit, div bit and prediv bit
+ * positions of the peripheral clocks of the src and div registers
+ */
+struct clk_bit_info {
+ int8_t src_bit;
+ int8_t div_bit;
+ int8_t prediv_bit;
+};
+
+/* src_bit div_bit prediv_bit */
+static struct clk_bit_info clk_bit_info[PERIPH_ID_COUNT] = {
+ {0, 0, -1},
+ {4, 4, -1},
+ {8, 8, -1},
+ {12,12, -1},
+ {0, 0, 8},
+ {4, 16, 24},
+ {8, 0, 8},
+ {12,16, 24},
+ {-1,-1, -1},
+ {16,0, 8},
+ {20,16, 24},
+ {24,0, 8},
+ {0, 0, 4},
+ {4, 12, 16},
+ {-1,-1, -1},
+ {-1,-1, -1},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+};
+
/* Epll Clock division values to achive different frequency output */
static struct set_epll_con_val exynos5_epll_div[] = {
{ 19200, 0, 48, 3, 1, 0 },
@@ -201,6 +244,101 @@ static unsigned long exynos5_get_pll_clk(int pllreg)
return fout;
}
+unsigned long exynos5_get_periph_rate(enum periph_id peripheral)
static?
please int instead of enum periph_id.
+{
+ struct clk_bit_info *bit_info = clk_bit_info[peripheral];
+ unsigned long sclk, sub_clk;
+ unsigned int src, div, sub_div;
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+
+ switch (peripheral) {
+ case PERIPH_ID_UART0:
+ case PERIPH_ID_UART1:
+ case PERIPH_ID_UART2:
+ case PERIPH_ID_UART3:
+ src = readl(clk-src_peric0);
+ div = readl(clk-div_peric0);
+ break;
+ case PERIPH_ID_PWM0:
+ case PERIPH_ID_PWM1:
+ case PERIPH_ID_PWM2:
+ case PERIPH_ID_PWM3:
+ case PERIPH_ID_PWM4:
+ src = readl(clk-src_peric0);
+ div = readl(clk-div_peric3);
+ break;
+ case PERIPH_ID_SPI0:
+ case PERIPH_ID_SPI1:
+ src = readl(clk-src_peric1);
+ div = readl(clk-div_peric1);
+ break;
+ case PERIPH_ID_SPI2:
+ src = readl(clk-src_peric1);
+ div = readl(clk-div_peric2);
+ break;
+ case PERIPH_ID_SPI3:
+ case PERIPH_ID_SPI4:
+ src = readl(clk-sclk_src_isp);
+ div = readl(clk-sclk_div_isp);
+ break;
+ case PERIPH_ID_SDMMC0:
+ case PERIPH_ID_SDMMC1:
+ case PERIPH_ID_SDMMC2:
+ case PERIPH_ID_SDMMC3:
+ src = readl(clk-src_fsys);
+ div = readl(clk-div_fsys1);
+ break;
+ case PERIPH_ID_I2C0:
+ case PERIPH_ID_I2C1:
+ case PERIPH_ID_I2C2:
+ case PERIPH_ID_I2C3:
+ case PERIPH_ID_I2C4:
+ case PERIPH_ID_I2C5:
+ case PERIPH_ID_I2C6:
+ case PERIPH_ID_I2C7:
+ sclk = exynos5_get_pll_clk(MPLL);
+ sub_div = ((readl(clk-div_top1) bit_info-div_bit)
+ 0x7) + 1;
+ div = ((readl(clk-div_top0) bit_info-prediv_bit)
+ 0x7) + 1;
+ return (sclk / sub_div) / div;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return -1;
+ };
+
+ src = (src bit_info-src_bit) 0xf;
please add a blank line here.
+ if (src == EXYNOS_SRC_MPLL)
+ sclk = exynos5_get_pll_clk(MPLL);
+
Re: [U-Boot] [PATCH 9/9 v2] Exynos: pwm: Use generic api to get pwm clk freq
On 28/02/13 19:59, Akshay Saraswat wrote:
Use generic api to get the pwm clock frequency
Test with command sf probe 1:0; time sf read 40008000 0 1000.
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Restored get_pwm_clk call in case of non-exynos5 cpu.
arch/arm/cpu/armv7/s5p-common/pwm.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 6f401b8..f5e9a95 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -28,6 +28,7 @@
#include asm/io.h
#include asm/arch/pwm.h
#include asm/arch/clk.h
+#include asm/arch/periph.h
int pwm_enable(int pwm_id)
{
@@ -60,7 +61,10 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned
long freq)
unsigned long tin_parent_rate;
unsigned int div;
- tin_parent_rate = get_pwm_clk();
+ if (cpu_is_exynos5())
+ tin_parent_rate = clock_get_periph_rate(PERIPH_ID_PWM0);
+ else
+ tin_parent_rate = get_pwm_clk();
for (div = 2; div = 16; div *= 2) {
if ((tin_parent_rate / (div 16)) freq)
@@ -165,8 +169,15 @@ int pwm_init(int pwm_id, int div, int invert)
ticks_per_period = -1UL;
} else {
const unsigned long pwm_hz = 1000;
- unsigned long timer_rate_hz = get_pwm_clk() /
- ((prescaler + 1) * (1 div));
+ unsigned long timer_rate_hz;
+
+ if (cpu_is_exynos5()) {
+ timer_rate_hz = clock_get_periph_rate(PERIPH_ID_PWM0)
+ / ((prescaler + 1) * (1 div));
+ } else {
+ timer_rate_hz = get_pwm_clk() /
+ ((prescaler + 1) * (1 div));
+ }
ticks_per_period = timer_rate_hz / pwm_hz;
}
How about this?
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 956427c..a6051b0 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -1210,7 +1210,7 @@ unsigned long get_i2c_clk(void)
unsigned long get_pwm_clk(void)
{
if (cpu_is_exynos5())
- return exynos5_get_pwm_clk();
+ return clock_get_periph_rate(PERIPH_ID_PWM0);
else {
if (proid_is_exynos4412())
return exynos4x12_get_pwm_clk();
When we implement generic clock function for exynos4 then,
we can use clock_get_periph_rate instead of get_pwm_clk.
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9 v2] Exynos: Avoid a divide by zero by specifying a non-zero period for pwm 4
On 28/02/13 19:59, Akshay Saraswat wrote:
The pwm_config function in the exynos pwm driver divides by its period
period parameter. A function was calling pwm_config with a 0ns period and a
0ns duty cycle. That doesn't actually make any sense physically, and results
in a divide by zero in the driver. This change changes the paremters to be a
typo.
paremters - parameter
10ns period and duty cycle.
Test with command sf probe 1:0; time sf read 40008000 0 1000.
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by: Simon Glass.
arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index de61405..6a0fa58 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -58,7 +58,7 @@ int timer_init(void)
{
/* PWM Timer 4 */
pwm_init(4, MUX_DIV_4, 0);
- pwm_config(4, 0, 0);
+ pwm_config(4, 10, 10);
0 is a numerator.
I think.. it doesn't matter.
pwm_enable(4);
/* Use this as the current monotonic time in us */
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9 v2] Exynos: pwm: Fix two bugs in the exynos pwm configuration code
Dear Akshay,
On 28/02/13 19:59, Akshay Saraswat wrote:
First, the div value was being used incorrectly to compute the frequency of
the PWM timer. The value passed in is a constant which reflects the value
that would be found in a configuration register, 0 to 4. That should
correspond to a scaling factor of 1, 2, 4, 8, or 16, 1 div, but div + 1 was
being used instead.
Second, the reset value of the timers were being calculated to give an overall
frequency, thrown out, and set to a maximum value. This was done so that PWM 4
could be used as the system clock by counting down from a high value, but it
was applied indiscriminantly. It should at most be applied only to PWM 4.
This change also takes the opportunity to tidy up the pwm_init function.
Test with command sf probe 1:0; time sf read 40008000 0 1000.
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by: Simon Glass.
arch/arm/cpu/armv7/s5p-common/pwm.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 3147f59..02156d1 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -143,7 +143,7 @@ int pwm_init(int pwm_id, int div, int invert)
u32 val;
const struct s5p_timer *pwm =
(struct s5p_timer *)samsung_get_base_timer();
- unsigned long timer_rate_hz;
+ unsigned long ticks_per_period;
unsigned int offset, prescaler;
/*
@@ -167,20 +167,24 @@ int pwm_init(int pwm_id, int div, int invert)
val |= (div 0xf) MUX_DIV_SHIFT(pwm_id);
writel(val, pwm-tcfg1);
- timer_rate_hz = get_pwm_clk() / ((prescaler + 1) *
- (div + 1));
+ if (pwm_id == 4) {
+ /*
+ * TODO(sjg): Use this as a countdown timer for now. We count
+ * down from the maximum value to 0, then reset.
+ */
+ ticks_per_period = -1UL;
+ } else {
+ const unsigned long pwm_hz = 1000;
+ unsigned long timer_rate_hz = get_pwm_clk() /
+ ((prescaler + 1) * (1 div));
good catch. thanks.
- timer_rate_hz = timer_rate_hz / CONFIG_SYS_HZ;
+ ticks_per_period = timer_rate_hz / pwm_hz;
why don't you use CONFIG_SYS_HZ?
pwm_hz seems to constant.
+ }
/* set count value */
offset = pwm_id * 3;
- /*
- * TODO(sjg): Use this as a countdown timer for now. We count down
- * from the maximum value to 0, then reset.
- */
- timer_rate_hz = -1;
- writel(timer_rate_hz, pwm-tcntb0 + offset);
+ writel(ticks_per_period, pwm-tcntb0 + offset);
val = readl(pwm-tcon) ~(0xf TCON_OFFSET(pwm_id));
if (invert (pwm_id 4))
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On 2013-03-27 10:29, Javier Martinez Canillas wrote:
On Wed, Mar 27, 2013 at 5:50 AM, Manfred Huber man.hu...@arcor.de wrote:
Please test the Patch. It is very simple on a Beagleboard. I guess you
have flashed the actual SPL and u-boot and Beagleboard boots correctly.
Now press and hold 'User' button and connect power. SPL should hang.
You can see some symbols on the console from the ROM code.
Hi Manfred,
I don't have access to my IGEP board right now but I'll test your
patch as soon as posible.
Install the Patch, compile it and flash the NAND. Beagleboard still
boots correctly. Now press and hold 'User' button again and Beagleboard
should also boot correctly. The Patch works.
I suspect the IGEP board has the same bug. If so, the Patch should work
on this board too and we don't need CONFIG_SYS_NS16550_BROKEN_TEMT
anymore.
I still think that we should keep CONFIG_SYS_NS16550_BROKEN_TEMT or
something similar instead of just checking for CONFIG_OMAP34XX. Since
we don't know if this problem is also present on other TI OMAP
platforms (or any other platform). I would just change
CONFIG_SYS_NS16550_BROKEN_TEMT semantics once is confirmed that this
also fixes the issue on IGEP boards.
Also, if you are removing CONFIG_SYS_NS16550_BROKEN_TEMT then you have
to update the README too since it is explained there what this config
option does.
If you don't want a patch for this bug please let me know. I will not
bother you again.
Thanks a lot for working on this. Some people work on mainline U-Boot
on their free time (like myself) so it can take a few days until you
get a response about a patch. Please be patient :-)
Hi Javier,
Also like me. The patch is not for me, because I have written my own
serial driver. So this comment was only not to waste your and my time if
no one needs this patch.
Best regards,
Manfred
Best regards,
Manfred
Thank a lot and best regards,
Javier
On 2013-03-25 23:02, Manfred Huber wrote:
From: Manfred Huber
Due to a Bug in the ROM code of some OMAP3 devices, the TEMT bit is not
set if UART3 is configured before (only THRE is set). Reason is the
disabling of UART3 even though the Transmitter is not empty. Enabling
UART3 allows the Transmitter to be empty.
Signed-off-by: Manfred Huber man.hu...@arcor.de
---
drivers/serial/ns16550.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index b2da8b3..24ff84f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,10 +36,18 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
-#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
+#if (defined(CONFIG_SPL_BUILD) defined(CONFIG_OMAP34XX))
+if ((serial_in(com_port-lsr) (UART_LSR_TEMT | UART_LSR_THRE))
== UART_LSR_THRE) {
+serial_out(UART_LCR_DLAB, com_port-lcr);
+serial_out(baud_divisor 0xff, com_port-dll);
+serial_out((baud_divisor 8) 0xff, com_port-dlm);
+serial_out(UART_LCRVAL, com_port-lcr);
+serial_out(0, com_port-mdr1);
+}
+#endif
+
while (!(serial_in(com_port-lsr) UART_LSR_TEMT))
;
-#endif
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
