Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver
Hi,
Thanks for the reply. This is my first patch to u-boot. Any advice is
appreciated. Comments in-line below.
- Original Message
From: Scott Wood scottw...@freescale.com
To: Chris Kiick cki...@att.net
Cc: u-boot@lists.denx.de
Sent: Wed, December 19, 2012 1:02:52 PM
Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat
driver
On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
Allow boards to set their own ECC layouts and functions in NAND_PLAT_INIT
without being stomped on by nand_base.c intialization.
Signed-off-by: ckiick chris at kiicks.net
---
drivers/mtd/nand/nand_base.c |11 +++
drivers/mtd/nand/nand_plat.c |4 ++--
include/configs/qong.h |2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a2d06be..614fc72 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3035,8 +3035,10 @@ int nand_scan_tail(struct mtd_info *mtd)
chip-ecc.mode = NAND_ECC_SOFT;
case NAND_ECC_SOFT:
-chip-ecc.calculate = nand_calculate_ecc;
-chip-ecc.correct = nand_correct_data;
+if (!chip-ecc.calculate)
+ chip-ecc.calculate = nand_calculate_ecc;
+ if (!chip-ecc.correct)
+ chip-ecc.correct = nand_correct_data;
chip-ecc.read_page = nand_read_page_swecc;
chip-ecc.read_subpage = nand_read_subpage;
chip-ecc.write_page = nand_write_page_swecc;
@@ -3044,9 +3046,10 @@ int nand_scan_tail(struct mtd_info *mtd)
chip-ecc.write_page_raw = nand_write_page_raw;
chip-ecc.read_oob = nand_read_oob_std;
chip-ecc.write_oob = nand_write_oob_std;
-if (!chip-ecc.size)
+ if (!chip-ecc.size) {
chip-ecc.size = 256;
- chip-ecc.bytes = 3;
+ chip-ecc.bytes = 3;
+ }
break;
case NAND_ECC_SOFT_BCH:
How is this part specific to nand plat?
OK, it's not, but if you are using nand plat, then you are forced to go through
this code path with no chance of making any changes after because of the way
board_nand_init() is written. I seem to see other nand drivers setting up ecc
layouts and then calling nand_scan_tail(), I'm not sure how they are getting
around this.
I reasoned that the change was safe for existing code because if something was
not setting its own ecc layout, it would still use the default, but it if was,
then it had to be after the call to nand_scan_tail() and that would override
whatever was set there anyway.
I'm not sure how specifying your own ECC functions fits with the purpose of
either NAND_ECC_SOFT or nand plat.
Well, NAND_ECC_SOFT is the only scheme that does fit with custom ECC
algorithms.
You have to pick one of the existing ECC schemes, and SOFT is the scheme that
allows you to do your own ECC, if you setup the layout, calculate and correct
parts. Looking at the code, that's what I thought it was for.
Is there another way to implement custom ECC algorithms, done in software?
As for the plat driver, it shouldn't care what ECC I'm using. It's just
running
the low-level byte-bang part of the driver for me, so I don't have to duplicate
the code. Isn't that its purpose? Do I have to re-write a driver interface
that
does the same thing as nand plat just because my ECC isn't the default?
If I'm going in the wrong direction, I'd appreciate advice on how it's supposed
to be done.
diff --git a/drivers/mtd/nand/nand_plat.c b/drivers/mtd/nand/nand_plat.c
index 37a0206..b3bda11 100644
--- a/drivers/mtd/nand/nand_plat.c
+++ b/drivers/mtd/nand/nand_plat.c
@@ -8,7 +8,7 @@
/* Your board must implement the following macros:
* NAND_PLAT_WRITE_CMD(chip, cmd)
* NAND_PLAT_WRITE_ADR(chip, cmd)
- * NAND_PLAT_INIT()
+ * NAND_PLAT_INIT(nand)
*
* It may also implement the following:
* NAND_PLAT_DEV_READY(chip)
@@ -53,7 +53,7 @@ int board_nand_init(struct nand_chip *nand)
#endif
#ifdef NAND_PLAT_INIT
- NAND_PLAT_INIT();
+NAND_PLAT_INIT(nand);
#endif
nand-cmd_ctrl = plat_cmd_ctrl;
diff --git a/include/configs/qong.h b/include/configs/qong.h
index d9bf201..077cbae 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -226,7 +226,7 @@ extern int qong_nand_rdy(void *chip);
#define CONFIG_NAND_PLAT
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_BASECS3_BASE
-#define NAND_PLAT_INIT() qong_nand_plat_init(nand)
+#define NAND_PLAT_INIT(nand) qong_nand_plat_init(nand)
#define QONG_NAND_CLE(chip) ((unsigned long)(chip)-IO_ADDR_W | (1
24))
#define QONG_NAND_ALE(chip) ((unsigned long)(chip)-IO_ADDR_W | (1 23))
This part looks unrelated.
It follows as a logical consequence of the other change. If
Re: [U-Boot] [PATCH] mv-common.h: increase malloc arena to 4MiB
-Original Message- From: Andreas Bießmann [mailto:andreas.de...@googlemail.com] Sent: 30 October 2012 05:29 To: U-Boot List Cc: Andreas Bießmann; Prafulla Wadaskar; dimax.m...@gmail.com Subject: [PATCH] mv-common.h: increase malloc arena to 4MiB This will fix the following error: ---8--- UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume 'ubi:root' errno=-12! ---8--- Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: prafu...@marvell.com Cc: dimax.m...@gmail.com --- include/configs/mv-common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h index 7086d1d..405a842 100644 --- a/include/configs/mv-common.h +++ b/include/configs/mv-common.h @@ -92,7 +92,7 @@ /* * Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN(1024 * 1024) /* 1MiB for malloc() */ +#define CONFIG_SYS_MALLOC_LEN(1024 * 1024 * 4) /* 4MiB for malloc() */ /* * Other required minimal configurations -- 1.7.10.4 Applied to u-boot-marvell.git master branch Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mv-common.h: increase malloc arena to 4MiB
Dear Prafulla Wadaskar, On 20.12.2012 10:31, Prafulla Wadaskar wrote: -Original Message- From: Andreas Bießmann [mailto:andreas.de...@googlemail.com] Sent: 30 October 2012 05:29 To: U-Boot List Cc: Andreas Bießmann; Prafulla Wadaskar; dimax.m...@gmail.com Subject: [PATCH] mv-common.h: increase malloc arena to 4MiB This will fix the following error: ---8--- UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume 'ubi:root' errno=-12! ---8--- snip Applied to u-boot-marvell.git master branch I've just seen you requested a pull before this add. Would be great to have this patch in 2013.01 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] mv-common.h: increase malloc arena to 4MiB
-Original Message- From: Andreas Bießmann [mailto:andreas.de...@googlemail.com] Sent: 20 December 2012 15:19 To: Prafulla Wadaskar Cc: Andreas Bießmann; U-Boot List; dimax.m...@gmail.com Subject: Re: [PATCH] mv-common.h: increase malloc arena to 4MiB Dear Prafulla Wadaskar, On 20.12.2012 10:31, Prafulla Wadaskar wrote: -Original Message- From: Andreas Bießmann [mailto:andreas.de...@googlemail.com] Sent: 30 October 2012 05:29 To: U-Boot List Cc: Andreas Bießmann; Prafulla Wadaskar; dimax.m...@gmail.com Subject: [PATCH] mv-common.h: increase malloc arena to 4MiB This will fix the following error: ---8--- UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume 'ubi:root' errno=-12! ---8--- snip Applied to u-boot-marvell.git master branch I've just seen you requested a pull before this add. Would be great to have this patch in 2013.01 Best regards Andreas Bießmann Dear Andreas, Sure I will resend the pull request. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-marvell.git
Dear Albert Please discard my earlier pull request and please pull The following changes since commit b8a7c467960ffb4d5a5e1eef5f7783fb6f594542: Albert ARIBAUD (1): Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' are available in the git repository at: u-boot-marvell.git master branch. Albert ARIBAUD (3): mv88e61xx: refactor PHY and SWITCH level-code kirkwood: make MPP arrays static const ARM: lacie_kw: add support for WIRELESS_SPACE Holger Brunck (3): arm/km: fix memory settings km/common: drop unneeded std* environment variables km/common: cosmetic change reported from checkpatch Luke Lowrey (1): arch-kirkwood: Ethernet port macro returning incorrect address Michael Walle (1): lsxl: unset ncip for rescue mode Valentin Longchamp (1): arm/km: remove duplicate code andreas.de...@googlemail.com (1): mv-common.h: increase malloc arena to 4MiB arch/arm/cpu/arm926ejs/kirkwood/mpp.c |2 +- arch/arm/include/asm/arch-kirkwood/cpu.h|2 +- arch/arm/include/asm/arch-kirkwood/mpp.h|2 +- board/LaCie/net2big_v2/net2big_v2.c |2 +- board/LaCie/netspace_v2/netspace_v2.c |2 +- board/LaCie/wireless_space/Makefile | 46 +++ board/LaCie/wireless_space/kwbimage.cfg | 82 board/LaCie/wireless_space/wireless_space.c | 176 board/Marvell/dreamplug/dreamplug.c |2 +- board/Marvell/guruplug/guruplug.c |2 +- board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +- board/Marvell/openrd/openrd.c |2 +- board/Marvell/rd6281a/rd6281a.c |2 +- board/Marvell/sheevaplug/sheevaplug.c |2 +- board/Seagate/dockstar/dockstar.c |2 +- board/buffalo/lsxl/lsxl.c |7 +- board/cloudengines/pogo_e02/pogo_e02.c |2 +- board/d-link/dns325/dns325.c|2 +- board/iomega/iconnect/iconnect.c|2 +- board/karo/tk71/tk71.c |2 +- board/keymile/common/common.c |2 +- board/keymile/km_arm/km_arm.c | 16 +- board/keymile/km_arm/kwbimage-memphis.cfg |6 +- board/keymile/km_arm/kwbimage.cfg |6 +- board/keymile/km_arm/kwbimage_128M16_1.cfg | 25 +- board/keymile/km_arm/kwbimage_256M8_1.cfg | 25 +- board/raidsonic/ib62x0/ib62x0.c |2 +- boards.cfg |1 + drivers/net/phy/mv88e61xx.c | 495 ++ drivers/net/phy/mv88e61xx.h | 39 ++- drivers/spi/kirkwood_spi.c | 12 +- include/configs/km/keymile-common.h |3 - include/configs/lsxl.h |2 +- include/configs/mv-common.h |2 +- include/configs/wireless_space.h| 194 + include/netdev.h| 21 +- 36 files changed, 896 insertions(+), 298 deletions(-) create mode 100644 board/LaCie/wireless_space/Makefile create mode 100644 board/LaCie/wireless_space/kwbimage.cfg create mode 100644 board/LaCie/wireless_space/wireless_space.c create mode 100644 include/configs/wireless_space.h Regards... Prafulla . . . -Original Message- From: Prafulla Wadaskar Sent: 20 December 2012 12:27 To: 'Albert ARIBAUD' Cc: 'u-boot@lists.denx.de'; Ashish Karkare; Prabhanjan Sarnaik; 'Wolfgang Denk' Subject: Pull request for u-boot-marvell.git Dear Albert, Please pull The following changes since commit b8a7c467960ffb4d5a5e1eef5f7783fb6f594542: Albert ARIBAUD (1): Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' are available in the git repository at: u-boot-marvell.git master branch. Albert ARIBAUD (3): mv88e61xx: refactor PHY and SWITCH level-code kirkwood: make MPP arrays static const ARM: lacie_kw: add support for WIRELESS_SPACE Holger Brunck (3): arm/km: fix memory settings km/common: drop unneeded std* environment variables km/common: cosmetic change reported from checkpatch Valentin Longchamp (1): arm/km: remove duplicate code arch/arm/cpu/arm926ejs/kirkwood/mpp.c |2 +- arch/arm/include/asm/arch-kirkwood/mpp.h|2 +- board/LaCie/net2big_v2/net2big_v2.c |2 +- board/LaCie/netspace_v2/netspace_v2.c |2 +- board/LaCie/wireless_space/Makefile | 46 +++ board/LaCie/wireless_space/kwbimage.cfg | 82 board/LaCie/wireless_space/wireless_space.c | 176 board/Marvell/dreamplug/dreamplug.c |2 +- board/Marvell/guruplug/guruplug.c |2 +- board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +- board/Marvell/openrd/openrd.c
[U-Boot] [PATCH] lcd: restore ability to display 8 bpp BMPs on 16 bpp LCDs
Commit fb6a9aab7ae78c (LCD: display 32bpp decompressed bitmap image)
broke the check that allowed U-Boot to display 8 bpp BMPs on a 16
bpp LCD screen, effectively turning this feature off.
Restore this feature by changing the check back to the same meaning
it originally had.
To avoid future confusion, the check has also been rephrased to make
its meaning clear.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
common/lcd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/lcd.c b/common/lcd.c
index 4c83a8b..cfa1134 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -834,7 +834,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
/* We support displaying 8bpp BMPs on 16bpp LCDs */
- if (bpix != bmp_bpix (bmp_bpix != 8 || bpix != 16 || bpix != 32)) {
+ if (bpix != bmp_bpix !(bmp_bpix == 8 bpix == 16)) {
printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
bpix,
le16_to_cpu(bmp-header.bit_count));
--
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/4] Optimized nand_read_buf for kirkwood
Hi Prafulla, On Wed, Dec 19, 2012 at 10:44:01PM -0800, Prafulla Wadaskar wrote: For your next post of this patch, please do not forget to add version info and changlog to the patch. Ah yes, indeed! Thanks a lot for the hint and sorry for the confusion caused. Best wishes, Phil -- Viprinet Europe GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49 6721 49030-0 Direct line/Durchwahl:+49 6721 49030-134 Fax: +49 6721 49030-109 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany Commercial register/Handelsregister: Amtsgericht Mainz HRB44090 CEO/Geschäftsführer: Simon Kissel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung/resolve
Hi Stephen, On Wed, 19 Dec 2012 23:24:07 -0700, Stephen Warren swar...@wwwdotorg.org wrote: On 12/19/2012 10:59 PM, Minkyu Kang wrote: Dear Albert and Stephen, On 20/12/12 01:28, Albert ARIBAUD wrote: ... Can you answer the question Stephen has asked on this list on 11/12 ? http://www.mail-archive.com/u-boot@lists.denx.de/msg101291.html Comes from u-boot-arm tree. The base of this pull request is u-boot tree, hence some u-boot-arm commits are included. But it doesn't matter maybe.. because this pull request is for u-boot-arm tree. OK, that might explain it, but isn't there a way to list only the new commits? Yes there is, because when doing the pull request, you don't care where commits come from, you only care where they'll be pulled into. IOW, there is no notion of a 'base' for a pull request: you just specify the destination -- here, u-boot-arm -- and that prints only the needed commits. Since pull requests do nothing more than print on the standard output, and in order to speed my merging, I'll fetch u-boot-samsung and perform a local pull request from -samsung/master onto -arm/master and check that the resulting commits are ok. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] split nand writes
On 12/19/2012 11:47 PM, Scott Wood wrote: On 12/19/2012 09:43:01 AM, Jaap de Jong wrote: Hi All, suppose the image I want to flash is bigger than the available ram in the unit. Is there a way to copy the image f.i. in pieces into the flash? nand write should have a 'continue on last block' option for that purpose. Something like that would be nice. These patches are relevant: http://patchwork.ozlabs.org/patch/204939/ http://patchwork.ozlabs.org/patch/204940/ That could do the trick also. You would have to do some arithmetic to calculate the next startaddress in the flash. So there is not an out-of-the-box solution at the moment? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bricked when trying to attach UBI
Hi Luca, On 12/19/2012 06:37 PM, Luca Ceresoli wrote: I had some days ago, but I double-checked now as you suggested. Indeed there is an important difference: attach_by_scanning() (build.c) calls ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in a swapped order! This swap dates back to: commit d63894654df72b010de2abb4b3f07d0d755f65b6 Author: Holger Brunck holger.bru...@keymile.com Date: Mon Oct 10 13:08:19 2011 +0200 UBI: init eba tables before wl when attaching a device This fixes that u-boot gets stuck when a bitflip was detected during ubi part ubi_device. If a bitflip was detected UBI tries to copy the PEB to a different place. This needs that the eba table are initialized, but this was done after the wear levelling worker detects the bitflip. So changes the initialisation of these two tasks in u-boot. This is a u-boot specific patch and not needed in the linux layer, because due to commit 1b1f9a9d00447d UBI: Ensure that background thread operations are really executed we schedule these tasks in place and not as in linux after the inital task which schedule this new task is finished. Signed-off-by: Holger Brunck holger.bru...@keymile.com cc: Stefan Roese s...@denx.de Signed-off-by: Stefan Roese s...@denx.de I tried reverting that commit and... surprise! U-Boot can now attach UBI and boot properly! :-( But the cited commit actually fixed a bug that bite our board a few months back, so it should not be reverted without thinking twice. Now it apparently introduced another bug. :-( yes definetely. I didn't read the whole thread, so I don't know what your exact problem is. On my boards the ubi layer seems to work fine on latest u-boot. But I see a general problem we have in the ubi layer in u-boot. I try to summarize my view: The UBI layer was initialy copied from the linux implementation. But the linux implementation relies for some tasks e.g. fix correctable errors on a background thread. Due to the fact that u-boot is single threaded there was one commit which wants to take care that these background tasks are really executed (CC-ing the author): commit 1b1f9a9d00 UBI: Ensure that background thread operations are really executed U-boot executes this background taks immediately but the linux implementation executes this tasks later with the help of some synchronisation mechanism. Therefore we have a different order executing these tasks. My fix did now a change in the initialisation order of eba tables and the wear leveling thread, to address my problem. But now it seems to cause a new problem on your side. So the synchronisation mechanism in u-boot for the ubi tasks which are running on linux in background is incorrect. But how this could be fixed needs to have some deeper analyses. Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)
Hi all, i am using u-boot-2013.02.rc2 and cross-compiling for target am335x_evm_uart2_config target its creating MLO and u-boot.img for my target.buts its not booting on uart2. is there any configuration i need to change in u-boot source code? Thanks Regards Pavan -- View this message in context: http://u-boot.10912.n7.nabble.com/configuring-u-boot-for-custom-board-based-on-beaglebone-am335xx-evm-tp143228p143311.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/4] Add support for FIMD and DP on SMDK5250
Changes since V2: -- Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM. -- Create and use new config CONFIG_EXYNOS_LOGO instead of using CONFIG_CMD_BMP -- Remove explicit call for cfg_lcd_gpio and add it as callback. [PATCH RESEND V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console [PATCH V3 4/4]EXYNOS5: Add support for FIMD and DP arch/arm/cpu/armv7/exynos/clock.c|2 +- arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 ++ board/samsung/smdk5250/smdk5250.c| 97 ++ drivers/video/exynos_fb.c|5 +- drivers/video/exynos_fimd.c | 10 ++- include/configs/smdk5250.h |8 ++ include/configs/trats.h |1 + 7 files changed, 126 insertions(+), 4 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM
When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
error saying exynos_mipi_dsi_init() not defined. So, we add
dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
is not defined.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 9a7cbeb..b73263d 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
};
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
int exynos_mipi_dsi_init(void);
+#else
+int exynos_mipi_dsi_init(void)
+{
+ return 0;
+}
+#endif
/*
* register mipi_dsim_lcd_driver object defined by lcd panel driver
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL
With VPLL as source clock to FIMD, Exynos DP Initializaton was failing sometimes with unstable clock. Changing FIMD source to MPLL resolves this issue. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/exynos/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index fe61f88..bfcd5f7 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void) */ cfg = readl(clk-src_disp1_0); cfg = ~(0xf); - cfg |= 0x8; + cfg |= 0x6; writel(cfg, clk-src_disp1_0); /* -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console
Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
existing logo feature intact in Trats.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/video/exynos_fb.c |5 -
drivers/video/exynos_fimd.c | 10 --
include/configs/trats.h |1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..c111a09 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+#ifdef CONFIG_EXYNOS_LOGO
static void draw_logo(void)
{
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
}
+#endif
static void lcd_panel_on(vidinfo_t *vid)
{
@@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
+#ifdef CONFIG_EXYNOS_LOGO
if (panel_info.logo_on) {
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) 3));
draw_logo();
}
-
+#endif
lcd_panel_on(panel_info);
}
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..f2e4c27 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
- /* bpp is 32 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
- /* pixel format is unpacked RGB888 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
writel(cfg, (unsigned int)fimd_ctrl-wincon0 +
EXYNOS_WINCON(win_id));
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a24e945..1573573 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -252,6 +252,7 @@
#define CONFIG_EXYNOS_FB
#define CONFIG_LCD
#define CONFIG_CMD_BMP
+#define CONFIG_EXYNOS_LOGO
#define CONFIG_BMP_32BPP
#define CONFIG_FB_ADDR 0x52504000
#define CONFIG_S6E8AX0
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/4] EXYNOS5: Add support for FIMD and DP
Add panel_info structure required by LCD driver
and DP panel platdata for SMDK5250.
Add GPIO configuration for LCD.
Enable FIMD and DP support on SMDK5250.
DP Panel size: 2560x1600.
We use 16BPP resolution to get LCD console.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
board/samsung/smdk5250/smdk5250.c | 97 +
include/configs/smdk5250.h|8 +++
2 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4c50342..46fd2a5 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -24,12 +24,15 @@
#include asm/io.h
#include i2c.h
#include netdev.h
+#include lcd.h
#include spi.h
#include asm/arch/cpu.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
+#include asm/arch/power.h
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
+#include asm/arch/dp_info.h
#include pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -181,6 +184,100 @@ static int board_uart_init(void)
return 0;
}
+void cfg_lcd_gpio(void)
+{
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
+
+ /* For Backlight */
+ s5p_gpio_cfg_pin(gpio1-b2, 0, GPIO_OUTPUT);
+ s5p_gpio_set_value(gpio1-b2, 0, 1);
+
+ /* LCD power on */
+ s5p_gpio_cfg_pin(gpio1-x1, 5, GPIO_OUTPUT);
+ s5p_gpio_set_value(gpio1-x1, 5, 1);
+
+ /* Set Hotplug detect for DP */
+ s5p_gpio_cfg_pin(gpio1-x0, 7, GPIO_FUNC(0x3));
+}
+
+vidinfo_t panel_info = {
+ .vl_freq= 60,
+ .vl_col = 2560,
+ .vl_row = 1600,
+ .vl_width = 2560,
+ .vl_height = 1600,
+ .vl_clkp= CONFIG_SYS_LOW,
+ .vl_hsp = CONFIG_SYS_LOW,
+ .vl_vsp = CONFIG_SYS_LOW,
+ .vl_dp = CONFIG_SYS_LOW,
+ .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
+
+ /* wDP panel timing infomation */
+ .vl_hspw= 32,
+ .vl_hbpd= 80,
+ .vl_hfpd= 48,
+
+ .vl_vspw= 6,
+ .vl_vbpd= 37,
+ .vl_vfpd= 3,
+ .vl_cmd_allow_len = 0xf,
+
+ .win_id = 3,
+ .cfg_gpio = cfg_lcd_gpio,
+ .backlight_on = NULL,
+ .lcd_power_on = NULL,
+ .reset_lcd = NULL,
+ .dual_lcd_enabled = 0,
+
+ .init_delay = 0,
+ .power_on_delay = 0,
+ .reset_delay= 0,
+ .interface_mode = FIMD_RGB_INTERFACE,
+ .dp_enabled = 1,
+};
+
+static struct edp_device_info edp_info = {
+ .disp_info = {
+ .h_res = 2560,
+ .h_sync_width = 32,
+ .h_back_porch = 80,
+ .h_front_porch = 48,
+ .v_res = 1600,
+ .v_sync_width = 6,
+ .v_back_porch = 37,
+ .v_front_porch = 3,
+ .v_sync_rate = 60,
+ },
+ .lt_info = {
+ .lt_status = DP_LT_NONE,
+ },
+ .video_info = {
+ .master_mode = 0,
+ .bist_mode = DP_DISABLE,
+ .bist_pattern = NO_PATTERN,
+ .h_sync_polarity = 0,
+ .v_sync_polarity = 0,
+ .interlaced = 0,
+ .color_space = COLOR_RGB,
+ .dynamic_range = VESA,
+ .ycbcr_coeff = COLOR_YCBCR601,
+ .color_depth = COLOR_8,
+ },
+};
+
+static struct exynos_dp_platform_data dp_platform_data = {
+ .phy_enable = set_dp_phy_ctrl,
+ .edp_dev_info = edp_info,
+};
+
+void init_panel_info(vidinfo_t *vid)
+{
+ vid-rgb_mode = MODE_RGB_P,
+
+ exynos_set_dp_platform_data(dp_platform_data);
+}
+
#ifdef CONFIG_SYS_I2C_INIT_BOARD
static int board_i2c_init(void)
{
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..a9b3b8b 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -256,6 +256,14 @@
#define CONFIG_SOUND_WM8994
#endif
+/* Display */
+#define CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_XRES 2560
+#define LCD_YRES 1600
+#define LCD_BPPLCD_COLOR16
+
/* Enable devicetree support */
#define CONFIG_OF_LIBFDT
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command
Dear Jagan Teki, In message CAD6G_RRw=YgbYtkwaZMC=KaS_5Lbfbm+fR-=lv96aoy72w3...@mail.gmail.com you wrote: Apart from this sometimes (very rare) due to the slowness of UART or SPI flash even if we run the sf commands it will not execute the actual code just terminate with showing u-boot prompt, so the user assumes that this command is happen properly. [but actually command is not done] But that would be a different thing - if there are errors without clear error messages, this is a bug that needs fixing. [But I do not see which part of your patch would address such an issue. Am I missing something?] Adding verbose progress messages is a different thing, though. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is much easier to suggest solutions when you know nothing ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] COMMON: MMC: Command to support eMMC booting
Hi SImon,
Thanks for the review comments.
Please find below the responses for your comments.
Thanks Regards
Amarendra
On 20 December 2012 08:10, Simon Glass s...@chromium.org wrote:
Hi Amar,
On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
This patch adds commands to open, close and create partitions on eMMC
Signed-off-by: Amar amarendra...@samsung.com
---
common/cmd_mmc.c | 101
+-
1 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 62a1c22..1fd6b94 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -248,6 +248,102 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag,
int
argc, char * const argv[])
curr_device, mmc-part_num);
return 0;
+ } else if (strcmp(argv[1], open) == 0) {
+ int dev;
+ struct mmc *mmc;
+
+ if (argc == 2)
+ dev = curr_device;
+ else if (argc == 3)
+ dev = simple_strtoul(argv[2], NULL, 10);
+ else if (argc == 4)
+ return 1;
Should this be CMD_RET_USAGE? What is returning 1 for?
Yes. Shall correct it.
+
+ else
+ return CMD_RET_USAGE;
+
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf(SD device cannot be opened/closed\n);
+ return 1;
+ }
+
+ if (!(mmc_boot_open(mmc))) {
+ printf(eMMC OPEN Success.!!\n);
+ printf(\t\t\t!!!Notice!!!\n);
+ printf(!You must close eMMC boot Partition
+ after all image
writing!\n);
+ printf(!eMMC boot partition has continuity
+ at image writing
time.!\n);
+ printf(!So, Do not close boot partition,
Before,
+ all images is
written.!\n);
Maybe:
So, do not close boot partition before all images are written
OK.. will change the wordings.
+ } else {
+ printf(eMMC OPEN Failed.!!\n);
Is it eMMC or MMC? Lower case or upper case? Your messages should be
consistent. And you don't need the !!! I think.
OK. Will maintain EMMC consistently every where. Will remove !!!.
+ }
+ return 0;
+
+ } else if (strcmp(argv[1], close) == 0) {
+ int dev;
+ struct mmc *mmc;
+
+ if (argc == 2)
+ dev = curr_device;
+ else if (argc == 3)
+ dev = simple_strtoul(argv[2], NULL, 10);
+ else if (argc == 4)
+ return 1;
Same Q here as above.
Ok, will be addressed.
+ else
+ return CMD_RET_USAGE;
+
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf(SD device cannot be opened/closed\n);
+ return 1;
+ }
+
Seems the open/close code is almost the same. Can you combine it?
Ok. Will combine open/close.
+ if (!(mmc_boot_close(mmc)))
+ printf(eMMC CLOSE Success.!!\n);
+ else
+ printf(eMMC CLOSE Failed.!!\n);
+
+ return 0;
+
+ } else if (strcmp(argv[1], bootpart) == 0) {
+ int dev;
+ dev = simple_strtoul(argv[2], NULL, 10);
+
+ struct mmc *mmc = find_mmc_device(dev);
+ u32 bootsize = simple_strtoul(argv[3], NULL, 10);
+ u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
+
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf(It is not a eMMC device\n);
+ return 1;
+ }
+
+ if (0 == mmc_boot_partition_size_change(mmc,
+ bootsize, rpmbsize)) {
+ printf(eMMC boot partition Size %d MB!!\n,
bootsize);
+ printf(eMMC RPMB partition Size %d MB!!\n,
rpmbsize);
+
Re: [U-Boot] [PATCH 8/9] SMDK5250: Enable eMMC booting
Hi SImon,
Thanks for the review comments.
Please find below the responses for your comments.
Thanks Regards
Amarendra
On 20 December 2012 08:05, Simon Glass s...@chromium.org wrote:
Hi Amar,
On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
This patch adds support for eMMC booting on SMDK5250
Signed-off-by: Amar amarendra...@samsung.com
---
board/samsung/smdk5250/spl_boot.c | 38
-
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index d8f3c1e..2648b4e 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -23,15 +23,40 @@
#includecommon.h
#includeconfig.h
+#include asm/arch/clock.h
+#include asm/arch/clk.h
+
+#define FSYS1_MMC0_DIV_VAL 0x0701
Should go in arch/arm/include/... ?
OK. shall move it.
+
enum boot_mode {
BOOT_MODE_MMC = 4,
+ BOOT_MODE_eMMC = 8, /* eMMC44 */
I think should you use upper case E, although I'm not completely sure.
OK. will make it upper case to be consistent every where.
BOOT_MODE_SERIAL = 20,
/* Boot based on Operating Mode pin settings */
BOOT_MODE_OM = 32,
BOOT_MODE_USB, /* Boot using USB download */
};
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
Should avoid adding typedefs.
Ok.
+static void set_emmc_clk(void);
+
+/*
+* Set MMC0 clock divisor value.
+* So that the mmc0 device operating freq is 50MHz.
Do we only support booting from mmc0? That's fine, but I suggest adding a
little comment.
OK.
+*/
+static void set_emmc_clk(void)
+{
+ struct exynos5_clock *clk = (struct exynos5_clock
*)EXYNOS5_CLOCK_BASE;
+ unsigned int addr;
+ unsigned int div_mmc;
+
+ addr = (unsigned int) clk-div_fsys1;
+
+ div_mmc = readl(addr) ~FSYS1_MMC0_DIV_MASK;
+ div_mmc |= FSYS1_MMC0_DIV_VAL;
+ writel(div_mmc, addr);
Can this function go in clock.c?
This function is used by SPL, only during EMMC boot.
Hence can be moved into board/samsung/smdk5250/clock_init.c.
Please comment on this.
+}
+
/*
* Copy U-boot from mmc to RAM:
@@ -43,6 +68,8 @@ 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_emmc)(u32, u32);
+ void (*end_bootop_emmc)(void);
bootmode = readl(EXYNOS5_POWER_BASE) OM_STAT;
@@ -57,6 +84,15 @@ void copy_uboot_to_ram(void)
copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
CONFIG_SYS_TEXT_BASE);
break;
+ case BOOT_MODE_eMMC:
+ set_emmc_clk();
+ end_bootop_emmc = (void *) *(u32
*)EMMC44_END_BOOTOP_FNPTR_ADDR;
+ copy_bl2_emmc = (void *) *(u32
*)EMMC44_COPY_BL2_FNPTR_ADDR;
I think these are pointers to functions in the IROM. Do they have the same
signature? Is it possible to create a table of them somewhere instead of
using defines?
OK.
The signatures are different for different booting devices.
More over, SDMMC / SPI / USB booting requires only one function pointer.
Where as EMMC 4.3/4.4 requires two of those function pointers.
May be something like this can be used to create table
void (*ptr_table[])(void) = {
(void *)0x02020030, /* iROM Function Pointer - SDMMC boot */
(void *)0x0202003C, /* iROM Function Pointer - EMMC 4.3 boot*/
(void *)0x02020040, /* iROM Function Pointer - EMMC 4.3 end boot op
*/
(void *)0x02020044, /* iROM Function Pointer - EMMC 4.4 boot*/
(void *)0x02020048, /* iROM Function Pointer - EMMC 4.4 end boot op
*/
(void *)0x02020050, /* iROM Function Pointer - EFNAND boot */
(void *)0x02020058, /* iROM Function Pointer - SPI boot */
(void *)0x02020070 /* iROM Function Pointer - USB boot */
};
Usage:
copy_bl2_from_emmc = (void *) *(u32 *)ptr_table[3];
end_bootop_from_emmc = (void *) *(u32 *)ptr_table[4];
+
+ copy_bl2_emmc(BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
+ end_bootop_emmc();
+ break;
+
default:
break;
}
--
1.7.0.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] MMC: APIs to support creation of boot partition
Hi Simon,
Ok. I will ensure to get rid of these little errors.
Thanks Regards
Amarendra Reddy
On 20 December 2012 08:01, Simon Glass s...@chromium.org wrote:
Hi Amar,
On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
This pathc adds APIs to open, close and to create boot partiton for eMMC.
Signed-off-by: Amar amarendra...@samsung.com
I think you should run checkpatch (or patman!) on your patches to get rid
of little errors. Or maybe you need to upgrade your checkpatch.
---
drivers/mmc/mmc.c | 118
+
include/mmc.h | 16 +++
2 files changed, 134 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 5ffd8c5..88b0435 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1302,3 +1302,121 @@ int mmc_initialize(bd_t *bis)
return 0;
}
+
+int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long
bootsize,
+ unsigned long rpmbsize)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Only use this command for raw eMMC moviNAND */
+ /* Enter backdoor mode */
/*
* line 1
* line 2
*/
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG1;
+
[snip]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/3] fw_env: fix type of len
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/12 00:47, Joe Hershberger wrote: Hi Tom, On Wed, Dec 19, 2012 at 5:00 PM, Tom Rini tr...@ti.com wrote: On Sat, Nov 10, 2012 at 07:47:45PM -, Mike Frysinger wrote: This variable is assigned by a size_t, and is printed that way, but is incorrectly declared as an int. Which means we get warnings: fw_env.c: In function 'fw_setenv': fw_env.c:409:5: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'int' [-Wformat] Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: Joe Hershberger joe.hershber...@ni.com For the series, applied to u-boot/master, thanks! I NACKed the third in this series. Did you not see it? Yeah, I missed that, sorry. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ0x/nAAoJENk4IS6UOR1WJ+IP/2g/Gb25k5WwKLG9LJWGp+ve h173Xt1GhMWB8tutmEd1zc4Gat/ZhFv8PO6SxlR/3RxTZzNkg7v74SBkNnglHQVa cvYIgzb72QvpIl7gHITHA38XedcV0UjEIJmlV6alqbZ/z4XBlNr/5Z71lwmI6VdM H+yopRxmxXAtthTHNfyTyF6+MVItlCY15RkKFTvv93Pof1CRtRLI1jL5+497VtbS hi7Fao2N/bHBUVkjQDU3hKOyApTNJhMBgxPu9EZszeAYqNLCNMH6FT4HvUNkYIjT OEyG8bfm5D+v4x79fmLuLwPRg+yaBKu4nVJe7pzeTsQKfM3loIvyoaci2DLm9afS ybmf97tRafMBYYiOTGJoRH3LXubCs1NZNgQIwCcDC9q59qy1E+uxp2jhBx/xfqGF ixlz3A+J0c9Ahfjybejf9Y1M3I/3Sbyx6/fJR7jZsQo/lJROkp4W+yJHcmSzLqQO jufYVZNi5lYo73R11TUa2oXngoBNW7jY4A9JHSA06JoB+GHp8Ze6yTFZD0QviTkY oAWNHMvTFqzvC4UAHLXOGiiBTuxVaCd8nOR2/z/BzcKEHJuTTJxwe0ABB/FU9o3b wF1MxwONT3/kfYA5eDItbjGaSa6NyY/66czjFSZjO0YJFZEKwKtLigwcgKw6Krq+ Mfv8c0WC0IXzgYikHFMm =Fiob -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Tue, Dec 18, 2012 at 07:19:10PM +0100, Marek Vasut wrote: I reduced it, DFU will have to wait, sorry. The following changes since commit ebbf0d20aa85f623c49b7ed3349ebfea450c152d: Prepare v2013.01-rc2 (2012-12-14 14:43:22 -0700) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 4f8dd5920f52462a9a5d794dc310a9a7a49ca89b: cm_t35: use new low level interface for usb ehci (2012-12-17 15:38:15 +0100) Lukasz Dalek (2): pxa25x_udc: Remove usbdescriptors.h h2200: Add USB CDC ethernet support Milind Choudhary (1): usb: Clean up newly allocated device nodes in case of configuration failure Nikita Kiryanov (2): cm-t35: add USB host support cm_t35: use new low level interface for usb ehci Pantelis Antoniou (2): g_dnl: Issue connect/disconnect as appropriate g_dnl: Properly terminate string list. Richard Genoud (1): usb documentation: fix typo Vincent Palatin (1): usb: properly detect empty mass storage media reader Vipin Kumar (1): usbh/ehci: Increase timeout for enumeration board/cm_t35/cm_t35.c | 77 + board/h2200/h2200.c | 11 +++ common/usb.c| 12 common/usb_hub.c| 35 ++- common/usb_storage.c| 10 ++ doc/README.usb |2 +- drivers/usb/gadget/g_dnl.c | 12 +++- drivers/usb/gadget/pxa25x_udc.c |1 - include/configs/cm_t35.h|8 +++- include/configs/h2200.h | 25 + include/usb.h |1 + 11 files changed, 185 insertions(+), 9 deletions(-) The cm_t35 parts don't compile, NAK. cm_t35.c: In function 'ehci_hcd_init': cm_t35.c:522:34: error: 'TWL4030_GPIO_GPIODATADIR1' undeclared (first use in this function) cm_t35.c:522:34: note: each undeclared identifier is reported only once for each function it appears in cm_t35.c:527:34: error: 'TWL4030_GPIO_SETGPIODATAOUT1' undeclared (first use in this function) -- 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] spi: Add progress percentage and write speed to `sf update`
On Wed, Dec 19, 2012 at 05:18:55PM -0800, Simon Glass wrote: Hi Tom, On Wed, Dec 19, 2012 at 5:03 PM, Tom Rini tr...@ti.com wrote: On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote: Dear Tom Rini, In message 20121219225945.GF14589@bill-the-cat you wrote: ... With this change, applied to u-boot/master. Argh :-( Can we please undo this somehow? This does not fit at all conceptually. U-Boot is supposed to use the good ols UNIX philosophy of being terse by default, and special casing one specific storage device makes no sense at all to me. We need to fix some of the underlying problems so that we're consistent here. Sometimes we have output (network #), sometimes we don't. Sometimes we have a speed (network, filesystem load), sometimes we don't. I'd be quite happy to have a uniform output and a uniform ON/OFF switch. I'm happy to do something like this. Obviously we want a config, but do we also want an env variable to control it? Could be useful. The biggest blocker I see is that we should start the series by re-orging things, if we can, so that we don't have this code in N places. And at the risk of killing it with feature creep, perhaps we could have two levels of verbosity: progress (which repeatedly updates on the same line) and notice (which does not). That might take care of Jagannadha's use case also. If we can do it such that it's (a) clean looking and (b) build-time configurable too, I don't see why we can't give it a look at least. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bricked when trying to attach UBI
Hi,
I'm Cc'ing the linux-mtd list as well as the authors of the Linux
commits cited below.
For these new readers: I reported a problem with U-Boot 2012.04.01 not
being able to attach an UBI partition in NAND, while Linux (2.6.37) can
attach and repair it.
It looks like an U-Boot bug, but I discovered strange things around the
chip-badblockbits variable (in the NAND code) by comparing the
relevant code in U-Boot and Linux.
Sorry for Cc'ing so many people, but following this issue I was lead
from one subsystem to another (and from U-Boot to Linux).
Previous discussion is here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/149624
Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
Hi Luca,
On 19.12.2012 16:56, Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
...
Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0,
need 1)
Now the device is totally blocked, and power cycling does not change
the result.
have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We
know
ubi recovery needs some ram and 1MiB may be not enough.
Thanks for your suggestion.
Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 10) to both (1024 12) and (1024 14), but without any
difference.
Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?
I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!
This swap dates back to:
commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck holger.bru...@keymile.com
Date: Mon Oct 10 13:08:19 2011 +0200
UBI: init eba tables before wl when attaching a device
This fixes that u-boot gets stuck when a bitflip was detected
during ubi part ubi_device. If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.
This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that background thread operations are really executed
we schedule these tasks in place and not as in linux after the inital
task which schedule this new task is finished.
Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Stefan Roese s...@denx.de
Signed-off-by: Stefan Roese s...@denx.de
I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!
But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(
I'm Cc:ing the commit author for comments.
Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.
What attach_by_scanning() does in Linux is (abbreviated):
static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi-some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si); /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}
See the two swapped calls.
At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi-avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux: UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0
The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().
After half a day of debugging and an insane amount of printk()s added to
both U-Boot and Linux, I have some more hints to understand the problem.
The two different results quoted above
Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver
Hi,
Well, you are of course 100% correct. I went back and took out the nand plat
stuff, made my own driver and used NAND_ECC_HW mode. A few tweaks and it works
just great. No changes needed to nand base code.
The mode names are a bit misleading, perhaps someone could document them in
the README?
What do I do to withdraw the patch? Or does it just get bounced out of the
queue.
Thanks for the help,
--
Chris J. Kiick ch...@kiicks.net
- Original Message
From: Scott Wood scottw...@freescale.com
To: Chris Kiick cki...@att.net
Cc: u-boot@lists.denx.de
Sent: Wed, December 19, 2012 3:40:49 PM
Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat
driver
On 12/19/2012 03:16:19 PM, Chris Kiick wrote:
Hi,
Thanks for the reply. This is my first patch to u-boot. Any advice is
appreciated. Comments in-line below.
- Original Message
From: Scott Wood scottw...@freescale.com
To: Chris Kiick cki...@att.net
Cc: u-boot@lists.denx.de
Sent: Wed, December 19, 2012 1:02:52 PM
Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand
plat
driver
On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
Allow boards to set their own ECC layouts and functions in
NAND_PLAT_INIT
without being stomped on by nand_base.c intialization.
Signed-off-by: ckiick chris at kiicks.net
---
drivers/mtd/nand/nand_base.c |11 +++
drivers/mtd/nand/nand_plat.c |4 ++--
include/configs/qong.h |2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c
b/drivers/mtd/nand/nand_base.c
index a2d06be..614fc72 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3035,8 +3035,10 @@ int nand_scan_tail(struct mtd_info *mtd)
chip-ecc.mode = NAND_ECC_SOFT;
case NAND_ECC_SOFT:
-chip-ecc.calculate = nand_calculate_ecc;
- chip-ecc.correct = nand_correct_data;
+ if (!chip-ecc.calculate)
+ chip-ecc.calculate = nand_calculate_ecc;
+ if (!chip-ecc.correct)
+ chip-ecc.correct = nand_correct_data;
chip-ecc.read_page = nand_read_page_swecc;
chip-ecc.read_subpage = nand_read_subpage;
chip-ecc.write_page = nand_write_page_swecc;
@@ -3044,9 +3046,10 @@ int nand_scan_tail(struct mtd_info *mtd)
chip-ecc.write_page_raw = nand_write_page_raw;
chip-ecc.read_oob = nand_read_oob_std;
chip-ecc.write_oob = nand_write_oob_std;
-if (!chip-ecc.size)
+ if (!chip-ecc.size) {
chip-ecc.size = 256;
- chip-ecc.bytes = 3;
+ chip-ecc.bytes = 3;
+ }
break;
case NAND_ECC_SOFT_BCH:
How is this part specific to nand plat?
OK, it's not, but if you are using nand plat, then you are forced to go
through
this code path with no chance of making any changes after because of the
way
board_nand_init() is written.
nand plat is meant to be a simple driver for simple hardware that follows a
certain pattern. If you have hardware that doesn't fit that, don't use nand
plat.
I seem to see other nand drivers setting up ecc
layouts and then calling nand_scan_tail(), I'm not sure how they are
getting
around this.
They don't use NAND_ECC_SOFT.
I reasoned that the change was safe for existing code because if something
was
not setting its own ecc layout, it would still use the default, but it if
was,
then it had to be after the call to nand_scan_tail() and that would
override
whatever was set there anyway.
It's not a matter of safety, but rather a sign that you're misusing things.
I'm not sure how specifying your own ECC functions fits with the
purpose
of
either NAND_ECC_SOFT or nand plat.
Well, NAND_ECC_SOFT is the only scheme that does fit with custom ECC
algorithms.
No, it's the opposite. NAND_ECC_SOFT is telling the generic code please do
ECC for me. NAND_ECC_HW is telling the generic code I want to do ECC
myself, usually because you have hardware that implements it. In your case,
it's because you're trying to maintain compatibility with something.
You have to pick one of the existing ECC schemes, and SOFT is the scheme
that
allows you to do your own ECC, if you setup the layout, calculate and
correct
parts. Looking at the code, that's what I thought it was for.
You just described NAND_ECC_HW. :-)
Is there another way to implement custom ECC algorithms, done in software?
As for the plat driver, it shouldn't care what ECC I'm using. It's just
running
the low-level byte-bang part of the driver for me, so I don't have to
duplicate
the code. Isn't that its
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
On Wed, Dec 19, 2012 at 5:32 PM, Allen Martin amar...@nvidia.com wrote: On Wed, Dec 19, 2012 at 02:42:24PM -0800, Albert ARIBAUD wrote: Hi Allen, Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and resolved the conflicts and I've pushed the result to: git://github.com/arm000/u-boot.git branch: u-boot-arm-merge-resolved I resolved all the conflicts, but the only ones I claim I did correctly were the changes to: include/configs/seaboard.h include/configs/tegra-common-post.h the other conflicts were not related to tegra. If you want a new pull request, you'll first have to unroll the previously merged tegra patches from u-boot-arm/master so I can give you a conflict free merge request. Thanks Allen, this branch is what I wanted exactly -- I don't want to ask for a rollback. As soon as I am sure about the samsung branch, I'll merge all fix branches into ARM. Ok, let me know if you have any problems resolving and I'll try to help the best I can. Tom, you'll need to rebase u-boot-tegra/next on top of this, and there will be conflicts when you do. I've resolved those as well for reference and pushed to: git://github.com/arm000/u-boot.git branch: u-boot-tegra-next-rebased -Allen Thanks, Allen, I probably won't get to this before the holiday break, but I'll pick it up next year and see where we're at. Appreciate your help with this. Albert - if you need anything from me, it'll have to be today or tomorrow, or next year. Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/master
On Thu, Dec 20, 2012 at 02:12:32PM +0900, Nobuhiro Iwamatsu wrote: Hi Tom, Please pull u-boot-sh master branch. Best regards, Nobuhiro The following changes since commit 095728803eedfce850a2f85828f79500cb09979e: Merge branch 'master' of git://git.denx.de/u-boot-net (2012-12-17 18:39:50 -0700) are available in the git repository at: git://git.denx.de/u-boot-sh master for you to fetch changes up to bb474b8187878181493b4ba1d422fb83df9b4335: serial_sh: Add support Renesas SH7752 (2012-12-20 13:20:17 +0900) Yoshihiro Shimoda (2): sh: add support for sh7752evb board serial_sh: Add support Renesas SH7752 MAINTAINERS |1 + arch/sh/include/asm/cpu_sh4.h |2 + arch/sh/include/asm/cpu_sh7752.h| 211 ++ board/renesas/sh7752evb/Makefile| 36 ++ board/renesas/sh7752evb/lowlevel_init.S | 460 + board/renesas/sh7752evb/sh7752evb.c | 330 board/renesas/sh7752evb/spi-boot.c | 116 ++ board/renesas/sh7752evb/u-boot.lds | 97 + boards.cfg |1 + doc/README.sh7752evb| 67 + drivers/serial/serial_sh.h |2 +- include/configs/sh7752evb.h | 153 +++ 12 files changed, 1475 insertions(+), 1 deletion(-) create mode 100644 arch/sh/include/asm/cpu_sh7752.h create mode 100644 board/renesas/sh7752evb/Makefile create mode 100644 board/renesas/sh7752evb/lowlevel_init.S create mode 100644 board/renesas/sh7752evb/sh7752evb.c create mode 100644 board/renesas/sh7752evb/spi-boot.c create mode 100644 board/renesas/sh7752evb/u-boot.lds create mode 100644 doc/README.sh7752evb create mode 100644 include/configs/sh7752evb.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] i.mx53 NFC support
Hello folks, I have a custom i.mx53 board with NAND Flash connected using the i.mx53 NAND flash controller.I have been trying to the flash working in U-boot with no success. I was looking at the driver mtd/nand/mxc_nand.c which I thought would work, but it seems that it only supports the older NFC versions found in the mx25, mx27, and mx35. Is there a working driver available for the NFC in the mx5 processors? If not, do you think it would be easier for me to try and patch the mxc_nand driver to support the newer NFC or to try and port the imx_nand driver from the Linux kernel? Best regards, Mark Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.mx53 NFC support
Dear Mark Roy, On Thursday, December 20, 2012 6:57:29 PM, Mark Roy wrote: I have a custom i.mx53 board with NAND Flash connected using the i.mx53 NAND flash controller.I have been trying to the flash working in U-boot with no success. I was looking at the driver mtd/nand/mxc_nand.c which I thought would work, but it seems that it only supports the older NFC versions found in the mx25, mx27, and mx35. Is there a working driver available for the NFC in the mx5 processors? If not, do you think it would be easier for me to try and patch the mxc_nand driver to support the newer NFC or to try and port the imx_nand driver from the Linux kernel? Please apply the following patch on u-boot/master: http://patchwork.ozlabs.org/patch/179176/ http://patchwork.ozlabs.org/patch/179176/raw/ You may also be interested in the following threads: http://lists.denx.de/pipermail/u-boot/2012-October/138129.html http://lists.denx.de/pipermail/u-boot/2012-December/142349.html Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM
Hi Ajay,
On Thu, Dec 20, 2012 at 4:35 AM, Ajay Kumar ajaykumar...@samsung.comwrote:
When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
error saying exynos_mipi_dsi_init() not defined. So, we add
dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
is not defined.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 9a7cbeb..b73263d 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
};
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
int exynos_mipi_dsi_init(void);
+#else
+int exynos_mipi_dsi_init(void)
Should this be static inline? I suppose it is included only once, but it
might be a good idea to add this.
+{
+ return 0;
+}
+#endif
/*
* register mipi_dsim_lcd_driver object defined by lcd panel driver
--
1.7.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console
Hi,
On Thu, Dec 20, 2012 at 4:35 AM, Ajay Kumar ajaykumar...@samsung.comwrote:
Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
existing logo feature intact in Trats.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
There is nothing in the README, but I suppose this is a chip-specific
patch, so fair enough. But see below.
Acked-by: Simon Glass s...@chomium.org
---
drivers/video/exynos_fb.c |5 -
drivers/video/exynos_fimd.c | 10 --
include/configs/trats.h |1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..c111a09 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+#ifdef CONFIG_EXYNOS_LOGO
Do you actually need this #ifdef, and the one below it? You already have
panel_info.logo_on. I suppose you could do, at the top of the file:
+#ifdef CONFIG_EXYNOS_LOGO
#define panal_exynos_logo() panel_info.logo_on
#else
#define panal_exynos_logo() 0
#endif
static void draw_logo(void)
{
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
}
+#endif
static void lcd_panel_on(vidinfo_t *vid)
{
@@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
+#ifdef CONFIG_EXYNOS_LOGO
if (panel_info.logo_on) {
Then could do 'if (panal_exynos_logo())' here and rermove the #ifdefs. Same
below. #ifdefs are considered bad because they create new code paths that
might not always be compiled.
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) 3));
draw_logo();
}
-
+#endif
lcd_panel_on(panel_info);
}
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..f2e4c27 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
- /* bpp is 32 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
- /* pixel format is unpacked RGB888 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
writel(cfg, (unsigned int)fimd_ctrl-wincon0 +
EXYNOS_WINCON(win_id));
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a24e945..1573573 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -252,6 +252,7 @@
#define CONFIG_EXYNOS_FB
#define CONFIG_LCD
#define CONFIG_CMD_BMP
+#define CONFIG_EXYNOS_LOGO
#define CONFIG_BMP_32BPP
#define CONFIG_FB_ADDR 0x52504000
#define CONFIG_S6E8AX0
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/4] EXYNOS5: Add support for FIMD and DP
On Thu, Dec 20, 2012 at 4:35 AM, Ajay Kumar ajaykumar...@samsung.comwrote:
Add panel_info structure required by LCD driver
and DP panel platdata for SMDK5250.
Add GPIO configuration for LCD.
Enable FIMD and DP support on SMDK5250.
DP Panel size: 2560x1600.
We use 16BPP resolution to get LCD console.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chomium.org
---
board/samsung/smdk5250/smdk5250.c | 97
+
include/configs/smdk5250.h|8 +++
2 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4c50342..46fd2a5 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -24,12 +24,15 @@
#include asm/io.h
#include i2c.h
#include netdev.h
+#include lcd.h
#include spi.h
#include asm/arch/cpu.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
+#include asm/arch/power.h
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
+#include asm/arch/dp_info.h
#include pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -181,6 +184,100 @@ static int board_uart_init(void)
return 0;
}
+void cfg_lcd_gpio(void)
+{
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *)
samsung_get_base_gpio_part1();
+
+ /* For Backlight */
+ s5p_gpio_cfg_pin(gpio1-b2, 0, GPIO_OUTPUT);
+ s5p_gpio_set_value(gpio1-b2, 0, 1);
+
+ /* LCD power on */
+ s5p_gpio_cfg_pin(gpio1-x1, 5, GPIO_OUTPUT);
+ s5p_gpio_set_value(gpio1-x1, 5, 1);
+
+ /* Set Hotplug detect for DP */
+ s5p_gpio_cfg_pin(gpio1-x0, 7, GPIO_FUNC(0x3));
+}
+
+vidinfo_t panel_info = {
+ .vl_freq= 60,
+ .vl_col = 2560,
+ .vl_row = 1600,
+ .vl_width = 2560,
+ .vl_height = 1600,
+ .vl_clkp= CONFIG_SYS_LOW,
+ .vl_hsp = CONFIG_SYS_LOW,
+ .vl_vsp = CONFIG_SYS_LOW,
+ .vl_dp = CONFIG_SYS_LOW,
+ .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on
LCD */
+
+ /* wDP panel timing infomation */
+ .vl_hspw= 32,
+ .vl_hbpd= 80,
+ .vl_hfpd= 48,
+
+ .vl_vspw= 6,
+ .vl_vbpd= 37,
+ .vl_vfpd= 3,
+ .vl_cmd_allow_len = 0xf,
+
+ .win_id = 3,
+ .cfg_gpio = cfg_lcd_gpio,
+ .backlight_on = NULL,
+ .lcd_power_on = NULL,
+ .reset_lcd = NULL,
+ .dual_lcd_enabled = 0,
+
+ .init_delay = 0,
+ .power_on_delay = 0,
+ .reset_delay= 0,
+ .interface_mode = FIMD_RGB_INTERFACE,
+ .dp_enabled = 1,
+};
+
+static struct edp_device_info edp_info = {
+ .disp_info = {
+ .h_res = 2560,
+ .h_sync_width = 32,
+ .h_back_porch = 80,
+ .h_front_porch = 48,
+ .v_res = 1600,
+ .v_sync_width = 6,
+ .v_back_porch = 37,
+ .v_front_porch = 3,
+ .v_sync_rate = 60,
+ },
+ .lt_info = {
+ .lt_status = DP_LT_NONE,
+ },
+ .video_info = {
+ .master_mode = 0,
+ .bist_mode = DP_DISABLE,
+ .bist_pattern = NO_PATTERN,
+ .h_sync_polarity = 0,
+ .v_sync_polarity = 0,
+ .interlaced = 0,
+ .color_space = COLOR_RGB,
+ .dynamic_range = VESA,
+ .ycbcr_coeff = COLOR_YCBCR601,
+ .color_depth = COLOR_8,
+ },
+};
+
+static struct exynos_dp_platform_data dp_platform_data = {
+ .phy_enable = set_dp_phy_ctrl,
+ .edp_dev_info = edp_info,
+};
+
+void init_panel_info(vidinfo_t *vid)
+{
+ vid-rgb_mode = MODE_RGB_P,
+
+ exynos_set_dp_platform_data(dp_platform_data);
+}
+
#ifdef CONFIG_SYS_I2C_INIT_BOARD
static int board_i2c_init(void)
{
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..a9b3b8b 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -256,6 +256,14 @@
#define CONFIG_SOUND_WM8994
#endif
+/* Display */
+#define CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_XRES 2560
+#define LCD_YRES 1600
+#define LCD_BPPLCD_COLOR16
+
/* Enable devicetree support */
#define CONFIG_OF_LIBFDT
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing
On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote: On 12/10/2012 07:41:43 AM, Phil Sutter wrote: On Fri, Dec 07, 2012 at 11:38:11AM -0600, Scott Wood wrote: On 12/07/2012 10:58:53 AM, Phil Sutter wrote: Hmm. Does not look like CONFIG_ENV_OFFSET_OOB is used to select the block(s) within the erase page to save the environment. Looking at common/env_nand.c:318, the environment offset saved in the OOB seems to be in erase page unit. I'm not sure what you mean by block(s) within the erase page -- blocks are the unit of erasing, and of bad block marking. Not always, at least not with NAND flash. Erase pages are mostly bigger than write pages (or blocks). In my case, flash consists of 0x800 bytes write pages and 0x2000 bytes erase pages. Erase blocks are larger than write pages, yes. I've never heard erase blocks called pages or write pages called blocks -- but my main point is that the unit of erasing and the unit of badness are the same. Ah, OK. Please excuse my humble nomenclature, I never cared enough to sort out what is called what. Of course, this is not the best basis for a discussion about these things. But getting back to the topic: The assumption of blocks getting bad, not pages within a block means that for any kind of bad block prevention, multiple blocks need to be used. Although I'm honestly speaking not really sure why this needs to be like that. Maybe the bad page marking would disappear when erasing the block it belongs to? The block to hold the environment is stored in the OOB of block zero, which is usually guaranteed to not be bad. Erase or write block? Note that every write block has it's own OOB. block means erase block. Every write page has its own OOB, but it is erase blocks that are marked bad. Typically the block can be marked bad in either the first or the second page of the erase block. Interesting. I had the impression of pages being marked bad and the block's badness being taken from whether it contains bad pages. Probably the 'nand markbad' command tricked me. On the other hand, I could not find code that alters this setting based on bad blocks found or whatever. This seems to simply be an alternative to setting CONFIG_ENV_OFFSET at build-time. It is set by the nand env.oob command. It is currently a manual process (or rather, automation is left to the user's board preparation process rather than being built into U-Boot), as U-Boot wouldn't know how to give back unused blocks to other purposes. So that assumes that any block initially identified 'good' will ever turn 'bad' later on? We don't currently have any mechanism for that to happen with the environment -- which could be another good reason to have real redundancy that doesn't get crippled from day one by having one copy land on a factory bad block. Of course, that requires someone to implement support for redundant environment combined with CONFIG_ENV_OFFSET_OOB. Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to the other copy in case of error there would be a working system in three of four cases instead of only one. Maybe a better option is to implement support for storing the environment in ubi, although usually if your environment is in NAND that means your U-Boot image is in NAND, so you have the same problem there. Maybe you could have an SPL that contains ubi support, that fits in the guaranteed-good first block. Do you have any data on how often a block might go bad that wasn't factory-bad, to what extent reads versus writes matter, and whether there is anything special about block zero beyond not being factory-bad? No, sadly not. I'd guess this information depends on what hardware being used specifically. But I suppose block zero being prone to becoming worn just like any other block, although it not being erased as often should help a lot. Assuming a certain number of erase cycles after each block is worn out and given the fact that CONFIG_ENV_OFFSET_REDUND has always both blocks written (unless power failure occurs), they would turn bad at the same time and therefore rendering the environment useless with or without fallback. :) Best wishes, Phil -- Viprinet Europe GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49 6721 49030-0 Direct line/Durchwahl:+49 6721 49030-134 Fax: +49 6721 49030-109 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany Commercial register/Handelsregister: Amtsgericht Mainz HRB44090 CEO/Geschäftsführer: Simon Kissel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing
On 12/20/2012 03:28:39 PM, Phil Sutter wrote: On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote: Erase blocks are larger than write pages, yes. I've never heard erase blocks called pages or write pages called blocks -- but my main point is that the unit of erasing and the unit of badness are the same. Ah, OK. Please excuse my humble nomenclature, I never cared enough to sort out what is called what. Of course, this is not the best basis for a discussion about these things. But getting back to the topic: The assumption of blocks getting bad, not pages within a block means that for any kind of bad block prevention, multiple blocks need to be used. Although I'm honestly speaking not really sure why this needs to be like that. Maybe the bad page marking would disappear when erasing the block it belongs to? Yes, it would disappear. This is why erase operations skip bad blocks, unless the scrub option is uesd. The block to hold the environment is stored in the OOB of block zero, which is usually guaranteed to not be bad. Erase or write block? Note that every write block has it's own OOB. block means erase block. Every write page has its own OOB, but it is erase blocks that are marked bad. Typically the block can be marked bad in either the first or the second page of the erase block. Interesting. I had the impression of pages being marked bad and the block's badness being taken from whether it contains bad pages. Probably the 'nand markbad' command tricked me. Do you mean the lack of error checking if you pass a non-block-aligned offset into nand markbad? So that assumes that any block initially identified 'good' will ever turn 'bad' later on? We don't currently have any mechanism for that to happen with the environment -- which could be another good reason to have real redundancy that doesn't get crippled from day one by having one copy land on a factory bad block. Of course, that requires someone to implement support for redundant environment combined with CONFIG_ENV_OFFSET_OOB. Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to the other copy in case of error there would be a working system in three of four cases instead of only one. I'm not sure what you mean here -- where do three, four, and one come from? Maybe a better option is to implement support for storing the environment in ubi, although usually if your environment is in NAND that means your U-Boot image is in NAND, so you have the same problem there. Maybe you could have an SPL that contains ubi support, that fits in the guaranteed-good first block. Do you have any data on how often a block might go bad that wasn't factory-bad, to what extent reads versus writes matter, and whether there is anything special about block zero beyond not being factory-bad? No, sadly not. I'd guess this information depends on what hardware being used specifically. But I suppose block zero being prone to becoming worn just like any other block, although it not being erased as often should help a lot. Assuming a certain number of erase cycles after each block is worn out and given the fact that CONFIG_ENV_OFFSET_REDUND has always both blocks written (unless power failure occurs), they would turn bad at the same time and therefore rendering the environment useless with or without fallback. :) That depends on whether the specified number of erase cycles per block is a minimum for any block not marked factory-bad, or whether some fraction of non-factory-bad blocks may fail early. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] env: don't generate callback list entries for SPL
SPL doesn't write to the environment. These list entries prevent the
functions from being garbage-collected, even though nothing will look at
the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to
break due to size limitations and/or unresolved symbols.
A static inline function is used to provide a context in which we
can consume the callback, and thus avoid unused function warnings.
Signed-off-by: Scott Wood scottw...@freescale.com
Acked-by: Joe Hershberger joe.hershber...@gmail.com
---
v2: Update commit message to reflect that some SPLs do use the
environment, in a read-only fashion. Also update commit message
to indicate that the size of the included functions wasn't the only
problem seen.
---
include/env_callback.h |8
1 file changed, 8 insertions(+)
diff --git a/include/env_callback.h b/include/env_callback.h
index 47fdc6f..c583120 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -68,8 +68,16 @@ void env_callback_init(ENTRY *var_entry);
* when associated through the .callbacks environment variable, the callback
* will be executed any time the variable is inserted, overwritten, or deleted.
*/
+#ifdef CONFIG_SPL_BUILD
+#define U_BOOT_ENV_CALLBACK(name, callback) \
+ static inline void _u_boot_env_noop_##name(void) \
+ { \
+ (void)callback; \
+ }
+#else
#define U_BOOT_ENV_CALLBACK(name, callback) \
ll_entry_declare(struct env_clbk_tbl, name, env_clbk, env_clbk) = \
{#name, callback}
+#endif
#endif /* __ENV_CALLBACK_H__ */
--
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] mx53loco: Fix PMIC name
On Tue, Dec 11, 2012 at 10:36 AM, Fabio Estevam
fabio.este...@freescale.com wrote:
commit c73368150 (pmic: Extend PMIC framework to support multiple instances
of PMIC devices) has incorrectly passed the PMIC name under the FSL PMIC case.
Fix that by passing FSL_PMIC as the parameter of pmic_get.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx53loco/mx53loco.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 81c511c..2c8cb7a 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -374,7 +374,7 @@ static int power_init(void)
if (retval)
return retval;
- p = pmic_get(DIALOG_PMIC);
+ p = pmic_get(FSL_PMIC);
if (!p)
return -ENODEV;
--
1.7.9.5
Hi Fabio,
It looks like we need one more fixup after commit c73368150 on the
first run/older (non R, Dialog, bug wired extra Capacitor) version of
this board.. Do you happen to have any in your lab?
U-Boot 2013.01-rc2-dirty (Dec 20 2012 - 15:55:01)
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
pmic_alloc: No available memory for allocation!
pmic_init: POWER allocation error!
CPU: Freescale i.MX53 family rev2.0 at 800 MHz
Reset cause: POR
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment
(and it just keeps on resetting)
It looks to be failing after calloc...
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/power/power_core.c#l100
100 p = calloc(sizeof(*p), 1);
101 if (!p) {
102 printf(%s: No available memory for
allocation!\n, __func__);
103 return NULL;
104 }
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] env: don't generate callback list entries for SPL
On Thu, 20 Dec 2012 15:51:05 -0600 Scott Wood scottw...@freescale.com wrote: SPL doesn't write to the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations and/or unresolved symbols. A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings. Signed-off-by: Scott Wood scottw...@freescale.com Acked-by: Joe Hershberger joe.hershber...@gmail.com --- Acked-by: Kim Phillips kim.phill...@freescale.com Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] split nand writes
On 12/20/2012 06:35:49 AM, Jaap de Jong wrote: On 12/19/2012 11:47 PM, Scott Wood wrote: On 12/19/2012 09:43:01 AM, Jaap de Jong wrote: Hi All, suppose the image I want to flash is bigger than the available ram in the unit. Is there a way to copy the image f.i. in pieces into the flash? nand write should have a 'continue on last block' option for that purpose. Something like that would be nice. These patches are relevant: http://patchwork.ozlabs.org/patch/204939/ http://patchwork.ozlabs.org/patch/204940/ That could do the trick also. You would have to do some arithmetic to calculate the next startaddress in the flash. So there is not an out-of-the-box solution at the moment? There isn't. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver
On 12/20/2012 09:05:49 AM, Chris Kiick wrote: Hi, Well, you are of course 100% correct. I went back and took out the nand plat stuff, made my own driver and used NAND_ECC_HW mode. A few tweaks and it works just great. No changes needed to nand base code. The mode names are a bit misleading, perhaps someone could document them in the README? Patches welcome. :-) What do I do to withdraw the patch? Or does it just get bounced out of the queue. An e-mail reply is fine (which you just did). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: Secure boot framework
Hi Simon, Thanks for your reply. On Tue, Dec 18, 2012 at 1:37 AM, Simon Glass s...@chromium.org wrote: Hi Joel, On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A joelag...@ti.com wrote: Hi, Can anyone comment on what has been discussed about a framework for secure boot and authentication, if there has been such a discussion, in the community? I have some U-boot code that is based off of a slightly older U-boot which does authentication and/or decryption. The main code that does the cryptography is in the ROM of the SoC. However, I'm sure there will be other U-boot developers requiring the crypto algorithms itself to be supported. My questions are : (1) Would a general framework for performing authentication and/or decryption of signed and/or encrypted images be useful for U-boot? These operations seem to make a lot of sense for a bootloader. (2) Does such a framework make sense for any of your usecase(s)? (3) Has there been any work or discussions of coming up with such a framework for U-boot? We have created a secure boot system on top of U-Boot - it is in the Chromium tree if you want to take a look. Three ChromeOS devices have shipped with this so far. However it is not really suitable for generic upstream use, so... There have been some discussions lately on the list about using the FIT format to hold an image which can then be verified using a public key. We have put together a possible design for this and I am working on this as I make time. Which Processor and silicon revision is this? Can you point to a security hardware specification so that I could take a quick look at the architecture you have in mind? Is it [1]? Also, is it possible to share the design for modification to FIT you have put together so far? I imagine a framework like this will atleast consist of: 1. General purposes cryptographic functions in a library (which we might not need for our case), some light weight crypto library. 2. Hooks for board/Soc-specific functions that call into the general crypto lib and do any other board/SoC-specific stuff. 3. General commands (in a cmd_crpto.c) that calls into the callbacks mentioned in 2. for encryption and verification of an image already in memory. (making it commands can allow us to leave bootm alone and do the inplace decryption/verification independently - however for SPL, we don't need the commands and call into 2. directly). 4. Abstract any other change(s) to common boot code in a common place. Yes that seems reasonable. Thanks. A very basic hashing framework recently went into U-Boot, and this can be used to plumb in SOC hashing acceleration code. I suspect we will do the same with RSA, supporting a few different key lengths and associated padding. My plan at present is roughly (and in short order) to: 1. Define how signatures are represented in FIT Just wondering what architecture / silicon are you using from the ChromiumOS, I guess its the Samsun Exynos? Anyway, isn't the representation of the signature and the other structure of the image fixed by your ROM or hardware specification? For example, to load U-boot SPL, doesn't your ROM or firmware expect the image signatures/certificates etc to be in a certain format? Then how can you use FIT for the purpose of verification/authentication? I agree FIT can be possibly modified enough to support this, but what about the first-stage loading of U-boot SPL. Does your ROM or architecture understand FIT? I agree second-state bootloader loading and then kernel can use FIT but I'm not clear on how you do verified-boot for U-boot SPL for example. Representing U-boot SPL as FIT is not possible right. Just a note, we run U-boot SPL from internal SRAM and not a programmable ROM. 2. Enhance mkimage to sign an image or a configuration (consisting of image +fdt, for example) 3. Enhance FIT command to verify an image given a public key Yeah, this sound like a good plan. 4. Support checking of version information against a TPM rollback counter I have no idea about TPM rollback, can you point to docs for that? 5. Work this into the bootm code 6. Add RSA2048/4096 cool , ok. For us right now we have ROM API that does all boot-time crypto (using hw acceleration where possible), but I guess those details can be abstracted for different secure boot architectures, and folks who need a pure software implementation can use it. Thanks, Joel [1] http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL
On 2012년 12월 20일 21:35, Ajay Kumar wrote: With VPLL as source clock to FIMD, Exynos DP Initializaton was failing sometimes with unstable clock. Changing FIMD source to MPLL resolves this issue. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/exynos/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index fe61f88..bfcd5f7 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void) */ cfg = readl(clk-src_disp1_0); cfg = ~(0xf); - cfg |= 0x8; + cfg |= 0x6; writel(cfg, clk-src_disp1_0); /* It looks good to me. Acked-by: Donghwa Lee dh09@samsung.com Thank you, Donghwa Lee ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM
On 2012년 12월 20일 21:35, Ajay Kumar wrote:
When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
error saying exynos_mipi_dsi_init() not defined. So, we add
dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
is not defined.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 9a7cbeb..b73263d 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
};
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
int exynos_mipi_dsi_init(void);
+#else
+int exynos_mipi_dsi_init(void)
+{
+ return 0;
+}
+#endif
/*
* register mipi_dsim_lcd_driver object defined by lcd panel driver
It looks good to me.
Acked-by: Donghwa Lee dh09@samsung.com
Thank you,
Donghwa Lee
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console
On 2012년 12월 20일 21:35, Ajay Kumar wrote:
Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
existing logo feature intact in Trats.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/video/exynos_fb.c |5 -
drivers/video/exynos_fimd.c | 10 --
include/configs/trats.h |1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..c111a09 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+#ifdef CONFIG_EXYNOS_LOGO
static void draw_logo(void)
{
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
}
+#endif
static void lcd_panel_on(vidinfo_t *vid)
{
@@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
+#ifdef CONFIG_EXYNOS_LOGO
if (panel_info.logo_on) {
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) 3));
draw_logo();
}
-
+#endif
lcd_panel_on(panel_info);
}
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..f2e4c27 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
- /* bpp is 32 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
- /* pixel format is unpacked RGB888 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
writel(cfg, (unsigned int)fimd_ctrl-wincon0 +
EXYNOS_WINCON(win_id));
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a24e945..1573573 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -252,6 +252,7 @@
#define CONFIG_EXYNOS_FB
#define CONFIG_LCD
#define CONFIG_CMD_BMP
+#define CONFIG_EXYNOS_LOGO
#define CONFIG_BMP_32BPP
#define CONFIG_FB_ADDR0x52504000
#define CONFIG_S6E8AX0
Hi,
How about use 'if (vid-logo_on)' instead of #ifdef CONFIG_EXYNOS_LOGO?
In the vidinfo_t structure, 'logo_on' flag already exist.
Thank you,
Donghwa Lee
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] usb: net: asix: Do a fast init if link already established
Hi Simon, On Thu, Dec 13, 2012 at 8:21 PM, Simon Glass s...@chromium.org wrote: The Asix driver takes the link down during init() and then brings it back up. This commit changes this so that if a link has already been established successfully we simply check that the link is still good. Also fix up asix_halt() to actually halt RX on the interface. Previously this was not done, so the device would continue to operate evern when halted, violating a U-Boot requirement. This reduces the delay between successive network commands. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] usb: usbeth: smsc95xx: remove EEPROM loaded check
Hi Simon, On Thu, Dec 13, 2012 at 8:21 PM, Simon Glass s...@chromium.org wrote: From: Michael Spang sp...@chromium.org [port of Linux kernel commit bcd218be5aeb by Steve Glendinning] The eeprom read write commands currently check the E2P_CMD_LOADED_ bit is set before allowing any operations. This prevents any reading or writing unless a correctly programmed EEPROM is installed. Signed-off-by: Michael Spang sp...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Acked-by: Marek Vasut ma...@denx.de --- Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console
Dear Ajay,
On 21/12/12 10:53, Donghwa Lee wrote:
On 2012년 12월 20일 21:35, Ajay Kumar wrote:
Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
existing logo feature intact in Trats.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/video/exynos_fb.c |5 -
drivers/video/exynos_fimd.c | 10 --
include/configs/trats.h |1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..c111a09 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+#ifdef CONFIG_EXYNOS_LOGO
static void draw_logo(void)
{
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
}
+#endif
static void lcd_panel_on(vidinfo_t *vid)
{
@@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
+#ifdef CONFIG_EXYNOS_LOGO
if (panel_info.logo_on) {
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) 3));
draw_logo();
}
-
+#endif
lcd_panel_on(panel_info);
}
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..f2e4c27 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
-/* bpp is 32 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else/* To get output console on LCD */
+cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
-/* pixel format is unpacked RGB888 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else/* To get output console on LCD */
+cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
writel(cfg, (unsigned int)fimd_ctrl-wincon0 +
EXYNOS_WINCON(win_id));
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a24e945..1573573 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -252,6 +252,7 @@
#define CONFIG_EXYNOS_FB
#define CONFIG_LCD
#define CONFIG_CMD_BMP
+#define CONFIG_EXYNOS_LOGO
#define CONFIG_BMP_32BPP
#define CONFIG_FB_ADDR0x52504000
#define CONFIG_S6E8AX0
Hi,
How about use 'if (vid-logo_on)' instead of #ifdef CONFIG_EXYNOS_LOGO?
In the vidinfo_t structure, 'logo_on' flag already exist.
I agreed with Donghwa.
Ajay, please check it.
Thank you,
Donghwa Lee
Thanks.
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] no mtdparted from U-Boot prompt
This is my first post to the list. I am using u-boot-1.3.4 in buildroot-2011.11 My device is a at91sam9g20-ek I have a patch adding: include/configs/at91sam9g20ek.h which I gather acts as a config file for u-boot. U-Boot help does not list mtdparts But my bootargs does use it: bootargs=mem=64M console=ttyS0,115200 mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) root=/dev/mtdblock1 rw rootfstype=jffs2 Is there a trick to add the mtdparts command? Or is there supposed to be a command? I unsuccessfully added to include/configs/at91sam9g20ek.h #define CONFIG_JFFS2_NAND 1 #define CONFIG_JFFS2_CMDLINE 1 #define CONFIG_CMD_JFFS2 1 // Required to include cmd_jffs2.c which did not result in adding the command line. NOTICE: This email may contain confidential information. Please see http://www.meyersound.com/confidential/ for our complete policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor
Hi Simon,
Thanks for your review comments.
Please find the responses below.
Thanks Regards
Amarendra Reddy
On 20 December 2012 07:54, Simon Glass s...@chromium.org wrote:
Hi Amar,
On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
This API computes the divisor value based on MPLL clock and
writes it into the FSYS1 register.
Signed-off-by: Amar amarendra...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 39
++-
arch/arm/include/asm/arch-exynos/clk.h |1 +
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 731bbff..6517296 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -379,7 +379,7 @@ static unsigned long exynos4_get_mmc_clk(int
dev_index)
(struct exynos4_clock *)samsung_get_base_clock();
unsigned long uclk, sclk;
unsigned int sel, ratio, pre_ratio;
- int shift;
+ int shift = 0;
sel = readl(clk-src_fsys);
sel = (sel (dev_index 2)) 0xf;
@@ -428,7 +428,7 @@ static unsigned long exynos5_get_mmc_clk(int
dev_index)
(struct exynos5_clock *)samsung_get_base_clock();
unsigned long uclk, sclk;
unsigned int sel, ratio, pre_ratio;
- int shift;
+ int shift = 0;
sel = readl(clk-src_fsys);
sel = (sel (dev_index 2)) 0xf;
@@ -526,6 +526,41 @@ static void exynos5_set_mmc_clk(int dev_index,
unsigned int div)
writel(val, addr);
}
+/* exynos5: set the mmc clock div ratio in fsys1 */
+int exynos5_mmc_set_clk_div(int dev_index)
Shouldn't this take a periph_id instead of a dev_index?
Ok will convert index int to peripheral_id in the calling function.
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ unsigned int addr;
+ unsigned int clock;
+ unsigned int tmp;
+ unsigned int i;
+
+ /* get mpll clock */
+ clock = get_pll_clk(MPLL) / 100;
+
+ /*
+* CLK_DIV_FSYS1
+* MMC0_PRE_RATIO [15:8], MMC0_RATIO [3:0]
+* CLK_DIV_FSYS2
+* MMC2_PRE_RATIO [15:8], MMC2_RATIO [3:0]
+*/
+ if (dev_index 2) {
+ addr = (unsigned int)clk-div_fsys1;
+ } else {
+ addr = (unsigned int)clk-div_fsys2;
+ }
+
+ tmp = readl(addr) ~FSYS1_MMC0_DIV_MASK;
+ for (i = 0; i = 0xf; i++) {
+ if ((clock / (i + 1)) = 400) {
+ writel(tmp | i 0, addr);
+ break;
+ }
+ }
+ return 0;
+}
+
/* get_lcd_clk: return lcd clock frequency */
static unsigned long exynos4_get_lcd_clk(void)
{
diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
index ff155d8..b0ecdd4 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -36,6 +36,7 @@ unsigned long get_pwm_clk(void);
unsigned long get_uart_clk(int dev_index);
unsigned long get_mmc_clk(int deV_index);
void set_mmc_clk(int dev_index, unsigned int div);
+int exynos5_mmc_set_clk_div(int dev_index);
unsigned long get_lcd_clk(void);
void set_lcd_clk(void);
void set_mipi_clk(void);
--
1.7.0.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] EXYNOS5: DWMMC: Added dt support for DWMMC
Hi Simon,
Thanks for your review comments.
Please find the responses below.
Thanks Regards
Amarendra Reddy
On 20 December 2012 07:53, Simon Glass s...@chromium.org wrote:
Hi Amar,
On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
Signed-off-by: Amar amarendra...@samsung.com
Good to see this patch! Please can you add a short commit message?
Oops.. sorry. I will put the commit msg.
---
arch/arm/include/asm/arch-exynos/dwmmc.h |4 +
drivers/mmc/exynos_dw_mmc.c | 117
--
include/dwmmc.h |4 +
3 files changed, 119 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
b/arch/arm/include/asm/arch-exynos/dwmmc.h
index 8acdf9b..92352df 100644
--- a/arch/arm/include/asm/arch-exynos/dwmmc.h
+++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
@@ -27,6 +27,9 @@
#define DWMCI_SET_DRV_CLK(x) ((x) 16)
#define DWMCI_SET_DIV_RATIO(x) ((x) 24)
+#ifdef CONFIG_OF_CONTROL
+unsigned int exynos_dwmmc_init(const void *blob);
+#else
int exynos_dwmci_init(u32 regbase, int bus_width, int index);
static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
@@ -34,3 +37,4 @@ static inline unsigned int exynos_dwmmc_init(int index,
int bus_width)
unsigned int base = samsung_get_base_mmc() + (0x1 * index);
return exynos_dwmci_init(base, bus_width, index);
}
+#endif
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 72a31b7..3b3e3e5 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -19,23 +19,38 @@
*/
#include common.h
-#include malloc.h
#include dwmmc.h
+#include fdtdec.h
+#include libfdt.h
+#include malloc.h
#include asm/arch/dwmmc.h
#include asm/arch/clk.h
+#include asm/arch/pinmux.h
+
+#defineDWMMC_MAX_CH_NUM4
+#defineDWMMC_MAX_FREQ 5200
+#defineDWMMC_MIN_FREQ 40
+#defineDWMMC_MMC0_CLKSEL_VAL 0x03030001
+#defineDWMMC_MMC2_CLKSEL_VAL 0x03020001
What do these last two values mean? I think clock setting should be done in
clock.c, not here.
In case of non-dt support, these two values are written into respective
clock selection register-CLKSEL, to select the clock for MMC-channel0 and
MMC-channel2.
Will move clock setting into clock.c and the #defines will be moved into
include/asm/arch/clk.h.
static char *EXYNOS_NAME = EXYNOS DWMMC;
static void exynos_dwmci_clksel(struct dwmci_host *host)
{
- u32 val;
- val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
- DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) |
DWMCI_SET_DIV_RATIO(0);
+ dwmci_writel(host, DWMCI_CLKSEL, host-clksel_val);
+}
- dwmci_writel(host, DWMCI_CLKSEL, val);
+unsigned int exynos_dwmci_get_clk(int dev_index)
+{
+ return get_mmc_clk(dev_index);
}
+#ifdef CONFIG_OF_CONTROL
+static int exynos_dwmci_init(u32 regbase, int bus_width,
+ int index, u32 *timing)
+#else
int exynos_dwmci_init(u32 regbase, int bus_width, int index)
+#endif
I'm really not keen on having the same function with different signatures.
My first question is whether we need to support operation without
CONFIG_OF_CONTROL. If so, I suggest having an init routine that takes an
FDT blob as a parameter, and a separate add_port function which can be
called by non-FDT-enabled board files. The init routine will call the
add_port function for each port it finds in the FDT.
I think we need support operation without CONFIG_OF_CONTROL atleast untill
the entire FDT is formed.
Hence I will implement it as per your suggestion.
Also please can you briefly comment non-trivial functions?
OK.
{
struct dwmci_host *host = NULL;
host = malloc(sizeof(struct dwmci_host));
@@ -44,14 +59,104 @@ int exynos_dwmci_init(u32 regbase, int bus_width,
int
index)
return 1;
}
+ /* set the clock divisor - clk_div_fsys for mmc */
+ if (exynos5_mmc_set_clk_div(index)) {
+ debug(mmc clock div set failed\n);
+ return -1;
+ }
+
host-name = EXYNOS_NAME;
host-ioaddr = (void *)regbase;
host-buswidth = bus_width;
+#ifdef CONFIG_OF_CONTROL
+ host-clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
+ DWMCI_SET_DRV_CLK(timing[1]) |
+ DWMCI_SET_DIV_RATIO(timing[2]));
+#else
+ if (0 == index)
+ host-clksel_val = DWMMC_MMC0_CLKSEL_VAL;
+ if (2 == index)
+ host-clksel_val = DWMMC_MMC2_CLKSEL_VAL;
+#endif
host-clksel = exynos_dwmci_clksel;
host-dev_index = index;
+ host-mmc_clk =
Re: [U-Boot] [PATCH 6/9] SMDK5250: Enable DWMMC
Hi Simon,
Thanks for the review comments.
Please find the responses below.
Thanks Regards
Amarendra Reddy
On 20 December 2012 07:59, Simon Glass s...@chromium.org wrote:
Hi Amar,
On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
This patch enables DWMMC for SMDK5250.
Support both dt and non-dt versions.
Signed-off-by: Amar amarendra...@samsung.com
---
board/samsung/smdk5250/smdk5250.c | 36
include/configs/exynos5250-dt.h |9 +
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4d24978..7a9c8f6 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -27,6 +27,7 @@
#include netdev.h
#include spi.h
#include asm/arch/cpu.h
+#include asm/arch/dwmmc.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
#include asm/arch/pinmux.h
@@ -192,16 +193,43 @@ int checkboard(void)
#ifdef CONFIG_GENERIC_MMC
int board_mmc_init(bd_t *bis)
{
- int err;
+ int err = 0, ret = 0;
+#ifdef CONFIG_OF_CONTROL
+ /* dwmmc initializattion for available channels */
+ err = exynos_dwmmc_init(gd-fdt_blob);
+ if (err) {
+ debug(dwmmc init failed\n);
+ }
+ ret |= err;
+#else
err = exynos_pinmux_config(PERIPH_ID_SDMMC0,
PINMUX_FLAG_8BIT_MODE);
if (err) {
debug(SDMMC0 not configured\n);
- return err;
}
+ ret |= err;
Perhaps we need an exynos5-dt.c board file instead of using smdk5250? It
seems like you will end up with lots of #ifdefs otherwise.
OK.
- err = s5p_mmc_init(0, 8);
- return err;
+ /*eMMC: dwmmc Channel-0 with 8 bit bus width */
+ err = exynos_dwmmc_init(0, 8);
+ if (err) {
+ debug(dwmmc Channel-0 init failed\n);
Don't need {} here.
OK.
+ }
+ ret |= err;
+
+ err = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
+ if (err) {
+ debug(SDMMC2 not configured\n);
and here
OK.
+ }
+ ret |= err;
+
+ /*SD: dwmmc Channel-2 with 4 bit bus width */
+ err = exynos_dwmmc_init(2, 4);
+ if (err) {
+ debug(dwmmc Channel-2 init failed\n);
+ }
+ ret |= err;
+#endif
+ return ret;
}
#endif
diff --git a/include/configs/exynos5250-dt.h
b/include/configs/exynos5250-dt.h
index 12f555c..3b89e20 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -84,6 +84,8 @@
#define CONFIG_MMC
#define CONFIG_SDHCI
#define CONFIG_S5P_SDHCI
+#define CONFIG_DWMMC
What does this config enable? Is it in a README somewhere?
CONFIG_DWMMC is for enaling DWMMC. It has to be added into README.
+#define CONFIG_EXYNOS_DWMMC
#define CONFIG_BOARD_EARLY_INIT_F
@@ -116,6 +118,13 @@
#define CONFIG_SPL
#define COPY_BL2_FNPTR_ADDR0x02020030
+/* eMMC4.4 SPL */
+#define EMMC44_COPY_BL2_FNPTR_ADDR 0x02020044
+#define EMMC44_END_BOOTOP_FNPTR_ADDR 0x02020048
What are these for?
These are the IROM function pointers used druing SPL boot.
Any how these #defines wii be removed, as a table for all iROM function
pointers will be maintained in spl_boot.c.
+
+#define FSYS1_MMC0_DIV_MASK0xff0f
This seems like something for the SOC headers, not the board header.
FSYS1_MMC0_DIV_MASK will be moved into include/asm/arch/clk.h
+
+
/* specific .lds file */
#define CONFIG_SPL_LDSCRIPT
board/samsung/smdk5250/smdk5250-uboot-spl.lds
#define CONFIG_SPL_TEXT_BASE 0x02023400
--
1.7.0.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command
Hi Wolfgang Denk, On Thu, Dec 20, 2012 at 6:19 PM, Wolfgang Denk w...@denx.de wrote: Dear Jagan Teki, In message CAD6G_RRw=YgbYtkwaZMC=KaS_5Lbfbm+fR-=lv96aoy72w3...@mail.gmail.com you wrote: Apart from this sometimes (very rare) due to the slowness of UART or SPI flash even if we run the sf commands it will not execute the actual code just terminate with showing u-boot prompt, so the user assumes that this command is happen properly. [but actually command is not done] But that would be a different thing - if there are errors without clear error messages, this is a bug that needs fixing. [But I do not see which part of your patch would address such an issue. Am I missing something?] Basically if there is an error while executing these commands, then this print will show an :ERROR based on the return value from spi_flash_erase. of-course there is a verbose print already if spi_flash_erase returns 1 (error case). OK, I agree my patch will show only verbose prints for both in Success and Failure cases. I thought it could be a good progress prints for sf read/write/erase commands as we didn't have these verbose prints before. Do you think these are useful/required messages?, please take my above concerns. Thanks, Jagan. Adding verbose progress messages is a different thing, though. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is much easier to suggest solutions when you know nothing ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command
Dear Jagan Teki, In message cad6g_rqtzzinzcx0halqr-jd4cjm8wyjzzggarz-+dwazjn...@mail.gmail.com you wrote: I thought it could be a good progress prints for sf read/write/erase commands as we didn't have these verbose prints before. Do you think these are useful/required messages?, please take my above concerns. Some people will like such verbocity, others will dislike it. Also, some people will dislike th memory footprint that comes with the added code. So in any case this should be configurable. But most of all: SF is just one storage device out of a much larger list. If we add such a feature, it should be done in common code and in a generic way that all similar devices can use as well. Please see again the other thread, and Simon's response. I think it makes sense to handle these things together, as a common set of patches. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only person who always got his work done by Friday was Robinson Crusoe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc8572ds: Enable bank interleaving to cs0+cs1 for dual-rank DIMMs
The controller interleaving only takes the usable memory mapped to cs0. In the case of bank interleaving not enabled, only half of dual-rank DIMM will be used. For single-rank DIMM bank interleaving will be auto disabled. Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- include/configs/MPC8572DS.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index a62b7d5..d233365 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -735,7 +735,7 @@ #define CONFIG_BAUDRATE115200 #defineCONFIG_EXTRA_ENV_SETTINGS \ -hwconfig=fsl_ddr:ctlr_intlv=bank,ecc=off\0 \ +hwconfig=fsl_ddr:ctlr_intlv=bank,bank_intlv=cs0_cs1,ecc=off\0 \ netdev=eth0\0\ uboot= __stringify(CONFIG_UBOOTPATH) \0\ tftpflash=tftpboot $loadaddr $uboot; \ -- 1.7.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc8544ds: Add USB controller support for MPC8544DS
USB controller in uboot is a required feature for MPC8544DS. Without this support there is no 'usb' command in uboot. Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- include/configs/MPC8544DS.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h index 83b8668..d5f3c5f 100644 --- a/include/configs/MPC8544DS.h +++ b/include/configs/MPC8544DS.h @@ -415,6 +415,18 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_CMD_EXT2 #endif +/* + * USB + */ +#define CONFIG_USB_EHCI + +#ifdef CONFIG_USB_EHCI +#define CONFIG_CMD_USB +#define CONFIG_USB_EHCI_PCI +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET +#define CONFIG_USB_STORAGE +#define CONFIG_PCI_EHCI_DEVICE 0 +#endif #undef CONFIG_WATCHDOG /* watchdog disabled */ -- 1.7.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/12 16:30, Tom Rini wrote: On Tue, Dec 18, 2012 at 07:19:10PM +0100, Marek Vasut wrote: I reduced it, DFU will have to wait, sorry. The following changes since commit ebbf0d20aa85f623c49b7ed3349ebfea450c152d: Prepare v2013.01-rc2 (2012-12-14 14:43:22 -0700) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 4f8dd5920f52462a9a5d794dc310a9a7a49ca89b: cm_t35: use new low level interface for usb ehci (2012-12-17 15:38:15 +0100) Lukasz Dalek (2): pxa25x_udc: Remove usbdescriptors.h h2200: Add USB CDC ethernet support Milind Choudhary (1): usb: Clean up newly allocated device nodes in case of configuration failure Nikita Kiryanov (2): cm-t35: add USB host support cm_t35: use new low level interface for usb ehci Pantelis Antoniou (2): g_dnl: Issue connect/disconnect as appropriate g_dnl: Properly terminate string list. Richard Genoud (1): usb documentation: fix typo Vincent Palatin (1): usb: properly detect empty mass storage media reader Vipin Kumar (1): usbh/ehci: Increase timeout for enumeration board/cm_t35/cm_t35.c | 77 + board/h2200/h2200.c | 11 +++ common/usb.c| 12 common/usb_hub.c| 35 ++- common/usb_storage.c| 10 ++ doc/README.usb |2 +- drivers/usb/gadget/g_dnl.c | 12 +++- drivers/usb/gadget/pxa25x_udc.c |1 - include/configs/cm_t35.h|8 +++- include/configs/h2200.h | 25 + include/usb.h |1 + 11 files changed, 185 insertions(+), 9 deletions(-) The cm_t35 parts don't compile, NAK. cm_t35.c: In function 'ehci_hcd_init': cm_t35.c:522:34: error: 'TWL4030_GPIO_GPIODATADIR1' undeclared (first use in this function) cm_t35.c:522:34: note: each undeclared identifier is reported only once for each function it appears in cm_t35.c:527:34: error: 'TWL4030_GPIO_SETGPIODATAOUT1' undeclared (first use in this function) In the original pull request, there was another patch: twl4030: add gpio register offsets which got dropped somehow... Marek, can you please, fix this? - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ1Af9AAoJEBDE8YO64Efa1vQP/0cG6TEiqzfqqZKyQyi29QRU +0Wa2t/HoyY8/tscN2PyVln3QW6g7Xtf0lAREegoiJMfKiPIgT1raUAyi2HbjACq uSaBCNMJjEgSS4fLl7NTgCuxGWZk5cQTnrRrwUATLmhci3pwZ2CsmEE9jqdtoelk 076CzJSLgPUr3X0/cxmKdw7/CNWMOrfLkLET0t9Lmt2ZsJOhzJ9wOWAHk+xiVeHZ YXVj1DRfBK1YVEd/o/58lt/EZ4mRTVSLR4zfLgGp5VOBj7UcxjIpTYaGhD7KbTCZ W23zHnrjsGp73qQKopgiawjptAkMnGJpHYZdD8mzSx0IzIXXg4UBgHZfH0gRHlaP iTg6KAQCk0BSO6oOntKlNYro9xVzoy/8KIKr8pr3FJM0tuh/gGBK4HmbHHl2IVzs rU1teFvkmKktxTqShlfyEQKJHs4nzefnbsHmzKOzf8DvphnEoKsSjket8+J0dRnk q4xVFWiq+kj6rBLmnHVrZHTmYugZfXO5U+4r9TvgcH8GR8aIKMuxgw9ofD5ejpib SC4DV3NHQczXHNN1YoILt87gpDWUUCtbrGYFZvZJ1hXd5MYb/DXitFNdbHqIouSB /SlgXj8ncHbW6pVwiOdu+P4EclmumD0+pRimIgfZRj1QiEAEaT63d/EvGzDChhWi QtlYLz8b/BJMKgZUzvOg =Nw5X -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
