[U-Boot] ARM Cortext 9 AMP mode support
Hi, I would like to know whether u-boot has support for AMP mode for ARM Cortex A9. If yes can you provide me the details on how to boot multiple OS using u-boot? If not, can I know what changes I need to do in u-boot to boot multiple OS on multiple CPUs of ARM core? Thanks & Regards, Tushar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] USB: Fix EHCI to work with data cache enabled
Dear Marek, After applying these 4 patches I don't see any alignment spew and it detects the mass storage device perfectly though I see a warning "EHCI timed out on TD - token=0x80008c80" consistently in each "usb reset". Thanx & Regards, Puneet On Monday 09 April 2012 08:42 AM, Marek Vasut wrote: Dear Marek Vasut, This patchset reworks the USB core and EHCI-HCD to work with data caches. Marek Vasut (3): USB: Drop ehci_alloc/ehci_free in ehci-hcd USB: Drop cache flush bloat in EHCI-HCD USB: Document the QH and qTD antics in EHCI-HCD Puneet Saxena (1): USB: Align buffers at cacheline common/cmd_usb.c|3 +- common/usb.c| 22 ++-- common/usb_hub.c| 27 ++-- common/usb_storage.c| 59 +- disk/part_dos.c |2 +- drivers/usb/host/ehci-hcd.c | 284 ++- include/scsi.h | 4 +- include/usb.h |4 +- 8 files changed, 155 insertions(+), 250 deletions(-) Cc: Puneet Saxena Puneet, can you please test this stuff? It should fix your cache misalignment issues. Mine are now gone and USB works with caches on too. I'd like to queue this for -next. Best regards, Marek Vasut --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] USB: Fix EHCI to work with data cache enabled
Dear puneets, > Dear Marek, > After applying these 4 patches I don't see any alignment spew and it > detects the > mass storage device perfectly though I see a warning "EHCI timed out on > TD - token=0x80008c80" > consistently in each "usb reset". That's something else (unrelated to this patchset), I saw it in your backlog too. Can you try debuging it on top of these patches? Because these patches fix a lot of other issues, so let's take them as a base for now. Also, did you really test dos partition table and vfat? I had to fix them to work with patches, you change to part_dos.c wasn't enough. > > Thanx & Regards, > Puneet > > On Monday 09 April 2012 08:42 AM, Marek Vasut wrote: > > Dear Marek Vasut, > > > >> This patchset reworks the USB core and EHCI-HCD to work with data > >> caches. > >> > >> Marek Vasut (3): > >>USB: Drop ehci_alloc/ehci_free in ehci-hcd > >>USB: Drop cache flush bloat in EHCI-HCD > >>USB: Document the QH and qTD antics in EHCI-HCD > >> > >> Puneet Saxena (1): > >>USB: Align buffers at cacheline > >> > >> common/cmd_usb.c|3 +- > >> common/usb.c| 22 ++-- > >> common/usb_hub.c| 27 ++-- > >> common/usb_storage.c| 59 +- > >> disk/part_dos.c |2 +- > >> drivers/usb/host/ehci-hcd.c | 284 > >> > >> ++- include/scsi.h > >> | > >> > >>4 +- > >> > >> include/usb.h |4 +- > >> 8 files changed, 155 insertions(+), 250 deletions(-) > >> > >> Cc: Puneet Saxena > > > > Puneet, can you please test this stuff? It should fix your cache > > misalignment issues. Mine are now gone and USB works with caches on too. > > > > I'd like to queue this for -next. > > > > Best regards, > > Marek Vasut > > --- > This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy > all copies of the original message. > --- > Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)
Dear Simon, On 15.10.2011 17:48, Simon Glass wrote: This new option allows U-Boot to embed a binary device tree into its image to allow run-time control of peripherals. This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel. The device tree compiler output should be placed in the $(obj) rooted tree. Since $(OBJCOPY) insists on adding the path to the generated symbol names, to ensure consistency it should be invoked from the directory where the .dtb file is located and given the input file name without the path. This commit contains my entry for the ugliest Makefile / shell interaction competition. Signed-off-by: Simon Glass --- ... diff --git a/doc/README.fdt-control b/doc/README.fdt-control new file mode 100644 index 000..3f8bb5a --- /dev/null +++ b/doc/README.fdt-control ... Reading your README.fdt-control and browsing the source code a little for the CONFIG_OF_* options I found two questions. Sorry if I haven't read carefully enough ;) +Device Tree Control in U-Boot += + +This feature provides for run-time configuration of U-Boot via a flat +device tree (fdt). U-Boot configuration has traditionally been done +using CONFIG options in the board config file. This feature aims to +make it possible for a single U-Boot binary to support multiple boards, +with the exact configuration of each board controlled by a flat device +tree (fdt). This is the approach recently taken by the ARM Linux kernel +and has been used by PowerPC for some time. + +The fdt is a convenient vehicle for implementing run-time configuration +for three reasons. Firstly it is easy to use, being a simple text file. +It is extensible since it consists of nodes and properties in a nice +hierarchical format. + +Finally, there is already excellent infrastructure for the fdt: a +compiler checks the text file and converts it to a compact binary +format, and a library is already available in U-Boot (libfdt) for +handling this format. + +The dts directory contains a Makefile for building the device tree blob +and embedding it in your U-Boot image. This is useful since it allows +U-Boot to configure itself according to what it finds there. If you have +a number of similar boards with different peripherals, you can describe +the features of each board in the device tree file, and have a single +generic source base. + +To enable this feature, add CONFIG_OF_CONTROL to your board config file. + + ... +Where do I get an fdt file for my board? + + +You may find that the Linux kernel has a suitable file. Look in the +kernel source in arch//boot/dts. + +If not you might find other boards with suitable files that you can +modify to your needs. Look in the board directories for files with a +.dts extension. + +Failing that, you could write one from scratch yourself! + + +Configuration +- + +Use: + +#define CONFIG_DEFAULT_DEVICE_TREE "" + +to set the filename of the device tree source. Then put your device tree +file into + + board//dts/.dts + +This should include your CPU or SOC's device tree file, placed in +arch//dts, and then make any adjustments required. The name of this +is CONFIG_ARCH_DEVICE_TREE.dts. + +If CONFIG_OF_EMBED is defined, then it will be picked up and built into +the U-Boot image (including u-boot.bin). + +If CONFIG_OF_SEPARATE is defined, then it will be built and placed in +a u-boot.dtb file alongside u-boot.bin. A common approach is then to +join the two: + + cat u-boot.bin u-boot.dtb>image.bin + +and then flash image.bin onto your board. 1. Above, the README.fdt-control talks about "make it possible for a single U-Boot binary to support multiple boards". Now, if I understood correctly, the 'Configuration' section above describes how to include/append *one* dtb. But wouldn't we need to include *multiple* dtbs to support multiple boards? 2. The section 'Where do I get an fdt file for my board' talks about taking the fdt from the Linux kernel. This is fine. Is U-Boot able to pass the included/appended (OF_EMBED/OF_SEPARATE) dtb to the Linux kernel, then, too? Or is the included/appended dtb only used for the U-Boot configuration? And the one passed to the Linux kernel has to be taken from anywhere else, additionally? Many thanks and best regards Dirk P.S.: Any idea about http://lists.denx.de/pipermail/u-boot/2012-March/120916.html ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/3] mmc: support sdhci instead of s5p_mmc
This patchset is supported the sdhci controller for Samsung-SoC. In mmc driver, already implemented the generic sdhci. There is no reason that didn't use sdhci.c. So, use the sdhci instead of s5p_mmc. Changelog-v3: - Add the quirks for broken R1b response. - Add the timeout to prevent infinite loop. Changelog-v2: - removed the s5p_mmc.c - based-on u-boot-samsung repository. Jaehoon Chung (3): mmc: sdhci: add the quirk for broken R1b response mmc: use sdhci.c intead of s5p_mmc.c ARM: SAMSUNG: support sdhci controller arch/arm/include/asm/arch-exynos/mmc.h | 93 +++--- arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++--- drivers/mmc/Makefile|2 +- drivers/mmc/s5p_mmc.c | 490 --- drivers/mmc/s5p_sdhci.c | 98 ++ drivers/mmc/sdhci.c | 24 ++ include/configs/origen.h|3 +- include/configs/s5p_goni.h |3 +- include/configs/s5pc210_universal.h |3 +- include/configs/smdk5250.h |3 +- include/configs/smdkv310.h |3 +- include/configs/trats.h |3 +- include/sdhci.h |7 + 13 files changed, 236 insertions(+), 589 deletions(-) delete mode 100644 drivers/mmc/s5p_mmc.c create mode 100644 drivers/mmc/s5p_sdhci.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] mmc: sdhci: add the quirk for broken R1b response
When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
but in while(), didn't check that flag.
So sdhci controller didn't work fine.
CMD6 didn't always complete.
So add the quirks for broken r1b response
and add the timeout value to prevent the infinite loop.
Signed-off-by: Jaehoon Chung
Signed-off-by: Kyungmin Park
---
drivers/mmc/sdhci.c | 12
include/sdhci.h |1 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index fc904b5..4de19e8 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -128,6 +128,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
int trans_bytes = 0, is_aligned = 1;
u32 mask, flags, mode;
unsigned int timeout, start_addr = 0;
+ unsigned int retry = 1000;
/* Wait max 10 ms */
timeout = 10;
@@ -210,8 +211,19 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
+ if (retry-- == 0)
+ break;
} while ((stat & mask) != mask);
+ if (retry == 0) {
+ if (host->quirks == SDHCI_QUIRK_BROKEN_R1B)
+ return 0;
+ else {
+ printf("Timeout for stauts update!\n");
+ return TIMEOUT;
+ }
+ }
+
if ((stat & (SDHCI_INT_ERROR | mask)) == mask) {
sdhci_cmd_done(host, cmd);
sdhci_writel(host, mask, SDHCI_INT_STATUS);
diff --git a/include/sdhci.h b/include/sdhci.h
index 800f9d9..a2415ba 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -216,6 +216,7 @@
*/
#define SDHCI_QUIRK_32BIT_DMA_ADDR (1 << 0)
#define SDHCI_QUIRK_REG32_RW (1 << 1)
+#define SDHCI_QUIRK_BROKEN_R1B (1 << 2)
/* to make gcc happy */
struct sdhci_host;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] ARM: SAMSUNG: support sdhci controller
To support sdhci controller, remove the CONFIG_S5P_MMC.. Instead, use the CONFIG_S5P_SDHCI/CONFIG_SDHCI. Signed-off-by: Jaehoon Chung Signed-off-by: Kyungmin Park --- include/configs/origen.h|3 ++- include/configs/s5p_goni.h |3 ++- include/configs/s5pc210_universal.h |3 ++- include/configs/smdk5250.h |3 ++- include/configs/smdkv310.h |3 ++- include/configs/trats.h |3 ++- 6 files changed, 12 insertions(+), 6 deletions(-) diff --git a/include/configs/origen.h b/include/configs/origen.h index 8ede825..ea8066f 100644 --- a/include/configs/origen.h +++ b/include/configs/origen.h @@ -71,7 +71,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 56b5547..f659699 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -65,7 +65,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/s5pc210_universal.h b/include/configs/s5pc210_universal.h index 8286680..33cbaf9 100644 --- a/include/configs/s5pc210_universal.h +++ b/include/configs/s5pc210_universal.h @@ -68,7 +68,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 9659f9e..0f63040 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -78,7 +78,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC #define CONFIG_MMC -#define CONFIG_S5P_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h index 93c25da..077f0e0 100644 --- a/include/configs/smdkv310.h +++ b/include/configs/smdkv310.h @@ -70,7 +70,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/trats.h b/include/configs/trats.h index 10f11d9..71b9393 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -74,7 +74,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC #define CONFIG_MMC -#define CONFIG_S5P_MMC +#define CONFIG_S5P_SDHCI +#define CONFIG_SDHCI /* PWM */ #define CONFIG_PWM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] mmc: use sdhci.c intead of s5p_mmc.c
In driver mmc, generic sdhci code is implemented.
s5p_mmc file is dupulicated.
we are good that use the generic sdhci.
This patch supported the sdhci for Samsung-SoC.
Signed-off-by: Jaehoon Chung
Signed-off-by: Kyungmin Park
---
arch/arm/include/asm/arch-exynos/mmc.h | 93 +++---
arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++---
drivers/mmc/Makefile|2 +-
drivers/mmc/s5p_mmc.c | 490 ---
drivers/mmc/s5p_sdhci.c | 98 ++
drivers/mmc/sdhci.c | 12 +
include/sdhci.h |6 +
7 files changed, 211 insertions(+), 583 deletions(-)
delete mode 100644 drivers/mmc/s5p_mmc.c
create mode 100644 drivers/mmc/s5p_sdhci.c
diff --git a/arch/arm/include/asm/arch-exynos/mmc.h
b/arch/arm/include/asm/arch-exynos/mmc.h
index 30f82b8..0f701c9 100644
--- a/arch/arm/include/asm/arch-exynos/mmc.h
+++ b/arch/arm/include/asm/arch-exynos/mmc.h
@@ -21,53 +21,54 @@
#ifndef __ASM_ARCH_MMC_H_
#define __ASM_ARCH_MMC_H_
-#ifndef __ASSEMBLY__
-struct s5p_mmc {
- unsigned intsysad;
- unsigned short blksize;
- unsigned short blkcnt;
- unsigned intargument;
- unsigned short trnmod;
- unsigned short cmdreg;
- unsigned intrspreg0;
- unsigned intrspreg1;
- unsigned intrspreg2;
- unsigned intrspreg3;
- unsigned intbdata;
- unsigned intprnsts;
- unsigned char hostctl;
- unsigned char pwrcon;
- unsigned char blkgap;
- unsigned char wakcon;
- unsigned short clkcon;
- unsigned char timeoutcon;
- unsigned char swrst;
- unsigned intnorintsts; /* errintsts */
- unsigned intnorintstsen;/* errintstsen */
- unsigned intnorintsigen;/* errintsigen */
- unsigned short acmd12errsts;
- unsigned char res1[2];
- unsigned intcapareg;
- unsigned char res2[4];
- unsigned intmaxcurr;
- unsigned char res3[0x34];
- unsigned intcontrol2;
- unsigned intcontrol3;
- unsigned char res4[4];
- unsigned intcontrol4;
- unsigned char res5[0x6e];
- unsigned short hcver;
- unsigned char res6[0xFF00];
-};
+#define SDHCI_CONTROL2 0x80
+#define SDHCI_CONTROL3 0x84
+#define SDHCI_CONTROL4 0x8C
-struct mmc_host {
- struct s5p_mmc *reg;
- unsigned int version; /* SDHCI spec. version */
- unsigned int clock; /* Current clock (MHz) */
- int dev_index;
-};
+#define SDHCI_CTRL2_ENSTAASYNCCLR (1 << 31)
+#define SDHCI_CTRL2_ENCMDCNFMSK(1 << 30)
+#define SDHCI_CTRL2_CDINVRXD3 (1 << 29)
+#define SDHCI_CTRL2_SLCARDOUT (1 << 28)
-int s5p_mmc_init(int dev_index, int bus_width);
+#define SDHCI_CTRL2_FLTCLKSEL_MASK (0xf << 24)
+#define SDHCI_CTRL2_FLTCLKSEL_SHIFT(24)
+#define SDHCI_CTRL2_FLTCLKSEL(_x) ((_x) << 24)
-#endif /* __ASSEMBLY__ */
+#define SDHCI_CTRL2_LVLDAT_MASK(0xff << 16)
+#define SDHCI_CTRL2_LVLDAT_SHIFT (16)
+#define SDHCI_CTRL2_LVLDAT(_x) ((_x) << 16)
+
+#define SDHCI_CTRL2_ENFBCLKTX (1 << 15)
+#define SDHCI_CTRL2_ENFBCLKRX (1 << 14)
+#define SDHCI_CTRL2_SDCDSEL(1 << 13)
+#define SDHCI_CTRL2_SDSIGPC(1 << 12)
+#define SDHCI_CTRL2_ENBUSYCHKTXSTART (1 << 11)
+
+#define SDHCI_CTRL2_DFCNT_MASK(_x) ((_x) << 9)
+#define SDHCI_CTRL2_DFCNT_SHIFT(9)
+
+#define SDHCI_CTRL2_ENCLKOUTHOLD (1 << 8)
+#define SDHCI_CTRL2_RWAITMODE (1 << 7)
+#define SDHCI_CTRL2_DISBUFRD (1 << 6)
+#define SDHCI_CTRL2_SELBASECLK_MASK(_x)((_x) << 4)
+#define SDHCI_CTRL2_SELBASECLK_SHIFT (4)
+#define SDHCI_CTRL2_PWRSYNC(1 << 3)
+#define SDHCI_CTRL2_ENCLKOUTMSKCON (1 << 1)
+#define SDHCI_CTRL2_HWINITFIN (1 << 0)
+
+#define SDHCI_CTRL3_FCSEL3 (1 << 31)
+#define SDHCI_CTRL3_FCSEL2 (1 << 23)
+#define SDHCI_CTRL3_FCSEL1 (1 << 15)
+#define SDHCI_CTRL3_FCSEL0 (1 << 7)
+
+#define SDHCI_CTRL4_DRIVE_MASK(_x) ((_x) << 16)
+#define SDHCI_CTRL4_DRIVE_SHIFT(16)
+
+int s5p_sdhci_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks);
+
+static inline unsigned int s5p_mmc_init(int index, int bus_width)
+{
+ unsigned int base = samsung_get_base_mmc() + (0x1 * index);
+ return s5p_sdhci_init(base, 5200, 40, index);
+}
#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
index adef4ee..0f701c9 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
@@ -21,53 +21,54 @@
#ifndef __ASM_ARCH_MMC_H_
#define __ASM_ARCH_MMC_H_
-#ifndef __ASSEMBLY__
-struct s5p_mmc {
- unsigned intsysad;
- unsigned short blksize;
-
Re: [U-Boot] [PATCH v4] AT91SAM9*: Change kernel address in dataflash to match u-boot's size
Dear Andreas, In message <4f82835f.2030...@googlemail.com> you wrote: > > > Where are these odd sizes like > > > >> #define CONFIG_ENV_SIZE 0x4200 > > > > coming from? Has a size of 0x4200 any special maning on these > > systems? > > please read Ulfs mail: > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/123862/focus=125897 Thanks for the pointer. > I think it is OK to apply this patch. I did not intend to object against this patch; I just wonered about the odd numbers, > I think another point is that these Atmel devices became less important > than before in U-Boot (I see not really much users here even though a > lot of people use it): > a) a lot of users favor the at91bootstrap SPL to boot linux (no need > for u-boot) This could probably be changed if they were converted to using U-Boot's SPL mechanism instead - but then, I also realize that there is only very low interest for them. > b) they have well-hung cores Indeed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "If it ain't broke, don't fix it." - Bert Lantz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
On 09.04.2012 08:45, Marek Vasut wrote:
Align the FAT FS buffers so DMA on various systems can directly pick them.
Just fyi:
http://lists.denx.de/pipermail/u-boot/2012-March/119311.html
http://lists.denx.de/pipermail/u-boot/2012-March/119309.html
Best regards
Dirk
Signed-off-by: Marek Vasut
---
fs/fat/fat.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 1f95eb4..d709e59 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/*
* Convert a string to lowercase.
@@ -62,7 +63,7 @@ static int disk_read(__u32 block, __u32 nr_blocks, void *buf)
int fat_register_device (block_dev_desc_t * dev_desc, int part_no)
{
- unsigned char buffer[dev_desc->blksz];
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
/* First close any currently found FAT filesystem */
cur_dev = NULL;
@@ -293,9 +294,10 @@ get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
return -1;
}
if (size % mydata->sect_size) {
- __u8 tmpbuf[mydata->sect_size];
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, tmpbuf,
mydata->sect_size);
idx = size / mydata->sect_size;
+
ret = disk_read(startsect + idx, 1, tmpbuf);
if (ret != 1) {
debug("Error reading data (got %d)\n", ret);
@@ -709,7 +711,7 @@ read_bootsectandvi (boot_sector *bs, volume_info *volinfo,
int *fatsize)
return -1;
}
- block = malloc(cur_dev->blksz);
+ block = memalign(ARCH_DMA_MINALIGN, cur_dev->blksz);
if (block == NULL) {
debug("Error: allocating block\n");
return -1;
@@ -765,9 +767,6 @@ exit:
return ret;
}
-__attribute__ ((__aligned__ (__alignof__ (dir_entry
-__u8 do_fat_read_block[MAX_CLUSTSIZE];
-
long
do_fat_read (const char *filename, void *buffer, unsigned long maxsize,
int dols)
@@ -788,6 +787,7 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
__u32 root_cluster = 0;
int rootdir_size = 0;
int j;
+ uint8_t do_fat_read_block[MAX_CLUSTSIZE] __attribute__((aligned(32)));
if (read_bootsectandvi(&bs,&volinfo,&mydata->fatsize)) {
debug("Error: reading boot sector\n");
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
Dear Dirk Behme, > On 09.04.2012 08:45, Marek Vasut wrote: > > Align the FAT FS buffers so DMA on various systems can directly pick > > them. > > Just fyi: > > http://lists.denx.de/pipermail/u-boot/2012-March/119311.html > > http://lists.denx.de/pipermail/u-boot/2012-March/119309.html Heh, nice! :-) I've been so dug up in debugging the USB cache issues I didn't bother to look around the list for previous efforts. So obviously, apply Eric's patch! :-) > Best regards > > Dirk > Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SMDK5250: fix compiler warning
On 4 April 2012 13:28, Minkyu Kang wrote: > this patch fixed following warning. > tzpc_init.c: In function 'tzpc_init': > tzpc_init.c:35: warning: assignment from incompatible pointer type > > Signed-off-by: Minkyu Kang > Cc: Chander Kashyap > --- > board/samsung/smdk5250/tzpc_init.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > applied to u-boot-samsung. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] USB:gadget:designware USB OTG implementation
Dear Marek,
[...]
+static void dwc_otg_read_packet(struct dwc_ep *ep, u16 bytes)
+{
+ u32 i;
+ int word_count = (bytes + 3) / 4;
+ u32 *fifo = dev_if->data_fifo[0];
+ u32 *data_buff = (u32 *) ep->xfer_buff;
+ u32 unaligned;
+ /*
+ * This requires reading data from the FIFO into a u32 temp buffer,
+ * then moving it into the data buffer.
+ */
+ if ((bytes< 4)&& (bytes> 0)) {
+ unaligned = readl(fifo);
+ memcpy(data_buff,&unaligned, bytes);
+ } else {
+ for (i = 0; i< word_count; i++, data_buff++)
+ *data_buff = readl(fifo);
Thinking of this, will this really handle unaligned access of length for example
5 ?
If data_buff is unaligned, there will be a problem!
+ }
+}
+
+/* Handle RX transaction on non-ISO endpoint. */
+static void dw_udc_epn_rx(struct dwc_ep *ep, int bcnt)
+{
+ struct urb *urb;
+ struct usb_endpoint_instance *endpoint = dw_find_ep(ep->num);
+
+ if (endpoint) {
if (!endpoint)
return;
... code ...
Ok.
+ urb = endpoint->rcv_urb;
+
+ if (urb) {
+ ep->xfer_buff = urb->buffer + urb->actual_length;
+ dwc_otg_read_packet(ep, bcnt);
+ usbd_rcv_complete(endpoint, bcnt, 0);
+ }
+ }
+}
[...]
+ /* program pkt count */
+ temp = ep->xfer_len;
+ temp |= (1<< PKTCNT_SHIFT);
+ writel(temp,&in_ep_regs->dieptsiz);
+
+ /* enable EP*/
missing space before ending comment
Ok, 'll correct.
+ setbits_le32(&in_ep_regs->diepctl, EPENA | CNAK);
+
+ /* clear TX Fifo Empty intr*/
+ writel(NPTXFEMPTY,&core_global_regs->gintsts);
+
+ setbits_le32(&core_global_regs->gintmsk, NPTXFEMPTY);
+
+ start = get_timer(0);
+ while (!(readl(&core_global_regs->gintsts)& NPTXFEMPTY)) {
+ if (get_timer(start)> timeout) {
+ printf("%s: NPTXFEMPTY: TimeOUT\n", __func__);
+ WATCHDOG_RESET();
+ }
+ }
+
+ /* write to fifo */
+ if ((ep->xfer_len< 4)&& (ep->xfer_len> 0)) {
+ memcpy(&unaligned, data_buff, ep->xfer_len);
+ *fifo = unaligned;
+ } else {
+ for (i = 0; i< dword_count; i++, data_buff++)
+ *fifo = *data_buff;
DTTO, will this handle unaligned xfer of size> 4 properly ?
Again, this part needs to be made more generic. I'll amend it in V3.
+ }
+
+ writel(NPTXFEMPTY,&core_global_regs->gintsts);
+
[...]
+/* This function returns pointer to out ep struct with number num */
+static struct dwc_ep *get_out_ep(u32 num)
+{
+ u32 i;
+ int num_out_eps = MAX_EPS_CHANNELS;
+ struct dwc_pcd *pcd =&dev_if->pcd;
+
+ if (num == 0)
+ return&pcd->ep0;
+
+ for (i = 0; i< num_out_eps; ++i) {
i++ ... ++i has no meaning here (not even a compiler hint).
Ok, 'll amend
+ if (pcd->out_ep[i].num == num)
+ return&pcd->out_ep[i];
+ }
+
+ return 0;
+}
+
[...]
+ * to the destination buffer
+ */
Otherwise, I think you did a pretty decent job, one more round and I'm queueing
this ;-)
.
:)
Sorry for my delayed response.
Best Regards
Amit Virdi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] USB:gadget:designware USB OTG implementation
Dear Amit Virdi,
> Dear Marek,
>
> [...]
>
> >> +static void dwc_otg_read_packet(struct dwc_ep *ep, u16 bytes)
> >> +{
> >> + u32 i;
> >> + int word_count = (bytes + 3) / 4;
> >> + u32 *fifo = dev_if->data_fifo[0];
> >> + u32 *data_buff = (u32 *) ep->xfer_buff;
> >> + u32 unaligned;
> >> + /*
> >> + * This requires reading data from the FIFO into a u32 temp
> >> buffer, + * then moving it into the data buffer.
> >> + */
> >> + if ((bytes< 4)&& (bytes> 0)) {
> >> + unaligned = readl(fifo);
> >> + memcpy(data_buff,&unaligned, bytes);
> >> + } else {
> >> + for (i = 0; i< word_count; i++, data_buff++)
> >> + *data_buff = readl(fifo);
> >
> > Thinking of this, will this really handle unaligned access of length for
> > example 5 ?
>
> If data_buff is unaligned, there will be a problem!
>
> >> + }
> >> +}
> >> +
> >> +/* Handle RX transaction on non-ISO endpoint. */
> >> +static void dw_udc_epn_rx(struct dwc_ep *ep, int bcnt)
> >> +{
> >> + struct urb *urb;
> >> + struct usb_endpoint_instance *endpoint = dw_find_ep(ep->num);
> >> +
> >> + if (endpoint) {
> >
> > if (!endpoint)
> >
> > return;
> >
> > ... code ...
>
> Ok.
>
> >> + urb = endpoint->rcv_urb;
> >> +
> >> + if (urb) {
> >> + ep->xfer_buff = urb->buffer + urb->actual_length;
> >> + dwc_otg_read_packet(ep, bcnt);
> >> + usbd_rcv_complete(endpoint, bcnt, 0);
> >> + }
> >> + }
> >> +}
>
> [...]
>
> >> + /* program pkt count */
> >> + temp = ep->xfer_len;
> >> + temp |= (1<< PKTCNT_SHIFT);
> >> + writel(temp,&in_ep_regs->dieptsiz);
> >> +
> >> + /* enable EP*/
> >
> > missing space before ending comment
>
> Ok, 'll correct.
>
> >> + setbits_le32(&in_ep_regs->diepctl, EPENA | CNAK);
> >> +
> >> + /* clear TX Fifo Empty intr*/
> >> + writel(NPTXFEMPTY,&core_global_regs->gintsts);
> >> +
> >> + setbits_le32(&core_global_regs->gintmsk, NPTXFEMPTY);
> >> +
> >> + start = get_timer(0);
> >> + while (!(readl(&core_global_regs->gintsts)& NPTXFEMPTY)) {
> >> + if (get_timer(start)> timeout) {
> >> + printf("%s: NPTXFEMPTY: TimeOUT\n", __func__);
> >> + WATCHDOG_RESET();
> >> + }
> >> + }
> >> +
> >> + /* write to fifo */
> >> + if ((ep->xfer_len< 4)&& (ep->xfer_len> 0)) {
> >> + memcpy(&unaligned, data_buff, ep->xfer_len);
> >> + *fifo = unaligned;
> >> + } else {
> >> + for (i = 0; i< dword_count; i++, data_buff++)
> >> + *fifo = *data_buff;
> >
> > DTTO, will this handle unaligned xfer of size> 4 properly ?
>
> Again, this part needs to be made more generic. I'll amend it in V3.
>
> >> + }
> >> +
> >> + writel(NPTXFEMPTY,&core_global_regs->gintsts);
> >> +
>
> [...]
>
> >> +/* This function returns pointer to out ep struct with number num */
> >> +static struct dwc_ep *get_out_ep(u32 num)
> >> +{
> >> + u32 i;
> >> + int num_out_eps = MAX_EPS_CHANNELS;
> >> + struct dwc_pcd *pcd =&dev_if->pcd;
> >> +
> >> + if (num == 0)
> >> + return&pcd->ep0;
> >> +
> >> + for (i = 0; i< num_out_eps; ++i) {
> >
> > i++ ... ++i has no meaning here (not even a compiler hint).
>
> Ok, 'll amend
>
> >> + if (pcd->out_ep[i].num == num)
> >> + return&pcd->out_ep[i];
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
>
> [...]
>
> >> + * to the destination buffer
> >> + */
> >
> > Otherwise, I think you did a pretty decent job, one more round and I'm
> > queueing this ;-)
> >
> > .
> :
> :)
>
> Sorry for my delayed response.
Don't worry about it :)
>
> Best Regards
> Amit Virdi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM Cortex 9 AMP mode support
Hi, I would like to know whether u-boot has support for AMP mode for ARM Cortex A9. If yes can you provide me the details on how to boot multiple OS using u-boot? If not, can I know what changes I need to do in u-boot to boot multiple OS on multiple CPUs of ARM core? Thanks & Regards, Tushar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] mmc: use sdhci.c intead of s5p_mmc.c
On 04/09/2012 05:49 PM, Lei Wen wrote:
> Hi Jaehoon,
>
>> -Original Message-
>> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>> Sent: Monday, April 09, 2012 3:58 PM
>> To: u-boot@lists.denx.de; Andy Fleming; mk7.k...@samsung.com; Kyungmin Park;
>> Lei Wen
>> Subject: [PATCH v3 2/3] mmc: use sdhci.c intead of s5p_mmc.c
>>
>> In driver mmc, generic sdhci code is implemented.
>> s5p_mmc file is dupulicated.
>> we are good that use the generic sdhci.
>> This patch supported the sdhci for Samsung-SoC.
>>
>> Signed-off-by: Jaehoon Chung
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/include/asm/arch-exynos/mmc.h | 93 +++---
>> arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++---
>> drivers/mmc/Makefile|2 +-
>> drivers/mmc/s5p_mmc.c | 490
>> ---
>> drivers/mmc/s5p_sdhci.c | 98 ++
>> drivers/mmc/sdhci.c | 12 +
>> include/sdhci.h |6 +
>
>
> I think you'd better to separate the sdhci code change with other codes
> change.
> So that others could easily cherry pick your updated sdhci patches.
Ok..i will re-work and resend the patches.
Best Regards,
Jaehoon Chung
>
> Thanks,
> Lei
>
>> 7 files changed, 211 insertions(+), 583 deletions(-)
>> delete mode 100644 drivers/mmc/s5p_mmc.c
>> create mode 100644 drivers/mmc/s5p_sdhci.c
>>
>> diff --git a/arch/arm/include/asm/arch-exynos/mmc.h
>> b/arch/arm/include/asm/arch-exynos/mmc.h
>> index 30f82b8..0f701c9 100644
>> --- a/arch/arm/include/asm/arch-exynos/mmc.h
>> +++ b/arch/arm/include/asm/arch-exynos/mmc.h
>> @@ -21,53 +21,54 @@
>> #ifndef __ASM_ARCH_MMC_H_
>> #define __ASM_ARCH_MMC_H_
>>
>> -#ifndef __ASSEMBLY__
>> -struct s5p_mmc {
>> - unsigned intsysad;
>> - unsigned short blksize;
>> - unsigned short blkcnt;
>> - unsigned intargument;
>> - unsigned short trnmod;
>> - unsigned short cmdreg;
>> - unsigned intrspreg0;
>> - unsigned intrspreg1;
>> - unsigned intrspreg2;
>> - unsigned intrspreg3;
>> - unsigned intbdata;
>> - unsigned intprnsts;
>> - unsigned char hostctl;
>> - unsigned char pwrcon;
>> - unsigned char blkgap;
>> - unsigned char wakcon;
>> - unsigned short clkcon;
>> - unsigned char timeoutcon;
>> - unsigned char swrst;
>> - unsigned intnorintsts; /* errintsts */
>> - unsigned intnorintstsen;/* errintstsen */
>> - unsigned intnorintsigen;/* errintsigen */
>> - unsigned short acmd12errsts;
>> - unsigned char res1[2];
>> - unsigned intcapareg;
>> - unsigned char res2[4];
>> - unsigned intmaxcurr;
>> - unsigned char res3[0x34];
>> - unsigned intcontrol2;
>> - unsigned intcontrol3;
>> - unsigned char res4[4];
>> - unsigned intcontrol4;
>> - unsigned char res5[0x6e];
>> - unsigned short hcver;
>> - unsigned char res6[0xFF00];
>> -};
>> +#define SDHCI_CONTROL2 0x80
>> +#define SDHCI_CONTROL3 0x84
>> +#define SDHCI_CONTROL4 0x8C
>>
>> -struct mmc_host {
>> - struct s5p_mmc *reg;
>> - unsigned int version; /* SDHCI spec. version */
>> - unsigned int clock; /* Current clock (MHz) */
>> - int dev_index;
>> -};
>> +#define SDHCI_CTRL2_ENSTAASYNCCLR(1 << 31)
>> +#define SDHCI_CTRL2_ENCMDCNFMSK (1 << 30)
>> +#define SDHCI_CTRL2_CDINVRXD3(1 << 29)
>> +#define SDHCI_CTRL2_SLCARDOUT(1 << 28)
>>
>> -int s5p_mmc_init(int dev_index, int bus_width);
>> +#define SDHCI_CTRL2_FLTCLKSEL_MASK (0xf << 24)
>> +#define SDHCI_CTRL2_FLTCLKSEL_SHIFT (24)
>> +#define SDHCI_CTRL2_FLTCLKSEL(_x)((_x) << 24)
>>
>> -#endif /* __ASSEMBLY__ */
>> +#define SDHCI_CTRL2_LVLDAT_MASK (0xff << 16)
>> +#define SDHCI_CTRL2_LVLDAT_SHIFT (16)
>> +#define SDHCI_CTRL2_LVLDAT(_x) ((_x) << 16)
>> +
>> +#define SDHCI_CTRL2_ENFBCLKTX(1 << 15)
>> +#define SDHCI_CTRL2_ENFBCLKRX(1 << 14)
>> +#define SDHCI_CTRL2_SDCDSEL (1 << 13)
>> +#define SDHCI_CTRL2_SDSIGPC (1 << 12)
>> +#define SDHCI_CTRL2_ENBUSYCHKTXSTART (1 << 11)
>> +
>> +#define SDHCI_CTRL2_DFCNT_MASK(_x) ((_x) << 9)
>> +#define SDHCI_CTRL2_DFCNT_SHIFT (9)
>> +
>> +#define SDHCI_CTRL2_ENCLKOUTHOLD (1 << 8)
>> +#define SDHCI_CTRL2_RWAITMODE(1 << 7)
>> +#define SDHCI_CTRL2_DISBUFRD (1 << 6)
>> +#define SDHCI_CTRL2_SELBASECLK_MASK(_x) ((_x) << 4)
>> +#define SDHCI_CTRL2_SELBASECLK_SHIFT (4)
>> +#define SDHCI_CTRL2_PWRSYNC (1 << 3)
>> +#define SDHCI_CTRL2_ENCLKOUTMSKCON (1 << 1)
>> +#define SDHCI_CTRL2_HWINITFIN(1 << 0)
>> +
>> +#define SDHCI_CTRL3_FCSEL3 (1 << 31)
>> +#define SDHCI_CTRL3_FCSEL2 (1 << 23)
>> +#define SDHCI_CTRL3_FCSE
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
On 09.04.2012 10:26, Marek Vasut wrote: Dear Dirk Behme, On 09.04.2012 08:45, Marek Vasut wrote: Align the FAT FS buffers so DMA on various systems can directly pick them. Just fyi: http://lists.denx.de/pipermail/u-boot/2012-March/119311.html http://lists.denx.de/pipermail/u-boot/2012-March/119309.html Heh, nice! :-) I've been so dug up in debugging the USB cache issues I didn't bother to look around the list for previous efforts. So obviously, apply Eric's patch! :-) Do you need this for 2012.04? Or is the stuff which needs this scheduled for -next? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
Dear Dirk Behme, > On 09.04.2012 10:26, Marek Vasut wrote: > > Dear Dirk Behme, > > > >> On 09.04.2012 08:45, Marek Vasut wrote: > >>> Align the FAT FS buffers so DMA on various systems can directly pick > >>> them. > >> > >> Just fyi: > >> > >> http://lists.denx.de/pipermail/u-boot/2012-March/119311.html > >> > >> http://lists.denx.de/pipermail/u-boot/2012-March/119309.html > > > > Heh, nice! :-) > > > > I've been so dug up in debugging the USB cache issues I didn't bother to > > look around the list for previous efforts. So obviously, apply Eric's > > patch! :-) > > Do you need this for 2012.04? Or is the stuff which needs this > scheduled for -next? Definitelly -next, we're on -RC1 now, close to RC2. > > Best regards > > Dirk Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] i.MX28: Allow coexistence of PIO and DMA mode for SD/MMC
On 05/04/2012 15:30, Marek Vasut wrote: > This SD DMA function of i.MX28 is still apparently too experimental to be > enabled by default in 2012.04 release. Enable this feature only if the user > plans to tinker with DCache or explicitly enables it. > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > Cc: Wolfgang Denk > Cc: Detlev Zundel > Cc: Fabio Estevam > --- Applied to u-boot-imx (fix), thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM926EJS: Make asm routines volatile in cache ops
On 06/04/2012 15:25, Marek Vasut wrote:
> We certainly don't want the compiler to reorganise the code for dcache
> flushing.
>
> Signed-off-by: Marek Vasut
> Cc: Stefano Babic
> Cc: Albert ARIBAUD
> ---
> arch/arm/cpu/arm926ejs/cache.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
> index 5b23e3a..0b36294 100644
> --- a/arch/arm/cpu/arm926ejs/cache.c
> +++ b/arch/arm/cpu/arm926ejs/cache.c
> @@ -82,7 +82,7 @@ void flush_dcache_range(unsigned long start, unsigned long
> stop)
> start += CONFIG_SYS_CACHELINE_SIZE;
> }
>
> - asm("mcr p15, 0, %0, c7, c10, 4\n"::"r"(0));
> + asm volatile("mcr p15, 0, %0, c7, c10, 4\n"::"r"(0));
> }
>
> void flush_cache(unsigned long start, unsigned long size)
Acked-by: Stefano Babic
Thanks to point this issue - the same happens on MX3x. I will send a
patch (ptch for cache in ARM1136 is already merged).
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX35: mx35pdk: wrong board revision
The board revision is detected accessing to the pmic,
that is not available before relocation (I2C).
This generates the following error:
CPU: Freescale i.MX35 rev 2.0 at 532 MHz.
Reset cause: WDOG
= 7 is invalid. Should be less than 0
Board: MX35 PDK 1.0
The revision number is wrong, as a default value is printed
(tested on a mx35pdk Rev. 2.0).
Move the output in the board_late_init(), when
pmic can be accessed.
Signed-off-by: Stefano Babic
---
board/freescale/mx35pdk/mx35pdk.c |8 +---
include/configs/mx35pdk.h |1 -
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx35pdk/mx35pdk.c
b/board/freescale/mx35pdk/mx35pdk.c
index cce7123..d5b592b 100644
--- a/board/freescale/mx35pdk/mx35pdk.c
+++ b/board/freescale/mx35pdk/mx35pdk.c
@@ -258,9 +258,13 @@ int board_late_init(void)
val |= 0x80;
mc9sdz60_reg_write(MC9SDZ60_REG_RESET_1, val);
+ /* Print board revision */
+ printf("Board: MX35 PDK %d.0\n", ((get_board_rev() >> 8) + 1) & 0x0F);
+
return 0;
}
+#if 0
int checkboard(void)
{
/*
@@ -269,11 +273,9 @@ int checkboard(void)
*/
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
- /* Print board revision */
- printf("Board: MX35 PDK %d.0\n", ((get_board_rev() >> 8) + 1) & 0x0F);
-
return 0;
}
+#endif
int board_eth_init(bd_t *bis)
{
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 1e03639..de4b954 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -34,7 +34,6 @@
#define CONFIG_MX35_HCLK_FREQ 2400
#define CONFIG_DISPLAY_CPUINFO
-#define CONFIG_DISPLAY_BOARDINFO
/* Set TEXT at the beginning of the NOR flash */
#define CONFIG_SYS_TEXT_BASE 0xA000
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM1136: MX35: Make asm routines volatile in cache ops
As well as pushed for ARM926EJS, we certainly don't want
the compiler to reorganise the code for dcache flushing
Fix checkpatch warnings as well.
Signed-off-by: Stefano Babic
CC: Marek Vasut
CC: Albert Aribaud
---
arch/arm/cpu/arm1136/cpu.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index f2e30b5..f72bab6 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -70,10 +70,12 @@ int cleanup_before_linux (void)
static void cache_flush(void)
{
unsigned long i = 0;
-
- asm ("mcr p15, 0, %0, c7, c10, 0": :"r" (i)); /* clean entire data
cache */
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches
and flush btb */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync
things */
+ /* clean entire data cache */
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (i));
+ /* invalidate both caches and flush btb */
+ asm volatile("mcr p15, 0, %0, c7, c7, 0" : : "r" (i));
+ /* mem barrier to sync things */
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (i));
}
#ifndef CONFIG_SYS_DCACHE_OFF
@@ -84,13 +86,13 @@ static void cache_flush(void)
void invalidate_dcache_all(void)
{
- asm ("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
}
void flush_dcache_all(void)
{
- asm ("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
- asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
}
static inline int bad_cache_range(unsigned long start, unsigned long stop)
@@ -116,7 +118,7 @@ void invalidate_dcache_range(unsigned long start, unsigned
long stop)
return;
while (start < stop) {
- asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
+ asm volatile("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
start += CONFIG_SYS_CACHELINE_SIZE;
}
}
@@ -127,11 +129,11 @@ void flush_dcache_range(unsigned long start, unsigned
long stop)
return;
while (start < stop) {
- asm ("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
+ asm volatile("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
start += CONFIG_SYS_CACHELINE_SIZE;
}
- asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
}
void flush_cache(unsigned long start, unsigned long size)
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] MX35: mx35pdk: wrong board revision
The board revision is detected accessing to the pmic,
that is not available before relocation (I2C).
This generates the following error:
CPU: Freescale i.MX35 rev 2.0 at 532 MHz.
Reset cause: WDOG
= 7 is invalid. Should be less than 0
Board: MX35 PDK 1.0
The revision number is wrong, as a default value is printed
(tested on a mx35pdk Rev. 2.0).
Move the output in the board_late_init(), when
pmic can be accessed.
Signed-off-by: Stefano Babic
---
V2: drop dead code
board/freescale/mx35pdk/mx35pdk.c | 11 ---
include/configs/mx35pdk.h |1 -
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/board/freescale/mx35pdk/mx35pdk.c
b/board/freescale/mx35pdk/mx35pdk.c
index cce7123..bc415b8 100644
--- a/board/freescale/mx35pdk/mx35pdk.c
+++ b/board/freescale/mx35pdk/mx35pdk.c
@@ -258,17 +258,6 @@ int board_late_init(void)
val |= 0x80;
mc9sdz60_reg_write(MC9SDZ60_REG_RESET_1, val);
- return 0;
-}
-
-int checkboard(void)
-{
- /*
-* Be sure that I2C is initialized to check
-* the board revision
-*/
- i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
-
/* Print board revision */
printf("Board: MX35 PDK %d.0\n", ((get_board_rev() >> 8) + 1) & 0x0F);
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 1e03639..de4b954 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -34,7 +34,6 @@
#define CONFIG_MX35_HCLK_FREQ 2400
#define CONFIG_DISPLAY_CPUINFO
-#define CONFIG_DISPLAY_BOARDINFO
/* Set TEXT at the beginning of the NOR flash */
#define CONFIG_SYS_TEXT_BASE 0xA000
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] MX35: mx35pdk: wrong board revision
On 4/9/12, Stefano Babic wrote: > The board revision is detected accessing to the pmic, > that is not available before relocation (I2C). > This generates the following error: > > CPU: Freescale i.MX35 rev 2.0 at 532 MHz. > Reset cause: WDOG > = 7 is invalid. Should be less than 0 > Board: MX35 PDK 1.0 > > The revision number is wrong, as a default value is printed > (tested on a mx35pdk Rev. 2.0). > > Move the output in the board_late_init(), when > pmic can be accessed. > > Signed-off-by: Stefano Babic > --- > > V2: drop dead code > > board/freescale/mx35pdk/mx35pdk.c | 11 --- > include/configs/mx35pdk.h |1 - > 2 files changed, 0 insertions(+), 12 deletions(-) Looks like there is something wrong with this patch: 12 deletions and no insertions. Comparing it with v1 I would expect that only the "#if 0 and #endif" were removed. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX28: Lower the amount of blocks transfered in one DMA cycle
Hi Marek, On 4/9/12, Marek Vasut wrote: > Some MMC cards, like my ancient 32.0MB SanDisk RS-MMC cards had issue if > b_max > was set to 0x40 and DMA was enabled. Lower this value to 0x20, which allows > these cards to work too. I know this is off topic here, but I am wondering whether the mxs mmc driver in the kernel is able to handle this card correctly or not. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
On 04/09/2012 01:26 AM, Marek Vasut wrote:
Dear Dirk Behme,
On 09.04.2012 08:45, Marek Vasut wrote:
Align the FAT FS buffers so DMA on various systems can directly pick
them.
Just fyi:
http://lists.denx.de/pipermail/u-boot/2012-March/119311.html
http://lists.denx.de/pipermail/u-boot/2012-March/119309.html
Heh, nice! :-)
I've been so dug up in debugging the USB cache issues I didn't bother to look
around the list for previous efforts. So obviously, apply Eric's patch! :-)
Hi guys,
It looks like I missed this bit though:
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 1f95eb4..d709e59 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -709,7 +711,7 @@ read_bootsectandvi (boot_sector *bs, volume_info *volinfo,
int *fatsize)
return -1;
}
- block = malloc(cur_dev->blksz);
+ block = memalign(ARCH_DMA_MINALIGN, cur_dev->blksz);
if (block == NULL) {
debug("Error: allocating block\n");
return -1;
Perhaps I got lucky in my testing!
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Standalone Binary
Dear all, I'm try to execute hello_world standalone after booting u-boot. In examples/Makefile, I found load address where I'm loading hello_world.bin (via tftp). ifeq ($(ARCH),arm) LOAD_ADDR = 0xc10 endif OK6410 # bootelf c10 ## No elf image at address 0x0c10 OK6410 # go c10 ## Starting application at 0x0C10 ... <<< No response from here >>> I also check with objdump as, arm-linux-objdump -d hello_world | less And found: 0c10 . Can any one suggest me if I'm wrong in any process to execute standalone binary from u-boot ? Viral ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V3] DMA: Split the APBH DMA init into block and channel init
On Mon, Apr 9, 2012 at 12:34 AM, Marek Vasut wrote: > This fixes the issue where mxs_dma_init() was called either twice or never, > without introducing any new init hooks. > > The idea is to allow each and every device using the APBH DMA block to > configure and request only the channels it uses, instead of making it call > init > for all the channels as is now. > > The common DMA block init part, which only configures the block, is then > called > from CPUs arch_cpu_init() call. > > NOTE: This patch depends on: > > http://patchwork.ozlabs.org/patch/150957/ > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > Cc: Wolfgang Denk > Cc: Detlev Zundel > Cc: Fabio Estevam This fixes the mmc issue on mx28. Tested-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx: Add GPIO_TO_PORT macro
Hello Dirk,
On 4/9/2012 11:03 AM, Dirk Behme wrote:
Dear Vikram ,
On 06.04.2012 10:56, Stefano Babic wrote:
On 04/04/2012 18:05, Vikram Narayanan wrote:
imx: Add GPIO_TO_PORT macro
Signed-off-by: Vikram Narayanan
Hi,
---
arch/arm/include/asm/arch-mx5/gpio.h | 2 ++
arch/arm/include/asm/arch-mx6/gpio.h | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
50.0% arch/arm/include/asm/arch-mx5/
50.0% arch/arm/include/asm/arch-mx6/
diff --git a/arch/arm/include/asm/arch-mx5/gpio.h
b/arch/arm/include/asm/arch-mx5/gpio.h
index 1dc34e9..bcb5edb 100644
--- a/arch/arm/include/asm/arch-mx5/gpio.h
+++ b/arch/arm/include/asm/arch-mx5/gpio.h
@@ -25,6 +25,8 @@
#ifndef __ASM_ARCH_MX5_GPIO_H
#define __ASM_ARCH_MX5_GPIO_H
+#define GPIO_TO_PORT(number) (number/32)
+
/* GPIO registers */
struct gpio_regs {
u32 gpio_dr;
diff --git a/arch/arm/include/asm/arch-mx6/gpio.h
b/arch/arm/include/asm/arch-mx6/gpio.h
index 20c4e57..385d12d 100644
--- a/arch/arm/include/asm/arch-mx6/gpio.h
+++ b/arch/arm/include/asm/arch-mx6/gpio.h
@@ -25,6 +25,8 @@
#ifndef __ASM_ARCH_MX6_GPIO_H
#define __ASM_ARCH_MX6_GPIO_H
+#define GPIO_TO_PORT(number) (number/32)
+
/* GPIO registers */
struct gpio_regs {
u32 gpio_dr;
NAK. We have already (and probably too many) GPIO_TO_PORT:
arch/arm/include/asm/arch-mx6/imx-regs.h:#define GPIO_TO_PORT(number)
(((number)/32)+1)
arch/arm/include/asm/arch-mx5/mx5x_pins.h:#define GPIO_TO_PORT(n)
(n / GPIO_NUM_PIN)
Are they not enough ?
@Stefano: Yeah. Just didn't notice it. Will resend it.
Vikram, it seems to me you sent the already NAKed patch to me
https://github.com/dirkbehme/u-boot-imx6/pull/2
again?
Sorry, something went wrong with my filter settings in my mailbox. I
wasn't aware that it got NACked. Sorry for sending a pull req anyways.
Please send U-Boot patches only to this U-Boot mailing list.
Sure. From now on!
Dirk
~Vikram
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] LMB: Fix undefined lmb_reserve() on non-lmb platforms
Dear Marek Vasut, In message <1333288786-10296-1-git-send-email-ma...@denx.de> you wrote: > Signed-off-by: Marek Vasut > Cc: Wolfgang Denk > Cc: Mike Frysinger > Cc: Stephen Warren > Cc: Tom Warren > Cc: Graeme Russ > --- > common/cmd_bootm.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Applied, thanks. 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 human mind ordinarily operates at only ten percent of its capaci- ty - the rest is overhead for the operating system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-x86/master
Dear Graeme Russ, In message <4f783f94.5080...@gmail.com> you wrote: > Hi Wolfgang, > > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > are available in the git repository at: > git://git.denx.de/u-boot-x86.git master > > Simon Glass (1): > x86: Remove dead code in eNET > > board/eNET/eNET.c |5 - > 1 files changed, 0 insertions(+), 5 deletions(-) Applied, thanks. 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 O Staat! Wie tief dir alle Besten fluchen! Du bist kein Ziel. Der Mensch muß weiter suchen. - Christian Morgenstern ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nios/master
Dear Thomas Chou, In message <4f799aae.2010...@wytron.com.tw> you wrote: > > So please pull the u-boot-nios/master. Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's a design philosophy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-onenand
Dear Lukasz Majewski, In message <20120404171512.145ea7e0@lmajewski.digital.local> you wrote: > Hi Wolfgang, > > Please pull following commits: > > The following changes since commit > c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > are available in the git repository at: > ssh://gu-onen...@git.denx.de/u-boot-onenand master > > Lukasz Majewski (4): > onenand:samsung Target dependent OneNAND chip probe function > onenand:samsung OneNAND chip probe functions added for GONI and > Exynos4210 > onenand: Replace ONENAND_IS_MLC() with ONENAND_HAS_4KB() > onenand: samsung: Enable OneNAND support at Samsung's > Exynos4210 > > board/samsung/goni/onenand.c |1 + > board/samsung/universal_c210/onenand.c |2 + > drivers/mtd/onenand/onenand_base.c | 88 > +++ > drivers/mtd/onenand/samsung.c | 10 > include/configs/s5pc210_universal.h|1 + > include/linux/mtd/onenand.h|5 ++ > include/linux/mtd/samsung_onenand.h|2 + > > 7 files changed, 86 insertions(+), 23 deletions(-) Applied, thanks. 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 "Everything should be made as simple as possible, but not simpler." - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net
Dear Joe Hershberger, In message you wrote: > Hi Wolfgang, > > Please pull following commits: > > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > Wolfgang Denk (1): > Prepare v2012.04-rc1 > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git master > > Amit Virdi (1): > net/designware: Change timeout loop implementation > > Armando Visconti (2): > net/designware: Consecutive writes must have delay > net/designware: Set ANAR to 0x1e1 > > Eric Miao (1): > net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back > > Joe Hershberger (1): > Update net subsystem maintainer in doc/git-mailrc > > Stefan Bigler (1): > mvgbe: remove warning for unused methods > > Stephan Linz (4): > net: ll_temac: Add LL TEMAC driver to u-boot > microblaze: Enable several ethernet driver compilation > microblaze: Add faked LL_TEMAC driver configuration > microblaze: Wire up LL_TEMAC driver initialization > > Vikas Manocha (1): > net/designware: Program phy registers when auto-negotiation is ON > > Vipin KUMAR (3): > net/designware: Fix to restore hw mac address > net/designware: Fix the max frame length size > net/designware: Phy address fix > > Vipin Kumar (1): > net/designware: Try configuring phy on each dw_eth_init > > board/xilinx/microblaze-generic/config.mk |6 +- > .../xilinx/microblaze-generic/microblaze-generic.c | 36 ++ > board/xilinx/microblaze-generic/xparameters.h | 12 +- > doc/git-mailrc |3 +- > drivers/net/Makefile |2 + > drivers/net/designware.c | 128 +-- > drivers/net/designware.h |3 +- > drivers/net/mvgbe.c|2 + > drivers/net/xilinx_ll_temac.c | 399 > > drivers/net/xilinx_ll_temac.h | 310 +++ > drivers/net/xilinx_ll_temac_fifo.c | 143 +++ > drivers/net/xilinx_ll_temac_fifo.h | 122 ++ > drivers/net/xilinx_ll_temac_mdio.c | 180 + > drivers/net/xilinx_ll_temac_mdio.h | 53 +++ > drivers/net/xilinx_ll_temac_sdma.c | 370 ++ > drivers/net/xilinx_ll_temac_sdma.h | 281 ++ > include/configs/microblaze-generic.h | 11 +- > include/netdev.h | 12 + > net/eth.c |3 +- > 19 files changed, 2025 insertions(+), 51 deletions(-) > create mode 100644 drivers/net/xilinx_ll_temac.c > create mode 100644 drivers/net/xilinx_ll_temac.h > create mode 100644 drivers/net/xilinx_ll_temac_fifo.c > create mode 100644 drivers/net/xilinx_ll_temac_fifo.h > create mode 100644 drivers/net/xilinx_ll_temac_mdio.c > create mode 100644 drivers/net/xilinx_ll_temac_mdio.h > create mode 100644 drivers/net/xilinx_ll_temac_sdma.c > create mode 100644 drivers/net/xilinx_ll_temac_sdma.h Applied, thanks. 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 value of marriage is not that adults produce children, but that children produce adults."- Peter De Vries ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-staging/marek.va...@gmail.com :: FOR u-boot/master
Dear Marek Vasut, In message <201204060454.56108.ma...@denx.de> you wrote: ... > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-staging.git marek.va...@gmail.com > > for you to fetch changes up to f4cdde40195078a9183a0e29f741dac31ea3d425: > > LMB: Fix undefined lmb_reserve() on non-lmb platforms (2012-04-02 15:54:53 > +0200) > > > Daniel Schwierzeck (3): > MIPS: board.c: fix init of flash data in bd_info > MIPS: fix inconsistency in config option for cache operation mode > MIPS: fix endianess handling These are all MIPS related patches, so they are suppoesed to go through the MIPS custodian repository, or at least need his blessing. I put Shinya Kuribayashi on cc: > Marek Vasut (1): > LMB: Fix undefined lmb_reserve() on non-lmb platforms I already applied this directly. Thanks! 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 Two wrongs don't make a right, but three rights make a left. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-staging/ma...@denx.de :: FOR u-boot/-next
Dear Marek Vasut, In message <201204060455.17359.ma...@denx.de> you wrote: > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-staging.git ma...@denx.de > > for you to fetch changes up to c98167f1df33c6273355050fc0dbbdb73aec51ea: > > MIPS: start.S: refactor reset and exception vector setup (2012-03-31 > 22:51:57 > +0200) > > > Daniel Schwierzeck (6): > MIPS: board.c: fix init of flash data in bd_info > MIPS: add register definition for EBase register > MIPS: make cache operation mode configurable in dcache_enable() > MIPS: add header file for generic GPIO API > MIPS: extend cache initialization for recent MIPS CPU cores > MIPS: start.S: refactor reset and exception vector setup > > README |5 + > arch/mips/cpu/mips32/cache.S | 16 +++- > arch/mips/cpu/mips32/start.S | 204 > ++ > arch/mips/include/asm/gpio.h | 13 +++ > arch/mips/include/asm/mipsregs.h | 20 > arch/mips/lib/board.c|8 +- > 6 files changed, 112 insertions(+), 154 deletions(-) > create mode 100644 arch/mips/include/asm/gpio.h This is again all MIPS stuff. Please negotiate with MIPS custodian. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have often regretted my speech, never my silence. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx: Add GPIO_TO_PORT macro
Hi,
On 4/6/2012 2:26 PM, Stefano Babic wrote:
On 04/04/2012 18:05, Vikram Narayanan wrote:
imx: Add GPIO_TO_PORT macro
Signed-off-by: Vikram Narayanan
Hi,
---
arch/arm/include/asm/arch-mx5/gpio.h |2 ++
arch/arm/include/asm/arch-mx6/gpio.h |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
50.0% arch/arm/include/asm/arch-mx5/
50.0% arch/arm/include/asm/arch-mx6/
diff --git a/arch/arm/include/asm/arch-mx5/gpio.h
b/arch/arm/include/asm/arch-mx5/gpio.h
index 1dc34e9..bcb5edb 100644
--- a/arch/arm/include/asm/arch-mx5/gpio.h
+++ b/arch/arm/include/asm/arch-mx5/gpio.h
@@ -25,6 +25,8 @@
#ifndef __ASM_ARCH_MX5_GPIO_H
#define __ASM_ARCH_MX5_GPIO_H
+#define GPIO_TO_PORT(number) (number/32)
+
/* GPIO registers */
struct gpio_regs {
u32 gpio_dr;
diff --git a/arch/arm/include/asm/arch-mx6/gpio.h
b/arch/arm/include/asm/arch-mx6/gpio.h
index 20c4e57..385d12d 100644
--- a/arch/arm/include/asm/arch-mx6/gpio.h
+++ b/arch/arm/include/asm/arch-mx6/gpio.h
@@ -25,6 +25,8 @@
#ifndef __ASM_ARCH_MX6_GPIO_H
#define __ASM_ARCH_MX6_GPIO_H
+#define GPIO_TO_PORT(number) (number/32)
+
/* GPIO registers */
struct gpio_regs {
u32 gpio_dr;
NAK. We have already (and probably too many) GPIO_TO_PORT:
Yes. You are right.
So, instead of defining all the headers this way,
#if defined(CONFIG_MX53) || defined(CONFIG_MX51)
#include
#elif defined(CONFIG_MX6)
#include
#endif
. etc
Why not define the GPIO_TO_PORT macro in the driver? Anyways for all its
the same 32 pins. Any suggestions/flames?
Thanks,
Vikram
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] davinci/spi: allow usage of other chip selects and buses
On Sun, Apr 08, 2012 at 05:22:52PM -0400, J??r??me Carretero wrote: > Use the spi_slave bus and cs attributes, reduce C2T/T2C delays, > allow overriding of spi_cs_is_valid(). > > As it is, this patch breaks the configuration files for DaVinci boards > that only use SPI1. > > Signed-off-by: J??r??me Carretero > CC: Manjunathappa, Prakash Please fix the configs that this patch breaks, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone Binary
Dear Viral Sachde, In message you wrote: > > I'm try to execute hello_world standalone after booting u-boot. > > In examples/Makefile, I found load address where I'm loading > hello_world.bin (via tftp). Load address != entry point address. > Can any one suggest me if I'm wrong in any process to execute > standalone binary from u-boot ? It appears you did not read the documentation. See the FAQ, especially this one: http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork 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 Neckties strangle clear thinking. -- Lin Yutang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-staging/ma...@denx.de :: FOR u-boot/-next
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201204060455.17359.ma...@denx.de> you wrote: > > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > > > are available in the git repository at: > > git://git.denx.de/u-boot-staging.git ma...@denx.de > > > > for you to fetch changes up to c98167f1df33c6273355050fc0dbbdb73aec51ea: > > MIPS: start.S: refactor reset and exception vector setup (2012-03-31 > > 22:51:57 > > > > +0200) > > > > > > > > Daniel Schwierzeck (6): > > MIPS: board.c: fix init of flash data in bd_info > > MIPS: add register definition for EBase register > > MIPS: make cache operation mode configurable in dcache_enable() > > MIPS: add header file for generic GPIO API > > MIPS: extend cache initialization for recent MIPS CPU cores > > MIPS: start.S: refactor reset and exception vector setup > > > > README |5 + > > arch/mips/cpu/mips32/cache.S | 16 +++- > > arch/mips/cpu/mips32/start.S | 204 > > ++ arch/mips/include/asm/gpio.h > > | 13 +++ > > arch/mips/include/asm/mipsregs.h | 20 > > arch/mips/lib/board.c|8 +- > > 6 files changed, 112 insertions(+), 154 deletions(-) > > create mode 100644 arch/mips/include/asm/gpio.h > > This is again all MIPS stuff. Please negotiate with MIPS custodian. I did talk to Shinya, he said he has not much time for mips stuff anymore :-( > Best regards, > > Wolfgang Denk Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX28: Lower the amount of blocks transfered in one DMA cycle
Dear Fabio Estevam, > Hi Marek, > > On 4/9/12, Marek Vasut wrote: > > Some MMC cards, like my ancient 32.0MB SanDisk RS-MMC cards had issue if > > b_max > > was set to 0x40 and DMA was enabled. Lower this value to 0x20, which > > allows these cards to work too. > > I know this is off topic here, but I am wondering whether the mxs mmc > driver in the kernel is able to handle this card correctly or not. Linux does, but I think there must be some limit to multiblock transfers there, otherwise it'd fail too. > Regards, > > Fabio Estevam Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-staging/marek.va...@gmail.com :: FOR u-boot/master
Dear Marek Vasut, In message <201204060454.56108.ma...@denx.de> you wrote: ... > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-staging.git marek.va...@gmail.com > > for you to fetch changes up to f4cdde40195078a9183a0e29f741dac31ea3d425: > > LMB: Fix undefined lmb_reserve() on non-lmb platforms (2012-04-02 15:54:53 > +0200) > > > Daniel Schwierzeck (3): > MIPS: board.c: fix init of flash data in bd_info > MIPS: fix inconsistency in config option for cache operation mode > MIPS: fix endianess handling Applied, thanks. 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 "Don't try to outweird me, three-eyes. I get stranger things than you free with my breakfast cereal." - Zaphod Beeblebrox in "Hitchhiker's Guide to the Galaxy" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone Binary
On Mon, Apr 9, 2012 at 11:32 PM, Wolfgang Denk wrote: > Dear Viral Sachde, > > In message > you > wrote: >> >> I'm try to execute hello_world standalone after booting u-boot. >> >> In examples/Makefile, I found load address where I'm loading >> hello_world.bin (via tftp). > > Load address != entry point address. > >> Can any one suggest me if I'm wrong in any process to execute >> standalone binary from u-boot ? > > It appears you did not read the documentation. See the FAQ, > especially this one: > http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork > > Best regards, > > Wolfgang Denk Dear Wolfgang Denk, I forgot to mention but I did tried -nm too as below: arm-linux-nm -n hello_world 0c10 T hello_world Let me know if you have any other suggestion. Viral > 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 > Neckties strangle clear thinking. -- Lin Yutang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone Binary
Dear Viral Sachde, In message you wrote: > > I forgot to mention but I did tried -nm too as below: > > arm-linux-nm -n hello_world > 0c10 T hello_world What is the memory map on your system? Maybe you provide a bit more information - like which processor and board we are talking about? And which exact version of U-Boot you use? 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 My brother sent me a postcard the other day with this big sattelite photo of the entire earth on it. On the back it said: "Wish you were here".- Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ld fails with .bss / .rel.dyn overlap for 2011.12
This email is to report a problem building u-boot 2011.12 with a gcc 4.3.2 toolchain. I've added support locally for a marvell 78xx0 based board. It's using arm926ejs and I have not modified the *.lds linker script. Case 1: With gcc 4.3.2 provided by marvell, the build fails with this error: arm-mv5vfp-linux-gnueabi-ld: section .bss [fffbba08 -> fffc3137] overlaps section .rel.dyn [fffbba08 -> fffbeea7] arm-mv5vfp-linux-gnueabi-ld: section .dynsym [fffbeea8 -> fffbef57] overlaps section .bss [fffbba08 -> fffc3137] arm-mv5vfp-linux-gnueabi-ld: u-boot: section .bss lma 0xfffbba08 overlaps previous sections make: *** [u-boot] Error 1 Through trial-and-error, I found that this error only occurs when .bss is unaligned. In my example .bss is only 2-byte aligned and u-boot.map indicates that the linker added 2-bytes of zero fill at the end of bss. If I add a global unsigned short so .bss is 4-byte aligned the error goes away and gcc produces a good binary. Case 2: With gcc 4.6.3 built with crosstool-ng, the build has no problem. I can provide u-boot.map files (~70k) for each case. -joey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/23] i2c: Add TPS6586X driver
On 04/02/2012 05:18 PM, Simon Glass wrote:
> This power management chip supports battery charging and a large number
> of power supplies. This initial driver only provides the ability to adjust
> the two synchronous buck converters SM0 and SM1 in a stepwise manner.
>
> Signed-off-by: Simon Glass
> +#define MAX_I2C_RETRY3
> +int tps6586x_read(int reg)
...
> + for (i = 0; i < MAX_I2C_RETRY; ++i) {
> + if (!i2c_read(I2C_ADDRESS, reg, 1, &data, 1)) {
> + retval = (int)data;
> + goto exit;
> + }
> +
> + /* i2c access failed, retry */
> + udelay(100);
> + }
Why do we need this retry logic; the kernel driver doesn't appear to
have this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/23] tegra: Move ap20.h header into arch location
On 04/02/2012 05:18 PM, Simon Glass wrote: > We want to include this from board code, so move the header into > an easily-accessible location. > > Signed-off-by: Simon Glass > diff --git a/arch/arm/cpu/armv7/tegra2/board.c > b/arch/arm/cpu/armv7/tegra2/board.c > +#include That seems unrelated. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/23] tegra: Move ap20.h header into arch location
On 04/02/2012 05:18 PM, Simon Glass wrote: > We want to include this from board code, so move the header into > an easily-accessible location. > diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c > b/arch/arm/cpu/armv7/tegra2/ap20.c > -#include "ap20.h" > #include > #include > +#include BTW, why do we have separate tegra2.h and ap20.h? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/23] tegra: Add tegra_get_chip_type() to detect SKU
On 04/02/2012 05:18 PM, Simon Glass wrote:
> We want to know which type of chip we are running on - the Tegra
> family has several SKUs. This can be determined by reading a
> fuse register, so add this function to ap20.
>
> Signed-off-by: Simon Glass
> Acked-by: Stephen Warren
> ---
> Changes in v2:
> - Add check of undocumented values in hidrev register
> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c
> b/arch/arm/cpu/armv7/tegra2/ap20.c
> +int tegra_get_chip_type(void)
> +{
> + struct apb_misc_gp_ctlr *gp;
> + struct fuse_regs *fuse = (struct fuse_regs *)TEGRA2_FUSE_BASE;
> + uint tegra_sku_id, rev;
> +
> + /*
> + * This is undocumented, Chip ID is bits 15:8 of the register
> + * APB_MISC + 0x804, and has value 0x20 for Tegra20, 0x30 for
> + * Tegra30
> + */
> + gp = (struct apb_misc_gp_ctlr *)TEGRA2_APB_MISC_GP_BASE;
> + rev = (readl(&gp->hidrev) & HIDREV_CHIPID_MASK) >> HIDREV_CHIPID_SHIFT;
That's not entirely true; the register and its fields are documented in
the TRM. The values of the CHIPID field itself are indeed not documented.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ld fails with .bss / .rel.dyn overlap for 2011.12
Dear Joey Oravec, In message <4f834e09.3010...@drewtech.com> you wrote: > This email is to report a problem building u-boot 2011.12 with a gcc > 4.3.2 toolchain. I've added support locally for a marvell 78xx0 based > board. It's using arm926ejs and I have not modified the *.lds linker script. > > Case 1: With gcc 4.3.2 provided by marvell, the build fails with this error: ... > I can provide u-boot.map files (~70k) for each case. Thanks, but what should we do about that? You are referring to code that is unknown to us, and to a tool chain we have no access to. It would probably be best to report this to the Marvell compiler team. 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 There were meetings. There were always meetings. And they were dull, which is part of the reason they were meetings. Dull likes company. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/23] tegra: Move ap20.h header into arch location
Hi Stephen, On Mon, Apr 9, 2012 at 2:06 PM, Stephen Warren wrote: > On 04/02/2012 05:18 PM, Simon Glass wrote: >> We want to include this from board code, so move the header into >> an easily-accessible location. > >> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c >> b/arch/arm/cpu/armv7/tegra2/ap20.c > >> -#include "ap20.h" >> #include >> #include >> +#include > > BTW, why do we have separate tegra2.h and ap20.h? I'm not sure - was ap20 the old name? Tom do you know? For now we use ap20 as the interface to the AVP side, and where we start up the A9. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/23] i2c: Add TPS6586X driver
Hi Stephen,
On Mon, Apr 9, 2012 at 2:01 PM, Stephen Warren wrote:
> On 04/02/2012 05:18 PM, Simon Glass wrote:
>> This power management chip supports battery charging and a large number
>> of power supplies. This initial driver only provides the ability to adjust
>> the two synchronous buck converters SM0 and SM1 in a stepwise manner.
>>
>> Signed-off-by: Simon Glass
>
>> +#define MAX_I2C_RETRY 3
>> +int tps6586x_read(int reg)
> ...
>> + for (i = 0; i < MAX_I2C_RETRY; ++i) {
>> + if (!i2c_read(I2C_ADDRESS, reg, 1, &data, 1)) {
>> + retval = (int)data;
>> + goto exit;
>> + }
>> +
>> + /* i2c access failed, retry */
>> + udelay(100);
>> + }
>
> Why do we need this retry logic; the kernel driver doesn't appear to
> have this.
We apparently have found the device to be flaky on i2c sometimes,
which is why this is here.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
On 04/05/2012 03:55 PM, Simon Glass wrote:
> From: Jimmy Zhang
>
> Set Seaboard to optimal memory settings based on the SOC in use (T20 or T25).
>
> Signed-off-by: Simon Glass
> ---
> Changes in v2:
> - Move EMC tables to device tree
> - Removed check for nominal voltage (not needed as it is done just before)
>
> Changes in v3:
> - Add better error reporting when EMC setup fails
>
> Changes in v4:
> - Remove support for T20 memory timings
> diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
> +/* This rate is hard-coded for now, until fdt provides them */
> +#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
> +
> +int board_emc_init(void)
> +{
> + unsigned rate;
> +
> + switch (tegra_get_chip_type()) {
> + default:
> + case TEGRA_SOC_T20:
> + debug("%s: EMC timings not supported for T20 Seaboard\n",
> + __func__);
This isn't Seaboard-specific code, so the string shouldn't say
"Seaboard" there.
Why not support Tegra20? Many/all of the other Tegra boards U-Boot
supports are Tegra20 not Tegra25.
Presumably this code doesn't blow up if the EMC tables aren't in the
.dts file; the code should use the tables if they're present, otherwise
be a no-op.
> + return -1;
> + case TEGRA_SOC_T25:
> + rate = EMC_SDRAM_RATE_T25;
> + break;
> + }
> + return tegra_set_emc(gd->fdt_blob, rate);
> +}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 22/23] tegra: fdt: Add EMC data for Tegra2 Seaboard
On 04/05/2012 03:55 PM, Simon Glass wrote: > This adds timings for T20 and T25 Seaboards, using the bindings found here: > > http://patchwork.ozlabs.org/patch/132928/ > > We supply both full speed options for normal running, and half speed options > for testing / development. > > Signed-off-by: Simon Glass Acked-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/23] tegra: Add warmboot implementation
On 04/02/2012 05:18 PM, Simon Glass wrote:
> From: Yen Lin
>
> Add code to set up the warm boot area in the Tegra CPU ready for a
> resume after suspend.
>
> Signed-off-by: Simon Glass
> Acked-by: Stephen Warren
> +static enum fuse_operating_mode fuse_get_operation_mode(void)
> +{
> + u32 chip_id;
> + struct apb_misc_gp_ctlr *gp =
> + (struct apb_misc_gp_ctlr *)TEGRA2_APB_MISC_GP_BASE;
> +
> + chip_id = (readl(&gp->hidrev) & HIDREV_CHIPID_MASK) >>
> + HIDREV_CHIPID_SHIFT;
This duplicates code from the SKU retrieval function added in an earlier
patch. Not a big deal; it could be unified in a followon patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
+Olof
Hi Stephen,
On Mon, Apr 9, 2012 at 2:27 PM, Stephen Warren wrote:
> On 04/05/2012 03:55 PM, Simon Glass wrote:
>> From: Jimmy Zhang
>>
>> Set Seaboard to optimal memory settings based on the SOC in use (T20 or T25).
>>
>> Signed-off-by: Simon Glass
>> ---
>> Changes in v2:
>> - Move EMC tables to device tree
>> - Removed check for nominal voltage (not needed as it is done just before)
>>
>> Changes in v3:
>> - Add better error reporting when EMC setup fails
>>
>> Changes in v4:
>> - Remove support for T20 memory timings
>
>> diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
>
>> +/* This rate is hard-coded for now, until fdt provides them */
>> +#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
>> +
>> +int board_emc_init(void)
>> +{
>> + unsigned rate;
>> +
>> + switch (tegra_get_chip_type()) {
>> + default:
>> + case TEGRA_SOC_T20:
>> + debug("%s: EMC timings not supported for T20 Seaboard\n",
>> + __func__);
>
> This isn't Seaboard-specific code, so the string shouldn't say
> "Seaboard" there.
>
> Why not support Tegra20? Many/all of the other Tegra boards U-Boot
> supports are Tegra20 not Tegra25.
>
> Presumably this code doesn't blow up if the EMC tables aren't in the
> .dts file; the code should use the tables if they're present, otherwise
> be a no-op.
I don't mind, we can either go with v3 (with T20) or v4 (without).
Both sets of patches are on the list and the removable of T20 support
is the only change in v4. Please can you discuss this with Olof?
>
>> + return -1;
>> + case TEGRA_SOC_T25:
>> + rate = EMC_SDRAM_RATE_T25;
>> + break;
>> + }
>> + return tegra_set_emc(gd->fdt_blob, rate);
>> +}
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] net/tsec: Don't tell the link status if used with netconsole
On Sun, Apr 8, 2012 at 3:26 AM, Mike Frysinger wrote:
> On Wednesday 04 April 2012 11:27:44 Joe Hershberger wrote:
>> On Tue, Apr 3, 2012 at 3:54 PM, Sebastian Andrzej Siewior wrote:
>> > On 04/03/2012 10:42 PM, Mike Frysinger wrote:
>> >> On Friday 23 March 2012 16:11:19 Sebastian Andrzej Siewior wrote:
>> >>> --- a/drivers/net/tsec.c
>> >>> +++ b/drivers/net/tsec.c
>> >>>
>> >>> + if (strcmp(getenv("stdout"), "nc"))
>> >>
>> >> i really don't like special casing devices like this
>>
>> In this case I think it is better to check if stdout is nc, but not to
>> explicitly write to serial_printf(). The nc device is the reason to
>> avoid printing this since it uses the network. The serial_printf
>> seems like the special case to avoid. Consider the case of using a
>> SPI UART. There is no reason these traces should not go to it via the
>> normal printf routing.
>
> my point is that this doesn't scale ... not even close. either drop the
> printf calls in the core net case (when it'd be a problem with the
> netconsole), or figure out a solution that does actually scale. maybe a
> net_printf().
I agree. A net_printf sounds like a good solution.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ld fails with .bss / .rel.dyn overlap for 2011.12
On 4/9/2012 5:12 PM, Wolfgang Denk wrote: Dear Joey Oravec, In message<4f834e09.3010...@drewtech.com> you wrote: This email is to report a problem building u-boot 2011.12 with a gcc 4.3.2 toolchain. I've added support locally for a marvell 78xx0 based board. It's using arm926ejs and I have not modified the *.lds linker script. Case 1: With gcc 4.3.2 provided by marvell, the build fails with this error: ... I can provide u-boot.map files (~70k) for each case. Thanks, but what should we do about that? You are referring to code that is unknown to us, and to a tool chain we have no access to. It would probably be best to report this to the Marvell compiler team. Possibly nothing -- I'm reporting it because there have been other mailing list thread with the same error message, sometimes without a clear resolution: http://lists.denx.de/pipermail/u-boot/2012-February/117009.html http://lists.denx.de/pipermail/u-boot/2010-November/082122.html I don't know enough about the linker or *.map file to understand the root cause of the error message. I can only report my observations and suggest that if somebody else hits the same problem they should try using a newer toolchain. In my case it fixed the problem. I don't need anybody to take any action on this, so feel free to disregard if this report is not interesting. I have no support through Marvell but I thought it was appropriate to share my results with this mailing list. -joey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/23] tegra: Move ap20.h header into arch location
Simon/Stephen, > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: Monday, April 09, 2012 2:24 PM > To: Stephen Warren > Cc: U-Boot Mailing List; Tom Warren > Subject: Re: [PATCH v3 06/23] tegra: Move ap20.h header into arch location > > Hi Stephen, > > On Mon, Apr 9, 2012 at 2:06 PM, Stephen Warren > wrote: > > On 04/02/2012 05:18 PM, Simon Glass wrote: > >> We want to include this from board code, so move the header into an > >> easily-accessible location. > > > >> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c > >> b/arch/arm/cpu/armv7/tegra2/ap20.c > > > >> -#include "ap20.h" > >> #include > >> #include > >> +#include > > > > BTW, why do we have separate tegra2.h and ap20.h? > > I'm not sure - was ap20 the old name? Tom do you know? For now we use > ap20 as the interface to the AVP side, and where we start up the A9. AP20 is the name of one classification/sku/bin/type of Tegra20 chip - Application Processor, IIRC. Usually AP20 and T20 are used interchangeably. The history of ap20.h is messy - it came from our Embedded group originally and was ported to U-Boot by stripping out all the NV-proprietary-API cruft, changing CamelCase var/func names, to U-Boot-compliant code, etc. At this point, it might be able to be merged w/tegra2.h, but tegra2.h is more general to the entire chip and its periphs, and ap20.h is more specific to the CPU(s) and AVP/CPU init. But I won't object to a merger. Tom > > Regards, > Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/23] tegra: Add tegra_get_chip_type() to detect SKU
Hi Stephen,
On Mon, Apr 9, 2012 at 2:09 PM, Stephen Warren wrote:
> On 04/02/2012 05:18 PM, Simon Glass wrote:
>> We want to know which type of chip we are running on - the Tegra
>> family has several SKUs. This can be determined by reading a
>> fuse register, so add this function to ap20.
>>
>> Signed-off-by: Simon Glass
>> Acked-by: Stephen Warren
>> ---
>> Changes in v2:
>> - Add check of undocumented values in hidrev register
>
>> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c
>> b/arch/arm/cpu/armv7/tegra2/ap20.c
>
>> +int tegra_get_chip_type(void)
>> +{
>> + struct apb_misc_gp_ctlr *gp;
>> + struct fuse_regs *fuse = (struct fuse_regs *)TEGRA2_FUSE_BASE;
>> + uint tegra_sku_id, rev;
>> +
>> + /*
>> + * This is undocumented, Chip ID is bits 15:8 of the register
>> + * APB_MISC + 0x804, and has value 0x20 for Tegra20, 0x30 for
>> + * Tegra30
>> + */
>> + gp = (struct apb_misc_gp_ctlr *)TEGRA2_APB_MISC_GP_BASE;
>> + rev = (readl(&gp->hidrev) & HIDREV_CHIPID_MASK) >> HIDREV_CHIPID_SHIFT;
>
> That's not entirely true; the register and its fields are documented in
> the TRM. The values of the CHIPID field itself are indeed not documented.
OK I have updated this. It is confusing because there is another
register at TEGRA2_APB_MISC_PP_BASE which has a space in those fields.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/23] tegra: Move ap20.h header into arch location
Hi Tom, On Mon, Apr 9, 2012 at 2:50 PM, Tom Warren wrote: > Simon/Stephen, > >> -Original Message- >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass >> Sent: Monday, April 09, 2012 2:24 PM >> To: Stephen Warren >> Cc: U-Boot Mailing List; Tom Warren >> Subject: Re: [PATCH v3 06/23] tegra: Move ap20.h header into arch location >> >> Hi Stephen, >> >> On Mon, Apr 9, 2012 at 2:06 PM, Stephen Warren >> wrote: >> > On 04/02/2012 05:18 PM, Simon Glass wrote: >> >> We want to include this from board code, so move the header into an >> >> easily-accessible location. >> > >> >> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c >> >> b/arch/arm/cpu/armv7/tegra2/ap20.c >> > >> >> -#include "ap20.h" >> >> #include >> >> #include >> >> +#include >> > >> > BTW, why do we have separate tegra2.h and ap20.h? >> >> I'm not sure - was ap20 the old name? Tom do you know? For now we use >> ap20 as the interface to the AVP side, and where we start up the A9. > AP20 is the name of one classification/sku/bin/type of Tegra20 chip - > Application Processor, IIRC. Usually AP20 and T20 are used interchangeably. > The history of ap20.h is messy - it came from our Embedded group originally > and was ported to U-Boot by stripping out all the NV-proprietary-API cruft, > changing CamelCase var/func names, to U-Boot-compliant code, etc. At this > point, it might be able to be merged w/tegra2.h, but tegra2.h is more general > to the entire chip and its periphs, and ap20.h is more specific to the CPU(s) > and AVP/CPU init. But I won't object to a merger. Thanks for that. Perhaps we should rename it to avp or cpu_init. Something to think about. > > Tom >> >> Regards, >> Simon > -- > nvpublic Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 22/23] tegra: fdt: Add EMC data for Tegra2 Seaboard
Hi Stephen, On Mon, Apr 9, 2012 at 2:30 PM, Stephen Warren wrote: > On 04/05/2012 03:55 PM, Simon Glass wrote: >> This adds timings for T20 and T25 Seaboards, using the bindings found here: >> >> http://patchwork.ozlabs.org/patch/132928/ >> >> We supply both full speed options for normal running, and half speed options >> for testing / development. >> >> Signed-off-by: Simon Glass > > Acked-by: Stephen Warren This is the patch where I removed the T20 data. If it is not present, then things will still work, although if you define DEBUG then you will get warnings. We can either leave it out or put it back in for v5, up to you. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/23] tegra: warmboot (suspend / resume) support
On 04/02/2012 05:18 PM, Simon Glass wrote: > This series adds support for warm boot, allowing the device to suspend > and resume. U-Boot sets up some 'warm boot' code in a special area such > that the SOC can find it on a resume. This code is responsible for > setting up memory and clocked and then allowing the OS to continue > where it left off. > > Also included here is support for the EMC, which allows setting the memory > timings correctly in U-Boot for maximum speed operation. The series partially: Tested-by: Stephen Warren I tested that on both Harmony and Seaboard, this series didn't seem to impact existing operation (boot to a command-prompt, load files from an SD card, produce serial output). I didn't actually test LP0. Note: Neither board appears to be able to actually boot a kernel any more, failing with the following error: = Starting kernel ... Uncompressing Linux... done, booting the kernel. Warning: Neither atags nor dtb found = However, this problem is present in u-boot-tegra/master before any changes in this series. Tom, do you want me to file an internal bug for this? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/23] tegra: Move ap20.h header into arch location
On 04/09/2012 03:24 PM, Simon Glass wrote: > Hi Stephen, > > On Mon, Apr 9, 2012 at 2:06 PM, Stephen Warren wrote: >> On 04/02/2012 05:18 PM, Simon Glass wrote: >>> We want to include this from board code, so move the header into >>> an easily-accessible location. >> >>> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c >>> b/arch/arm/cpu/armv7/tegra2/ap20.c >> >>> -#include "ap20.h" >>> #include >>> #include >>> +#include >> >> BTW, why do we have separate tegra2.h and ap20.h? > > I'm not sure - was ap20 the old name? Tom do you know? For now we use > ap20 as the interface to the AVP side, and where we start up the A9. AP20 and T20 are different SKUs of Tegra 2/Tegra20. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/23] i2c: Add TPS6586X driver
On 04/09/2012 03:25 PM, Simon Glass wrote:
> Hi Stephen,
>
> On Mon, Apr 9, 2012 at 2:01 PM, Stephen Warren wrote:
>> On 04/02/2012 05:18 PM, Simon Glass wrote:
>>> This power management chip supports battery charging and a large number
>>> of power supplies. This initial driver only provides the ability to adjust
>>> the two synchronous buck converters SM0 and SM1 in a stepwise manner.
>>>
>>> Signed-off-by: Simon Glass
>>
>>> +#define MAX_I2C_RETRY3
>>> +int tps6586x_read(int reg)
>> ...
>>> + for (i = 0; i < MAX_I2C_RETRY; ++i) {
>>> + if (!i2c_read(I2C_ADDRESS, reg, 1, &data, 1)) {
>>> + retval = (int)data;
>>> + goto exit;
>>> + }
>>> +
>>> + /* i2c access failed, retry */
>>> + udelay(100);
>>> + }
>>
>> Why do we need this retry logic; the kernel driver doesn't appear to
>> have this.
>
> We apparently have found the device to be flaky on i2c sometimes,
> which is why this is here.
Is it the device itself, or bad board layout/...? Do we need something
similar in the kernel?
In general though, if we're having problems communicating with the PMIC,
we're pretty screwed; how do we know whether failed transactions simply
fail (e.g. no ACK), or send bogus data to the PMIC (e.g. set some random
register so that something gets programmed to be over-voltage)? A better
solution might be a full system reset when you fail to communicate with
the PMIC.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
On 04/09/2012 03:40 PM, Simon Glass wrote:
> +Olof
>
> Hi Stephen,
>
> On Mon, Apr 9, 2012 at 2:27 PM, Stephen Warren wrote:
>> On 04/05/2012 03:55 PM, Simon Glass wrote:
>>> From: Jimmy Zhang
>>>
>>> Set Seaboard to optimal memory settings based on the SOC in use (T20 or
>>> T25).
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>> Changes in v2:
>>> - Move EMC tables to device tree
>>> - Removed check for nominal voltage (not needed as it is done just before)
>>>
>>> Changes in v3:
>>> - Add better error reporting when EMC setup fails
>>>
>>> Changes in v4:
>>> - Remove support for T20 memory timings
>>
>>> diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
>>
>>> +/* This rate is hard-coded for now, until fdt provides them */
>>> +#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
>>> +
>>> +int board_emc_init(void)
>>> +{
>>> + unsigned rate;
>>> +
>>> + switch (tegra_get_chip_type()) {
>>> + default:
>>> + case TEGRA_SOC_T20:
>>> + debug("%s: EMC timings not supported for T20 Seaboard\n",
>>> + __func__);
>>
>> This isn't Seaboard-specific code, so the string shouldn't say
>> "Seaboard" there.
>>
>> Why not support Tegra20? Many/all of the other Tegra boards U-Boot
>> supports are Tegra20 not Tegra25.
>>
>> Presumably this code doesn't blow up if the EMC tables aren't in the
>> .dts file; the code should use the tables if they're present, otherwise
>> be a no-op.
>
> I don't mind, we can either go with v3 (with T20) or v4 (without).
> Both sets of patches are on the list and the removable of T20 support
> is the only change in v4. Please can you discuss this with Olof?
IIRC, Olof objected to the incorrect Seaboard .dts file (which contained
two unrelated sets of EMC tables for different board variants), not the
ability for the EMC driver itself to function on either Tegra20 or Tegra25.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
On Mon, Apr 9, 2012 at 2:59 PM, Stephen Warren wrote:
> On 04/09/2012 03:40 PM, Simon Glass wrote:
>> +Olof
>>
>> Hi Stephen,
>>
>> On Mon, Apr 9, 2012 at 2:27 PM, Stephen Warren wrote:
>>> On 04/05/2012 03:55 PM, Simon Glass wrote:
From: Jimmy Zhang
Set Seaboard to optimal memory settings based on the SOC in use (T20 or
T25).
Signed-off-by: Simon Glass
---
Changes in v2:
- Move EMC tables to device tree
- Removed check for nominal voltage (not needed as it is done just before)
Changes in v3:
- Add better error reporting when EMC setup fails
Changes in v4:
- Remove support for T20 memory timings
>>>
diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
>>>
+/* This rate is hard-coded for now, until fdt provides them */
+#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
+
+int board_emc_init(void)
+{
+ unsigned rate;
+
+ switch (tegra_get_chip_type()) {
+ default:
+ case TEGRA_SOC_T20:
+ debug("%s: EMC timings not supported for T20 Seaboard\n",
+ __func__);
>>>
>>> This isn't Seaboard-specific code, so the string shouldn't say
>>> "Seaboard" there.
>>>
>>> Why not support Tegra20? Many/all of the other Tegra boards U-Boot
>>> supports are Tegra20 not Tegra25.
>>>
>>> Presumably this code doesn't blow up if the EMC tables aren't in the
>>> .dts file; the code should use the tables if they're present, otherwise
>>> be a no-op.
>>
>> I don't mind, we can either go with v3 (with T20) or v4 (without).
>> Both sets of patches are on the list and the removable of T20 support
>> is the only change in v4. Please can you discuss this with Olof?
>
> IIRC, Olof objected to the incorrect Seaboard .dts file (which contained
> two unrelated sets of EMC tables for different board variants), not the
> ability for the EMC driver itself to function on either Tegra20 or Tegra25.
Correct. I objected to the one device tree describing 50% inaccurate
contents without a documented way to tell the accurate from inaccurate
(unlike the case with bootid straps).
What we do on the kernel side is that if the existing programming,
i.e. what's setup by BCT/u-boot is not matching the clocks in the
table, then we report it but continue with the existing settings. If
someone passes in bogus (matching) data in both BCT and the device
tree then all bets are off.
-Olof
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/23] tegra: warmboot (suspend / resume) support
Stephen, > -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Monday, April 09, 2012 2:54 PM > To: Simon Glass; Tom Warren > Cc: U-Boot Mailing List > Subject: Re: [PATCH v3 0/23] tegra: warmboot (suspend / resume) support > > On 04/02/2012 05:18 PM, Simon Glass wrote: > > This series adds support for warm boot, allowing the device to suspend > > and resume. U-Boot sets up some 'warm boot' code in a special area > > such that the SOC can find it on a resume. This code is responsible > > for setting up memory and clocked and then allowing the OS to continue > > where it left off. > > > > Also included here is support for the EMC, which allows setting the > > memory timings correctly in U-Boot for maximum speed operation. > > The series partially: > > Tested-by: Stephen Warren > > I tested that on both Harmony and Seaboard, this series didn't seem to > impact existing operation (boot to a command-prompt, load files from an SD > card, produce serial output). I didn't actually test LP0. > > Note: > > Neither board appears to be able to actually boot a kernel any more, failing > with the following error: > > = > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Warning: Neither atags nor dtb found > = > > However, this problem is present in u-boot-tegra/master before any changes > in this series. > > Tom, do you want me to file an internal bug for this? Has the upstream Seaboard (or Harmony) build ever been able to boot a kernel? I've never tried it, as I thought it was too incomplete for that yet (i.e. needs more drivers/periphs init'd first). You can file a bug if you wish as a placeholder. I'm not sure what's missing (if it's not a regression) - bootargs for a kernel? _ATAG config items? If they were there & were taken out in a particular patch series, I'd like to see the person responsible for that be tasked w/replacing them (edited, if need be, for current state such as WB/LP0 vec, usb/mmc boot, etc.). Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/23] tegra: warmboot (suspend / resume) support
On 04/09/2012 04:05 PM, Tom Warren wrote: > From: Stephen Warren wrote at Monday, April 09, 2012 2:54 PM: ... >> Note: >> >> Neither board appears to be able to actually boot a kernel any more, failing >> with the following error: >> >> = >> Starting kernel ... >> >> Uncompressing Linux... done, booting the kernel. >> Warning: Neither atags nor dtb found >> = >> >> However, this problem is present in u-boot-tegra/master before any changes >> in this series. >> >> Tom, do you want me to file an internal bug for this? > > Has the upstream Seaboard (or Harmony) build ever been able to boot a kernel? > I've never tried it, as I thought it was too incomplete for that yet (i.e. > needs more drivers/periphs init'd first). Yes, this (used to) work just fine, on both boards, booting with either ATAGs or device tree. Same for Ventana and Paz00. For reference, I use commit 9a4209869bd2c37affd931d627b3c3e72952 plus a few patches that have since been upstreamed, plus a local change to the default environment. I believe I tested a much later commmit than that while testing other patches of Simon's as well (an earlier version of the DT/USB/I2C patchset), but didn't update all my systems since I didn't need that functionality. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx: Add GPIO_TO_PORT macro
Am 09/04/2012 18:09, schrieb Vikram Narayanan: > Hi, > Hi, > > Yes. You are right. > So, instead of defining all the headers this way, > > #if defined(CONFIG_MX53) || defined(CONFIG_MX51) > #include > #elif defined(CONFIG_MX6) > #include > #endif > . etc We have not this code - I cannot find in u-boot, and wedo not want to introduce it. As you say, it is nasty. Where have you find it ? There is no driver including mx*_pins.h. At the moment, only board specific code includes the SOC specific pin header. > > Why not define the GPIO_TO_PORT macro in the driver? Maybe there was some use of the macro outside the driver in the past. I think before i.MX code was adapted to use common gpio_ functions, boards are used to write directly into the registers of the GPIO controller. I do not see any track of the macro in the current tree. So yes, we can move GPIO_ macros inside the driver. > Anyways for all its > the same 32 pins. Any suggestions/flames? It seems to me also that the defined GPIO_PORT for MX6 is wrong. arch/arm/include/asm/arch-mx6/imx-regs.h: #define GPIO_TO_PORT(number)(((number)/32)+1) Why is the port starting from 1 ? It is wrong, but really GPIO_TO_PORT() is not used anymore. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/23] i2c: Add TPS6586X driver
+Jimmy, who wrote the original pmu code
Hi Stephen,
On Mon, Apr 9, 2012 at 2:57 PM, Stephen Warren wrote:
> On 04/09/2012 03:25 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Apr 9, 2012 at 2:01 PM, Stephen Warren wrote:
>>> On 04/02/2012 05:18 PM, Simon Glass wrote:
This power management chip supports battery charging and a large number
of power supplies. This initial driver only provides the ability to adjust
the two synchronous buck converters SM0 and SM1 in a stepwise manner.
Signed-off-by: Simon Glass
>>>
+#define MAX_I2C_RETRY 3
+int tps6586x_read(int reg)
>>> ...
+ for (i = 0; i < MAX_I2C_RETRY; ++i) {
+ if (!i2c_read(I2C_ADDRESS, reg, 1, &data, 1)) {
+ retval = (int)data;
+ goto exit;
+ }
+
+ /* i2c access failed, retry */
+ udelay(100);
+ }
>>>
>>> Why do we need this retry logic; the kernel driver doesn't appear to
>>> have this.
>>
>> We apparently have found the device to be flaky on i2c sometimes,
>> which is why this is here.
>
> Is it the device itself, or bad board layout/...? Do we need something
> similar in the kernel?
I am not sure - Jimmy do you know?
>
> In general though, if we're having problems communicating with the PMIC,
> we're pretty screwed; how do we know whether failed transactions simply
> fail (e.g. no ACK), or send bogus data to the PMIC (e.g. set some random
> register so that something gets programmed to be over-voltage)? A better
> solution might be a full system reset when you fail to communicate with
> the PMIC.
I believe the problem is that there is no ACK - it would be pretty bad
if it ACKed but didn't work :-)
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
Hi Stephen,
On Mon, Apr 9, 2012 at 3:03 PM, Olof Johansson wrote:
> On Mon, Apr 9, 2012 at 2:59 PM, Stephen Warren wrote:
>> On 04/09/2012 03:40 PM, Simon Glass wrote:
>>> +Olof
>>>
>>> Hi Stephen,
>>>
>>> On Mon, Apr 9, 2012 at 2:27 PM, Stephen Warren
>>> wrote:
On 04/05/2012 03:55 PM, Simon Glass wrote:
> From: Jimmy Zhang
>
> Set Seaboard to optimal memory settings based on the SOC in use (T20 or
> T25).
>
> Signed-off-by: Simon Glass
> ---
> Changes in v2:
> - Move EMC tables to device tree
> - Removed check for nominal voltage (not needed as it is done just before)
>
> Changes in v3:
> - Add better error reporting when EMC setup fails
>
> Changes in v4:
> - Remove support for T20 memory timings
> diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
> +/* This rate is hard-coded for now, until fdt provides them */
> +#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
> +
> +int board_emc_init(void)
> +{
> + unsigned rate;
> +
> + switch (tegra_get_chip_type()) {
> + default:
> + case TEGRA_SOC_T20:
> + debug("%s: EMC timings not supported for T20 Seaboard\n",
> + __func__);
This isn't Seaboard-specific code, so the string shouldn't say
"Seaboard" there.
Why not support Tegra20? Many/all of the other Tegra boards U-Boot
supports are Tegra20 not Tegra25.
Presumably this code doesn't blow up if the EMC tables aren't in the
.dts file; the code should use the tables if they're present, otherwise
be a no-op.
>>>
>>> I don't mind, we can either go with v3 (with T20) or v4 (without).
>>> Both sets of patches are on the list and the removable of T20 support
>>> is the only change in v4. Please can you discuss this with Olof?
>>
>> IIRC, Olof objected to the incorrect Seaboard .dts file (which contained
>> two unrelated sets of EMC tables for different board variants), not the
>> ability for the EMC driver itself to function on either Tegra20 or Tegra25.
>
> Correct. I objected to the one device tree describing 50% inaccurate
> contents without a documented way to tell the accurate from inaccurate
> (unlike the case with bootid straps).
>
> What we do on the kernel side is that if the existing programming,
> i.e. what's setup by BCT/u-boot is not matching the clocks in the
> table, then we report it but continue with the existing settings. If
> someone passes in bogus (matching) data in both BCT and the device
> tree then all bets are off.
OK, that's different from what I understood (remove support for T20
Seaboard as was apparently done in the kernel). So I think this means
that this patch should revert back to the original version, right?
>
>
> -Olof
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] gunzip: rename z{alloc, free} to gz{alloc, free}
This allows us to add a proper zalloc() func (one that does a zeroing
alloc), and removes duplicate prototypes.
Signed-off-by: Mike Frysinger
---
fs/cramfs/uncompress.c |7 ++-
include/u-boot/zlib.h |3 +++
lib/gunzip.c | 11 ---
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/fs/cramfs/uncompress.c b/fs/cramfs/uncompress.c
index 228fe68..f431cc4 100644
--- a/fs/cramfs/uncompress.c
+++ b/fs/cramfs/uncompress.c
@@ -27,9 +27,6 @@
static z_stream stream;
-void *zalloc(void *, unsigned, unsigned);
-void zfree(void *, void *, unsigned);
-
/* Returns length of decompressed data. */
int cramfs_uncompress_block (void *dst, void *src, int srclen)
{
@@ -59,8 +56,8 @@ int cramfs_uncompress_init (void)
{
int err;
- stream.zalloc = zalloc;
- stream.zfree = zfree;
+ stream.zalloc = gzalloc;
+ stream.zfree = gzfree;
stream.next_in = 0;
stream.avail_in = 0;
diff --git a/include/u-boot/zlib.h b/include/u-boot/zlib.h
index fb27081..fbb08a3 100644
--- a/include/u-boot/zlib.h
+++ b/include/u-boot/zlib.h
@@ -691,6 +691,9 @@ ZEXTERN int ZEXPORT inflateInit2_ OF((z_streamp strm, int
windowBits,
struct internal_state {int dummy;}; /* hack for buggy compilers */
#endif
+extern void *gzalloc(void *, unsigned, unsigned);
+extern void gzfree(void *, void *, unsigned);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/gunzip.c b/lib/gunzip.c
index 8b16b24..99a8ab0 100644
--- a/lib/gunzip.c
+++ b/lib/gunzip.c
@@ -36,10 +36,7 @@
#define RESERVED 0xe0
#define DEFLATED 8
-void *zalloc(void *, unsigned, unsigned);
-void zfree(void *, void *, unsigned);
-
-void *zalloc(void *x, unsigned items, unsigned size)
+void *gzalloc(void *x, unsigned items, unsigned size)
{
void *p;
@@ -51,7 +48,7 @@ void *zalloc(void *x, unsigned items, unsigned size)
return (p);
}
-void zfree(void *x, void *addr, unsigned nb)
+void gzfree(void *x, void *addr, unsigned nb)
{
free (addr);
}
@@ -94,8 +91,8 @@ int zunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp,
z_stream s;
int r;
- s.zalloc = zalloc;
- s.zfree = zfree;
+ s.zalloc = gzalloc;
+ s.zfree = gzfree;
r = inflateInit2(&s, -MAX_WBITS);
if (r != Z_OK) {
--
1.7.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] lin_gadget: use common linux/compat.h
Merge our duplicate definitions with the common header.
Signed-off-by: Mike Frysinger
---
include/linux/compat.h |3 +++
include/usb/lin_gadget_compat.h | 15 ++-
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 39c693f..593b07f 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -48,5 +48,8 @@
#define BUG_ON(condition) do { if (condition) BUG(); } while(0)
#endif /* BUG */
+#define WARN_ON(x) if (x) {printf("WARNING in %s line %d\n" \
+ , __FILE__, __LINE__); }
+
#define PAGE_SIZE 4096
#endif
diff --git a/include/usb/lin_gadget_compat.h b/include/usb/lin_gadget_compat.h
index 1b937e4..8287b9d 100644
--- a/include/usb/lin_gadget_compat.h
+++ b/include/usb/lin_gadget_compat.h
@@ -23,6 +23,8 @@
#ifndef __LIN_COMPAT_H__
#define __LIN_COMPAT_H__
+#include
+
/* common */
#define spin_lock_init(...)
#define spin_lock(...)
@@ -36,25 +38,12 @@
#define mutex_lock(...)
#define mutex_unlock(...)
-#define WARN_ON(x) if (x) {printf("WARNING in %s line %d\n" \
- , __FILE__, __LINE__); }
-
-#define KERN_WARNING
-#define KERN_ERR
-#define KERN_NOTICE
-#define KERN_DEBUG
-
#define GFP_KERNEL 0
#define IRQ_HANDLED1
#define ENOTSUPP 524 /* Operation is not supported */
-#define kmalloc(size, type) memalign(CONFIG_SYS_CACHELINE_SIZE, size)
-#define kfree(addr) free(addr)
-
-#define __iomem
-#define min_t min
#define dma_cache_maint(addr, size, mode) cache_flush()
void cache_flush(void);
--
1.7.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] lin_gadget: use common mdelay
No need to provide our own mdelay() macro when we have a func for it.
Signed-off-by: Mike Frysinger
---
include/usb/lin_gadget_compat.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/usb/lin_gadget_compat.h b/include/usb/lin_gadget_compat.h
index fce3be7..1b937e4 100644
--- a/include/usb/lin_gadget_compat.h
+++ b/include/usb/lin_gadget_compat.h
@@ -52,7 +52,6 @@
#define kmalloc(size, type) memalign(CONFIG_SYS_CACHELINE_SIZE, size)
#define kfree(addr) free(addr)
-#define mdelay(n) ({unsigned long msec = (n); while (msec--) udelay(1000); })
#define __iomem
#define min_t min
--
1.7.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] linux/compat.h: rename from linux/mtd/compat.h
This lets us use it in more places than just mtd code.
Signed-off-by: Mike Frysinger
---
board/samsung/smdkc100/onenand.c|2 +-
common/cmd_onenand.c|2 +-
common/env_onenand.c|2 +-
drivers/mtd/mtdconcat.c |2 +-
drivers/mtd/mtdcore.c |2 +-
drivers/mtd/mtdpart.c |2 +-
drivers/mtd/nand/mpc5121_nfc.c |2 +-
drivers/mtd/nand/nand_base.c|2 +-
drivers/mtd/nand/nand_bbt.c |2 +-
drivers/mtd/onenand/onenand_base.c |2 +-
drivers/mtd/onenand/onenand_bbt.c |2 +-
drivers/mtd/onenand/onenand_uboot.c |2 +-
drivers/mtd/onenand/samsung.c |2 +-
fs/jffs2/jffs2_1pass.c |2 +-
include/linux/{mtd => }/compat.h|0
include/linux/err.h |2 +-
include/linux/mtd/mtd-abi.h |2 +-
include/linux/mtd/nand.h|2 +-
include/linux/mtd/onenand.h |2 +-
include/nand.h |2 +-
20 files changed, 19 insertions(+), 19 deletions(-)
rename include/linux/{mtd => }/compat.h (100%)
diff --git a/board/samsung/smdkc100/onenand.c b/board/samsung/smdkc100/onenand.c
index 501855e..e34cd31 100644
--- a/board/samsung/smdkc100/onenand.c
+++ b/board/samsung/smdkc100/onenand.c
@@ -22,7 +22,7 @@
*/
#include
-#include
+#include
#include
#include
#include
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index 0f2e208..a0d25e5 100644
--- a/common/cmd_onenand.c
+++ b/common/cmd_onenand.c
@@ -13,7 +13,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/common/env_onenand.c b/common/env_onenand.c
index 652665a..7197ab6 100644
--- a/common/env_onenand.c
+++ b/common/env_onenand.c
@@ -33,7 +33,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index fc22701..e6d9384 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -9,7 +9,7 @@
*/
#include
-#include
+#include
#include
#include
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index a195dda..3a81ada 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -8,7 +8,7 @@
*/
#include
-#include
+#include
#include
struct mtd_info *mtd_table[MAX_MTD_DEVICES];
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index f647e43..96dcda2 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
/* Our partition linked list */
struct list_head mtd_partitions;
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 7fd8a35..e6b7a70 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -29,7 +29,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 44f7b91..bef79be 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -39,7 +39,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2b730e0..dc6c648 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -61,7 +61,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 480ae7a..96a5b08 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -20,7 +20,7 @@
*/
#include
-#include
+#include
#include
#include
diff --git a/drivers/mtd/onenand/onenand_bbt.c
b/drivers/mtd/onenand/onenand_bbt.c
index 1354877..9d5da54 100644
--- a/drivers/mtd/onenand/onenand_bbt.c
+++ b/drivers/mtd/onenand/onenand_bbt.c
@@ -15,7 +15,7 @@
*/
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/mtd/onenand/onenand_uboot.c
b/drivers/mtd/onenand/onenand_uboot.c
index c642016..ae60c3b 100644
--- a/drivers/mtd/onenand/onenand_uboot.c
+++ b/drivers/mtd/onenand/onenand_uboot.c
@@ -14,7 +14,7 @@
*/
#include
-#include
+#include
#include
#include
diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index c9d33ec..0d94ea5 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -28,7 +28,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index a0b02e4..c856983 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -119,7 +119,7 @@
#include
#include
#include
-#include
+#include
#include
#include "jffs2_private.h"
diff --git a/include/linux/mtd/compat.h b/include/linux/compat.h
similarity index 100%
rename from include/linux/mtd/compat.h
rename to incl
[U-Boot] [PATCH v4 1/4] mmc: sdhci: add the quirk for broken r1b response
When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
but in while(), didn't check that flag.
So sdhci controller didn't work fine.
CMD6 didn't always complete.
So add the quirks for broken r1b response
and add the timeout value to prevent the infinite loop.
Signed-off-by: Jaehoon Chung
Signed-off-by: Kyungmin Park
---
drivers/mmc/sdhci.c | 12
include/sdhci.h |1 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index fc904b5..4de19e8 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -128,6 +128,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
int trans_bytes = 0, is_aligned = 1;
u32 mask, flags, mode;
unsigned int timeout, start_addr = 0;
+ unsigned int retry = 1000;
/* Wait max 10 ms */
timeout = 10;
@@ -210,8 +211,19 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
+ if (retry-- == 0)
+ break;
} while ((stat & mask) != mask);
+ if (retry == 0) {
+ if (host->quirks == SDHCI_QUIRK_BROKEN_R1B)
+ return 0;
+ else {
+ printf("Timeout for stauts update!\n");
+ return TIMEOUT;
+ }
+ }
+
if ((stat & (SDHCI_INT_ERROR | mask)) == mask) {
sdhci_cmd_done(host, cmd);
sdhci_writel(host, mask, SDHCI_INT_STATUS);
diff --git a/include/sdhci.h b/include/sdhci.h
index 800f9d9..a2415ba 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -216,6 +216,7 @@
*/
#define SDHCI_QUIRK_32BIT_DMA_ADDR (1 << 0)
#define SDHCI_QUIRK_REG32_RW (1 << 1)
+#define SDHCI_QUIRK_BROKEN_R1B (1 << 2)
/* to make gcc happy */
struct sdhci_host;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/4] mmc: support sdhci instead of s5p_mmc
This patchset is supported the sdhci controller for Samsung-SoC. In mmc driver, already implemented the generic sdhci. There is no reason that didn't use sdhci.c. So, use the sdhci instead of s5p_mmc. Changelog-v4: - seperate the device driver and SoC patch. Changelog-v3: - Add the quirks for broken R1b response. - Add the timeout to prevent infinite loop. Changelog-v2: - removed the s5p_mmc.c - based-on u-boot-samsung repository. Jaehoon Chung (4): mmc: sdhci: add the quirk for broken r1b response mmc: add the quirk to use the sdhci for samsung-soc mmc: support the sdhci instead of s5p_mmc for samsung-soc ARM: SAMSUNG: support sdhci controller arch/arm/include/asm/arch-exynos/mmc.h | 93 +++--- arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++--- drivers/mmc/Makefile|2 +- drivers/mmc/s5p_mmc.c | 490 --- drivers/mmc/s5p_sdhci.c | 98 ++ drivers/mmc/sdhci.c | 24 ++ include/configs/origen.h|3 +- include/configs/s5p_goni.h |3 +- include/configs/s5pc210_universal.h |3 +- include/configs/smdk5250.h |3 +- include/configs/smdkv310.h |3 +- include/configs/trats.h |3 +- include/sdhci.h |7 + 13 files changed, 236 insertions(+), 589 deletions(-) delete mode 100644 drivers/mmc/s5p_mmc.c create mode 100644 drivers/mmc/s5p_sdhci.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/4] mmc: add the quirk to use the sdhci for samsung-soc
To support the Samsung-SoC, added the basically functions.
Samsung-SoC didn't used the SDHCI_CTRL_HISPD.
And added set_control_reg callback for s3c64xx.
Signed-off-by: Jaehoon Chung
Signed-off-by: Kyungmin Park
---
drivers/mmc/sdhci.c | 12
include/sdhci.h |6 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 4de19e8..a5d89c1 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -337,6 +337,9 @@ void sdhci_set_ios(struct mmc *mmc)
u32 ctrl;
struct sdhci_host *host = (struct sdhci_host *)mmc->priv;
+ if (host->set_control_reg)
+ host->set_control_reg(host);
+
if (mmc->clock != host->clock)
sdhci_set_clock(mmc, mmc->clock);
@@ -360,6 +363,9 @@ void sdhci_set_ios(struct mmc *mmc)
else
ctrl &= ~SDHCI_CTRL_HISPD;
+ if (host->quirks & SDHCI_QUIRK_NO_HISPD_BIT)
+ ctrl &= ~SDHCI_CTRL_HISPD;
+
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
}
@@ -443,9 +449,15 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk, u32
min_clk)
mmc->voltages |= MMC_VDD_29_30 | MMC_VDD_30_31;
if (caps & SDHCI_CAN_VDD_180)
mmc->voltages |= MMC_VDD_165_195;
+
+ if (host->quirks & SDHCI_QUIRK_BROKEN_VOLTAGE)
+ mmc->voltages |= host->voltages;
+
mmc->host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz | MMC_MODE_4BIT;
if (caps & SDHCI_CAN_DO_8BIT)
mmc->host_caps |= MMC_MODE_8BIT;
+ if (host->host_caps)
+ mmc->host_caps |= host->host_caps;
sdhci_reset(host, SDHCI_RESET_ALL);
mmc_register(mmc);
diff --git a/include/sdhci.h b/include/sdhci.h
index a2415ba..9d37183 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -217,6 +217,8 @@
#define SDHCI_QUIRK_32BIT_DMA_ADDR (1 << 0)
#define SDHCI_QUIRK_REG32_RW (1 << 1)
#define SDHCI_QUIRK_BROKEN_R1B (1 << 2)
+#define SDHCI_QUIRK_NO_HISPD_BIT (1 << 3)
+#define SDHCI_QUIRK_BROKEN_VOLTAGE (1 << 4)
/* to make gcc happy */
struct sdhci_host;
@@ -241,10 +243,14 @@ struct sdhci_host {
char *name;
void *ioaddr;
unsigned int quirks;
+ unsigned int host_caps;
unsigned int version;
unsigned int clock;
struct mmc *mmc;
const struct sdhci_ops *ops;
+
+ void (*set_control_reg)(struct sdhci_host *host);
+ uintvoltages;
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/4] mmc: support the sdhci instead of s5p_mmc for samsung-soc
In driver mmc, generic s5p_sdhci code is implemented.
s5p_mmc file is dupulicated.
we are good that use the generic sdhci.
This patch supported the sdhci for Samsung-SoC.
Signed-off-by: Jaehoon Chung
---
arch/arm/include/asm/arch-exynos/mmc.h | 93 +++---
arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++---
drivers/mmc/Makefile|2 +-
drivers/mmc/s5p_mmc.c | 490 ---
drivers/mmc/s5p_sdhci.c | 98 ++
5 files changed, 193 insertions(+), 583 deletions(-)
delete mode 100644 drivers/mmc/s5p_mmc.c
create mode 100644 drivers/mmc/s5p_sdhci.c
diff --git a/arch/arm/include/asm/arch-exynos/mmc.h
b/arch/arm/include/asm/arch-exynos/mmc.h
index 30f82b8..0f701c9 100644
--- a/arch/arm/include/asm/arch-exynos/mmc.h
+++ b/arch/arm/include/asm/arch-exynos/mmc.h
@@ -21,53 +21,54 @@
#ifndef __ASM_ARCH_MMC_H_
#define __ASM_ARCH_MMC_H_
-#ifndef __ASSEMBLY__
-struct s5p_mmc {
- unsigned intsysad;
- unsigned short blksize;
- unsigned short blkcnt;
- unsigned intargument;
- unsigned short trnmod;
- unsigned short cmdreg;
- unsigned intrspreg0;
- unsigned intrspreg1;
- unsigned intrspreg2;
- unsigned intrspreg3;
- unsigned intbdata;
- unsigned intprnsts;
- unsigned char hostctl;
- unsigned char pwrcon;
- unsigned char blkgap;
- unsigned char wakcon;
- unsigned short clkcon;
- unsigned char timeoutcon;
- unsigned char swrst;
- unsigned intnorintsts; /* errintsts */
- unsigned intnorintstsen;/* errintstsen */
- unsigned intnorintsigen;/* errintsigen */
- unsigned short acmd12errsts;
- unsigned char res1[2];
- unsigned intcapareg;
- unsigned char res2[4];
- unsigned intmaxcurr;
- unsigned char res3[0x34];
- unsigned intcontrol2;
- unsigned intcontrol3;
- unsigned char res4[4];
- unsigned intcontrol4;
- unsigned char res5[0x6e];
- unsigned short hcver;
- unsigned char res6[0xFF00];
-};
+#define SDHCI_CONTROL2 0x80
+#define SDHCI_CONTROL3 0x84
+#define SDHCI_CONTROL4 0x8C
-struct mmc_host {
- struct s5p_mmc *reg;
- unsigned int version; /* SDHCI spec. version */
- unsigned int clock; /* Current clock (MHz) */
- int dev_index;
-};
+#define SDHCI_CTRL2_ENSTAASYNCCLR (1 << 31)
+#define SDHCI_CTRL2_ENCMDCNFMSK(1 << 30)
+#define SDHCI_CTRL2_CDINVRXD3 (1 << 29)
+#define SDHCI_CTRL2_SLCARDOUT (1 << 28)
-int s5p_mmc_init(int dev_index, int bus_width);
+#define SDHCI_CTRL2_FLTCLKSEL_MASK (0xf << 24)
+#define SDHCI_CTRL2_FLTCLKSEL_SHIFT(24)
+#define SDHCI_CTRL2_FLTCLKSEL(_x) ((_x) << 24)
-#endif /* __ASSEMBLY__ */
+#define SDHCI_CTRL2_LVLDAT_MASK(0xff << 16)
+#define SDHCI_CTRL2_LVLDAT_SHIFT (16)
+#define SDHCI_CTRL2_LVLDAT(_x) ((_x) << 16)
+
+#define SDHCI_CTRL2_ENFBCLKTX (1 << 15)
+#define SDHCI_CTRL2_ENFBCLKRX (1 << 14)
+#define SDHCI_CTRL2_SDCDSEL(1 << 13)
+#define SDHCI_CTRL2_SDSIGPC(1 << 12)
+#define SDHCI_CTRL2_ENBUSYCHKTXSTART (1 << 11)
+
+#define SDHCI_CTRL2_DFCNT_MASK(_x) ((_x) << 9)
+#define SDHCI_CTRL2_DFCNT_SHIFT(9)
+
+#define SDHCI_CTRL2_ENCLKOUTHOLD (1 << 8)
+#define SDHCI_CTRL2_RWAITMODE (1 << 7)
+#define SDHCI_CTRL2_DISBUFRD (1 << 6)
+#define SDHCI_CTRL2_SELBASECLK_MASK(_x)((_x) << 4)
+#define SDHCI_CTRL2_SELBASECLK_SHIFT (4)
+#define SDHCI_CTRL2_PWRSYNC(1 << 3)
+#define SDHCI_CTRL2_ENCLKOUTMSKCON (1 << 1)
+#define SDHCI_CTRL2_HWINITFIN (1 << 0)
+
+#define SDHCI_CTRL3_FCSEL3 (1 << 31)
+#define SDHCI_CTRL3_FCSEL2 (1 << 23)
+#define SDHCI_CTRL3_FCSEL1 (1 << 15)
+#define SDHCI_CTRL3_FCSEL0 (1 << 7)
+
+#define SDHCI_CTRL4_DRIVE_MASK(_x) ((_x) << 16)
+#define SDHCI_CTRL4_DRIVE_SHIFT(16)
+
+int s5p_sdhci_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks);
+
+static inline unsigned int s5p_mmc_init(int index, int bus_width)
+{
+ unsigned int base = samsung_get_base_mmc() + (0x1 * index);
+ return s5p_sdhci_init(base, 5200, 40, index);
+}
#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
index adef4ee..0f701c9 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
@@ -21,53 +21,54 @@
#ifndef __ASM_ARCH_MMC_H_
#define __ASM_ARCH_MMC_H_
-#ifndef __ASSEMBLY__
-struct s5p_mmc {
- unsigned intsysad;
- unsigned short blksize;
- unsigned short blkcnt;
- unsigned intargument;
- unsigned short trnmod;
- unsigned short cmdreg
[U-Boot] [PATCH v4 4/4] ARM: SAMSUNG: support sdhci controller
To support sdhci controller, remove the CONFIG_S5P_MMC.. Instead, use the CONFIG_S5P_SDHCI/CONFIG_SDHCI. Signed-off-by: Jaehoon Chung Signed-off-by: Kyungmin Park --- include/configs/origen.h|3 ++- include/configs/s5p_goni.h |3 ++- include/configs/s5pc210_universal.h |3 ++- include/configs/smdk5250.h |3 ++- include/configs/smdkv310.h |3 ++- include/configs/trats.h |3 ++- 6 files changed, 12 insertions(+), 6 deletions(-) diff --git a/include/configs/origen.h b/include/configs/origen.h index 8ede825..ea8066f 100644 --- a/include/configs/origen.h +++ b/include/configs/origen.h @@ -71,7 +71,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 56b5547..f659699 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -65,7 +65,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/s5pc210_universal.h b/include/configs/s5pc210_universal.h index 1301275..241d209 100644 --- a/include/configs/s5pc210_universal.h +++ b/include/configs/s5pc210_universal.h @@ -68,7 +68,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 9659f9e..0f63040 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -78,7 +78,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC #define CONFIG_MMC -#define CONFIG_S5P_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h index 93c25da..077f0e0 100644 --- a/include/configs/smdkv310.h +++ b/include/configs/smdkv310.h @@ -70,7 +70,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC 1 #define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_SDHCI 1 +#define CONFIG_S5P_SDHCI 1 /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/trats.h b/include/configs/trats.h index 10f11d9..71b9393 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -74,7 +74,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC #define CONFIG_MMC -#define CONFIG_S5P_MMC +#define CONFIG_S5P_SDHCI +#define CONFIG_SDHCI /* PWM */ #define CONFIG_PWM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx: Add GPIO_TO_PORT macro
Hi Stefano, On 4/10/2012 4:01 AM, stefano babic wrote: Am 09/04/2012 18:09, schrieb Vikram Narayanan: Hi, Hi, Yes. You are right. So, instead of defining all the headers this way, #if defined(CONFIG_MX53) || defined(CONFIG_MX51) #include #elif defined(CONFIG_MX6) #include #endif . etc We have not this code - I cannot find in u-boot, and wedo not want to introduce it. As you say, it is nasty. Where have you find it ? I don't find it anyway. If I want to use the existing macro, it would result in this. There is no driver including mx*_pins.h. At the moment, only board specific code includes the SOC specific pin header. Why not define the GPIO_TO_PORT macro in the driver? Maybe there was some use of the macro outside the driver in the past. I think before i.MX code was adapted to use common gpio_ functions, boards are used to write directly into the registers of the GPIO controller. I do not see any track of the macro in the current tree. So yes, we can move GPIO_ macros inside the driver. Sure. I'll just do that. Anyways for all its the same 32 pins. Any suggestions/flames? It seems to me also that the defined GPIO_PORT for MX6 is wrong. arch/arm/include/asm/arch-mx6/imx-regs.h: #define GPIO_TO_PORT(number)(((number)/32)+1) Why is the port starting from 1 ? It is wrong, but really GPIO_TO_PORT() is not used anymore. Yes. You are right. I'll send the v2 for this. Thanks for your response, Vikram Best regards, Stefano Babic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
On 04/09/2012 05:07 PM, Simon Glass wrote:
> Hi Stephen,
>
> On Mon, Apr 9, 2012 at 3:03 PM, Olof Johansson wrote:
>> On Mon, Apr 9, 2012 at 2:59 PM, Stephen Warren wrote:
>>> On 04/09/2012 03:40 PM, Simon Glass wrote:
+Olof
Hi Stephen,
On Mon, Apr 9, 2012 at 2:27 PM, Stephen Warren
wrote:
> On 04/05/2012 03:55 PM, Simon Glass wrote:
>> From: Jimmy Zhang
>>
>> Set Seaboard to optimal memory settings based on the SOC in use (T20 or
>> T25).
>>
>> Signed-off-by: Simon Glass
>> ---
>> Changes in v2:
>> - Move EMC tables to device tree
>> - Removed check for nominal voltage (not needed as it is done just
>> before)
>>
>> Changes in v3:
>> - Add better error reporting when EMC setup fails
>>
>> Changes in v4:
>> - Remove support for T20 memory timings
>
>> diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
>
>> +/* This rate is hard-coded for now, until fdt provides them */
>> +#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
>> +
>> +int board_emc_init(void)
>> +{
>> + unsigned rate;
>> +
>> + switch (tegra_get_chip_type()) {
>> + default:
>> + case TEGRA_SOC_T20:
>> + debug("%s: EMC timings not supported for T20 Seaboard\n",
>> + __func__);
>
> This isn't Seaboard-specific code, so the string shouldn't say
> "Seaboard" there.
>
> Why not support Tegra20? Many/all of the other Tegra boards U-Boot
> supports are Tegra20 not Tegra25.
>
> Presumably this code doesn't blow up if the EMC tables aren't in the
> .dts file; the code should use the tables if they're present, otherwise
> be a no-op.
I don't mind, we can either go with v3 (with T20) or v4 (without).
Both sets of patches are on the list and the removable of T20 support
is the only change in v4. Please can you discuss this with Olof?
>>>
>>> IIRC, Olof objected to the incorrect Seaboard .dts file (which contained
>>> two unrelated sets of EMC tables for different board variants), not the
>>> ability for the EMC driver itself to function on either Tegra20 or Tegra25.
>>
>> Correct. I objected to the one device tree describing 50% inaccurate
>> contents without a documented way to tell the accurate from inaccurate
>> (unlike the case with bootid straps).
>>
>> What we do on the kernel side is that if the existing programming,
>> i.e. what's setup by BCT/u-boot is not matching the clocks in the
>> table, then we report it but continue with the existing settings. If
>> someone passes in bogus (matching) data in both BCT and the device
>> tree then all bets are off.
>
> OK, that's different from what I understood (remove support for T20
> Seaboard as was apparently done in the kernel). So I think this means
> that this patch should revert back to the original version, right?
In the kernel, the Seaboard .dts file only supports Tegra25 since the
EMC tables we put into that .dts file are for Tegra25. There is no
Seaboard-with-Tegra20 .dts file.
I don't believe the EMC driver has any code that cares about
Tegra20-vs-Tegra25, so should work just fine for either.
In practice, we don't have any .dts files for boards with Tegra20 that
contain EMC tables though.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
On Monday 09 April 2012 02:45:03 Marek Vasut wrote: > @@ -765,9 +767,6 @@ > > -__attribute__ ((__aligned__ (__alignof__ (dir_entry > -__u8 do_fat_read_block[MAX_CLUSTSIZE]; > - > > @@ -788,6 +787,7 @@ do_fat_read (const char *filename, void *buffer, > > int rootdir_size = 0; > int j; > + uint8_t do_fat_read_block[MAX_CLUSTSIZE] __attribute__((aligned(32))); what's going on here exactly ? the old code had the advantage of being in the bss and the linker taking care of the alignment. this new code has an incorrectly hard-coded "32", and puts a 64KiB array onto the *stack*. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
On Tuesday 03 April 2012 05:31:09 Lei Wen wrote: > Hi Mike, > > On Tue, Apr 3, 2012 at 3:17 AM, Mike Frysinger wrote: > > On Tue, Mar 27, 2012 at 04:04, Lei Wen wrote: > >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: > >>> From: Lei Wen > >>> > >>> This patch set add zip command support for uboot. > >>> The first two patches import deflate and trees functions from zlib > >>> 1.2.5 without any change. While the third patch did the necessary > >>> change to make the import file could be built passed in uboot > >>> environment. > >> > >> Any comments to this series? > > > > did you forward port the misc fixes/optimization that were done ? or > > did you just drop in the new code ? > > The fixes/optimization is already separated in different patch, as the > 0004 in current series. > Other file is just import as intact from zlib1.2.5, the 0001 and 0002 > patch. i don't understand what you mean. 0004 is "lib: zlib: remove the limitation for cannot using 0 as start" and doesn't look like a fix that was merged before. > > for example, cd514aeb996e2f7aefbe1f78481965d9d074aed4 is pretty important > > I see. I try my best to keep the current modification history adding > to the original zlib code. so you have maintained the bug fixes / optimizations ? it isn't clear in your response (at least to me). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv writes to bootdelay but not ethaddr
On Sunday 08 April 2012 18:16:51 Bishop, Mark wrote:
> > -Original Message-
> > From: Mike Frysinger [mailto:vap...@gentoo.org]
> > Sent: Sunday, April 08, 2012 5:32 PM
> > To: Bishop, Mark
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] fw_setenv writes to bootdelay but not ethaddr
> >
> > On Sunday 08 April 2012 17:15:26 Bishop, Mark wrote:
> > > From: Mike Frysinger [mailto:vap...@gentoo.org]
> > >
> > > > On Thursday 05 April 2012 16:32:11 Bishop, Mark wrote:
> > > > > root:/> fw_setenv ethaddr X1:X2:X3:X4:X5:X6 Can't overwrite
> > > > > "ethaddr"
> > > >
> > > > looks correct to me. you probably didn't set CONFIG_ENV_OVERWRITE.
> > >
> > > I wish it was so:
> > > #define CONFIG_ENV_OVERWRITE1
> > > is present in my board file.
> > >
> > > I've checked to make sure that it is the correct header file. I've
> > > also checked to make sure that CONFIG_OVERWRITE_ETHADDR_ONCE is not
> >
> > set.
> >
> > > I'm using the slightly outdated uclinux uboot from their head repo
> >
> > and
> >
> > > I am checking the patches applied to the uboot head if any were to
> >
> > fix
> >
> > > something like this.
> >
> > sorry, should have been a little clearer. the tools installed by
> > uclinux-dist do not have a config, so it uses the default one. the
> > CONFIG_xxx settings in your u-boot don't get used. fw_printenv has to
> > be built with those config settings.
> > -mike
>
> The entire conditional in fw_env_write() is wacked out.
>
> If the value is already set, then it never sets it again.
>
> .
> if ((oldval = envmatch (name, env)) != NULL)
> break;
> }
>
> /*
> * Delete any existing definition
> */
> if (oldval) {
> /*
> * Ethernet Address and serial# can be set only once
> */
> if ((strcmp (name, "ethaddr") == 0) ||
> (strcmp (name, "serial#") == 0)) {
> fprintf (stderr, "Can't overwrite \"%s\"\n", name);
> errno = EROFS;
> return -1;
> .
>
> I would have expected it to use a #ifdef CONFIG_OVERWRITE_ETHADDR_ONCE, but
> this is only supposed to be an example.
maybe the code base you're using is old. when i look at u-boot mainline, i
see that being protected by "#ifndef CONFIG_ENV_OVERWRITE".
> I am just going to remove the guard and move on.
should be fine as well
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Mike, On Tue, Apr 10, 2012 at 12:37 PM, Mike Frysinger wrote: > On Tuesday 03 April 2012 05:31:09 Lei Wen wrote: >> Hi Mike, >> >> On Tue, Apr 3, 2012 at 3:17 AM, Mike Frysinger wrote: >> > On Tue, Mar 27, 2012 at 04:04, Lei Wen wrote: >> >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >> >>> From: Lei Wen >> >>> >> >>> This patch set add zip command support for uboot. >> >>> The first two patches import deflate and trees functions from zlib >> >>> 1.2.5 without any change. While the third patch did the necessary >> >>> change to make the import file could be built passed in uboot >> >>> environment. >> >> >> >> Any comments to this series? >> > >> > did you forward port the misc fixes/optimization that were done ? or >> > did you just drop in the new code ? >> >> The fixes/optimization is already separated in different patch, as the >> 0004 in current series. >> Other file is just import as intact from zlib1.2.5, the 0001 and 0002 >> patch. > > i don't understand what you mean. 0004 is "lib: zlib: remove the limitation > for cannot using 0 as start" and doesn't look like a fix that was merged > before. > >> > for example, cd514aeb996e2f7aefbe1f78481965d9d074aed4 is pretty important >> >> I see. I try my best to keep the current modification history adding >> to the original zlib code. > > so you have maintained the bug fixes / optimizations ? it isn't clear in your > response (at least to me). I see what your concerns... Yes, this change is not included in the zlib's own code, but just added by myself. Without this change, in uboot, we cannot zip from the start of ddr memory, since many platforms, at least from what I saw, their start ddr memory address is from 0. If you are still not comfortable with this patch, I could remove the 004 from patch set. What do you think of this suggestion? > -mike Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: Properly align buffers to allow cache operations
Dear Mike Frysinger, > On Monday 09 April 2012 02:45:03 Marek Vasut wrote: > > @@ -765,9 +767,6 @@ > > > > -__attribute__ ((__aligned__ (__alignof__ (dir_entry > > -__u8 do_fat_read_block[MAX_CLUSTSIZE]; > > - > > > > @@ -788,6 +787,7 @@ do_fat_read (const char *filename, void *buffer, > > > > int rootdir_size = 0; > > int j; > > > > + uint8_t do_fat_read_block[MAX_CLUSTSIZE] __attribute__((aligned(32))); > > what's going on here exactly ? the old code had the advantage of being in > the bss and the linker taking care of the alignment. this new code has an > incorrectly hard-coded "32", and puts a 64KiB array onto the *stack*. This will be probably fixed in Eric's patch Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] procedure to down load u-boot to RAM
Hi Wolfgang, I have a number of u-boot development questions that I would like to raise to you for answers: (1) Is it possible to install u-boot in a Windows XP environment? If it is, please tell me the steps to follow. Are they the same as those cut out for Linux? (2) Is it possible to use 'cgywin' to build u-boot, since 'cgywin' mimicks Linux's environment? (3) Is it possible to directly download an u-boot image onto the RAM space of a customerized development board to debug u-boot? If it is, please list out the steps to follow. (4) What type of u-boot image should be used, if downloading of the u-boot image to the RAM space of the board is via a Lauterbach ICE (a debugger with a JTAG interface)? Normally, a Lauterbach ICE expects a .axf file to be downloaded (axf = archived, executable file), but in the u-boot case, should it be the ELF image u-boot build generates? (5) The intention of the endeavor is to develope some "standalone applications" that allow frequencies/operating-voltages of the CPU & peripherals to be changed, during the time when u-boot is run, such as to measure the performances of the CPU & other peripherals. The existing development board has an ARM Cortex-A9 and a Cortex-R4 running on it. (6) Is it possible to make "minor changes" to the u-boot codes, such that controls could be passed back to u-boot at will from an application, which gets executed using the u-boot command: go ? Please elaborate in as much details as possible, if it can. The motivation is that after a change of operating frequencies & voltages of the CPU & peripherals, u-boot command: go would be called to measure performances of the board. Thereafter, control would be returned to u-boot again, such that another set of operating frequencies & voltages could be selected. (7) Is it possible for a file to be read in, say, from a SD card via u-boot command, since u-boot comes with a SD driver? Also, is there any write-up that describes how to search past questions raised by u-boot users? As it stand, I google search seems to be the only way that I could be used to come up with relevant questions associated with a keyword. Thank you in advance for your help, and looking forward to your reply. Thanks, Ivan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/23] tegra: Add PMU to manage power supplies
On Mon, 2012-04-02 at 16:18 -0700, Simon Glass wrote: > From: Jimmy Zhang > > Power supplies must be adjusted in line with clock frequency. This code > provides a simple routine to set the voltage to allow operation at maximum > frequency. > > - Split PMU code into separate TPS6586X driver > Signed-off-by: Jimmy Zhang > Signed-off-by: Simon Glass > --- > --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/23] tegra: Add EMC support for optimal memory timings
On Mon, 2012-04-02 at 16:18 -0700, Simon Glass wrote: > From: Jimmy Zhang > > Add support for setting up the memory controller parameters. Boards > can set up an appropriate table in the device tree. > Signed-off-by: Jimmy Zhang > Signed-off-by: Simon Glass > --- --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] MX35: mx35pdk: wrong board revision
On 09/04/2012 14:56, Fabio Estevam wrote: > On 4/9/12, Stefano Babic wrote: >> The board revision is detected accessing to the pmic, >> that is not available before relocation (I2C). >> This generates the following error: >> >> CPU: Freescale i.MX35 rev 2.0 at 532 MHz. >> Reset cause: WDOG >> = 7 is invalid. Should be less than 0 >> Board: MX35 PDK 1.0 >> >> The revision number is wrong, as a default value is printed >> (tested on a mx35pdk Rev. 2.0). >> >> Move the output in the board_late_init(), when >> pmic can be accessed. >> >> Signed-off-by: Stefano Babic >> --- >> >> V2: drop dead code >> >> board/freescale/mx35pdk/mx35pdk.c | 11 --- >> include/configs/mx35pdk.h |1 - >> 2 files changed, 0 insertions(+), 12 deletions(-) > Hi Fabio, > Looks like there is something wrong with this patch: 12 deletions and > no insertions. > > Comparing it with v1 I would expect that only the "#if 0 and #endif" > were removed. At first glance, yes. However, the patch produces the correct code. The checkboard function is removed, but not completely, and its last two statements (printf and return) slip into the board_late_init() function, where the i2c is already initialized and pmic already used. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
