Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On Wednesday 30 January 2013 03:43 AM, Stephen Warren wrote:
On 01/29/2013 02:57 PM, Tom Warren wrote:
Stephen,
On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren wrote:
On 01/29/2013 01:40 PM, Tom Warren wrote:
Stephen,
On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren wrote:
On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
If you do keep this node, it needs the clocks property filled in.
+ i2c@7000c000 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
The I2C nodes also aren't backwards-compatible.
They were on T30 (same compatible string there, except of course
s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
(compat_names table).
Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
the Tegra20 driver would run unmodified on Tegra30 without issue. I
don't believe that's the case for Tegra114 though. The solution would be
to add the Tegra114 compatible value to the I2C driver so that it can
search for both.
Looking at the TRMs for both T30 and T114, I2C looks nearly identical,
except for some additional registers tacked onto the end for bus clear
support. 99% of the bits appear exactly the same, too (with the
addition of a bus clear int bit on T114 in an used bit position). I
know next to nothing about I2C, but it appears to me that the current
tegra_I2C.c driver should work fine on T114 (and does, since I can
probe addresses with it). I don't see a need for a different driver
or compat value here.
I Cc'd in Laxman here, since he wrote the Tegra114 I2C support for the
kernel. He made the decision that Tegra114 I2C wasn't compatible with
Tegra20/30 I2C, and can explain that. Certainly looking at the kernel
patch I pointed at, it seems some of the clock divisors must be
programmed differently, which certainly seems enough to declare the HW
blocks incompatible, even if everything else is identical.
Tegra30 i2c driver will not work as straight. There is los of change
which need to be taken care.
I posted the change for kernel driver.
Changes are:
- Enable/disable control for per packet transfer complete interrupt.
Earlier SoCs could not disable this.
- Single clock source for standard/fast and HS mode clock speed.
The clock divisor for fast/standard mode is added into the i2c
controller to meet the HS and standard/fast mode of clock speed
from single source.
---
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
[U-Boot] Watchdog of OMAP3530 in u-boot
Hi Everyone, I'm using DEVKIT8000, and I need to implement watchdog reset in u-boot, I have gone through all the registers used for watchdog registers but I'm not getting watchdog handlers, please anyone guide me how to use handlers and how to initialise watchdog in the u-boot. Thanks & Regards, Guru Charan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_DELAY_ENVIRONMENT usage
Hi Allen,
Am Dienstag, den 29.01.2013, 19:05 -0800 schrieb Allen Martin:
> The problem I'm seeing is that this regressed environment loading on
> all boards that use fdt, because none of them have
> /config/load-environment defined. If I read the commit message
> correctly, I think the actual intention is:
>
> static int should_load_env(void)
> {
> #ifdef CONFIG_DELAY_ENVIRONMENT
> #ifdef CONFIG_OF_CONTROL
> return fdtdec_get_config_int(gd->fdt_blob, "load-environment",
> 0);
> #else
> return 0;
> #endif
> #else
> return 1;
> #endif
> }
>
There is already a patch for that on the mailing list. See
http://www.mail-archive.com/u-boot@lists.denx.de/msg103841.html
We agreed that just swapping around the default value for the FDT case
is the right thing to do.
Regards,
Lucas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: support the correct card version for eMMC
eMMC vesrion is supported up to v4.5.
But bootloader isn't saw the exact eMMC version.
After applied this patch,
if use the mmcinfo command, then can see the exactly mmc version.
Signed-off-by: Jaehoon Chung
Signed-off-by: Kyungmin Park
---
common/cmd_mmc.c |2 +-
drivers/mmc/mmc.c | 18 ++
include/mmc.h | 21 +
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 7dacd51..9e8d293 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -106,7 +106,7 @@ static void print_mmcinfo(struct mmc *mmc)
printf("Rd Block Len: %d\n", mmc->read_bl_len);
printf("%s version %d.%d\n", IS_SD(mmc) ? "SD" : "MMC",
- (mmc->version >> 4) & 0xf, mmc->version & 0xf);
+ (mmc->version >> 8) & 0xf, mmc->version & 0xff);
printf("High Capacity: %s\n", mmc->high_capacity ? "Yes" : "No");
puts("Capacity: ");
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 72e8ce6..3b3317e 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1029,6 +1029,24 @@ static int mmc_startup(struct mmc *mmc)
mmc->capacity = capacity;
}
+ switch (ext_csd[EXT_CSD_REV]) {
+ case 1:
+ mmc->version = MMC_VERSION_4_1;
+ break;
+ case 2:
+ mmc->version = MMC_VERSION_4_2;
+ break;
+ case 3:
+ mmc->version = MMC_VERSION_4_3;
+ break;
+ case 5:
+ mmc->version = MMC_VERSION_4_41;
+ break;
+ case 6:
+ mmc->version = MMC_VERSION_4_5;
+ break;
+ }
+
/*
* Check whether GROUP_DEF is set, if yes, read out
* group size from ext_csd directly, or calculate
diff --git a/include/mmc.h b/include/mmc.h
index a13e2bd..d0ec744 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -30,16 +30,21 @@
#include
#define SD_VERSION_SD 0x2
-#define SD_VERSION_2 (SD_VERSION_SD | 0x20)
-#define SD_VERSION_1_0 (SD_VERSION_SD | 0x10)
-#define SD_VERSION_1_10(SD_VERSION_SD | 0x1a)
+#define SD_VERSION_2 (SD_VERSION_SD | 0x200)
+#define SD_VERSION_1_0 (SD_VERSION_SD | 0x100)
+#define SD_VERSION_1_10(SD_VERSION_SD | 0x10a)
#define MMC_VERSION_MMC0x1
#define MMC_VERSION_UNKNOWN(MMC_VERSION_MMC)
-#define MMC_VERSION_1_2(MMC_VERSION_MMC | 0x12)
-#define MMC_VERSION_1_4(MMC_VERSION_MMC | 0x14)
-#define MMC_VERSION_2_2(MMC_VERSION_MMC | 0x22)
-#define MMC_VERSION_3 (MMC_VERSION_MMC | 0x30)
-#define MMC_VERSION_4 (MMC_VERSION_MMC | 0x40)
+#define MMC_VERSION_1_2(MMC_VERSION_MMC | 0x102)
+#define MMC_VERSION_1_4(MMC_VERSION_MMC | 0x104)
+#define MMC_VERSION_2_2(MMC_VERSION_MMC | 0x202)
+#define MMC_VERSION_3 (MMC_VERSION_MMC | 0x300)
+#define MMC_VERSION_4 (MMC_VERSION_MMC | 0x400)
+#define MMC_VERSION_4_1(MMC_VERSION_MMC | 0x401)
+#define MMC_VERSION_4_2(MMC_VERSION_MMC | 0x402)
+#define MMC_VERSION_4_3(MMC_VERSION_MMC | 0x403)
+#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429)
+#define MMC_VERSION_4_5(MMC_VERSION_MMC | 0x405)
#define MMC_MODE_HS0x001
#define MMC_MODE_HS_52MHz 0x010
--
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] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization
It looks good to me. Acked-by: Jaehoon Chung On 01/29/2013 11:47 PM, Lukasz Majewski wrote: > Dear All, > > Any feedback about this patch? > >> This patch changes sdhci_init()'s behavior to NOT enable all interrupt >> sources by default. Moreover interrupt signaling has been disabled. >> >> This patch do not enable interrupts which aren't served in u-boot >> (they are defined at sdhci.h but NOT used elsewhere): >> - SDHCI_INT_CARD_INSERT, SDHCI_INT_CARD_REMOVE, SDHCI_BUS_POWER, >> SDHCI_INT_CARD_REMOVE, SDHCI_INT_CARD_INT >> >> Special care shall be put on SDHCI_INT_CARD_INT, which indicates >> interrupt generated by SD card. >> According to "SD Host Controller Simplified Spec. ver 3.00" when bit 8 >> (Card Interrupt Status Enable) at "Normal Interrupt Status Enable >> Register" (offset 0x34) is set, the card interrupt detection is >> started. Then eMMC card may cause the SD controller to set this bit >> and then this interrupt is passed to booted OS and might cause kernel >> crash. >> >> >> To sum up: >> - Only enable interrupts, which are served at u-boot >> - This cleanup as a side effect fixes SDHCI's CARD INTERRUPT problem >> at Linux kernel (versions 3.6+, sdhci controller) >> - Keep masked bits at "Normal Interrupt Signal Enable >> Register" (0x38h) >> >> Signed-off-by: Lukasz Majewski >> Signed-off-by: Kyungmin Park >> Cc: Lei Wen >> Cc: Andy Fleming >> --- >> drivers/mmc/sdhci.c |8 +--- >> 1 files changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c >> index 0fd1337..76c14fb 100644 >> --- a/drivers/mmc/sdhci.c >> +++ b/drivers/mmc/sdhci.c >> @@ -412,9 +412,11 @@ int sdhci_init(struct mmc *mmc) >> status = sdhci_readl(host, >> SDHCI_PRESENT_STATE); } >> >> -/* Eable all state */ >> -sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_ENABLE); >> -sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_SIGNAL_ENABLE); >> +/* Enable only interrupts served by the SD controller */ >> +sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK >> + , SDHCI_INT_ENABLE); >> +/* Mask all sdhci interrupt sources */ >> +sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE); >> >> return 0; >> } > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_DELAY_ENVIRONMENT usage
Simon, I had a question about your CONFIG_DELAY_ENVIRONMENT patch. In
the commit description it says:
When CONFIG_DELAY_ENVIRONMENT is defined, it is convenient to have a
run-time way of enabling loading of the environment. Add this to the
fdt as /config/delay-environment.
In the code, it's actually reading /config/load-environment, and it
defaults to prevent loading environment regardless if
CONFIG_DELAY_ENVIRONMENT is set or not:
static int should_load_env(void)
{
#ifdef CONFIG_OF_CONTROL
return fdtdec_get_config_int(gd->fdt_blob, "load-environment", 0);
#elif defined CONFIG_DELAY_ENVIRONMENT
return 0;
#else
return 1;
#endif
}
The problem I'm seeing is that this regressed environment loading on
all boards that use fdt, because none of them have
/config/load-environment defined. If I read the commit message
correctly, I think the actual intention is:
static int should_load_env(void)
{
#ifdef CONFIG_DELAY_ENVIRONMENT
#ifdef CONFIG_OF_CONTROL
return fdtdec_get_config_int(gd->fdt_blob, "load-environment",
0);
#else
return 0;
#endif
#else
return 1;
#endif
}
Is my understanding correct?
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/corenet: Add workaround for ELBC multi-bit ECC error
> On 01/28/2013 01:16:53 AM, Shaohui Xie wrote:
> > diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> > b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> > index e5ecf5d..f26d608 100644
> > --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> > +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> > @@ -227,6 +227,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag,
> > int argc, char * const argv[]) #ifdef
> > CONFIG_SYS_FSL_ERRATUM_NMG_LBC103
> > puts("Work-around for Erratum NMG_LBC103 enabled\n"); #endif
> > +#ifdef CONFIG_SYS_FSL_ELBC_MULTIBIT_ECC
> > + puts("Work-around for Erratum ELBC MULTIBIT ECC enabled\n"); #endif
>
> Is there still no erratum number for this?
[S.H] Yes, I did not find any update from validation for this erratum. It even
does not described in any errata doc.
Best Regards,
Shaohui Xie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 REPOST 2 2/7] ARM: rpi_b: use bcm2835 mbox driver to get memory size
The firmware running on the bcm2835 SoC's VideoCore CPU determines how
much of the system RAM is available for use by the ARM CPU. Previously,
U-Boot assumed that only 128MB was available, since this was the
smallest value configured by any public firmware. However, we can now
query the actual value at run-time from the firmware using the mbox
property protocol.
Signed-off-by: Stephen Warren
---
v5: No change; merged patch series.
v4: No change; rebased.
v3: No change.
v2: Updated to use macros etc. added in v2 of mbox driver patch.
---
board/raspberrypi/rpi_b/rpi_b.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 688b0aa..3c654a1 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -15,13 +15,32 @@
*/
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
+struct msg_get_arm_mem {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;
+ u32 end_tag;
+};
+
int dram_init(void)
{
- gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
+ ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
+ int ret;
+
+ BCM2835_MBOX_INIT_HDR(msg);
+ BCM2835_MBOX_INIT_TAG(&msg->get_arm_mem, GET_ARM_MEMORY);
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr);
+ if (ret) {
+ printf("bcm2835: Could not query ARM memory size\n");
+ return -1;
+ }
+
+ gd->ram_size = msg->get_arm_mem.body.resp.mem_size;
return 0;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 REPOST 2 6/7] mmc: add bcm2835 driver
This adds a simple driver for the BCM2835's SD controller. Workarounds are implemented for: * Register writes can't be too close to each-other in time, or they will be lost. * Register accesses must all be 32-bit, so implement custom accessors. This code was extracted from: git://github.com/gonzoua/u-boot-pi.git master which was created by Oleksandr Tymoshenko. Portions of the code there were obviously based on the Linux kernel at: git://github.com/raspberrypi/linux.git rpi-3.6.y commit f5b930b "Main bcm2708 linux port" signed-off-by Dom Cobley. swarren changed the following for upstream: * Removed hack udelay()s in bcm2835_sdhci_raw_writel(); setting SDHCI_QUIRK_WAIT_SEND_CMD appears to solve the issues. * Remove register logging from read*/write* functions. * Sort out confusion with min/max_freq values passed to add_sdhci(). * Use more descriptive variable names and calculations in IO accessors. * Simplified and commented twoticks_delay calculation. * checkpatch fixes. Cc: Andy Fleming Signed-off-by: Oleksandr Tymoshenko Signed-off-by: Stephen Warren --- v5: Invent struct bcm2835_sdhci_host to avoid static/global variables. v4: * Merged with video patch series due to dependencies in rpi_b.h. * Rebased onto latest u-boot-arm/master; no real changes. v3: No such version was posted. v2: * Use more descriptive variable names and calculations in IO accessors. * Add Oleksandr's S-o-b. * Rewrite commit description to note that the Linux code this was derived from was S-o-b Dom Cobley. --- arch/arm/include/asm/arch-bcm2835/sdhci.h | 24 drivers/mmc/Makefile |1 + drivers/mmc/bcm2835_sdhci.c | 189 + 3 files changed, 214 insertions(+) create mode 100644 arch/arm/include/asm/arch-bcm2835/sdhci.h create mode 100644 drivers/mmc/bcm2835_sdhci.c diff --git a/arch/arm/include/asm/arch-bcm2835/sdhci.h b/arch/arm/include/asm/arch-bcm2835/sdhci.h new file mode 100644 index 000..a4f867b --- /dev/null +++ b/arch/arm/include/asm/arch-bcm2835/sdhci.h @@ -0,0 +1,24 @@ +/* + * (C) Copyright 2012 Stephen Warren + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _BCM2835_SDHCI_H_ +#define _BCM2835_SDHCI_H_ + +#define BCM2835_SDHCI_BASE 0x2030 + +int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq); + +#endif diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 65791aa..1d6faa2 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -43,6 +43,7 @@ COBJS-$(CONFIG_MXS_MMC) += mxsmmc.o COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o COBJS-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o COBJS-$(CONFIG_SDHCI) += sdhci.o +COBJS-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o COBJS-$(CONFIG_TEGRA_MMC) += tegra_mmc.o diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c new file mode 100644 index 000..b0afc3c --- /dev/null +++ b/drivers/mmc/bcm2835_sdhci.c @@ -0,0 +1,189 @@ +/* + * This code was extracted from: + * git://github.com/gonzoua/u-boot-pi.git master + * and hence presumably (C) 2012 Oleksandr Tymoshenko + * + * Tweaks for U-Boot upstreaming + * (C) 2012 Stephen Warren + * + * Portions (e.g. read/write macros, concepts for back-to-back register write + * timing workarounds) obviously extracted from the Linux kernel at: + * https://github.com/raspberrypi/linux.git rpi-3.6.y + * + * The Linux kernel code has the following (c) and license, which is hence + * propagated to Oleksandr's tree and here: + * + * Support for SDHCI device on 2835 + * Based on sdhci-bcm2708.c (c) 2010 Broadcom + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Supports: + * SDHCI platform device - Arasan SD controller in BCM2708 + * + * Inspired by sdhci-pci.c, by Pierre Ossman + */ + +#include +#include +#include + +/* 400KHz is max freq for card ID etc. Use that as
[U-Boot] [PATCH V5 REPOST 2 5/7] video: add a driver for the bcm2835
The firmware running on the bcm2835 SoC's VideoCore CPU manages the
display controller. Add a simple "LCD" driver that communicates with the
firmware using the property mailbox protocol. This configures the
display and frame-buffer to match whatever physical resolution the
firmware chosen when booting, which is typically the native resolution
of the attached display device, presumably unless otherwise specified
in config.txt on the boot media.
Enable this driver in the Raspberry Pi board configuration.
Signed-off-by: Stephen Warren
Acked-by: Anatolij Gustschin
---
v5: No change; merged patch series.
v4: No change; rebased.
v3: Re-license to GPL-v2 or later. Fix typo in commit description.
v2: New patch.
---
drivers/video/Makefile |1 +
drivers/video/bcm2835.c | 127 +++
include/configs/rpi_b.h | 16 ++
3 files changed, 144 insertions(+)
create mode 100644 drivers/video/bcm2835.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 170a358..e8cecca 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_LD9040) += ld9040.o
COBJS-$(CONFIG_SED156X) += sed156x.o
COBJS-$(CONFIG_VIDEO_AMBA) += amba.o
+COBJS-$(CONFIG_VIDEO_BCM2835) += bcm2835.o
COBJS-$(CONFIG_VIDEO_COREBOOT) += coreboot_fb.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
new file mode 100644
index 000..1e9a84a
--- /dev/null
+++ b/drivers/video/bcm2835.c
@@ -0,0 +1,127 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Global variables that lcd.c expects to exist */
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+void *lcd_base;
+void *lcd_console_address;
+short console_col;
+short console_row;
+vidinfo_t panel_info;
+char lcd_cursor_enabled;
+ushort lcd_cursor_width;
+ushort lcd_cursor_height;
+
+struct msg_query {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_physical_w_h physical_w_h;
+ u32 end_tag;
+};
+
+struct msg_setup {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_physical_w_h physical_w_h;
+ struct bcm2835_mbox_tag_virtual_w_h virtual_w_h;
+ struct bcm2835_mbox_tag_depth depth;
+ struct bcm2835_mbox_tag_pixel_order pixel_order;
+ struct bcm2835_mbox_tag_alpha_mode alpha_mode;
+ struct bcm2835_mbox_tag_virtual_offset virtual_offset;
+ struct bcm2835_mbox_tag_overscan overscan;
+ struct bcm2835_mbox_tag_allocate_buffer allocate_buffer;
+ u32 end_tag;
+};
+
+void lcd_ctrl_init(void *lcdbase)
+{
+ ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1, 16);
+ int ret;
+ u32 w, h;
+
+ debug("bcm2835: Query resolution...\n");
+
+ BCM2835_MBOX_INIT_HDR(msg_query);
+ BCM2835_MBOX_INIT_TAG_NO_REQ(&msg_query->physical_w_h,
+ GET_PHYSICAL_W_H);
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg_query->hdr);
+ if (ret) {
+ printf("bcm2835: Could not query display resolution\n");
+ /* FIXME: How to disable the LCD to prevent errors? hang()? */
+ return;
+ }
+
+ w = msg_query->physical_w_h.body.resp.width;
+ h = msg_query->physical_w_h.body.resp.height;
+
+ debug("bcm2835: Setting up display for %d x %d\n", w, h);
+
+ BCM2835_MBOX_INIT_HDR(msg_setup);
+ BCM2835_MBOX_INIT_TAG(&msg_setup->physical_w_h, SET_PHYSICAL_W_H);
+ msg_setup->physical_w_h.body.req.width = w;
+ msg_setup->physical_w_h.body.req.height = h;
+ BCM2835_MBOX_INIT_TAG(&msg_setup->virtual_w_h, SET_VIRTUAL_W_H);
+ msg_setup->virtual_w_h.body.req.width = w;
+ msg_setup->virtual_w_h.body.req.height = h;
+ BCM2835_MBOX_INIT_TAG(&msg_setup->depth, SET_DEPTH);
+ msg_setup->depth.body.req.bpp = 16;
+ BCM2835_MBOX_INIT_TAG(&msg_setup->pixel_order, SET_PIXEL_ORDER);
+ msg_setup->pixel_order.body.req.order = BCM2835_MBOX_PIXEL_ORDER_BGR;
+ BCM2835_MBOX_INIT_TAG(&msg_setup->alpha_mode, SET_ALPHA_MODE);
+ msg_setup->alpha_mode.body.req.alpha = BCM
[U-Boot] [PATCH V5 REPOST 2 4/7] ARM: rpi_b: disable rpi_b dcache explicitly
There appears to be no implementation of flush_dcache_range() for ARM1176, so explicitly disable dcache support to avoid references to that function from the LCD core in the next patch. This was presumably not noticed before simply because no drivers for the rpi_b were attempting DMA. Signed-off-by: Stephen Warren --- v5: No change; merged patch series. v4: New patch. --- include/configs/rpi_b.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h index cf62e45..5db31f5 100644 --- a/include/configs/rpi_b.h +++ b/include/configs/rpi_b.h @@ -23,6 +23,7 @@ #define CONFIG_ARM1176 #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT +#define CONFIG_SYS_DCACHE_OFF /* * 2835 is a SKU in a series for which the 2708 is the first or primary SoC, * so 2708 has historically been used rather than a dedicated 2835 ID. -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 REPOST 2 7/7] ARM: rpi_b: enable SD controller, add related env/cmds
Enable the SD controller driver for the Raspberry Pi. Enable a number
of useful MMC, partition, and filesystem-related commands. Set up the
environment to provide standard locations for loading a kernel, DTB,
etc. Provide a boot command that loads and executes boot.scr.uimg from
the SD card; this is written considering future extensibilty to USB
storage.
Signed-off-by: Stephen Warren
---
v5: No change.
v4:
* Merged with video patch series due to dependencies in rpi_b.h.
* Rebased onto latest u-boot-arm/master; no real changes.
v3: No such version was posted.
v2: No change.
---
arch/arm/include/asm/arch-bcm2835/mbox.h | 26
board/raspberrypi/rpi_b/rpi_b.c | 26
include/configs/rpi_b.h | 68 --
3 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h
b/arch/arm/include/asm/arch-bcm2835/mbox.h
index 4752091..b07c4a0 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -144,6 +144,32 @@ struct bcm2835_mbox_tag_get_arm_mem {
} body;
};
+#define BCM2835_MBOX_TAG_GET_CLOCK_RATE0x00030002
+
+#define BCM2835_MBOX_CLOCK_ID_EMMC 1
+#define BCM2835_MBOX_CLOCK_ID_UART 2
+#define BCM2835_MBOX_CLOCK_ID_ARM 3
+#define BCM2835_MBOX_CLOCK_ID_CORE 4
+#define BCM2835_MBOX_CLOCK_ID_V3D 5
+#define BCM2835_MBOX_CLOCK_ID_H264 6
+#define BCM2835_MBOX_CLOCK_ID_ISP 7
+#define BCM2835_MBOX_CLOCK_ID_SDRAM8
+#define BCM2835_MBOX_CLOCK_ID_PIXEL9
+#define BCM2835_MBOX_CLOCK_ID_PWM 10
+
+struct bcm2835_mbox_tag_get_clock_rate {
+ struct bcm2835_mbox_tag_hdr tag_hdr;
+ union {
+ struct {
+ u32 clock_id;
+ } req;
+ struct {
+ u32 clock_id;
+ u32 rate_hz;
+ } resp;
+ } body;
+};
+
#define BCM2835_MBOX_TAG_ALLOCATE_BUFFER 0x00040001
struct bcm2835_mbox_tag_allocate_buffer {
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 3c654a1..6b3e095 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -26,6 +27,12 @@ struct msg_get_arm_mem {
u32 end_tag;
};
+struct msg_get_clock_rate {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_get_clock_rate get_clock_rate;
+ u32 end_tag;
+};
+
int dram_init(void)
{
ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
@@ -51,3 +58,22 @@ int board_init(void)
return 0;
}
+
+int board_mmc_init(void)
+{
+ ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
+ int ret;
+
+ BCM2835_MBOX_INIT_HDR(msg_clk);
+ BCM2835_MBOX_INIT_TAG(&msg_clk->get_clock_rate, GET_CLOCK_RATE);
+ msg_clk->get_clock_rate.body.req.clock_id = BCM2835_MBOX_CLOCK_ID_EMMC;
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg_clk->hdr);
+ if (ret) {
+ printf("bcm2835: Could not query eMMC clock rate\n");
+ return -1;
+ }
+
+ return bcm2835_sdhci_init(BCM2835_SDHCI_BASE,
+ msg_clk->get_clock_rate.body.resp.rate_hz);
+}
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index e485a06..3d55d36 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -51,6 +51,7 @@
#define CONFIG_SYS_MALLOC_LEN SZ_4M
#define CONFIG_SYS_MEMTEST_START 0x0010
#define CONFIG_SYS_MEMTEST_END 0x0020
+#define CONFIG_LOADADDR0x0020
/* Flash */
#define CONFIG_SYS_NO_FLASH
@@ -70,6 +71,13 @@
#define CONFIG_VIDEO_BCM2835
#define CONFIG_SYS_WHITE_ON_BLACK
+/* SD/MMC configuration */
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC
+#define CONFIG_SDHCI
+#define CONFIG_MMC_SDHCI_IO_ACCESSORS
+#define CONFIG_BCM2835_SDHCI
+
/* Console UART */
#define CONFIG_PL011_SERIAL
#define CONFIG_PL011_CLOCK 300
@@ -85,12 +93,59 @@
/* Environment */
#define CONFIG_ENV_SIZESZ_16K
#define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
#define CONFIG_SYS_LOAD_ADDR 0x100
#define CONFIG_CONSOLE_MUX
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
-#define CONFIG_EXTRA_ENV_SETTINGS "stdin=serial\0" \
- "stderr=serial,lcd\0" \
- "stdout=serial,lcd\0"
+/*
+ * Memory layout for where various images get loaded by boot scripts:
+ *
+ * scriptaddr can be pretty much anywhere that doesn't conflict with something
+ * else. Put it low in memory to avoid conflicts.
+ *
+ * kernel_addr_r must be within the first 128M of RAM in order for the
+ * kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will
+ * decompress it
[U-Boot] [PATCH V5 REPOST 2 1/7] ARM: bcm2835: add mailbox driver
The BCM2835 SoC contains (at least) two CPUs; the VideoCore (a/k/a "GPU")
and the ARM CPU. The ARM CPU is often thought of as the main CPU.
However, the VideoCore actually controls the initial SoC boot, and hides
much of the hardware behind a protocol. This protocol is transported
using the SoC's mailbox hardware module.
Here, we add a very simplistic driver for the mailbox module, and define
a few structures for the property messages.
Signed-off-by: Stephen Warren
---
v5: No change; merged patch series.
v4: No change; rebased.
v3: Re-license to GPL-v2 or later.
v2:
* Added documentation to mbox.h.
* Implemented macros to set up headers and tags.
* Implemented error-checking of response bits in bcm2835_mbox_call_prop().
* Reworked tag structs based on experience writing LCD driver.
* Added a lot more video-related tag structs.
* Added debug spew and error messages to mbox.c; useful when debugging LCD.
* Removed __packed attributes from message structs.
* Removed stale FIXME comments.
---
arch/arm/cpu/arm1176/bcm2835/Makefile|2 +-
arch/arm/cpu/arm1176/bcm2835/mbox.c | 164
arch/arm/include/asm/arch-bcm2835/mbox.h | 407 ++
3 files changed, 572 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/arm1176/bcm2835/mbox.c
create mode 100644 arch/arm/include/asm/arch-bcm2835/mbox.h
diff --git a/arch/arm/cpu/arm1176/bcm2835/Makefile
b/arch/arm/cpu/arm1176/bcm2835/Makefile
index 95da6a8..135de42 100644
--- a/arch/arm/cpu/arm1176/bcm2835/Makefile
+++ b/arch/arm/cpu/arm1176/bcm2835/Makefile
@@ -17,7 +17,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
-COBJS := init.o reset.o timer.o
+COBJS := init.o reset.o timer.o mbox.o
SRCS := $(SOBJS:.o=.c) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/arm/cpu/arm1176/bcm2835/mbox.c
b/arch/arm/cpu/arm1176/bcm2835/mbox.c
new file mode 100644
index 000..fd65e33
--- /dev/null
+++ b/arch/arm/cpu/arm1176/bcm2835/mbox.c
@@ -0,0 +1,164 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#define TIMEOUT (100 * 1000) /* 100mS in uS */
+
+int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv)
+{
+ struct bcm2835_mbox_regs *regs =
+ (struct bcm2835_mbox_regs *)BCM2835_MBOX_PHYSADDR;
+ ulong endtime = get_timer(0) + TIMEOUT;
+ u32 val;
+
+ debug("time: %lu timeout: %lu\n", get_timer(0), endtime);
+
+ if (send & BCM2835_CHAN_MASK) {
+ printf("mbox: Illegal mbox data 0x%08x\n", send);
+ return -1;
+ }
+
+ /* Drain any stale responses */
+
+ for (;;) {
+ val = readl(®s->status);
+ if (val & BCM2835_MBOX_STATUS_RD_EMPTY)
+ break;
+ if (get_timer(0) >= endtime) {
+ printf("mbox: Timeout draining stale responses\n");
+ return -1;
+ }
+ val = readl(®s->read);
+ }
+
+ /* Wait for space to send */
+
+ for (;;) {
+ val = readl(®s->status);
+ if (!(val & BCM2835_MBOX_STATUS_WR_FULL))
+ break;
+ if (get_timer(0) >= endtime) {
+ printf("mbox: Timeout waiting for send space\n");
+ return -1;
+ }
+ }
+
+ /* Send the request */
+
+ val = BCM2835_MBOX_PACK(chan, send);
+ debug("mbox: TX raw: 0x%08x\n", val);
+ writel(val, ®s->write);
+
+ /* Wait for the response */
+
+ for (;;) {
+ val = readl(®s->status);
+ if (!(val & BCM2835_MBOX_STATUS_RD_EMPTY))
+ break;
+ if (get_timer(0) >= endtime) {
+ printf("mbox: Timeout waiting for response\n");
+ return -1;
+ }
+ }
+
+ /* Read the response */
+
+ val = readl(®s->read);
+ debug("mbox: RX raw: 0x%08x\n", val);
+
+ /* Validate the response */
+
+ if (BCM2835_MBOX_UNPACK_CHAN(val) != chan) {
+ printf("mbox: Response channel mismatch\n");
+ return -1;
+ }
+
+ *recv = BCM2835_MBOX_UNPACK_DATA(val);
+
+ return 0;
+}
+
+#ifdef DEBUG
+void dump_buf(struct bcm2835_mbox_hdr *buffer)
+{
+
[U-Boot] [PATCH V5 REPOST 2 3/7] lcd: calculate line_length after lcd_ctrl_init()
When an LCD driver is actually driving a regular external display, e.g.
an HDMI monitor, the display resolution might not be known until the
display controller has initialized, i.e. during lcd_ctrl_init(). However,
lcd.c calculates lcd_line_length before calling this function, thus
relying on a hard-coded resolution in struct panel_info.
Instead, defer this calculation until after lcd_ctrl_init() has had the
chance to dynamically determine the resolution. This needs to happen
before lcd_clear(), since the value is used there.
grep indicates that no code outside lcd.c uses this lcd_line_length; in
particular, no lcd_ctrl_init() implementations read it.
Signed-off-by: Stephen Warren
Acked-by: Anatolij Gustschin
--
v5: No change; merged patch series.
v4: Adjusted to addition of lcd_get_size() function. Rebased.
v3: No change.
---
common/lcd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 66d4f94..9fa4e5c 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -384,8 +384,6 @@ int drv_lcd_init (void)
lcd_base = (void *)(gd->fb_base);
- lcd_get_size(&lcd_line_length);
-
lcd_init(lcd_base); /* LCD initialization */
/* Device initialization */
@@ -468,6 +466,8 @@ static int lcd_init(void *lcdbase)
debug("[LCD] Initializing LCD frambuffer at %p\n", lcdbase);
lcd_ctrl_init(lcdbase);
+ lcd_get_size(&lcd_line_length);
+ lcd_line_length = (panel_info.vl_col * NBITS(panel_info.vl_bpix)) / 8;
lcd_is_enabled = 1;
lcd_clear();
lcd_enable ();
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: add support for per architecture toolchains
On 01/29/2013 05:34 PM, Allen Martin wrote: > Add support for per architecture CROSS_COMPILE toolchain definitions > via CROSS_COMPILE_ARCH where "ARCH" is any of the supported u-boot > architectures. This allows building every supported u-boot board in a > single pass of MAKEALL. Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: atmel: add at91sam9g20ek_2mmc nand boot support
Add at91sam9g20_2mmc nand boot support. on this board, there is no
dataflash, so disable it
change one commet for at91sam9g20ek board
Signed-off-by: Bo Shen
---
board/atmel/at91sam9260ek/at91sam9260ek.c |7 ++-
boards.cfg|1 +
include/configs/at91sam9260ek.h |2 ++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 2555672..3aa394a 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -157,13 +157,18 @@ int board_early_init_f(void)
int board_init(void)
{
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+ /* arch number of AT91SAM9G20EK_2MMC-Board */
+ gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
#ifdef CONFIG_AT91SAM9G20EK
- /* arch number of AT91SAM9260EK-Board */
+ /* arch number of AT91SAM9G20EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
#else
/* arch number of AT91SAM9260EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
#endif
+#endif
/* adress of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
diff --git a/boards.cfg b/boards.cfg
index e4b0d44..fa863dc 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -95,6 +95,7 @@ at91sam9g10ek_nandflash arm arm926ejs
at91sam9261ek atmel
at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
+at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek atmel
at91
at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
at91sam9m10g45ek_nandflash arm arm926ejs at91sam9m10g45ekatmel
at91at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
at91sam9rlek_dataflash arm arm926ejs at91sam9rlekatmel
at91at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
at91sam9rlek_nandflash arm arm926ejs at91sam9rlekatmel
at91at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index f921fac..02696b3 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -126,6 +126,7 @@
#endif
/* DataFlash */
+#ifndef CONFIG_AT91SAM9G20EK_2MMC
#define CONFIG_ATMEL_DATAFLASH_SPI
#define CONFIG_HAS_DATAFLASH 1
#define CONFIG_SYS_SPI_WRITE_TOUT (5*CONFIG_SYS_HZ)
@@ -133,6 +134,7 @@
#define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS00xC000 /* CS0 */
#define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS10xD000 /* CS1 */
#define AT91_SPI_CLK 1500
+#endif
#ifdef CONFIG_AT91SAM9G20EK
#define DATAFLASH_TCSS (0x22 << 16)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can I read env from RAM in uboot script?
Hi John Stile, On 01/30/2013 01:33 AM, John Stile wrote: That worked! Very nice! But, I had to apply the patches manually. Email may have messed up the patch sets with new-lines and indentation. Can this be added to the main stream? I am on to learning 'env import'. Thank you. I will prepare the patch and send to u-boot mainline. If email messed it up once, I guess it could mess it up again, but I generated patches using: diff -Naur before/ after/> diff.patch I think this can not be applied to u-boot mainline directly, because it missed comments and author, and etc. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MAKEALL: add support for per architecture toolchains
Add support for per architecture CROSS_COMPILE toolchain definitions
via CROSS_COMPILE_ARCH where "ARCH" is any of the supported u-boot
architectures. This allows building every supported u-boot board in a
single pass of MAKEALL.
Signed-off-by: Allen Martin
Acked-by: Simon Glass
---
v2: Changed CROSS_COMPILE_ARM to CROSS_COMPILE_ in help text
---
MAKEALL | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 5b06c54..397adef 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -35,6 +35,9 @@ usage()
Environment variables:
BUILD_NCPUS number of parallel make jobs (default: auto)
CROSS_COMPILEcross-compiler toolchain prefix (default: "")
+ CROSS_COMPILE_ cross-compiler toolchain prefix for
+ architecture "ARCH". Substitute "ARCH" for any
+ supported architecture (default: "")
MAKEALL_LOGDIR output all logs to here (default: ./LOG/)
BUILD_DIRoutput build directory (default: ./)
BUILD_NBUILDSnumber of parallel targets (default: 1)
@@ -180,13 +183,6 @@ else
JOBS=""
fi
-
-if [ "${CROSS_COMPILE}" ] ; then
- MAKE="make CROSS_COMPILE=${CROSS_COMPILE}"
-else
- MAKE=make
-fi
-
if [ "${MAKEALL_LOGDIR}" ] ; then
LOG_DIR=${MAKEALL_LOGDIR}
else
@@ -585,6 +581,18 @@ get_target_maintainers() {
echo "$mail"
}
+get_target_arch() {
+ local target=$1
+
+ # Automatic mode
+ local line=`egrep -i "^[[:space:]]*${target}[[:space:]]" boards.cfg`
+
+ if [ -z "${line}" ] ; then echo "" ; return ; fi
+
+ set ${line}
+ echo "$2"
+}
+
list_target() {
if [ "$PRINT_MAINTS" != 'y' ] ; then
echo "$1"
@@ -655,6 +663,16 @@ build_target() {
export BUILD_DIR="${output_dir}"
+ target_arch=$(get_target_arch ${target})
+ eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
+ if [ "${cross_toolchain}" ] ; then
+ MAKE="make CROSS_COMPILE=${cross_toolchain}"
+ elif [ "${CROSS_COMPILE}" ] ; then
+ MAKE="make CROSS_COMPILE=${CROSS_COMPILE}"
+ else
+ MAKE=make
+ fi
+
${MAKE} distclean >/dev/null
${MAKE} -s ${target}_config
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 02:57 PM, Tom Warren wrote: > Stephen, > > On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren wrote: >> On 01/29/2013 01:40 PM, Tom Warren wrote: >>> Stephen, >>> >>> On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren >>> wrote: On 01/29/2013 12:19 PM, Tom Warren wrote: > Note that T114 does not have a separate/different DVC (power I2C) > controller like T20 - all 5 I2C controllers are identical, but > I2C5 is used to designate the controller intended for power > control (PWR_I2C in the schematics). > + reg = <0x7000c000 0x100>; The interrupts property is missing here. >>> >>> I didn't have an interrupts property for I2C on the T30 dts files, >>> either. >> >> That sounds like a bug in the DT. >> >>> What is it used for in U-Boot? >> >> U-Boot doesn't use interrupts at least on Tegra, so it's not used. >> However, it'd be best to keep the U-Boot DT in line with the kernel DT >> so we can easily spot differences. There has been talk of trying to use >> the same DT for both too, although we're a long long way off from that. > > I'll add it, but it seems silly to add unused values, especially when > your past review critiques of DT files have asked for minimum > functionality, which I agree with. I meant to mention here that my previous comments were about unused nodes; it doesn't seem useful to add a bunch of nodes that we aren't using, until the drivers are ready and we actually end up using those nodes. However, when a node is added, we should fill it in fully, so the DT conforms to the binding for that node. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/7] tegra20: fdt: add SPI SFLASH node
On 01/29/2013 04:51 PM, Allen Martin wrote: > Add node for tegra20 SPI SFLASH controller to fdt. The series, briefly, Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] tegra: SPI drivers
On Tue, Jan 29, 2013 at 03:51:22PM -0800, Allen Martin wrote: > This series updates the tegra20 SPI driver to add fdt support and adds > a new tegra30 SPI driver. > > Testing was done on trimslice (tegra20) and cardhu (tegra30). > Tom, this series applies cleanly on top of your T114 series. > Changes in v4: > -Added support for fdt aliases to slink driver > -Check "status" field of fdt node to make sure node is enabled > Changes in v3: > -Dropped some fdt patches from the series that were picked up in > u-boot-tegra/next already > -Removed SPI node from seaboard, added to trimslice > -Incorporated feedback from Simon Glass and Stephen Warren to slink > driver > Changes in v2: > -Added new patch to sort dts files prior to adding new nodes > -Moved "max-spi-frequency" out to board dts files > -Moved tegra20 SFLASH fdt changes out to separate patch > -Added valid flag to slink driver controller structure > > > Allen Martin (7): > tegra20: fdt: add SPI SFLASH node > tegra: spi: add fdt support to tegra SPI SFLASH driver > tegra30: add SBC1 to periph id mapping table > tegra30: fdt: add SPI SLINK nodes > tegra: add addresses of SPI SLINK controllers > tegra: add SPI SLINK driver > tegra: cardhu: config: enable SPI > > arch/arm/cpu/tegra30-common/clock.c |2 +- > arch/arm/dts/tegra20.dtsi | 12 + > arch/arm/dts/tegra30.dtsi | 72 ++ > arch/arm/include/asm/arch-tegra/tegra.h |6 + > arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 ++ > board/compulab/dts/tegra20-trimslice.dts |5 + > board/nvidia/common/board.c |3 +- > board/nvidia/dts/tegra30-cardhu.dts |5 + > drivers/spi/Makefile |1 + > drivers/spi/tegra_slink.c | 343 > + > drivers/spi/tegra_spi.c | 45 +++- > include/configs/cardhu.h | 11 + > include/fdtdec.h |2 + > lib/fdtdec.c |2 + > 14 files changed, 589 insertions(+), 4 deletions(-) > create mode 100644 arch/arm/include/asm/arch-tegra/tegra_slink.h > create mode 100644 drivers/spi/tegra_slink.c > > -- > 1.7.10.4 > -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] common: cmd_bdinfo: Fix compilation warning for microblaze
Dear Michal Simek Michal Simek xilinx.com> writes: > > Fix one printf compilation warning in microblaze bdinfo part. > > Warning log: > cmd_bdinfo.c: In function 'do_bdinfo': > cmd_bdinfo.c:219:2: warning: format '%u' expects argument of type > 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat] > > Signed-off-by: Michal Simek xilinx.com> > --- > common/cmd_bdinfo.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) I build tested these series of Xilinx patches on an ml507. This doesn't apply cleanly to HEAD. All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/7] tegra30: fdt: add SPI SLINK nodes
Add tegra30 SPI SLINK nodes to fdt.
Signed-off-by: Allen Martin
Acked-by: Simon Glass
---
arch/arm/dts/tegra30.dtsi | 72 +++
board/nvidia/dts/tegra30-cardhu.dts |5 +++
2 files changed, 77 insertions(+)
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index aa7e7ae..7b8126f 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -90,4 +90,76 @@
/* PERIPH_ID_I2C_DVC, CLK_M */
clocks = <&tegra_car 47>;
};
+
+ spi@7000d400 {
+ compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
+ reg = <0x7000d400 0x200>;
+ interrupts = <0 59 0x04>;
+ nvidia,dma-request-selector = <&apbdma 15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SBC1, PLLP_OUT0 */
+ clocks = <&tegra_car 41>;
+ };
+
+ spi@7000d600 {
+ compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
+ reg = <0x7000d600 0x200>;
+ interrupts = <0 82 0x04>;
+ nvidia,dma-request-selector = <&apbdma 16>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SBC2, PLLP_OUT0 */
+ clocks = <&tegra_car 44>;
+ };
+
+ spi@7000d800 {
+ compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
+ reg = <0x7000d480 0x200>;
+ interrupts = <0 83 0x04>;
+ nvidia,dma-request-selector = <&apbdma 17>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SBC3, PLLP_OUT0 */
+ clocks = <&tegra_car 46>;
+ };
+
+ spi@7000da00 {
+ compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
+ reg = <0x7000da00 0x200>;
+ interrupts = <0 93 0x04>;
+ nvidia,dma-request-selector = <&apbdma 18>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SBC4, PLLP_OUT0 */
+ clocks = <&tegra_car 68>;
+ };
+
+ spi@7000dc00 {
+ compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
+ reg = <0x7000dc00 0x200>;
+ interrupts = <0 94 0x04>;
+ nvidia,dma-request-selector = <&apbdma 27>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SBC5, PLLP_OUT0 */
+ clocks = <&tegra_car 104>;
+ };
+
+ spi@7000de00 {
+ compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
+ reg = <0x7000de00 0x200>;
+ interrupts = <0 79 0x04>;
+ nvidia,dma-request-selector = <&apbdma 28>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SBC6, PLLP_OUT0 */
+ clocks = <&tegra_car 105>;
+ };
};
diff --git a/board/nvidia/dts/tegra30-cardhu.dts
b/board/nvidia/dts/tegra30-cardhu.dts
index 3223ed4..f9f80c5 100644
--- a/board/nvidia/dts/tegra30-cardhu.dts
+++ b/board/nvidia/dts/tegra30-cardhu.dts
@@ -39,4 +39,9 @@
i2c@7000d000 {
clock-frequency = <10>;
};
+
+ spi@7000da00 {
+ status = "okay";
+ spi-max-frequency = <2500>;
+ };
};
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/7] tegra: add SPI SLINK driver
Add driver for tegra SPI "SLINK" style driver. This controller is
similar to the tegra20 SPI "SFLASH" controller. The difference is
that the SLINK controller is a genernal purpose SPI controller and the
SFLASH controller is special purpose and can only talk to FLASH
devices. In addition there are potentially many instances of an SLINK
controller on tegra and only a single instance of SFLASH. Tegra20 is
currently ths only version of tegra that instantiates an SFLASH
controller.
This driver supports basic PIO mode of operation and is configurable
(CONFIG_OF_CONTROL) to be driven off devicetree bindings. Up to 4
devices per controller may be attached, although typically only a
single chip select line is exposed from tegra per controller so in
reality this is usually limited to 1.
To enable this driver, use CONFIG_TEGRA_SLINK
Signed-off-by: Allen Martin
---
arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 ++
board/nvidia/common/board.c |3 +-
drivers/spi/Makefile |1 +
drivers/spi/tegra_slink.c | 343 +
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
6 files changed, 432 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-tegra/tegra_slink.h
create mode 100644 drivers/spi/tegra_slink.c
diff --git a/arch/arm/include/asm/arch-tegra/tegra_slink.h
b/arch/arm/include/asm/arch-tegra/tegra_slink.h
new file mode 100644
index 000..74804b5
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/tegra_slink.h
@@ -0,0 +1,84 @@
+/*
+ * NVIDIA Tegra SPI-SLINK controller
+ *
+ * Copyright 2010-2013 NVIDIA Corporation
+ *
+ * This software may be used and distributed according to the
+ * terms of the GNU Public License, Version 2, incorporated
+ * herein by reference.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _TEGRA_SLINK_H_
+#define _TEGRA_SLINK_H_
+
+#include
+
+struct slink_tegra {
+ u32 command;/* SLINK_COMMAND_0 register */
+ u32 command2; /* SLINK_COMMAND2_0 reg */
+ u32 status; /* SLINK_STATUS_0 register */
+ u32 reserved; /* Reserved offset 0C */
+ u32 mas_data; /* SLINK_MAS_DATA_0 reg */
+ u32 slav_data; /* SLINK_SLAVE_DATA_0 reg */
+ u32 dma_ctl;/* SLINK_DMA_CTL_0 register */
+ u32 status2;/* SLINK_STATUS2_0 reg */
+ u32 rsvd[56]; /* 0x20 to 0xFF reserved */
+ u32 tx_fifo;/* SLINK_TX_FIFO_0 reg off 100h */
+ u32 rsvd2[31]; /* 0x104 to 0x17F reserved */
+ u32 rx_fifo;/* SLINK_RX_FIFO_0 reg off 180h */
+};
+
+/* COMMAND */
+#define SLINK_CMD_ENB (1 << 31)
+#define SLINK_CMD_GO (1 << 30)
+#define SLINK_CMD_M_S (1 << 28)
+#define SLINK_CMD_CK_SDA (1 << 21)
+#define SLINK_CMD_CS_POL (1 << 13)
+#define SLINK_CMD_CS_VAL (1 << 12)
+#define SLINK_CMD_CS_SOFT (1 << 11)
+#define SLINK_CMD_BIT_LENGTH (1 << 4)
+#define SLINK_CMD_BIT_LENGTH_MASK 0x001F
+/* COMMAND2 */
+#define SLINK_CMD2_TXEN(1 << 30)
+#define SLINK_CMD2_RXEN(1 << 31)
+#define SLINK_CMD2_SS_EN (1 << 18)
+#define SLINK_CMD2_SS_EN_SHIFT 18
+#define SLINK_CMD2_SS_EN_MASK 0x000C
+#define SLINK_CMD2_CS_ACTIVE_BETWEEN (1 << 17)
+/* STATUS */
+#define SLINK_STAT_BSY (1 << 31)
+#define SLINK_STAT_RDY (1 << 30)
+#define SLINK_STAT_ERR (1 << 29)
+#define SLINK_STAT_RXF_FLUSH (1 << 27)
+#define SLINK_STAT_TXF_FLUSH (1 << 26)
+#define SLINK_STAT_RXF_OVF (1 << 25)
+#define SLINK_STAT_TXF_UNR (1 << 24)
+#define SLINK_STAT_RXF_EMPTY (1 << 23)
+#define SLINK_STAT_RXF_FULL(1 << 22)
+#define SLINK_STAT_TXF_EMPTY (1 << 21)
+#define SLINK_STAT_TXF_FULL(1 << 20)
+#define SLINK_STAT_TXF_OVF (1 << 19)
+#define SLINK_STAT_RXF_UNR (1 << 18)
+#define SLINK_STAT_CUR_BLKCNT (1 << 15)
+/* STATUS2 */
+#define SLINK_STAT2_RXF_FULL_CNT (1 << 16)
+#define SLINK_STAT2_TXF_FULL_CNT (1 << 0)
+
+#define SPI_TIMEOUT1000
+#define TEGRA_SPI_MAX_FREQ 5200
+
+#endif
[U-Boot] [PATCH v4 0/7] tegra: SPI drivers
This series updates the tegra20 SPI driver to add fdt support and adds a new tegra30 SPI driver. Testing was done on trimslice (tegra20) and cardhu (tegra30). Changes in v4: -Added support for fdt aliases to slink driver -Check "status" field of fdt node to make sure node is enabled Changes in v3: -Dropped some fdt patches from the series that were picked up in u-boot-tegra/next already -Removed SPI node from seaboard, added to trimslice -Incorporated feedback from Simon Glass and Stephen Warren to slink driver Changes in v2: -Added new patch to sort dts files prior to adding new nodes -Moved "max-spi-frequency" out to board dts files -Moved tegra20 SFLASH fdt changes out to separate patch -Added valid flag to slink driver controller structure Allen Martin (7): tegra20: fdt: add SPI SFLASH node tegra: spi: add fdt support to tegra SPI SFLASH driver tegra30: add SBC1 to periph id mapping table tegra30: fdt: add SPI SLINK nodes tegra: add addresses of SPI SLINK controllers tegra: add SPI SLINK driver tegra: cardhu: config: enable SPI arch/arm/cpu/tegra30-common/clock.c |2 +- arch/arm/dts/tegra20.dtsi | 12 + arch/arm/dts/tegra30.dtsi | 72 ++ arch/arm/include/asm/arch-tegra/tegra.h |6 + arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 ++ board/compulab/dts/tegra20-trimslice.dts |5 + board/nvidia/common/board.c |3 +- board/nvidia/dts/tegra30-cardhu.dts |5 + drivers/spi/Makefile |1 + drivers/spi/tegra_slink.c | 343 + drivers/spi/tegra_spi.c | 45 +++- include/configs/cardhu.h | 11 + include/fdtdec.h |2 + lib/fdtdec.c |2 + 14 files changed, 589 insertions(+), 4 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra/tegra_slink.h create mode 100644 drivers/spi/tegra_slink.c -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/7] tegra: cardhu: config: enable SPI
Turn on SPI in cardhu config file Signed-off-by: Allen Martin Acked-by: Simon Glass --- include/configs/cardhu.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/configs/cardhu.h b/include/configs/cardhu.h index aa725ba..1616b39 100644 --- a/include/configs/cardhu.h +++ b/include/configs/cardhu.h @@ -49,6 +49,17 @@ #define CONFIG_ENV_IS_NOWHERE +/* SPI */ +#define CONFIG_TEGRA_SLINK +#define CONFIG_TEGRA_SLINK_CTRLS 6 +#define CONFIG_SPI_FLASH +#define CONFIG_SPI_FLASH_WINBOND +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 +#define CONFIG_SF_DEFAULT_SPEED2400 +#define CONFIG_CMD_SPI +#define CONFIG_CMD_SF +#define CONFIG_SPI_FLASH_SIZE (4 << 20) + #include "tegra-common-post.h" #endif /* __CONFIG_H */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/7] tegra: add addresses of SPI SLINK controllers
Add I/O addresses of SPI SLINK controllers 1-6 Signed-off-by: Allen Martin Acked-by: Simon Glass --- arch/arm/include/asm/arch-tegra/tegra.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/include/asm/arch-tegra/tegra.h b/arch/arm/include/asm/arch-tegra/tegra.h index f97cfd0..bf7229d 100644 --- a/arch/arm/include/asm/arch-tegra/tegra.h +++ b/arch/arm/include/asm/arch-tegra/tegra.h @@ -40,6 +40,12 @@ #define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400) #define NV_PA_NAND_BASE(NV_PA_APB_MISC_BASE + 0x8000) #define NV_PA_SPI_BASE (NV_PA_APB_MISC_BASE + 0xC380) +#define NV_PA_SLINK1_BASE (NV_PA_APB_MISC_BASE + 0xD400) +#define NV_PA_SLINK2_BASE (NV_PA_APB_MISC_BASE + 0xD600) +#define NV_PA_SLINK3_BASE (NV_PA_APB_MISC_BASE + 0xD800) +#define NV_PA_SLINK4_BASE (NV_PA_APB_MISC_BASE + 0xDA00) +#define NV_PA_SLINK5_BASE (NV_PA_APB_MISC_BASE + 0xDC00) +#define NV_PA_SLINK6_BASE (NV_PA_APB_MISC_BASE + 0xDE00) #define TEGRA_DVC_BASE (NV_PA_APB_MISC_BASE + 0xD000) #define NV_PA_PMC_BASE (NV_PA_APB_MISC_BASE + 0xE400) #define NV_PA_EMC_BASE (NV_PA_APB_MISC_BASE + 0xF400) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/7] tegra: spi: add fdt support to tegra SPI SFLASH driver
Add support for configuring tegra SPI driver from devicetree.
Support is keyed off CONFIG_OF_CONTROL. Add entry in seaboard dts
file for spi controller to describe seaboard spi.
Signed-off-by: Allen Martin
---
drivers/spi/tegra_spi.c | 45 +++--
include/fdtdec.h|1 +
lib/fdtdec.c|1 +
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/tegra_spi.c b/drivers/spi/tegra_spi.c
index 9bb34e2..ce19095 100644
--- a/drivers/spi/tegra_spi.c
+++ b/drivers/spi/tegra_spi.c
@@ -32,6 +32,9 @@
#include
#include
#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SPI_CORRUPTS_UART)
#define corrupt_delay() udelay(CONFIG_SPI_CORRUPTS_UART_DLY);
@@ -44,6 +47,7 @@ struct tegra_spi_slave {
struct spi_tegra *regs;
unsigned int freq;
unsigned int mode;
+ int periph_id;
};
static inline struct tegra_spi_slave *to_tegra_spi(struct spi_slave *slave)
@@ -84,8 +88,45 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned
int cs,
}
spi->slave.bus = bus;
spi->slave.cs = cs;
- spi->freq = max_hz;
+#ifdef CONFIG_OF_CONTROL
+ int node = fdtdec_next_compatible(gd->fdt_blob, 0,
+ COMPAT_NVIDIA_TEGRA20_SFLASH);
+ if (node < 0) {
+ debug("%s: cannot locate sflash node\n", __func__);
+ return NULL;
+ }
+ if (!fdtdec_get_is_enabled(gd->fdt_blob, node)) {
+ debug("%s: sflash is disabled\n", __func__);
+ return NULL;
+ }
+ spi->regs = (struct spi_tegra *)fdtdec_get_addr(gd->fdt_blob,
+ node, "reg");
+ if ((fdt_addr_t)spi->regs == FDT_ADDR_T_NONE) {
+ debug("%s: no sflash register found\n", __func__);
+ return NULL;
+ }
+ spi->freq = fdtdec_get_int(gd->fdt_blob, node, "spi-max-frequency", 0);
+ if (!spi->freq) {
+ debug("%s: no sflash max frequency found\n", __func__);
+ return NULL;
+ }
+ spi->periph_id = clock_decode_periph_id(gd->fdt_blob, node);
+ if (spi->periph_id == PERIPH_ID_NONE) {
+ debug("%s: could not decode periph id\n", __func__);
+ return NULL;
+ }
+#else
spi->regs = (struct spi_tegra *)NV_PA_SPI_BASE;
+ spi->freq = TEGRA_SPI_MAX_FREQ;
+ spi->periph_id = PERIPH_ID_SPI1;
+#endif
+ if (max_hz < spi->freq) {
+ debug("%s: limiting frequency from %u to %u\n", __func__,
+ spi->freq, max_hz);
+ spi->freq = max_hz;
+ }
+ debug("%s: controller initialized at %p, freq = %u, periph_id = %d\n",
+ __func__, spi->regs, spi->freq, spi->periph_id);
spi->mode = mode;
return &spi->slave;
@@ -110,7 +151,7 @@ int spi_claim_bus(struct spi_slave *slave)
u32 reg;
/* Change SPI clock to correct frequency, PLLP_OUT0 source */
- clock_start_periph_pll(PERIPH_ID_SPI1, CLOCK_ID_PERIPH, spi->freq);
+ clock_start_periph_pll(spi->periph_id, CLOCK_ID_PERIPH, spi->freq);
/* Clear stale status here */
reg = SPI_STAT_RDY | SPI_STAT_RXF_FLUSH | SPI_STAT_TXF_FLUSH | \
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..5b67a77 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -70,6 +70,7 @@ enum fdt_compat_id {
COMPAT_NVIDIA_TEGRA20_NAND, /* Tegra2 NAND controller */
COMPAT_NVIDIA_TEGRA20_PWM, /* Tegra 2 PWM controller */
COMPAT_NVIDIA_TEGRA20_DC, /* Tegra 2 Display controller */
+ COMPAT_NVIDIA_TEGRA20_SFLASH, /* Tegra 2 SPI flash controller */
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16921e1..385e0e5 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -45,6 +45,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(NVIDIA_TEGRA20_NAND, "nvidia,tegra20-nand"),
COMPAT(NVIDIA_TEGRA20_PWM, "nvidia,tegra20-pwm"),
COMPAT(NVIDIA_TEGRA20_DC, "nvidia,tegra20-dc"),
+ COMPAT(NVIDIA_TEGRA20_SFLASH, "nvidia,tegra20-sflash"),
COMPAT(SMSC_LAN9215, "smsc,lan9215"),
COMPAT(SAMSUNG_EXYNOS5_SROMC, "samsung,exynos-sromc"),
COMPAT(SAMSUNG_S3C2440_I2C, "samsung,s3c2440-i2c"),
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/7] tegra30: add SBC1 to periph id mapping table
SBC1 is SPI controller 1 on tegra30
Signed-off-by: Allen Martin
Acked-by: Simon Glass
---
arch/arm/cpu/tegra30-common/clock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/tegra30-common/clock.c
b/arch/arm/cpu/tegra30-common/clock.c
index ee3c8b1..a93f2c9 100644
--- a/arch/arm/cpu/tegra30-common/clock.c
+++ b/arch/arm/cpu/tegra30-common/clock.c
@@ -290,7 +290,7 @@ static s8 periph_id_to_internal_id[PERIPH_ID_COUNT] = {
/* 40 */
NONE(KFUSE),
- NONE(SBC1), /* SBC1, 0x34, is this SPI1? */
+ PERIPHC_SBC1,
PERIPHC_NOR,
NONE(RESERVED43),
PERIPHC_SBC2,
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/7] tegra20: fdt: add SPI SFLASH node
Add node for tegra20 SPI SFLASH controller to fdt.
Signed-off-by: Allen Martin
---
arch/arm/dts/tegra20.dtsi| 12
board/compulab/dts/tegra20-trimslice.dts |5 +
2 files changed, 17 insertions(+)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 12049fd..9a89685 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -236,6 +236,18 @@
clocks = <&tegra_car 12>, <&tegra_car 124>;
};
+ spi@7000c380 {
+ compatible = "nvidia,tegra20-sflash";
+ reg = <0x7000c380 0x80>;
+ interrupts = <0 39 0x04>;
+ nvidia,dma-request-selector = <&apbdma 11>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_SPI1, PLLP_OUT0 */
+ clocks = <&tegra_car 43>;
+ };
+
i2c@7000c400 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/board/compulab/dts/tegra20-trimslice.dts
b/board/compulab/dts/tegra20-trimslice.dts
index c8a4dd4..7aeed67 100644
--- a/board/compulab/dts/tegra20-trimslice.dts
+++ b/board/compulab/dts/tegra20-trimslice.dts
@@ -23,6 +23,11 @@
status = "disabled";
};
+ spi@7000c380 {
+ status = "okay";
+ spi-max-frequency = <2500>;
+ };
+
i2c@7000c400 {
status = "disabled";
};
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MX23 patches
Dear Otavio Salvador, > On Tue, Jan 29, 2013 at 8:21 PM, Marek Vasut wrote: > > Hello, > > > > due to the recent influx of patches, I completely lost track of what is > > going on, what patches need review and what patches are already > > obsolete. Therefore, I'd like to ask you, Otavio, to proceed as follows: > > > > - I will discard all patches for mx23 currently in my mailbox > > > > - I'd like you to reset the versioning on all your patches and start with > > clean slate (from V1, as of this moment) > > - Repost all series you currently have, incl. those you already submitted > > with proper description in all patches and with a proper cover letter > > (git NNN -- cover-letter) > > I rolled out, early this morning, the last series (3 series): > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152364 > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152361 > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152358 > > So if you really need me to resend them all, I can do it but those are > the current versions and previous ones can be ignored. I wiped all the patches from patchwork now, resubmit everything that is not yet applied. > > - Wait at least one full day (24 hours) between re-sending a series, > > unless explicitly requested otherwise. > > Ok; deal. > > > - Always CC me, Fabio and Stefano on _all_ the patches in the series, not > > only selected ones. (you can add "Cc: Us Er " in the patch > > description, this will let git send-email automatically handle the Cc) > > I've been trying to follow maintainers role here but I can change it > and copy you three in all messages. No problem for me. Just add us on the Cc since we are all directly involved. Obviously, also Cc the custodians. > > - Read [1], esp. the part about In-Reply-To please , apply this only when > > re- posting series. Do NOT do In-Reply-To for the re-post of the series > > after this restart, only if V2 is needed from now on. > > One doubt here: when sending v2 I should put the In-Reply-To for v1? I > read it but it was not clear for me. Hang the V2 series under the V1 series cover letter. Or resubmit separate patches I-R-T. > Regards, > > -- > Otavio Salvador O.S. Systems > E-mail: ota...@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MX23 patches
On Tue, Jan 29, 2013 at 8:21 PM, Marek Vasut wrote: > Hello, > > due to the recent influx of patches, I completely lost track of what is going > on, what patches need review and what patches are already obsolete. Therefore, > I'd like to ask you, Otavio, to proceed as follows: > > - I will discard all patches for mx23 currently in my mailbox > > - I'd like you to reset the versioning on all your patches and start with > clean > slate (from V1, as of this moment) > - Repost all series you currently have, incl. those you already submitted with > proper description in all patches and with a proper cover letter (git NNN -- > cover-letter) I rolled out, early this morning, the last series (3 series): http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152364 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152361 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152358 So if you really need me to resend them all, I can do it but those are the current versions and previous ones can be ignored. > - Wait at least one full day (24 hours) between re-sending a series, unless > explicitly requested otherwise. Ok; deal. > - Always CC me, Fabio and Stefano on _all_ the patches in the series, not only > selected ones. (you can add "Cc: Us Er " in the patch description, > this > will let git send-email automatically handle the Cc) I've been trying to follow maintainers role here but I can change it and copy you three in all messages. No problem for me. > - Read [1], esp. the part about In-Reply-To please , apply this only when re- > posting series. Do NOT do In-Reply-To for the re-post of the series after this > restart, only if V2 is needed from now on. One doubt here: when sending v2 I should put the In-Reply-To for v1? I read it but it was not clear for me. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MX23 patches
Am 29/01/2013 23:21, schrieb Marek Vasut: > Hello, > Hi Marek, hi Otavio, > - Wait at least one full day (24 hours) between re-sending a series, unless > explicitly requested otherwise. I am on business trip and I have this week very few possibilities to access to my e-mail. Today I saw 80 messages related to mx23 patches, and I have no chances to read them, until I will be back next week. Regards, Stefano -- = 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
[U-Boot] MX23 patches
Hello, due to the recent influx of patches, I completely lost track of what is going on, what patches need review and what patches are already obsolete. Therefore, I'd like to ask you, Otavio, to proceed as follows: - I will discard all patches for mx23 currently in my mailbox - I'd like you to reset the versioning on all your patches and start with clean slate (from V1, as of this moment) - Repost all series you currently have, incl. those you already submitted with proper description in all patches and with a proper cover letter (git NNN -- cover-letter) - Wait at least one full day (24 hours) between re-sending a series, unless explicitly requested otherwise. - Always CC me, Fabio and Stefano on _all_ the patches in the series, not only selected ones. (you can add "Cc: Us Er " in the patch description, this will let git send-email automatically handle the Cc) - Read [1], esp. the part about In-Reply-To please , apply this only when re- posting series. Do NOT do In-Reply-To for the re-post of the series after this restart, only if V2 is needed from now on. That is all. [1] http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules 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] : Please pull u-boot-i2c
On Tue, Jan 29, 2013 at 08:41:26AM +0100, Heiko Schocher wrote: > Hello Tom, > > please pull from u-boot-i2c: > > The following changes since commit 54b08efcf2f4ff532ce99c53f341a59c193331a5: > > README.mips: update known issues and TODOs (2013-01-16 10:52:08 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-i2c.git master > > for you to fetch changes up to 019be4af642cf59df0fa97082e5d9e290d26f997: > > Remove unused CONFIG_SYS_I2C_BUS[_SELECT] (2013-01-29 06:40:01 +0100) > > > Marek Vasut (1): > i2c: mxs: Staticize the functions in the driver > > Michael Jones (1): > Remove unused CONFIG_SYS_I2C_BUS[_SELECT] > > drivers/i2c/mxs_i2c.c | 8 > include/configs/am3517_crane.h | 2 -- > include/configs/am3517_evm.h | 2 -- > include/configs/cm_t35.h | 2 -- > include/configs/devkit8000.h | 2 -- > include/configs/dig297.h | 2 -- > include/configs/igep00x0.h | 2 -- > include/configs/mcx.h | 1 - > include/configs/omap3_beagle.h | 2 -- > include/configs/omap3_evm_common.h | 2 -- > include/configs/omap3_logic.h | 2 -- > include/configs/omap3_mvblx.h | 2 -- > include/configs/omap3_pandora.h| 2 -- > include/configs/omap3_sdp3430.h| 2 -- > include/configs/omap3_zoom1.h | 2 -- > include/configs/omap3_zoom2.h | 2 -- > include/configs/omap4_common.h | 2 -- > include/configs/tam3517-common.h | 2 -- > include/configs/tricorder.h| 2 -- > 19 Dateien ge?ndert, 4 Zeilen hinzugef?gt(+), 39 Zeilen entfernt(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,GIT,PULL] u-boot-mpc83xx: support for new SPL
On Wed, Jan 16, 2013 at 02:41:08PM -, Kim Phillips wrote:
> Hi Tom,
>
> Please pull:
>
> The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d:
>
> Prepare v2013.01 (2013-01-15 14:47:42 -0700)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-mpc83xx.git master
>
> for you to fetch changes up to a6187dccd813920524987792e49ef2feffb213e6:
>
> Merge remote-tracking branch 'mpc83xx/next' (2013-01-16 18:34:09 -0600)
>
>
>
> Kim Phillips (1):
> Merge remote-tracking branch 'mpc83xx/next'
>
> Scott Wood (3):
> spl: Change PAD_TO to CONFIG_SPL_PAD_TO
> powerpc/mpc83xx: add support for new SPL
> powerpc/mpc83xx: convert MPC8313ERDB to new-SPL
>
> Makefile | 6 +-
> README | 10 ++
> arch/powerpc/cpu/mpc83xx/Makefile | 16 +++
> .../cpu/mpc83xx/{nand_init.c => spl_minimal.c} | 0
> arch/powerpc/cpu/mpc83xx/start.S | 31 +++---
> .../powerpc/cpu/mpc83xx/u-boot-spl.lds | 0
> arch/powerpc/lib/Makefile | 3 +-
> board/ait/cam_enc_4xx/config.mk| 2 +-
> board/freescale/mpc8313erdb/mpc8313erdb.c | 10 +-
> boards.cfg | 4 +-
> include/configs/MPC8313ERDB.h | 43 +---
> nand_spl/board/freescale/mpc8313erdb/Makefile | 108
> -
> nand_spl/board/freescale/mpc8315erdb/Makefile | 6 +-
> nand_spl/board/sheldon/simpc8313/Makefile | 6 +-
> 14 files changed, 96 insertions(+), 149 deletions(-)
> rename arch/powerpc/cpu/mpc83xx/{nand_init.c => spl_minimal.c} (100%)
> rename nand_spl/board/freescale/mpc8313erdb/u-boot.lds =>
> arch/powerpc/cpu/mpc83xx/u-boot-spl.lds (100%)
> delete mode 100644 nand_spl/board/freescale/mpc8313erdb/Makefile
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 02:57 PM, Tom Warren wrote:
> Stephen,
>
> On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren wrote:
>> On 01/29/2013 01:40 PM, Tom Warren wrote:
>>> Stephen,
>>>
>>> On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren
>>> wrote:
On 01/29/2013 12:19 PM, Tom Warren wrote:
> Note that T114 does not have a separate/different DVC (power I2C)
> controller like T20 - all 5 I2C controllers are identical, but
> I2C5 is used to designate the controller intended for power
> control (PWR_I2C in the schematics).
>>
If you do keep this node, it needs the clocks property filled in.
> + i2c@7000c000 {
> + compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
The I2C nodes also aren't backwards-compatible.
>>>
>>> They were on T30 (same compatible string there, except of course
>>> s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
>>> (compat_names table).
>>
>> Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
>> the Tegra20 driver would run unmodified on Tegra30 without issue. I
>> don't believe that's the case for Tegra114 though. The solution would be
>> to add the Tegra114 compatible value to the I2C driver so that it can
>> search for both.
>
> Looking at the TRMs for both T30 and T114, I2C looks nearly identical,
> except for some additional registers tacked onto the end for bus clear
> support. 99% of the bits appear exactly the same, too (with the
> addition of a bus clear int bit on T114 in an used bit position). I
> know next to nothing about I2C, but it appears to me that the current
> tegra_I2C.c driver should work fine on T114 (and does, since I can
> probe addresses with it). I don't see a need for a different driver
> or compat value here.
I Cc'd in Laxman here, since he wrote the Tegra114 I2C support for the
kernel. He made the decision that Tegra114 I2C wasn't compatible with
Tegra20/30 I2C, and can explain that. Certainly looking at the kernel
patch I pointed at, it seems some of the clock divisors must be
programmed differently, which certainly seems enough to declare the HW
blocks incompatible, even if everything else is identical.
> diff --git a/board/nvidia/dts/tegra114-dalmore.dts
> b/board/nvidia/dts/tegra114-dalmore.dts
>>> That's the way I have it on T30, and looking at
>>> arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
>>> 100KHz.
>>
>> But this is board-specific; it depends on which of the I2C controllers
>> are actually pinmux'd out onto the board (-> which to enable), and which
>> devices are attached to those buses (-> max I2C clock rate). I don't see
>> how Tegra30 nor tegra30.dtsi are relevant here.
>
> I see your point, but I don't know exactly how to find out the proper
> clock & disable settings for E1611 Dalmore. I'll talk to Yen & peruse
> the docs.
The board schematics should show which I2C buses are hooked up.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Stephen,
On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren wrote:
> On 01/29/2013 01:40 PM, Tom Warren wrote:
>> Stephen,
>>
>> On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren
>> wrote:
>>> On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
>
>>> If you do keep this node, it needs the clocks property filled in.
>>>
+ i2c@7000c000 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
>>>
>>> The I2C nodes also aren't backwards-compatible.
>>
>> They were on T30 (same compatible string there, except of course
>> s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
>> (compat_names table).
>
> Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
> the Tegra20 driver would run unmodified on Tegra30 without issue. I
> don't believe that's the case for Tegra114 though. The solution would be
> to add the Tegra114 compatible value to the I2C driver so that it can
> search for both.
Looking at the TRMs for both T30 and T114, I2C looks nearly identical,
except for some additional registers tacked onto the end for bus clear
support. 99% of the bits appear exactly the same, too (with the
addition of a bus clear int bit on T114 in an used bit position). I
know next to nothing about I2C, but it appears to me that the current
tegra_I2C.c driver should work fine on T114 (and does, since I can
probe addresses with it). I don't see a need for a different driver
or compat value here.
>
+ reg = <0x7000c000 0x100>;
>>>
>>> The interrupts property is missing here.
>>
>> I didn't have an interrupts property for I2C on the T30 dts files,
>> either.
>
> That sounds like a bug in the DT.
>
>> What is it used for in U-Boot?
>
> U-Boot doesn't use interrupts at least on Tegra, so it's not used.
> However, it'd be best to keep the U-Boot DT in line with the kernel DT
> so we can easily spot differences. There has been talk of trying to use
> the same DT for both too, although we're a long long way off from that.
I'll add it, but it seems silly to add unused values, especially when
your past review critiques of DT files have asked for minimum
functionality, which I agree with.
>
>> If it's really needed, can I
>> just crib it from the kernel dts file(s)?
>
> Yes, but the Tegra114 patches aren't all checked in yet. See the
> following proposed patch for what you need:
>
> https://lkml.org/lkml/2013/1/29/235
The only diff between Laxman's dtsi file in the proposed patch and
mine is the interrupts property. I added it (it's exactly the same as
the T30 values, BTW, so I'll add interrupts to the T30 dtsi file in a
separate patch).
>
> (note that patch is missing the clocks properties since the clock
> binding isn't finalized and checked in yet)
>
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
>>>
>>> Board changes would usually be a separate patch to an SoC change, but I
>>> guess not a big deal.
>>
>> Actually, this is the way I've always done DT files (in a separate
>> patch), and then the config files in a separate patch the enable the
>> feature.
>
> I meant that tegra114.dtsi and tegra114-dalmore.dts would usually be
> separate patches.
>
>>> All 5 I2C ports are used on the board and only support 100KHz? That
>>> seems unusual, but I suppose it's possible.
>>
>> That's the way I have it on T30, and looking at
>> arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
>> 100KHz.
>
> But this is board-specific; it depends on which of the I2C controllers
> are actually pinmux'd out onto the board (-> which to enable), and which
> devices are attached to those buses (-> max I2C clock rate). I don't see
> how Tegra30 nor tegra30.dtsi are relevant here.
I see your point, but I don't know exactly how to find out the proper
clock & disable settings for E1611 Dalmore. I'll talk to Yen & peruse
the docs.
Thanks,
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 01:40 PM, Tom Warren wrote:
> Stephen,
>
> On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren wrote:
>> On 01/29/2013 12:19 PM, Tom Warren wrote:
>>> Note that T114 does not have a separate/different DVC (power I2C)
>>> controller like T20 - all 5 I2C controllers are identical, but
>>> I2C5 is used to designate the controller intended for power
>>> control (PWR_I2C in the schematics).
>> If you do keep this node, it needs the clocks property filled in.
>>
>>> + i2c@7000c000 {
>>> + compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
>>
>> The I2C nodes also aren't backwards-compatible.
>
> They were on T30 (same compatible string there, except of course
> s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
> (compat_names table).
Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
the Tegra20 driver would run unmodified on Tegra30 without issue. I
don't believe that's the case for Tegra114 though. The solution would be
to add the Tegra114 compatible value to the I2C driver so that it can
search for both.
>>> + reg = <0x7000c000 0x100>;
>>
>> The interrupts property is missing here.
>
> I didn't have an interrupts property for I2C on the T30 dts files,
> either.
That sounds like a bug in the DT.
> What is it used for in U-Boot?
U-Boot doesn't use interrupts at least on Tegra, so it's not used.
However, it'd be best to keep the U-Boot DT in line with the kernel DT
so we can easily spot differences. There has been talk of trying to use
the same DT for both too, although we're a long long way off from that.
> If it's really needed, can I
> just crib it from the kernel dts file(s)?
Yes, but the Tegra114 patches aren't all checked in yet. See the
following proposed patch for what you need:
https://lkml.org/lkml/2013/1/29/235
(note that patch is missing the clocks properties since the clock
binding isn't finalized and checked in yet)
>>> diff --git a/board/nvidia/dts/tegra114-dalmore.dts
>>> b/board/nvidia/dts/tegra114-dalmore.dts
>>
>> Board changes would usually be a separate patch to an SoC change, but I
>> guess not a big deal.
>
> Actually, this is the way I've always done DT files (in a separate
> patch), and then the config files in a separate patch the enable the
> feature.
I meant that tegra114.dtsi and tegra114-dalmore.dts would usually be
separate patches.
>> All 5 I2C ports are used on the board and only support 100KHz? That
>> seems unusual, but I suppose it's possible.
>
> That's the way I have it on T30, and looking at
> arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
> 100KHz.
But this is board-specific; it depends on which of the I2C controllers
are actually pinmux'd out onto the board (-> which to enable), and which
devices are attached to those buses (-> max I2C clock rate). I don't see
how Tegra30 nor tegra30.dtsi are relevant here.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board
Stephen, On Tue, Jan 29, 2013 at 1:11 PM, Stephen Warren wrote: > On 01/29/2013 12:19 PM, Tom Warren wrote: >> Tested all 5 'buses', i2c probe enumerates device addresses on bus >> 1 and 2. > > Why don't the other 3 buses work? No idea, but I assume because my Dalmore doesn't have sub-boards w/I2C devices connected (gyro, accel, camera, etc.) > >> Note that this uses the tegra_i2c.c driver w/o modification. > > The kernel patches imply some mandatory differences in clock divider > programming; see: > > https://patchwork.kernel.org/patch/1936371/ I'll take a look. Thanks. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
On Tue, Jan 29, 2013 at 11:13 AM, Gabor Juhos wrote:
> 2013.01.29. 11:44 keltezéssel, Daniel Schwierzeck írta:
> > 2013/1/29 Gabor Juhos :
> >> The patch adds an unified linker script file which
> >> can be used for all currently supported MIPS targets.
> >>
> >> Signed-off-by: Gabor Juhos
> >> Cc: Daniel Schwierzeck
> >> Cc: Vlad Lungu
> >> Cc: Thomas Sailer
> >> Cc: Stefan Roese
> >> Cc: Wolfgang Denk
> >> Cc: Thomas Lange
> >> Cc: Xiangfu Liu
> >
> > AFAIK you can remove Vlad Lungu and Thomas Lange from the list of
> > board maintainers
>
> Ok. I will remove Thomas Sailer as well because his e-mail address bounces.
>
> >> ---
> >> arch/mips/cpu/u-boot.lds | 90
> ++
> >> 1 file changed, 90 insertions(+)
> >> create mode 100644 arch/mips/cpu/u-boot.lds
> >>
>
> <...>
>
> >> +OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
> >
> > we need to get rid of OUTPUT_FORMAT. This was always misused due to
> > some endianess and toolchain problems which have been resolved in the
> meantime.
> >
> > We should use gcc flags like it is done in linux kernel. The config.mk
> > of mips64 already
> > has those flags. Mips32 and xburst need to be extended with:
> >
> > PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
> > ifdef CONFIG_SYS_BIG_ENDIAN
> > PLATFORM_LDFLAGS += -m elf32btsmip
> > else
> > PLATFORM_LDFLAGS += -m elf32ltsmip
> > endif
>
> Makes sense. However I would do that in a separate change. Either before or
> after the current series.
>
> >
> >> +OUTPUT_ARCH(mips)
> >> +ENTRY(_start)
> >> +SECTIONS
> >> +{
> >> + . = 0x;
> >> +
> >> + . = ALIGN(4);
> >> + .text :
> >> + {
> >> + *(.text*)
> >> + }
> >
> > please fix the style globally to
> >
> > .text : {
> > *(.text*)
> > }
>
> Ok, will change it.
>
> >
> >> +
> >> + . = ALIGN(4);
> >> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> >> +
> >> + . = ALIGN(4);
> >> + .data : { *(.data*) }
> >> +
> >> + . = .;
> >> + _gp = ALIGN(16) +0x7ff0;
> >> +
> >> + .got : {
> >> + __got_start = .;
> >> + *(.got)
> >> + __got_end = .;
> >> + }
> >> +
> >> + . = ALIGN(4);
> >> + .sdata : { *(.sdata*) }
> >
> > *(.sdata*) should be merged with .data
>
> This is separated in all current linker scripts, so the merge should be
> done in
> a separate patch IMHO.
>
IIRC, If you put .sdata in with .data, you also have to adjust the _gp
initialization so the .sdata section is within the signed 16 bit address
offset allowed.
> >
> >> +
> >> + . = ALIGN(4);
> >> + .u_boot_list : {
> >> + #include
> >> + }
> >> +
> >> + uboot_end_data = .;
> >> +
> >> + num_got_entries = (__got_end - __got_start) >> PTR_COUNT_SHIFT;
> >> +
> >> + . = ALIGN(4);
> >> + .sbss : { *(.sbss*) }
> >> + .bss : {
> >> + *(.bss*)
> >> + . = ALIGN(4);
> >> + }
> >
> > . = ALIGN(4);
> > .bss : {
> > *(.bss*)
> > *(.sbss*)
> > . = ALIGN(4);
> > }
>
> Same as above.
>
> Thank you for the review!
>
> -Gabor
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Stephen,
On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren wrote:
> On 01/29/2013 12:19 PM, Tom Warren wrote:
>> Note that T114 does not have a separate/different DVC (power I2C)
>> controller like T20 - all 5 I2C controllers are identical, but
>> I2C5 is used to designate the controller intended for power
>> control (PWR_I2C in the schematics).
>>
>> Signed-off-by: Tom Warren
>> ---
>> arch/arm/dts/tegra114.dtsi| 93
>> +
>> board/nvidia/dts/tegra114-dalmore.dts | 33
>> 2 files changed, 126 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
>> index d06cd12..76fc83b 100644
>> --- a/arch/arm/dts/tegra114.dtsi
>> +++ b/arch/arm/dts/tegra114.dtsi
>> @@ -2,4 +2,97 @@
>>
>> / {
>> compatible = "nvidia,tegra114";
>> +
>> + tegra_car: clock@60006000 {
>> + compatible = "nvidia,tegra114-car", "nvidia,tegra20-car";
>
> I don't believe the Tegra114 CAR is backwards-compatible enough with
> Tegra20 to include the Tegra20 entry in compatible. In other words, just:
>
> compatible = "nvidia,tegra114-car";
Will do.
>
>> + reg = <0x60006000 0x1000>;
>> + #clock-cells = <1>;
>> + };
>
>> + apbdma: dma {
>> + compatible = "nvidia,tegra114-apbdma", "nvidia,tegra20-apbdma";
>
> Same here; it isn't fully backwards-compatible according to Laxman's
> kernel patches.
OK.
>
> I don't think you need the APB DMA node for I2C though; perhaps just
> drop it.
It exists in T20 and T30 (via Allen's apdma patch), so I brought it
forward. I can drop it if you feel strongly enough about it. Whoever
needs it (SPI?) will have to add it later.
>
> If you do keep this node, it needs the clocks property filled in.
>
>> + i2c@7000c000 {
>> + compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
>
> The I2C nodes also aren't backwards-compatible.
They were on T30 (same compatible string there, except of course
s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
(compat_names table).
>
>> + reg = <0x7000c000 0x100>;
>
> The interrupts property is missing here.
I didn't have an interrupts property for I2C on the T30 dts files,
either. What is it used for in U-Boot? If it's really needed, can I
just crib it from the kernel dts file(s)?
>
>> diff --git a/board/nvidia/dts/tegra114-dalmore.dts
>> b/board/nvidia/dts/tegra114-dalmore.dts
>
> Board changes would usually be a separate patch to an SoC change, but I
> guess not a big deal.
Actually, this is the way I've always done DT files (in a separate
patch), and then the config files in a separate patch the enable the
feature.
>
> All 5 I2C ports are used on the board and only support 100KHz? That
> seems unusual, but I suppose it's possible.
That's the way I have it on T30, and looking at
arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
100KHz.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Davinci: Make MAC address offset in EEPROM configurable, CONFIG_MAC_EEPROM_ADDR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2013 02:28 AM, Kim Bndergaard wrote:
> --- arch/arm/cpu/arm926ejs/davinci/misc.c | 5 - 1 file changed,
> 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/davinci/misc.c
> b/arch/arm/cpu/arm926ejs/davinci/misc.c index c310c69..d0389a4
> 100644 --- a/arch/arm/cpu/arm926ejs/davinci/misc.c +++
> b/arch/arm/cpu/arm926ejs/davinci/misc.c @@ -55,11 +55,14 @@ void
> dram_init_banksize(void) * Read ethernet MAC address from EEPROM
> for DVEVM compatible boards. * Returns 1 if found, 0 otherwise. */
> +#ifndef CONFIG_MAC_EEPROM_ADDR +#define CONFIG_MAC_EEPROM_ADDR
> 0x7F00 +#endif int dvevm_read_mac_address(uint8_t *buf) { #ifdef
> CONFIG_SYS_I2C_EEPROM_ADDR /* Read MAC address. */ - if
> (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0x7F00, + if
> (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, CONFIG_MAC_EEPROM_ADDR,
> CONFIG_SYS_I2C_EEPROM_ADDR_LEN, (uint8_t *) &buf[0], 6)) goto
> i2cerr;
Lets use CONFIG_SYS_I2C_EEPROM_MAC_OFFSET and just set it in all of
the davinci configs (yes, that's touching more files). Thanks!
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRCDGxAAoJENk4IS6UOR1WAXUP/1W8kLQrWCuIunb6SB2m1ef3
7I3i9hFpENqyX1agmQtXbqaxqUC3claLWrbzzIr/3Ddrwq9ZEmjRjgl0ZWnhYsUx
sryioGP+xMd6GXzVsCO59He1Qnb9x7n5NqActNdeC2gQvVV7H0ED/7tuYO97kXRV
hfUkuw6zZl/TSK4Sz7aNBkk0xCGkvcMVZbghjW+KdgmEJRp3QJOg8USUbypN9Osp
VDVDXPB/BZkALyX30/w1qTxMDXebq3yhkEAs6LypEVeq/2KOMRs6zrCLQfO2yL2t
sEaVFWPJMH8BJL+/Us8Ol4mV3PWkE1JaI7IDpPDYpZmmAdzA8kMb6xymTCa35+r8
KKCNYnHi/uVLzL6KilBAJGqRT6HSlsxwjO3WP4XHDaWlfL3IIITJg/es3NUIvDzF
GAgR3ORY/myZ4wWhlY5BKxVONvq08ZTG5wVvuxmSpBVpmXQrpXqGRR1Tjcg/rjP5
+bFsguseMxJnYuCmWz/DS/93/NRpIGLPd4lt+nGxgnWsWYA2iY7F8UCFhPB/gAse
NTkIMEf0L1eRJM88Ktl4KLsElHBPGAsa1nEkrDfrfUOlqTzHKnTp/c1jX+AUArLW
U0kOyTfS69quoJQmPbSC9f5QlnzSWKw7nUE36xryFgdMGXaxzXYyDbHj1b7jtI3Y
rA5AhaQw/jpeBBxcmfgB
=WlpG
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board
On 01/29/2013 12:19 PM, Tom Warren wrote: > Tested all 5 'buses', i2c probe enumerates device addresses on bus > 1 and 2. Why don't the other 3 buses work? > Note that this uses the tegra_i2c.c driver w/o modification. The kernel patches imply some mandatory differences in clock divider programming; see: https://patchwork.kernel.org/patch/1936371/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 12:19 PM, Tom Warren wrote:
> Note that T114 does not have a separate/different DVC (power I2C)
> controller like T20 - all 5 I2C controllers are identical, but
> I2C5 is used to designate the controller intended for power
> control (PWR_I2C in the schematics).
>
> Signed-off-by: Tom Warren
> ---
> arch/arm/dts/tegra114.dtsi| 93
> +
> board/nvidia/dts/tegra114-dalmore.dts | 33
> 2 files changed, 126 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
> index d06cd12..76fc83b 100644
> --- a/arch/arm/dts/tegra114.dtsi
> +++ b/arch/arm/dts/tegra114.dtsi
> @@ -2,4 +2,97 @@
>
> / {
> compatible = "nvidia,tegra114";
> +
> + tegra_car: clock@60006000 {
> + compatible = "nvidia,tegra114-car", "nvidia,tegra20-car";
I don't believe the Tegra114 CAR is backwards-compatible enough with
Tegra20 to include the Tegra20 entry in compatible. In other words, just:
compatible = "nvidia,tegra114-car";
> + reg = <0x60006000 0x1000>;
> + #clock-cells = <1>;
> + };
> + apbdma: dma {
> + compatible = "nvidia,tegra114-apbdma", "nvidia,tegra20-apbdma";
Same here; it isn't fully backwards-compatible according to Laxman's
kernel patches.
I don't think you need the APB DMA node for I2C though; perhaps just
drop it.
If you do keep this node, it needs the clocks property filled in.
> + i2c@7000c000 {
> + compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
The I2C nodes also aren't backwards-compatible.
> + reg = <0x7000c000 0x100>;
The interrupts property is missing here.
> diff --git a/board/nvidia/dts/tegra114-dalmore.dts
> b/board/nvidia/dts/tegra114-dalmore.dts
Board changes would usually be a separate patch to an SoC change, but I
guess not a big deal.
All 5 I2C ports are used on the board and only support 100KHz? That
seems unusual, but I suppose it's possible.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/corenet: Add workaround for ELBC multi-bit ECC error
On 01/28/2013 01:16:53 AM, Shaohui Xie wrote:
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index e5ecf5d..f26d608 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -227,6 +227,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_NMG_LBC103
puts("Work-around for Erratum NMG_LBC103 enabled\n");
#endif
+#ifdef CONFIG_SYS_FSL_ELBC_MULTIBIT_ECC
+ puts("Work-around for Erratum ELBC MULTIBIT ECC enabled\n");
+#endif
Is there still no erratum number for this?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x: NAND: add BCH16 and 4k page size support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2013 02:54 PM, Scott Wood wrote:
> On 01/28/2013 07:35:40 AM, Jordy van Wolferen wrote:
>> This is tested with a custom AM3359 (rev 2.0) board. NAND chip:
>> MT29F16G08ABABAWP
>>
>> This code allows me to boot from ROM code. The ROM code forces
>> BCH16 on NAND chips with a 4k page size.
>>
>> BCH16 is not enabled by default.
>>
>>
>> ---
>
> Missing Signed-off-by (please read the "Sign your work" section of
> Documentation/SubmittingPatches in Linux and be sure that you meet
> the conditions of the Developer's Certificate of Origin before
> adding your sign off).
Note that this also appears to be versus a TI SDK tree and not mainline
(but migrating the code shouldn't be overly difficult now that NAND
support is mainline).
> Could you explain the patch in a bit more detail? You say it is
> "not enabled by default" -- what would be required to enable it?
It needs to be auto-detected and switched to, just like how the ROM
does (which is to say when the ROM picks up BCH16 and wants it, we do
too).
[snip]
>> diff --git a/include/linux/mtd/mtd-abi.h
>> b/include/linux/mtd/mtd-abi.h index 8bdd231..6979a2a 100644 ---
>> a/include/linux/mtd/mtd-abi.h +++ b/include/linux/mtd/mtd-abi.h
>> @@ -125,7 +125,7 @@ struct nand_oobfree { */ struct
>> nand_ecclayout { uint32_t eccbytes; -uint32_t eccpos[128]; +
>> uint32_t eccpos[208]; uint32_t oobavail; struct nand_oobfree
>> oobfree[MTD_MAX_OOBFREE_ENTRIES]; };
>
> Changes to generic code should ideally be separate patches.
True. And I wonder if the mtd re-sync covers this or not.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRCCquAAoJENk4IS6UOR1WcP4P+wUmTIMJlxEVP0JQseXL3fG1
gS0+KRYzFgceBkunfbgXcCGAqP2z3gcmyNEn0s/8dVkrN1F9MirUNz2VApqQwn0b
lj8E/30e042EzM3sM/HyPO0S4yWBVf8GjYiRJMDb80gKOJelthrKNAjermIxqax6
dIHlSvV9pk6DYHTAmcgC7H3QLyHkwyZfSwii+ZRKm5hRPgpiQA2kI7klV8rEH8m7
x5d5c1Ry59hIrefmWWpJvrXhy9u8ipCzk37CCafyl3KbZJoOhZSHiXx73TebI1gP
Sg1ONCvi8MkOZrMmC+iXqbKtrPYUGYApd7TonIoJg2yTlkIBevbTY4OLS/p81Btq
HoJZ7PziCbeu4jZCVlS4Pz7OiIf5GyBbW1oJP/Uhz4tJAuSLJTrxHaiz7sUIZt3p
zNr1ZrL7d5h6hlv3XBuERxRvAn2E4K+sSUJsS+C+8zi/rYMWfWxm5ncB4ygGqCNn
QYvJSwWXK/yyFpq0NSbXZnHvBInwGcdrcQVJy3RftATxEW7B2EJKbLx8yJxcpoaU
nDyN/NDYEeqZx3Vwf8q2YAv7S72vFP6Lwfy+bAbOeyc3emH6sYTE9iDt2EzTYuMM
3nDjgWZiNGDzJ7WzUv6ptDUIV9UQXxdwa7Ay4qc7aKbSx4t/LhjtIDXJYVh9Bbxq
3cYj8flqqYG9yQQn5xk/
=fOZt
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x: NAND: add BCH16 and 4k page size support
On 01/28/2013 07:35:40 AM, Jordy van Wolferen wrote:
This is tested with a custom AM3359 (rev 2.0) board.
NAND chip: MT29F16G08ABABAWP
This code allows me to boot from ROM code.
The ROM code forces BCH16 on NAND chips with a 4k page size.
BCH16 is not enabled by default.
---
Missing Signed-off-by (please read the "Sign your work" section of
Documentation/SubmittingPatches in Linux and be sure that you meet the
conditions of the Developer's Certificate of Origin before adding your
sign off).
Could you explain the patch in a bit more detail? You say it is "not
enabled by default" -- what would be required to enable it?
arch/arm/include/asm/arch-am33xx/cpu.h | 8 +-
arch/arm/include/asm/arch-am33xx/omap_gpmc.h | 43
drivers/mtd/nand/omap_gpmc.c | 150
+--
include/linux/mtd/mtd-abi.h | 2 +-
4 files changed, 148 insertions(+), 55 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 16e8a80..0a1f1ff 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -78,6 +78,10 @@ struct bch_res_0_3 {
u32 bch_result_x[4];
};
+struct bch_res_4_6 {
+ u32 bch_result_x[3];
+};
+
struct gpmc {
u8 res1[0x10];
u32 sysconfig; /* 0x10 */
@@ -107,7 +111,9 @@ struct gpmc {
u8 res7[12];/* 0x224 */
u32 testmomde_ctrl; /* 0x230 */
u8 res8[12];/* 0x234 */
- struct bch_res_0_3 bch_result_0_3[2]; /* 0x240 */
+ struct bch_res_0_3 bch_result_0_3; /* 0x240 */
+ u32 dummy[44]; /* not used */
+ struct bch_res_4_6 bch_result_4_6; /* 300 */
};
/* Used for board specific gpmc initialization */
diff --git a/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
b/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
index 572f9d0..534fa6e 100644
--- a/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
+++ b/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
@@ -117,4 +117,47 @@
{.offset = 106,\
.length = 8 } } \
}
+
+#define GPMC_NAND_4K_HW_BCH8_ECC_LAYOUT {\
+ .eccbytes = 112,\
+ .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
+16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
26, 27,\
+28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39,\
+40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51,\
+52, 53, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63,\
+64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75,\
+76, 77, 78, 79, 80, 81, 82, 83, 84, 85,
86, 87,\
+88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99,\
+100, 101, 102, 103, 104, 105, 106, 107,
108, 109,\
+ 110, 111, 112, 113},\
+ .oobfree = {\
+ {.offset = 114,\
+.length = 110 } } \
+}
+
+#define GPMC_NAND_4K_HW_BCH16_ECC_LAYOUT {\
+ .eccbytes = 208,\
+ .eccpos = { 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
+16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
26, 27,\
+28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39,\
+40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51,\
+52, 53, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63,\
+64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75,\
+76, 77, 78, 79, 80, 81, 82, 83, 84, 85,
86, 87,\
+88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99,\
+100, 101, 102, 103, 104, 105, 106, 107,
108, 109,\
+110, 111, 112, 113, 114, 115, 116, 117,
118, 119,\
+120, 121, 122, 123, 124, 125, 126, 127,
128, 129,\
+130, 131, 132, 133, 134, 135, 136, 137,
138, 139,\
+140, 141, 142, 143, 144, 145, 146, 147,
148, 149,\
+150, 151, 152, 153, 154, 155, 156, 157,
158, 159,\
+160, 161, 162, 163, 164, 165, 166, 167,
168, 169,\
+170, 171, 172, 173, 174, 175, 176, 177,
178, 179,\
+180, 181, 182, 183, 184, 185, 186, 187,
188, 189,\
+190, 191, 192, 193, 194, 195, 196, 197,
198, 199,\
+200, 201, 202, 203, 204, 205, 206, 207,
208, 209},\
You have too many tabs here -- be sure your editor is set for
8-character tabs.
+ .oobfree = {\
+ {.offset = 210,\
+.length = 14 } } \
+}
#endif /* __ASM_ARCH_OMAP_GPMC_H */
diff --git a/drivers/mtd/nand/omap_gpmc.c
b/drivers/mtd/nand/omap_gpmc.c
index cee394e..3c42a54 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -76,8 +76,8 @@ int omap_spl_dev_ready(struct mtd_info *mtd)
/*
* omap_hwecc_init - Initialize the Hardware ECC for NAND flash in
- * GPMC controller
- * @mtd:MTD device structure
+ * GPMC controller
+ * @mtd: MTD device structure
*
*/
static void __maybe_unused omap_hwecc_init(struct nand_chip *chip)
No unrelated whitespace changes, please.
@@ -258,7 +258,7 @@ struct nand_bch_priv {
#define ECC_BCH8_NIBBLES 26
#define ECC_BCH
[U-Boot] [PATCH 2/2] Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board
Tested all 5 'buses', i2c probe enumerates device addresses on bus 1 and 2. Note that this uses the tegra_i2c.c driver w/o modification. Signed-off-by: Tom Warren --- include/configs/dalmore.h |9 + include/configs/tegra114-common.h |3 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/configs/dalmore.h b/include/configs/dalmore.h index ce32c80..b1a6e34 100644 --- a/include/configs/dalmore.h +++ b/include/configs/dalmore.h @@ -41,6 +41,15 @@ #define CONFIG_MACH_TYPE MACH_TYPE_DALMORE #define CONFIG_BOARD_EARLY_INIT_F + +/* I2C */ +#define CONFIG_TEGRA_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_MAX_I2C_BUS TEGRA_I2C_NUM_CONTROLLERS +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C + #define CONFIG_ENV_IS_NOWHERE #define MACH_TYPE_DALMORE 4304/* not yet in mach-types.h */ diff --git a/include/configs/tegra114-common.h b/include/configs/tegra114-common.h index 0033530..c2986d8 100644 --- a/include/configs/tegra114-common.h +++ b/include/configs/tegra114-common.h @@ -76,4 +76,7 @@ #define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/tegra114/u-boot-spl.lds" +/* Total I2C ports on Tegra114 */ +#define TEGRA_I2C_NUM_CONTROLLERS 5 + #endif /* _TEGRA114_COMMON_H_ */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
Signed-off-by: Tom Warren
---
arch/arm/dts/tegra114.dtsi| 93 +
board/nvidia/dts/tegra114-dalmore.dts | 33
2 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index d06cd12..76fc83b 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -2,4 +2,97 @@
/ {
compatible = "nvidia,tegra114";
+
+ tegra_car: clock@60006000 {
+ compatible = "nvidia,tegra114-car", "nvidia,tegra20-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ apbdma: dma {
+ compatible = "nvidia,tegra114-apbdma", "nvidia,tegra20-apbdma";
+ reg = <0x6000a000 0x1400>;
+ interrupts = <0 104 0x04
+ 0 105 0x04
+ 0 106 0x04
+ 0 107 0x04
+ 0 108 0x04
+ 0 109 0x04
+ 0 110 0x04
+ 0 111 0x04
+ 0 112 0x04
+ 0 113 0x04
+ 0 114 0x04
+ 0 115 0x04
+ 0 116 0x04
+ 0 117 0x04
+ 0 118 0x04
+ 0 119 0x04
+ 0 128 0x04
+ 0 129 0x04
+ 0 130 0x04
+ 0 131 0x04
+ 0 132 0x04
+ 0 133 0x04
+ 0 134 0x04
+ 0 135 0x04
+ 0 136 0x04
+ 0 137 0x04
+ 0 138 0x04
+ 0 139 0x04
+ 0 140 0x04
+ 0 141 0x04
+ 0 142 0x04
+ 0 143 0x04>;
+ };
+
+ i2c@7000c000 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000c000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_I2C1 */
+ clocks = <&tegra_car 12>;
+ };
+
+ i2c@7000c400 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000c400 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_I2C2 */
+ clocks = <&tegra_car 54>;
+ };
+
+ i2c@7000c500 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000c500 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_I2C3 */
+ clocks = <&tegra_car 67>;
+ };
+
+ i2c@7000c700 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000c700 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_I2C4 */
+ clocks = <&tegra_car 103>;
+ };
+
+ i2c@7000d000 {
+ compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000d000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ /* PERIPH_ID_I2C5 */
+ clocks = <&tegra_car 47>;
+ };
};
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
index 7315577..13b07f3 100644
--- a/board/nvidia/dts/tegra114-dalmore.dts
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -6,8 +6,41 @@
model = "NVIDIA Dalmore";
compatible = "nvidia,dalmore", "nvidia,tegra114";
+ aliases {
+ i2c0 = "/i2c@7000d000";
+ i2c1 = "/i2c@7000c000";
+ i2c2 = "/i2c@7000c400";
+ i2c3 = "/i2c@7000c500";
+ i2c4 = "/i2c@7000c700";
+ };
+
memory {
device_type = "memory";
reg = <0x8000 0x8000>;
};
+
+ i2c@7000c000 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c400 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c500 {
+ st
[U-Boot] [PATCH 0/2] Add I2C driver for Tegra114 Dalmore
Update DT tables and enable I2C driver support for the Tegra114 Dalmore board. This uses the standard Tegra I2C driver. 5 controllers are supported, although all may not have devices behind them on every board. Tom Warren (2): Tegra114: fdt: Update DT files with I2C info for T114/Dalmore Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board arch/arm/dts/tegra114.dtsi| 93 + board/nvidia/dts/tegra114-dalmore.dts | 33 include/configs/dalmore.h |9 +++ include/configs/tegra114-common.h |3 + 4 files changed, 138 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help : Marvell SDIO/MMC driver for Sheevaplug
Hi, On Tue, Jan 29, 2013 at 11:35 PM, DrEagle wrote: > Hi all, > >> > -Original Message- >> > From: u-boot-bounces at lists.denx.de [mailto:u-boot- >> > bounces at lists.denx.de] On Behalf Of DrEagle >> > Sent: 22 September 2012 12:45 >> > To: DrEagle >> > Cc: Lior Amsalem; u-boot at lists.denx.de; uboot at doukki.net >> > Subject: [U-Boot] [PATCH v2 0/5] Marvell SDIO/MMC driver for >> > Sheevaplug >> > >> > >> > This serie of patch add SDIO/MMC support to Sheevaplug board >> > >> > Change from v1: >> > - Fix an issue with most SDHC cards because of timeout delay >> > >> > drEagle (5): >> > Add Marvell SDIO/MMC driver for Kirkwood SoC >> > Add SDIO/MMC support for kirkwood SoC >> > Add SDIO/MMC support for Sheevaplug board >> > Fix env address for Sheevaplug board >> > Fix timeout in Marvell SDIO MMC driver >> >> Hi DrEagle >> I still request you to study mvsdhci.c which is similar framework used for >> Pantheon family of SoCs, >> try to use this infrastructure is possible for Kirkwood support. >> >> Regards... >> Prafulla . . . > > I have started looking at sdhci component but I find only theses small > details : > > ... > 9) mv_sdhci.c > - > This is a component of the SDHCI support, allowing it to run on Marvell > Kirkwood chip. It is probable the SDHCI support will have to be modified to > allow calling functions from this file based on information passed via > platform_data. > ... > 16) sdhci.c > --- > Follows the new API and also has a good encapsulation of the whole driver. > The > conversion here will be simple, though it'd be necessary to modify this > driver > to also support the Kirkwood series and probably also Tegra series of CPUs. > See the respective parts of this section for details. > ... > > Can anybody give me more advice on how to port efficiently a patch for > SDIO/MMC for SheevaPlug/Kirkwood SoC while using, as Prafulla asked, the > *sdhci* framework. Giving sdhci core support to your driver: I have listed few steps that I followed while doing on my driver. 1. On your driver need to allocate a sdhci_host 2. assign your sd bases address, version, some quirks (quirks are very impotent to change the functionalities of sdhci core)and few more... 3. call add_sdhci(sdhci_host, max_clk, min_clk) 4. any misc based on ur controller. On my experience using with SDHCI is it is functionally an intelligent core have issues with command delay..this may be because it's implemented newly. Starts using sdhci...post any issues..so-that we can tune sdhci more and more. Thanks, Jagan. > > What are the best practices and the technical details which can help me into > this ? > > Regards, > drEagle > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help : Marvell SDIO/MMC driver for Sheevaplug
Hi all, > > -Original Message- > > From: u-boot-bounces at lists.denx.de [mailto:u-boot- > > bounces at lists.denx.de] On Behalf Of DrEagle > > Sent: 22 September 2012 12:45 > > To: DrEagle > > Cc: Lior Amsalem; u-boot at lists.denx.de; uboot at doukki.net > > Subject: [U-Boot] [PATCH v2 0/5] Marvell SDIO/MMC driver for > > Sheevaplug > > > > > > This serie of patch add SDIO/MMC support to Sheevaplug board > > > > Change from v1: > > - Fix an issue with most SDHC cards because of timeout delay > > > > drEagle (5): > > Add Marvell SDIO/MMC driver for Kirkwood SoC > > Add SDIO/MMC support for kirkwood SoC > > Add SDIO/MMC support for Sheevaplug board > > Fix env address for Sheevaplug board > > Fix timeout in Marvell SDIO MMC driver > > Hi DrEagle > I still request you to study mvsdhci.c which is similar framework used for > Pantheon family of SoCs, > try to use this infrastructure is possible for Kirkwood support. > > Regards... > Prafulla . . . I have started looking at sdhci component but I find only theses small details : ... 9) mv_sdhci.c - This is a component of the SDHCI support, allowing it to run on Marvell Kirkwood chip. It is probable the SDHCI support will have to be modified to allow calling functions from this file based on information passed via platform_data. ... 16) sdhci.c --- Follows the new API and also has a good encapsulation of the whole driver. The conversion here will be simple, though it'd be necessary to modify this driver to also support the Kirkwood series and probably also Tegra series of CPUs. See the respective parts of this section for details. ... Can anybody give me more advice on how to port efficiently a patch for SDIO/MMC for SheevaPlug/Kirkwood SoC while using, as Prafulla asked, the *sdhci* framework. What are the best practices and the technical details which can help me into this ? Regards, drEagle signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can I read env from RAM in uboot script?
On Tue, 2013-01-29 at 17:58 +0800, Bo Shen wrote:
>
> You should use at91sam9g20ek_2mmc_nandflash to configure the u-boot
>
>
> diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
> b/board/atmel/at91sam9260ek/at91sam9260ek.c
> index 2555672..ce475df 100644
> --- a/board/atmel/at91sam9260ek/at91sam9260ek.c
> +++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
> @@ -157,6 +157,10 @@ int board_early_init_f(void)
>
> int board_init(void)
> {
> +#ifdef CONFIG_AT91SAM9G20EK_2MMC
> + /* arch number of AT91SAM9260EK-Board */
> + gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
> +#else
> #ifdef CONFIG_AT91SAM9G20EK
> /* arch number of AT91SAM9260EK-Board */
> gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
> @@ -164,6 +168,7 @@ int board_init(void)
> /* arch number of AT91SAM9260EK-Board */
> gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
> #endif
> +#endif
> /* adress of boot parameters */
> gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
>
> diff --git a/boards.cfg b/boards.cfg
> index e4b0d44..fa863dc 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -95,6 +95,7 @@ at91sam9g10ek_nandflash arm arm926ejs
> at91sam9261ek atmel
> at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek
> atmel at91
> at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
> at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek
> atmel at91
> at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
> at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek
> atmel at91
> at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
> +at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek
>atmel at91
> at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
> at91sam9m10g45ek_nandflash arm arm926ejs
> at91sam9m10g45ek
> atmel at91
> at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
> at91sam9rlek_dataflash arm arm926ejs at91sam9rlek
> atmel at91
> at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
> at91sam9rlek_nandflash arm arm926ejs at91sam9rlek
> atmel at91
> at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
> ---
>
>
That worked! Very nice! But, I had to apply the patches manually.
Email may have messed up the patch sets with new-lines and indentation.
Can this be added to the main stream? I am on to learning 'env import'.
Thank you.
If email messed it up once, I guess it could mess it up again, but I
generated patches using:
diff -Naur before/ after/ > diff.patch
--- board/atmel/at91sam9260ek/at91sam9260ek.c.orig2013-01-29
09:09:35.0 -0800
+++ board/atmel/at91sam9260ek/at91sam9260ek.c 2013-01-29 09:10:46.0
-0800
@@ -157,6 +157,10 @@
int board_init(void)
{
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+ /* arch number of AT91SAM9260EK-Board */
+ gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
#ifdef CONFIG_AT91SAM9G20EK
/* arch number of AT91SAM9260EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
@@ -164,6 +168,7 @@
/* arch number of AT91SAM9260EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
#endif
+#endif
/* adress of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
--- boards.cfg.orig 2013-01-29 08:56:47.0 -0800
+++ boards.cfg2013-01-29 08:58:21.0 -0800
@@ -94,6 +94,7 @@
at91sam9g10ek_nandflash arm arm926ejs at91sam9261ek atmel
at91at91sam9261ek:AT91SAM9G10,SYS_USE_NANDFLASH
at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
+at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek atmel
at91
at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
at91sam9m10g45ek_nandflash arm arm926ejs at91sam9m10g45ekatmel
at91at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
at91sam9rlek_dataflash arm arm926ejs at91sam9rlekatmel
at91at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
2013.01.29. 11:44 keltezéssel, Daniel Schwierzeck írta:
> 2013/1/29 Gabor Juhos :
>> The patch adds an unified linker script file which
>> can be used for all currently supported MIPS targets.
>>
>> Signed-off-by: Gabor Juhos
>> Cc: Daniel Schwierzeck
>> Cc: Vlad Lungu
>> Cc: Thomas Sailer
>> Cc: Stefan Roese
>> Cc: Wolfgang Denk
>> Cc: Thomas Lange
>> Cc: Xiangfu Liu
>
> AFAIK you can remove Vlad Lungu and Thomas Lange from the list of
> board maintainers
Ok. I will remove Thomas Sailer as well because his e-mail address bounces.
>> ---
>> arch/mips/cpu/u-boot.lds | 90
>> ++
>> 1 file changed, 90 insertions(+)
>> create mode 100644 arch/mips/cpu/u-boot.lds
>>
<...>
>> +OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
>
> we need to get rid of OUTPUT_FORMAT. This was always misused due to
> some endianess and toolchain problems which have been resolved in the
> meantime.
>
> We should use gcc flags like it is done in linux kernel. The config.mk
> of mips64 already
> has those flags. Mips32 and xburst need to be extended with:
>
> PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
> ifdef CONFIG_SYS_BIG_ENDIAN
> PLATFORM_LDFLAGS += -m elf32btsmip
> else
> PLATFORM_LDFLAGS += -m elf32ltsmip
> endif
Makes sense. However I would do that in a separate change. Either before or
after the current series.
>
>> +OUTPUT_ARCH(mips)
>> +ENTRY(_start)
>> +SECTIONS
>> +{
>> + . = 0x;
>> +
>> + . = ALIGN(4);
>> + .text :
>> + {
>> + *(.text*)
>> + }
>
> please fix the style globally to
>
> .text : {
> *(.text*)
> }
Ok, will change it.
>
>> +
>> + . = ALIGN(4);
>> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
>> +
>> + . = ALIGN(4);
>> + .data : { *(.data*) }
>> +
>> + . = .;
>> + _gp = ALIGN(16) +0x7ff0;
>> +
>> + .got : {
>> + __got_start = .;
>> + *(.got)
>> + __got_end = .;
>> + }
>> +
>> + . = ALIGN(4);
>> + .sdata : { *(.sdata*) }
>
> *(.sdata*) should be merged with .data
This is separated in all current linker scripts, so the merge should be done in
a separate patch IMHO.
>
>> +
>> + . = ALIGN(4);
>> + .u_boot_list : {
>> + #include
>> + }
>> +
>> + uboot_end_data = .;
>> +
>> + num_got_entries = (__got_end - __got_start) >> PTR_COUNT_SHIFT;
>> +
>> + . = ALIGN(4);
>> + .sbss : { *(.sbss*) }
>> + .bss : {
>> + *(.bss*)
>> + . = ALIGN(4);
>> + }
>
> . = ALIGN(4);
> .bss : {
> *(.bss*)
> *(.sbss*)
> . = ALIGN(4);
> }
Same as above.
Thank you for the review!
-Gabor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vfat: Fix mkcksum argument sizes
Marek Vasut denx.de> wrote: > In case a function argument is known/fixed size array in C, the argument is > still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore > calling sizeof on the function argument will result in the size of the > pointer, > not the size of the array. > > The VFAT code contains such a bug, this patch fixes it. > I had the same problem with VFAT formatted USB stick on U-Boot 2013.01 as the original bug reported by Michail Simek. I have not made any deeper analysis of your patch, but it solved the problem. Thanks! BR / Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel
Dear Marek Vasut, On 01/25/2013 12:16 PM, Marek Vasut wrote: Dear Piotr Wilczek, Dear Marek Vasut, -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Thursday, January 24, 2013 1:33 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski; Tom Rini; Andrzej Pietrasiewicz Subject: Re: [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel Dear Piotr Wilczek, From: Lukasz Majewski The storage_common.c source file from v2.6.36 Linux kernel. Is it not possibly to port anything more recent? If not, so be it. The reason was to use the simplest and tested version. Nevermind my dumb comment, I took a peek and figured as much as that we're stuck with .36-ish gadget framework. Now, completely unrelated question, but since you're the expert at these things, I'll just fire it at you -- do you think porting serial gadget would be too hard? Apparently the CONFIG_USB_TTY is a junk and with the new gadget drivers, this won't work, thus we need new usb-serial-gadget driver. Thank you for all your comments. Regarding your question, I'm not sure at the moment how much effort it is required to port that driver. Best regards, Marek Vasut Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr
Dear Wolfgang, On 29/01/2013 10.48, Wolfgang Denk wrote: Dear Luca Ellero, In message <51078bfd.60...@gmail.com> you wrote: in U-Boot version 2012.10 I used to skip "relocate_code" setting CONFIG_SYS_TEXT_BASE to relocaddr (obtained from bdinfo command). This since some hardware is able to configure SDRAM and load U-Boot directly to SDRAM, so relocation is useless and time consuming. You are wrong. relocation is not useless, even in your case. there are quite a number of configuration options that will put stuff above the U-Boot image, directly at the end of RAM (things like protected RAM, shared frame buffer, shared log buffer, etc.). In these cases, the relocation address may even be dynamic (i. e. depending on settings of environment variables, and thus unknown at compile time). Now I'm using latest git version and this isn't working anymore. Can someone explain me way? And what is the suggested way to skip relocation now. Don't. Got your point ;-) Thanks I'm asking that since I'm digging on ARM SDRAM configuration and found a bug on getting top of SDRAM (where u-boot will be relocated). On ARM architectures top of SDRAM will always be: CONFIG_SYS_SDRAM_BASE + gd->ram_size anyway this can be wrong since SDRAM can be composed by more that one bank in not-contiguous address space. (CONFIG_SYS_SDRAM_BASE + gd->ram_size) can land to not existent SDRAM addresses and can be very dangerous since it can potentially corrupt real SDRAM (in most cases SDRAM is aliased so writing to some not-existent address can write to real address). My proposed patch is something like this: - diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index cfe32cc..7525caf 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -333,7 +333,18 @@ void board_init_f(ulong bootflag) gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE; #endif +#if defined(PHYS_SDRAM_2) && defined(PHYS_SDRAM_2_SIZE) + if ( CONFIG_NR_DRAM_BANKS > 1 && + (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE) != PHYS_SDRAM_2 ) + addr = PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE; + else + addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; +#else addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; +#endif + - I know that some arch use more than 2 banks but implementing all macros checks to PHYS_SDRAM_* leads to some macro hell. So the point here is: if (n banks > 2) and they are not contiguous, relocate u-boot at the end of 2nd bank even if there are more than 2 banks. Please suggest me if this is the right way to follow or suggest me some more appropriate way to correct this bug Thanks again Regards Luca Ellero ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 5/7] cm-t35: add support for dvi displays
Hi Wolfgang Denk,
On 01/29/2013 04:00 PM, Wolfgang Denk wrote:
Dear Nikita Kiryanov,
In message <1359463349-11649-6-git-send-email-nik...@compulab.co.il> you wrote:
Add support for dvi displays with user selectable dvi presets.
...
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
/* SB-T35 Ethernet */
MUX_VAL(CP(GPMC_NCS4), (IEN | PTU | EN | M0)); /*GPMC_nCS4*/
+ /* DVI enable */
+ MUX_VAL(CP(GPMC_NCS3), (IDIS | PTU | DIS | M4));/*GPMC_nCS3*/
Is it intentional and correct to always enable DVI, even when this is
not configured by the user?
This simply prepares the mux that makes it possible to enable DVI.
The actual enabling of DVI is indeed conditional on user setup.
+/*
+ * The frame buffer is allocated before we have the chance to parse user input.
This seems broken to me.
Agreed.
Please explain why you think so?
This isn't just my impression. A patch was submitted by Stephen Warren
to address this issue (http://patchwork.ozlabs.org/patch/212378/), but
it isn't in mainline yet.
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+ .vl_col = 1400,
+ .vl_row = 1050,
+ .vl_bpix = LCD_BPP,
+ .cmap = (ushort *)0x8010,
Can we please avoid such hard coded magic numbers?
OK.
+/*
+ * env_parse_displaytype() - parse display type.
+ *
+ * Parses the environment variable "displaytype", which contains the
+ * name of the display type or preset, in which case it applies its
+ * configurations.
So we have yet another custom implementation for setting the display
type? Can we please agree on using common standard methods? thanks.
Most of what is custom in this patchset is parsing of environment
variables. For actually setting up the DSS I do use common code
(specifically omap3_dss_panel_config() and related structs/defines).
Best regards,
Wolfgang Denk
--
Regards,
Nikita.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization
Dear All, Any feedback about this patch? > This patch changes sdhci_init()'s behavior to NOT enable all interrupt > sources by default. Moreover interrupt signaling has been disabled. > > This patch do not enable interrupts which aren't served in u-boot > (they are defined at sdhci.h but NOT used elsewhere): > - SDHCI_INT_CARD_INSERT, SDHCI_INT_CARD_REMOVE, SDHCI_BUS_POWER, > SDHCI_INT_CARD_REMOVE, SDHCI_INT_CARD_INT > > Special care shall be put on SDHCI_INT_CARD_INT, which indicates > interrupt generated by SD card. > According to "SD Host Controller Simplified Spec. ver 3.00" when bit 8 > (Card Interrupt Status Enable) at "Normal Interrupt Status Enable > Register" (offset 0x34) is set, the card interrupt detection is > started. Then eMMC card may cause the SD controller to set this bit > and then this interrupt is passed to booted OS and might cause kernel > crash. > > > To sum up: > - Only enable interrupts, which are served at u-boot > - This cleanup as a side effect fixes SDHCI's CARD INTERRUPT problem > at Linux kernel (versions 3.6+, sdhci controller) > - Keep masked bits at "Normal Interrupt Signal Enable > Register" (0x38h) > > Signed-off-by: Lukasz Majewski > Signed-off-by: Kyungmin Park > Cc: Lei Wen > Cc: Andy Fleming > --- > drivers/mmc/sdhci.c |8 +--- > 1 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > index 0fd1337..76c14fb 100644 > --- a/drivers/mmc/sdhci.c > +++ b/drivers/mmc/sdhci.c > @@ -412,9 +412,11 @@ int sdhci_init(struct mmc *mmc) > status = sdhci_readl(host, > SDHCI_PRESENT_STATE); } > > - /* Eable all state */ > - sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_ENABLE); > - sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_SIGNAL_ENABLE); > + /* Enable only interrupts served by the SD controller */ > + sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK > + , SDHCI_INT_ENABLE); > + /* Mask all sdhci interrupt sources */ > + sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE); > > return 0; > } -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 4/7] lcd: add option for board specific splash screen preparation
Hi Wolfgang Denk, On 01/29/2013 03:46 PM, Wolfgang Denk wrote: Dear Nikita Kiryanov, In message <1359463349-11649-5-git-send-email-nik...@compulab.co.il> you wrote: Currently there is no logical place to put the code that prepares the splash image data. The splash image data should be ready in memory before bmp_display() is called, and after the environment is ready (since lcd.c looks for the splash image in an address specified by the environment variable "splashimage"). Our window of opportunity in board_init_r() is therefore: between env_relocate() and bmp_display(), and from the available options only the lcd related functions in drv_lcd_init() seem appropriate for such lcd oriented code. Add the option to prepare the splash image data in lcd_logo() right before it is sent to be displayed. Signed-off-by: Nikita Kiryanov Signed-off-by: Igor Grinberg You should add the video custodian on Cc: for such patches. [Done here]. Will do... I did Cc Anatolij when running git send-patch though... It's possible that it was dropped by mailman (see this discussion: http://www.mail-archive.com/u-boot@lists.denx.de/msg103585.html) but he should still get the email. Anyway, I'll start using the Cc line in the patches as requested.. Best regards, Wolfgang Denk -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/7] lcd: prevent unaligned memory access when displaying splash screen
Hi Wolfgang Denk,
On 01/29/2013 03:46 PM, Wolfgang Denk wrote:
Dear Nikita Kiryanov,
In message <1359463349-11649-4-git-send-email-nik...@compulab.co.il> you wrote:
When the bmp file is loaded to an address specified by the environment
variable "splashimage", its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by
mostly 32 bit fields, so when the address in splashimage is not equal to aligned
address plus/minus 2, the 32 bit members will be placed in unaligned addresses.
This results in a data abort on targets that cannot handle unaligned memory
accesses.
I don;t understand your +/- 2 argument. When there are 32 bit fielkds
in the header, these have to be 32 bit aligned, right?
Right. The problem stems from the structure of the bmp header, which
places the 32 bit fields at an offset of 2 from the load address.
From bmp_layout.h:
typedef struct bmp_header {
/* Header */
char signature[2]; <--- This is what's causing the offset
__u32 file_size;
__u32 reserved;
__u32 data_offset;
...
}
This means that in order for these 32 bit fields to be properly aligned
when you load the bmp into memory, it has to be placed with a +/- offset
relative to an aligned address to cancel the shift that
char signature[2] causes.
Check that the address is safe to use, and fix it if it's not.
If you perform any such fixes (thus essentially not doing what the
user asked for), you should at least print a warning message so the
user gets aware of such issues.
Also, you should add the video custodian on Cc: for such patches.
[Done here].
Thanks, I'll do that in the future.
Best regards,
Wolfgang Denk
--
Regards,
Nikita.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/7] omap3: allow dynamic selection of gfx_format
Hi Wolfgang Denk, On 01/29/2013 03:52 PM, Wolfgang Denk wrote: Dear Nikita Kiryanov, In message <1359463349-11649-3-git-send-email-nik...@compulab.co.il> you wrote: Currently the value of gfx_format is hardcoded into omap3_dss_panel_config(). Make it a field in struct panel_config, and update existing structs to set this field to the value that was originally hard coded. It is not exactly clear to me what exactly this is needed for? Are you just adding dead code? if not, then please explain this in the commit message. Currently if you want to use a gfx format other than what omap3_dss_panel_config() sets, you have to change it manually. It was suggested in the review of V1 that it would be better if this value could simply be passed to omap3_dss_panel_config() so that there wouldn't be a need for adjustments. I'll try to rephrase the commit message to explain the benefits of this. Best regards, Wolfgang Denk -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 1/7] omap3: add useful dss defines
Hi Wolfgang Denk, On 01/29/2013 03:55 PM, Wolfgang Denk wrote: Dear Nikita Kiryanov, In message <1359463349-11649-2-git-send-email-nik...@compulab.co.il> you wrote: Add useful omap3 dss defines for: polarity, TFT data lines, lcd display type, gfx burst size, and gfx format Just "useful" (as in generally useful, but mostly dead code here), or actually used somewhere? They are used in other patches in this series. The only exception is the #defines for gfx burst size, which were used in V1, but not in this version. I kept the gfx burst size defines in the hope they will be useful to someone, but I can remove them if you think this shouldn't be done. Best regards, Wolfgang Denk -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 5/7] cm-t35: add support for dvi displays
Dear Nikita Kiryanov,
In message <1359463349-11649-6-git-send-email-nik...@compulab.co.il> you wrote:
> Add support for dvi displays with user selectable dvi presets.
...
> --- a/board/cm_t35/cm_t35.c
> +++ b/board/cm_t35/cm_t35.c
> @@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
> /* SB-T35 Ethernet */
> MUX_VAL(CP(GPMC_NCS4), (IEN | PTU | EN | M0)); /*GPMC_nCS4*/
>
> + /* DVI enable */
> + MUX_VAL(CP(GPMC_NCS3), (IDIS | PTU | DIS | M4));/*GPMC_nCS3*/
Is it intentional and correct to always enable DVI, even when this is
not configured by the user?
> +/*
> + * The frame buffer is allocated before we have the chance to parse user
> input.
This seems broken to me.
Please explain why you think so?
> + * vl_{col | row} to the maximal resolution supported by OMAP3.
> + */
> +vidinfo_t panel_info = {
> + .vl_col = 1400,
> + .vl_row = 1050,
> + .vl_bpix = LCD_BPP,
> + .cmap = (ushort *)0x8010,
Can we please avoid such hard coded magic numbers?
> +/*
> + * env_parse_displaytype() - parse display type.
> + *
> + * Parses the environment variable "displaytype", which contains the
> + * name of the display type or preset, in which case it applies its
> + * configurations.
So we have yet another custom implementation for setting the display
type? Can we please agree on using common standard methods? 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
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
stardate 3468.1.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Current state and existing users of FIT (Flattened Image Tree)?
Just trying to correlate old patches on U-boot mailing list to draw a picture of the current state of FIT (Flattened Image Tree format).. still have the following questions: Can anyone familiar with this topic comment on the following? (1) Other than Chromium OS, who are the most notable examples/users of FIT? (2) There is no kernel build support for FIT (all patches that were sent for building FIT from kernel sources were NAK'ed). How does chromium-OS or other platforms build FIT images today? (3) Are there any open examples on the web or in the sources for any existing open source projects that show a working example of FIT? The only example I could find were few .its files in the U-boot doc/uImage.FIT directory. Thanks! Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 1/7] omap3: add useful dss defines
Dear Nikita Kiryanov, In message <1359463349-11649-2-git-send-email-nik...@compulab.co.il> you wrote: > Add useful omap3 dss defines for: polarity, TFT data lines, lcd > display type, gfx burst size, and gfx format Just "useful" (as in generally useful, but mostly dead code here), or actually used somewhere? 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 Often it is fatal to live too long. - Racine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/7] omap3: allow dynamic selection of gfx_format
Dear Nikita Kiryanov, In message <1359463349-11649-3-git-send-email-nik...@compulab.co.il> you wrote: > Currently the value of gfx_format is hardcoded into > omap3_dss_panel_config(). Make it a field in struct panel_config, and > update existing structs to set this field to the value that was originally > hard > coded. It is not exactly clear to me what exactly this is needed for? Are you just adding dead code? if not, then please explain this in the commit message. 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 word "fit", as I understand it, means "appropriate to a purpose", and I would say the body of the Dean is supremely appropriate to the purpose of sitting around all day and eating big heavy meals. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 7/7] cm-t35: add support for loading splash image from NAND
Dear Nikita Kiryanov, In message <1359463349-11649-8-git-send-email-nik...@compulab.co.il> you wrote: > Add support for loading splash image from NAND > > Signed-off-by: Nikita Kiryanov > Signed-off-by: Igor Grinberg > --- > Changes in V2: > - Added fix to bmp_load_addr to comply with what happens in lcd.c > following patch number 3. > > board/cm_t35/cm_t35.c| 65 > ++ > include/configs/cm_t35.h |4 +++ > 2 files changed, 69 insertions(+) Why exactly do you need to add code here? Is it not sufficient to add, for example, a "nand read" command as part of your "preboot" settings? 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 In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, "Wolf in the Fold", stardate 3615.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 6/7] cm-t35: add support for user defined lcd parameters
Dear Nikita Kiryanov, In message <1359463349-11649-7-git-send-email-nik...@compulab.co.il> you wrote: > Add support for user defined lcd parameters for cm-t35 splash screen. Why do you implement another custom method to configure the display? This has been done before, and we should reuse existing methods. 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 Name one thing windows is better than unix in? Making money for Microsoft? -- Randal L. Schwartz in <8cvi5t4c3t@gadget.cscaper.com> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/7] lcd: prevent unaligned memory access when displaying splash screen
Dear Nikita Kiryanov, In message <1359463349-11649-4-git-send-email-nik...@compulab.co.il> you wrote: > When the bmp file is loaded to an address specified by the environment > variable "splashimage", its header members might be unaligned. > This happens because the bmp header starts with two byte-size fields followd > by > mostly 32 bit fields, so when the address in splashimage is not equal to > aligned > address plus/minus 2, the 32 bit members will be placed in unaligned > addresses. > This results in a data abort on targets that cannot handle unaligned memory > accesses. I don;t understand your +/- 2 argument. When there are 32 bit fielkds in the header, these have to be 32 bit aligned, right? > Check that the address is safe to use, and fix it if it's not. If you perform any such fixes (thus essentially not doing what the user asked for), you should at least print a warning message so the user gets aware of such issues. Also, you should add the video custodian on Cc: for such patches. [Done here]. 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 are some good people in it, but the orchestra as a whole is equivalent to a gang bent on destruction." - John Cage, composer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 4/7] lcd: add option for board specific splash screen preparation
Dear Nikita Kiryanov, In message <1359463349-11649-5-git-send-email-nik...@compulab.co.il> you wrote: > Currently there is no logical place to put the code that prepares the > splash image data. The splash image data should be ready in memory > before bmp_display() is called, and after the environment is ready > (since lcd.c looks for the splash image in an address specified by > the environment variable "splashimage"). > > Our window of opportunity in board_init_r() is therefore: between > env_relocate() and bmp_display(), and from the available options > only the lcd related functions in drv_lcd_init() seem appropriate > for such lcd oriented code. > > Add the option to prepare the splash image data in lcd_logo() right > before it is sent to be displayed. > > Signed-off-by: Nikita Kiryanov > Signed-off-by: Igor Grinberg You should add the video custodian on Cc: for such patches. [Done here]. 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 "He only drinks when he gets depressed." "Why does he get depressed?" "Sometimes it's because he hasn't had a drink." - Terry Pratchett, _Men at Arms_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/7] cm-t35: add support for user defined lcd parameters
Add support for user defined lcd parameters for cm-t35 splash screen.
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V2:
- Set gfx_format to GFXFORMAT_RGB16 after parsing custom lcd settings.
board/cm_t35/display.c | 214 +++-
1 file changed, 211 insertions(+), 3 deletions(-)
diff --git a/board/cm_t35/display.c b/board/cm_t35/display.c
index da7784a..6d46762 100644
--- a/board/cm_t35/display.c
+++ b/board/cm_t35/display.c
@@ -3,6 +3,8 @@
*
* Authors: Nikita Kiryanov
*
+ * Parsing code based on linux/drivers/video/pxafb.c
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -33,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
enum display_type {
NONE,
DVI,
+ DVI_CUSTOM,
};
/*
@@ -150,6 +153,206 @@ static enum display_type set_dvi_preset(const struct
panel_config preset,
}
/*
+ * parse_mode() - parse the mode parameter of custom lcd settings
+ *
+ * @mode: x
+ *
+ * Returns -1 on error, 0 on success.
+ */
+static int parse_mode(const char *mode)
+{
+ unsigned int modelen = strlen(mode);
+ int res_specified = 0;
+ unsigned int xres = 0, yres = 0;
+ int yres_specified = 0;
+ int i;
+
+ for (i = modelen - 1; i >= 0; i--) {
+ switch (mode[i]) {
+ case 'x':
+ if (!yres_specified) {
+ yres = simple_strtoul(&mode[i + 1], NULL, 0);
+ yres_specified = 1;
+ } else {
+ goto done_parsing;
+ }
+
+ break;
+ case '0' ... '9':
+ break;
+ default:
+ goto done_parsing;
+ }
+ }
+
+ if (i < 0 && yres_specified) {
+ xres = simple_strtoul(mode, NULL, 0);
+ res_specified = 1;
+ }
+
+done_parsing:
+ if (res_specified) {
+ set_resolution_params(xres, yres);
+ } else {
+ printf("LCD: invalid mode: %s\n", mode);
+ return -1;
+ }
+
+ return 0;
+}
+
+#define PIXEL_CLK_NUMERATOR (26 * 432 / 39)
+/*
+ * parse_pixclock() - Parse the pixclock parameter of custom lcd settings
+ *
+ * @pixclock: the desired pixel clock
+ *
+ * Returns -1 on error, 0 on success.
+ *
+ * Handling the pixel_clock:
+ *
+ * Pixel clock is defined in the OMAP35x TRM as follows:
+ * pixel_clock =
+ * (SYS_CLK * 2 * PRCM.CM_CLKSEL2_PLL[18:8]) /
+ * (DSS.DISPC_DIVISOR[23:16] * DSS.DISPC_DIVISOR[6:0] *
+ * PRCM.CM_CLKSEL_DSS[4:0] * (PRCM.CM_CLKSEL2_PLL[6:0] + 1))
+ *
+ * In practice, this means that in order to set the
+ * divisor for the desired pixel clock one needs to
+ * solve the following equation:
+ *
+ * 26 * 432 / (39 * ) = DSS.DISPC_DIVISOR[6:0]
+ *
+ * NOTE: the explicit equation above is reduced. Do not
+ * try to infer anything from these numbers.
+ */
+static int parse_pixclock(char *pixclock)
+{
+ int divisor, pixclock_val;
+ char *pixclk_start = pixclock;
+
+ pixclock_val = simple_strtoul(pixclock, &pixclock, 10);
+ divisor = DIV_ROUND_UP(PIXEL_CLK_NUMERATOR, pixclock_val);
+ /* 0 and 1 are illegal values for PCD */
+ if (divisor <= 1)
+ divisor = 2;
+
+ panel_cfg.divisor = divisor | (1 << 16);
+ if (pixclock[0] != '\0') {
+ printf("LCD: invalid value for pixclock:%s\n", pixclk_start);
+ return -1;
+ }
+
+ return 0;
+}
+
+/*
+ * parse_setting() - parse a single setting of custom lcd parameters
+ *
+ * @setting: The custom lcd setting :
+ *
+ * Returns -1 on failure, 0 on success.
+ */
+static int parse_setting(char *setting)
+{
+ int num_val;
+ char *setting_start = setting;
+
+ if (!strncmp(setting, "mode:", 5)) {
+ return parse_mode(setting + 5);
+ } else if (!strncmp(setting, "pixclock:", 9)) {
+ return parse_pixclock(setting + 9);
+ } else if (!strncmp(setting, "left:", 5)) {
+ num_val = simple_strtoul(setting + 5, &setting, 0);
+ panel_cfg.timing_h |= DSS_HBP(num_val);
+ } else if (!strncmp(setting, "right:", 6)) {
+ num_val = simple_strtoul(setting + 6, &setting, 0);
+ panel_cfg.timing_h |= DSS_HFP(num_val);
+ } else if (!strncmp(setting, "upper:", 6)) {
+ num_val = simple_strtoul(setting + 6, &setting, 0);
+ panel_cfg.timing_v |= DSS_VBP(num_val);
+ } else if (!strncmp(setting, "lower:", 6)) {
+ num_val = simple_strtoul(setting + 6, &setting, 0);
+ panel_cfg.timing_v |= DSS_VFP(num_val);
+ } else if (!strncmp(setting, "hsynclen:", 9)) {
+ num_val = simple_strtoul(setting + 9, &setting, 0);
+ panel_cfg.timing_h |= DSS_HSW(num_val);
+ } els
[U-Boot] [PATCH V2 5/7] cm-t35: add support for dvi displays
Add support for dvi displays with user selectable dvi presets.
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V2:
- Used LCD_BPP for vl_bpix [Jeroen Hofstee]
- GFXFORMAT_RGB16 now passed to omap3_dss_panel_config() as part of
panel_cfg predefines. [Jeroen Hofstee]
- Added a comment to explain the choice of GFXFORMAT_RGB16.
[Jeroen Hofstee]
- Do not set gfx burst size to GFXBURSTSIZE16, as it is apparently not
necessary.
board/cm_t35/Makefile|1 +
board/cm_t35/cm_t35.c|3 +
board/cm_t35/display.c | 218 ++
include/configs/cm_t35.h |7 ++
4 files changed, 229 insertions(+)
create mode 100644 board/cm_t35/display.c
diff --git a/board/cm_t35/Makefile b/board/cm_t35/Makefile
index 894fa09..bde56e6 100644
--- a/board/cm_t35/Makefile
+++ b/board/cm_t35/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+COBJS-$(CONFIG_LCD) += display.o
COBJS := cm_t35.o leds.o $(COBJS-y)
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index edbb941..8f3d735 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
/* SB-T35 Ethernet */
MUX_VAL(CP(GPMC_NCS4), (IEN | PTU | EN | M0)); /*GPMC_nCS4*/
+ /* DVI enable */
+ MUX_VAL(CP(GPMC_NCS3), (IDIS | PTU | DIS | M4));/*GPMC_nCS3*/
+
/* CM-T3x Ethernet */
MUX_VAL(CP(GPMC_NCS5), (IDIS | PTU | DIS | M0)); /*GPMC_nCS5*/
MUX_VAL(CP(GPMC_CLK), (IEN | PTD | DIS | M4)); /*GPIO_59*/
diff --git a/board/cm_t35/display.c b/board/cm_t35/display.c
new file mode 100644
index 000..da7784a
--- /dev/null
+++ b/board/cm_t35/display.c
@@ -0,0 +1,218 @@
+/*
+ * (C) Copyright 2012 CompuLab, Ltd.
+ *
+ * Authors: Nikita Kiryanov
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+enum display_type {
+ NONE,
+ DVI,
+};
+
+/*
+ * The frame buffer is allocated before we have the chance to parse user input.
+ * To make sure enough memory is allocated for all resolutions, we define
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+ .vl_col = 1400,
+ .vl_row = 1050,
+ .vl_bpix = LCD_BPP,
+ .cmap = (ushort *)0x8010,
+};
+
+static struct panel_config panel_cfg;
+static enum display_type lcd_def;
+
+/*
+ * A note on DVI presets;
+ * U-Boot can convert 8 bit BMP data to 16 bit BMP data, and OMAP DSS can
+ * convert 16 bit data into 24 bit data. Thus, GFXFORMAT_RGB16 allows us to
+ * support two BMP types with one setting.
+ */
+static const struct panel_config preset_dvi_640X480 = {
+ .lcd_size = PANEL_LCD_SIZE(640, 480),
+ .timing_h = DSS_HBP(48) | DSS_HFP(16) | DSS_HSW(96),
+ .timing_v = DSS_VBP(33) | DSS_VFP(10) | DSS_VSW(2),
+ .divisor= 12 | (1 << 16),
+ .data_lines = LCD_INTERFACE_24_BIT,
+ .panel_type = ACTIVE_DISPLAY,
+ .load_mode = 2,
+ .gfx_format = GFXFORMAT_RGB16,
+};
+
+static const struct panel_config preset_dvi_800X600 = {
+ .lcd_size = PANEL_LCD_SIZE(800, 600),
+ .timing_h = DSS_HBP(88) | DSS_HFP(40) | DSS_HSW(128),
+ .timing_v = DSS_VBP(23) | DSS_VFP(1) | DSS_VSW(4),
+ .divisor= 8 | (1 << 16),
+ .data_lines = LCD_INTERFACE_24_BIT,
+ .panel_type = ACTIVE_DISPLAY,
+ .load_mode = 2,
+ .gfx_format = GFXFORMAT_RGB16,
+};
+
+static const struct panel_config preset_dvi_1024X768 = {
+ .lcd_size = PANEL_LCD_SIZE(1024, 768),
+ .timing_h = DSS_HBP(160) | DSS_HFP(24) | DSS_HSW(136),
+ .timing_v = DSS_VBP(29) | DSS_VFP(3) | DSS_VSW(6),
+ .divisor= 5 | (1 << 16),
+ .data_lines = LCD_INTERFACE_24_BIT,
+ .panel_type = ACTIVE_DISPLAY,
+ .load_mode = 2,
+ .gfx_format = GFXFORMAT_RGB16,
+};
+
+static const struct panel_config preset_dvi_1152X
[U-Boot] [PATCH V2 7/7] cm-t35: add support for loading splash image from NAND
Add support for loading splash image from NAND
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V2:
- Added fix to bmp_load_addr to comply with what happens in lcd.c
following patch number 3.
board/cm_t35/cm_t35.c| 65 ++
include/configs/cm_t35.h |4 +++
2 files changed, 69 insertions(+)
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index 8f3d735..9ad5cbe 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -33,7 +33,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -75,6 +77,69 @@ static u32 gpmc_nand_config[GPMC_MAX_REG] = {
0,
};
+#ifdef CONFIG_LCD
+#ifdef CONFIG_CMD_NAND
+static int splash_load_from_nand(u32 bmp_load_addr)
+{
+ struct bmp_header *bmp_hdr;
+ int res, splash_screen_nand_offset = 0x10;
+ size_t bmp_size, bmp_header_size = sizeof(struct bmp_header);
+
+ if (bmp_load_addr + bmp_header_size >= gd->start_addr_sp)
+ goto splash_address_too_high;
+
+ res = nand_read_skip_bad(&nand_info[nand_curr_device],
+ splash_screen_nand_offset, &bmp_header_size,
+ (u_char *)bmp_load_addr);
+ if (res < 0)
+ return res;
+
+ bmp_hdr = (struct bmp_header *)bmp_load_addr;
+ bmp_size = le32_to_cpu(bmp_hdr->file_size);
+
+ if (bmp_load_addr + bmp_size >= gd->start_addr_sp)
+ goto splash_address_too_high;
+
+ return nand_read_skip_bad(&nand_info[nand_curr_device],
+ splash_screen_nand_offset, &bmp_size,
+ (u_char *)bmp_load_addr);
+
+splash_address_too_high:
+ printf("Error: splashimage address too high. Data overwrites U-Boot "
+ "and/or placed beyond DRAM boundaries.\n");
+
+ return -1;
+}
+#else
+static inline int splash_load_from_nand(void)
+{
+ return -1;
+}
+#endif /* CONFIG_CMD_NAND */
+
+int board_splash_screen_prepare(void)
+{
+ char *env_splashimage_value;
+ u32 bmp_load_addr;
+
+ env_splashimage_value = getenv("splashimage");
+ if (env_splashimage_value == NULL)
+ return -1;
+
+ bmp_load_addr = simple_strtoul(env_splashimage_value, 0, 16);
+ if (bmp_load_addr == 0) {
+ printf("Error: bad splashimage address specified\n");
+ return -1;
+ }
+
+ /* Fix bmp_load_addr to the alignment that lcd.c expects */
+ if (bmp_load_addr % 4 != 2)
+ bmp_load_addr += (bmp_load_addr % 4) ?: 2;
+
+ return splash_load_from_nand(bmp_load_addr);
+}
+#endif /* CONFIG_LCD */
+
/*
* Routine: board_init
* Description: hardware init.
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 46d35ba..53c4e3c 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -344,5 +344,9 @@
#define LCD_BPPLCD_COLOR16
#define CONFIG_LCD
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+#define CONFIG_SPLASH_SCREEN_PREPARE
#endif /* __CONFIG_H */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/7] lcd: prevent unaligned memory access when displaying splash screen
When the bmp file is loaded to an address specified by the environment
variable "splashimage", its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by
mostly 32 bit fields, so when the address in splashimage is not equal to aligned
address plus/minus 2, the 32 bit members will be placed in unaligned addresses.
This results in a data abort on targets that cannot handle unaligned memory
accesses.
Check that the address is safe to use, and fix it if it's not.
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
NOTE: New patch in the series; no V1.
common/lcd.c |8
1 file changed, 8 insertions(+)
diff --git a/common/lcd.c b/common/lcd.c
index 66d4f94..104125d 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1046,6 +1046,14 @@ static void *lcd_logo(void)
do_splash = 0;
addr = simple_strtoul (s, NULL, 16);
+ /*
+* In order for the fields of bmp header to be properly aligned
+* in memory, splash image addr must be aligned to "aligned
+* address plus 2". Fix addr if necessary.
+*/
+ if (addr % 4 != 2)
+ addr += (addr % 4) ?: 2;
+
#ifdef CONFIG_SPLASH_SCREEN_ALIGN
s = getenv("splashpos");
if (s != NULL) {
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V1 4/7] lcd: add option for board specific splash screen preparation
Currently there is no logical place to put the code that prepares the
splash image data. The splash image data should be ready in memory
before bmp_display() is called, and after the environment is ready
(since lcd.c looks for the splash image in an address specified by
the environment variable "splashimage").
Our window of opportunity in board_init_r() is therefore: between
env_relocate() and bmp_display(), and from the available options
only the lcd related functions in drv_lcd_init() seem appropriate
for such lcd oriented code.
Add the option to prepare the splash image data in lcd_logo() right
before it is sent to be displayed.
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
README|8
common/lcd.c | 15 +++
include/lcd.h |1 +
3 files changed, 24 insertions(+)
diff --git a/README b/README
index a336476..89694d7 100644
--- a/README
+++ b/README
@@ -1550,6 +1550,14 @@ CBFS (Coreboot Filesystem) support
=> vertically centered image
at x = dspWidth - bmpWidth - 9
+ CONFIG_SPLASH_SCREEN_PREPARE
+
+ If this option is set then the board_splash_screen_prepare()
+ function, which must be defined in your code, is called as part
+ of the splash screen display sequence. It gives the board an
+ opportunity to prepare the splash image data before it is
+ processed and sent to the frame buffer by U-Boot.
+
- Gzip compressed BMP image support: CONFIG_VIDEO_BMP_GZIP
If this option is set, additionally to standard BMP
diff --git a/common/lcd.c b/common/lcd.c
index 104125d..bb8a7d2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1034,6 +1034,18 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
#endif
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+static inline int splash_screen_prepare(void)
+{
+ return board_splash_screen_prepare();
+}
+#else
+static inline int splash_screen_prepare(void)
+{
+ return 0;
+}
+#endif
+
static void *lcd_logo(void)
{
#ifdef CONFIG_SPLASH_SCREEN
@@ -1045,6 +1057,9 @@ static void *lcd_logo(void)
int x = 0, y = 0;
do_splash = 0;
+ if (splash_screen_prepare())
+ return (void *)gd->fb_base;
+
addr = simple_strtoul (s, NULL, 16);
/*
* In order for the fields of bmp header to be properly aligned
diff --git a/include/lcd.h b/include/lcd.h
index c24164a..4ac4ddd 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -47,6 +47,7 @@ extern struct vidinfo panel_info;
extern void lcd_ctrl_init (void *lcdbase);
extern void lcd_enable (void);
+extern int board_splash_screen_prepare(void);
/* setcolreg used in 8bpp/16bpp; initcolregs used in monochrome */
extern void lcd_setcolreg (ushort regno,
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/7] omap3: allow dynamic selection of gfx_format
Currently the value of gfx_format is hardcoded into
omap3_dss_panel_config(). Make it a field in struct panel_config, and
update existing structs to set this field to the value that was originally hard
coded.
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
NOTE: New patch in the series; no V1.
arch/arm/include/asm/arch-omap3/dss.h |1 +
board/htkw/mcx/mcx.c |1 +
board/teejet/mt_ventoux/mt_ventoux.c |2 ++
board/ti/beagle/beagle.h |6 --
drivers/video/omap3_dss.c |2 +-
5 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/dss.h
b/arch/arm/include/asm/arch-omap3/dss.h
index 74321ae..ad5a73e 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -213,6 +213,7 @@ struct panel_config {
u32 data_lines;
u32 load_mode;
u32 panel_color;
+ u32 gfx_format;
void *frame_buffer;
};
diff --git a/board/htkw/mcx/mcx.c b/board/htkw/mcx/mcx.c
index 9fe6408..5eda6c4 100644
--- a/board/htkw/mcx/mcx.c
+++ b/board/htkw/mcx/mcx.c
@@ -130,6 +130,7 @@ static struct panel_config lcd_cfg = {
.load_mode = 0x02, /* Frame Mode */
.panel_color= 0,
.lcd_size = PANEL_LCD_SIZE(800, 480),
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
};
int board_video_init(void)
diff --git a/board/teejet/mt_ventoux/mt_ventoux.c
b/board/teejet/mt_ventoux/mt_ventoux.c
index c516c75..78d81d6 100644
--- a/board/teejet/mt_ventoux/mt_ventoux.c
+++ b/board/teejet/mt_ventoux/mt_ventoux.c
@@ -81,6 +81,7 @@ static struct panel_config lcd_cfg[] = {
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
.panel_color= 0,
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
},
{
.timing_h = PANEL_TIMING_H(20, 192, 4),
@@ -91,6 +92,7 @@ static struct panel_config lcd_cfg[] = {
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
.panel_color= 0,
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
}
};
#endif
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index c0a94a9..6d71bbc 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -544,7 +544,8 @@ static const struct panel_config dvid_cfg = {
.panel_type = 0x01, /* TFT */
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
- .panel_color= DVI_BEAGLE_ORANGE_COL /* ORANGE */
+ .panel_color= DVI_BEAGLE_ORANGE_COL, /* ORANGE */
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
};
static const struct panel_config dvid_cfg_xm = {
@@ -556,6 +557,7 @@ static const struct panel_config dvid_cfg_xm = {
.panel_type = 0x01, /* TFT */
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
- .panel_color= DVI_BEAGLE_ORANGE_COL /* ORANGE */
+ .panel_color= DVI_BEAGLE_ORANGE_COL, /* ORANGE */
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
};
#endif
diff --git a/drivers/video/omap3_dss.c b/drivers/video/omap3_dss.c
index b1424bf..6efba12 100644
--- a/drivers/video/omap3_dss.c
+++ b/drivers/video/omap3_dss.c
@@ -121,7 +121,7 @@ void omap3_dss_panel_config(const struct panel_config
*panel_cfg)
if (!panel_cfg->frame_buffer)
return;
- writel(8 << GFX_FORMAT_SHIFT | GFX_ENABLE, &dispc->gfx_attributes);
+ writel(panel_cfg->gfx_format | GFX_ENABLE, &dispc->gfx_attributes);
writel(1, &dispc->gfx_row_inc);
writel(1, &dispc->gfx_pixel_inc);
writel(panel_cfg->lcd_size, &dispc->gfx_size);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V1 1/7] omap3: add useful dss defines
Add useful omap3 dss defines for: polarity, TFT data lines, lcd
display type, gfx burst size, and gfx format
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
arch/arm/include/asm/arch-omap3/dss.h | 35 +
1 file changed, 35 insertions(+)
diff --git a/arch/arm/include/asm/arch-omap3/dss.h
b/arch/arm/include/asm/arch-omap3/dss.h
index ffaffbb..74321ae 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -167,6 +167,41 @@ struct venc_regs {
#define VENC_OUT_SEL (1 << 6)
#define DIG_LPP_SHIFT 16
+/* LCD display type */
+#define PASSIVE_DISPLAY0
+#define ACTIVE_DISPLAY 1
+
+/* TFTDATALINES */
+#define LCD_INTERFACE_12_BIT 0
+#define LCD_INTERFACE_16_BIT 1
+#define LCD_INTERFACE_18_BIT 2
+#define LCD_INTERFACE_24_BIT 3
+
+/* Polarity */
+#define DSS_IVS(1 << 12)
+#define DSS_IHS(1 << 13)
+#define DSS_IPC(1 << 14)
+#define DSS_IEO(1 << 15)
+
+/* GFX format */
+#define GFXFORMAT_BITMAP1 (0x0 << 1)
+#define GFXFORMAT_BITMAP2 (0x1 << 1)
+#define GFXFORMAT_BITMAP4 (0x2 << 1)
+#define GFXFORMAT_BITMAP8 (0x3 << 1)
+#define GFXFORMAT_RGB12(0x4 << 1)
+#define GFXFORMAT_ARGB16 (0x5 << 1)
+#define GFXFORMAT_RGB16(0x6 << 1)
+#define GFXFORMAT_RGB24_UNPACKED (0x8 << 1)
+#define GFXFORMAT_RGB24_PACKED (0x9 << 1)
+#define GFXFORMAT_ARGB32 (0xC << 1)
+#define GFXFORMAT_RGBA32 (0xD << 1)
+#define GFXFORMAT_RGBx32 (0xE << 1)
+
+/* GFX burst size */
+#define GFXBURSTSIZE4 (0 << 6)
+#define GFXBURSTSIZE8 (1 << 6)
+#define GFXBURSTSIZE16 (2 << 6)
+
/* Panel Configuration */
struct panel_config {
u32 timing_h;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/7] Add splash screen for CM-T35
This patchset adds splash screen support for CM-T35. It includes the ability to initialize the display subsystem either using predefines (selected via env variable "displaytype"), or user supplied configuration options, also stored in an environment variables and pointed to by displaytype. The splash image data is currently read from NAND. As a preparation for the above functionality this patchset adds: - new DSS #defines - an option for board-specific splash screen preparation, which can be invoked in lcd_logo() right before displaying the splash screen (typical use case: load the image data from non-memory mapped storage in time for it to be displayed). - struct panel_config is extended to support setting the gfx_format dynamically - protection from data aborts due to unaligned bmp headers is added to lcd_logo's splashscreen section (I'm also looking into refining this protection later on). Changes in V2: - GFXFORMAT_RGB16 now passed to omap3_dss_panel_config() in a new field of panel_cfg. Updated existing panel_config structs to set this field to the value that was originally hardcoded into omap3_dss_panel_config(). [Jeroen Hofstee] - Used LCD_BPP for vl_bpix. [Jeroen Hofstee] - Added a comment to explain the choice of GFXFORMAT_RGB16. [Jeroen Hofstee] - Added an address check (and fix) to the address of splashimage in order to avoid alignment problems with bmp header. A similar check appears in board_splash_screen_prepare() for cm_t35. [Albert ARIBAUD] - Do not manually set gfx burst size to GFXBURSTSIZE16, as it is apparently not necessary. GFXBURSTSIZE* #defines were kept in patch 1 anyway in the hope they will be useful for someone. Nikita Kiryanov (7): omap3: add useful dss defines omap3: allow dynamic selection of gfx_format lcd: prevent unaligned memory access when displaying splash screen lcd: add option for board specific splash screen preparation cm-t35: add support for dvi displays cm-t35: add support for user defined lcd parameters cm-t35: add support for loading splash image from NAND README|8 + arch/arm/include/asm/arch-omap3/dss.h | 36 +++ board/cm_t35/Makefile |1 + board/cm_t35/cm_t35.c | 68 ++ board/cm_t35/display.c| 426 + board/htkw/mcx/mcx.c |1 + board/teejet/mt_ventoux/mt_ventoux.c |2 + board/ti/beagle/beagle.h |6 +- common/lcd.c | 23 ++ drivers/video/omap3_dss.c |2 +- include/configs/cm_t35.h | 11 + include/lcd.h |1 + 12 files changed, 582 insertions(+), 3 deletions(-) create mode 100644 board/cm_t35/display.c -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to CONFIG_SPL_MXS_PSWITCH_WAIT
Dear Otavio Salvador,
> The power switch option is compatible with i.MX23 and i.MX28 so the
> configration option needs to reflect it. We choose
> 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
>
> Signed-off-by: Otavio Salvador
Acked-by: Marek Vasut
Please read [1] too, I'm completely lost in the flurry of patches. I just can't
figure out anymore what's going on. I don't know what patches to review, in
what
order and what patches are obsolete and what are not.
Moreover, it's generally better to use "Cc:" in the patches. Also, if you want
my threading to work well so I want be lost, Cc me on the whole series.
http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules
> ---
> Changes in v3: None
> Changes in v2:
> - Rewrite short description as per Marek's request
>
> arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +-
> arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
> b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h index 2ddc5bc..084def5 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
> +++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
> @@ -30,7 +30,7 @@ void early_delay(int delay);
>
> void mxs_power_init(void);
>
> -#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
> +#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
> void mxs_power_wait_pswitch(void);
> #else
> static inline void mxs_power_wait_pswitch(void) { }
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index e9d6302..287c698
> 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> @@ -921,7 +921,7 @@ void mxs_power_init(void)
> early_delay(1000);
> }
>
> -#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
> +#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
> void mxs_power_wait_pswitch(void)
> {
> struct mxs_power_regs *power_regs =
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] sf: stmicro: Add support for N25Q32
From: Jagannadha Sutradharudu Teki
Add support for Numonyx N25Q32 SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki
Signed-off-by: Michal Simek
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 32df827..09a3d68 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -93,6 +93,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.name = "M25P128",
},
{
+ .id = 0xba16,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = "N25Q32",
+ },
+ {
.id = 0xba17,
.pages_per_sector = 256,
.nr_sectors = 128,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] sf: stmicro: Add support for N25Q256A
From: Jagannadha Sutradharudu Teki
Add support for Numonyx N25Q256A SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki
Signed-off-by: Michal Simek
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 87ed3d3..df432a1 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -134,6 +134,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 512,
.name = "N25Q256",
},
+ {
+ .id = 0xbb19,
+ .pages_per_sector = 256,
+ .nr_sectors = 512,
+ .name = "N25Q256A",
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] sf: stmicro: Add support for N25Q32A
From: Jagannadha Sutradharudu Teki
Add support for Numonyx N25Q32A SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki
Signed-off-by: Michal Simek
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 09a3d68..87ed3d3 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -99,6 +99,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.name = "N25Q32",
},
{
+ .id = 0xbb16,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = "N25Q32A",
+ },
+ {
.id = 0xba17,
.pages_per_sector = 256,
.nr_sectors = 128,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
On Tue, Jan 29, 2013 at 10:26 AM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Tue, Jan 29, 2013 at 12:33 AM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> This enables the 'Fast Auto Pre-Charge' found in the memory chip.
>> >>
>> >> Signed-off-by: Otavio Salvador
>> >> ---
>> >> Changes in v2:
>> >> - Improve commit message
>> >>
>> >> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
>> >> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87
>> >> 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
>> >> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
>> >> @@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
>> >>
>> >> #elif defined(CONFIG_MX23)
>> >>
>> >> 0x01010001, 0x00010100, 0x01000101, 0x0001,
>> >> 0x0101, 0x, 0x0001, 0x0101,
>> >>
>> >> - 0x, 0x0001, 0x07000200, 0x00070202,
>> >> + 0x0100, 0x0001, 0x07000200, 0x00070202,
>> >>
>> >> 0x0202, 0x04040a01, 0x0201, 0x0204,
>> >> 0x0200, 0x19000f08, 0x0d0d, 0x02021313,
>> >> 0x02061521, 0x000a, 0x00080008, 0x00200020,
>> >
>> > I went through the u-boot mem init and detected you apparently added the
>> > following undocumented portion of code (the writel((1 << 24 ...) already:
>> >
>> > 112 static void initialize_dram_values(void)
>> > 113 {
>> > 114 int i;
>> > 115
>> > 116 mxs_adjust_memory_params(dram_vals);
>> > 117
>> > 118 for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
>> > 119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
>> > 120
>> > 121 #ifdef CONFIG_MX23
>> > 122 writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
>> > 123 #endif
>> > 124 }
>> >
>> > It does enable the TRANS_LOCKOUT. So what the heck is going on here? Are
>> > you coding this stuff at random now ? WHAT THE FUCK IS HAPPENING HERE ?!
>>
>> What your tone, please.
>
> My tone reflects my frustration here.
This does not give you the right to be hard at someone, specially when
someone does not make a mistake by propose.
>> Indeed, it does it. It has been done lng time ago when we started
>> looking at MX23 and it was not obvious for me it.
>>
>> I will send a patch reverting it and adding a comment explaning it
>> there so it is documented.
>
> No! Again, you are charging forward without thinking first!
>
> Why was this code written like that in the first place? Why was this bit set
> later instead of during the register programming in the first place?
Check the patchset I sent before to shoot, please.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
Dear Otavio Salvador,
> On Tue, Jan 29, 2013 at 12:33 AM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> This enables the 'Fast Auto Pre-Charge' found in the memory chip.
> >>
> >> Signed-off-by: Otavio Salvador
> >> ---
> >> Changes in v2:
> >> - Improve commit message
> >>
> >> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> >> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87
> >> 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> >> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> >> @@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
> >>
> >> #elif defined(CONFIG_MX23)
> >>
> >> 0x01010001, 0x00010100, 0x01000101, 0x0001,
> >> 0x0101, 0x, 0x0001, 0x0101,
> >>
> >> - 0x, 0x0001, 0x07000200, 0x00070202,
> >> + 0x0100, 0x0001, 0x07000200, 0x00070202,
> >>
> >> 0x0202, 0x04040a01, 0x0201, 0x0204,
> >> 0x0200, 0x19000f08, 0x0d0d, 0x02021313,
> >> 0x02061521, 0x000a, 0x00080008, 0x00200020,
> >
> > I went through the u-boot mem init and detected you apparently added the
> > following undocumented portion of code (the writel((1 << 24 ...) already:
> >
> > 112 static void initialize_dram_values(void)
> > 113 {
> > 114 int i;
> > 115
> > 116 mxs_adjust_memory_params(dram_vals);
> > 117
> > 118 for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
> > 119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> > 120
> > 121 #ifdef CONFIG_MX23
> > 122 writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
> > 123 #endif
> > 124 }
> >
> > It does enable the TRANS_LOCKOUT. So what the heck is going on here? Are
> > you coding this stuff at random now ? WHAT THE FUCK IS HAPPENING HERE ?!
>
> What your tone, please.
My tone reflects my frustration here.
> Indeed, it does it. It has been done lng time ago when we started
> looking at MX23 and it was not obvious for me it.
>
> I will send a patch reverting it and adding a comment explaning it
> there so it is documented.
No! Again, you are charging forward without thinking first!
Why was this code written like that in the first place? Why was this bit set
later instead of during the register programming in the first place?
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 v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
Dear Otavio Salvador,
> On Tue, Jan 29, 2013 at 1:14 AM, Marek Vasut wrote:
> > Dear Marek Vasut,
> >
> >> Dear Otavio Salvador,
> >>
> >> > This enables the 'Fast Auto Pre-Charge' found in the memory chip.
> >> >
> >> > Signed-off-by: Otavio Salvador
> >> > ---
> >> > Changes in v2:
> >> > - Improve commit message
> >> >
> >> > arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> >> > b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87
> >> > 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> >> > +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> >> > @@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
> >> >
> >> > #elif defined(CONFIG_MX23)
> >> >
> >> > 0x01010001, 0x00010100, 0x01000101, 0x0001,
> >> > 0x0101, 0x, 0x0001, 0x0101,
> >> >
> >> > - 0x, 0x0001, 0x07000200, 0x00070202,
> >> > + 0x0100, 0x0001, 0x07000200, 0x00070202,
> >> >
> >> > 0x0202, 0x04040a01, 0x0201, 0x0204,
> >> > 0x0200, 0x19000f08, 0x0d0d, 0x02021313,
> >> > 0x02061521, 0x000a, 0x00080008, 0x00200020,
> >>
> >> I went through the u-boot mem init and detected you apparently added the
> >> following undocumented portion of code (the writel((1 << 24 ...)
> >> already:
> >>
> >> 112 static void initialize_dram_values(void)
> >> 113 {
> >> 114 int i;
> >> 115
> >> 116 mxs_adjust_memory_params(dram_vals);
> >> 117
> >> 118 for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
> >> 119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> >> 120
> >> 121 #ifdef CONFIG_MX23
> >> 122 writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
> >> 123 #endif
> >> 124 }
> >
> > [...]
> >
> > Sorry about me blowing. Anyway, I better put down the message I would
> > like to relay. Otavio, please follow these steps:
> >
> > * Work in proper sequence -- patches must apply one after another. The
> > same way you cannot build house from the roof to the ground, you can not
> > apply patches in anachronistic order against their dependencies.
> > * Prove why your patch fixes issues -- apply proper reasoning. Do a
> > proper research, there's no time-limit for sending a patch. There is no
> > deadline, take your time.
> > * Step back and slow down -- please do not roll one patch after another,
> > wait for more reviews. This does put a great deal of strain on everyone
> > in the ML, so please be considerate ; you are flooding the mailing list
> > for no reason ; you are also pushing too much work on the reviewers.
> > Thus, wait for some reviews, then fix the issues and repost.
> > * Focus on the changes you make -- look at the stuff above, you need to
> > properly study the code instead of rolling out random patches. Properly
> > focus on a single task, finish it, then move on to the other task.
> >
> > Hacking is not a race, it's an art .
>
> I've been trying to be cooperative and to improve on the way. I (as
> other humans) do mistakes but I try to fix them as soon as possible.
>
> I've been trying to get MX23 in basic working state (for users) and do
> wish to have it for next release and that's why I am trying to make
> things fast; I am sorry by the patch but it is normal to make mistakes
> on the way.
>
> I am glad you noticed it but not so glad by the way you communicated it.
Slow down already. We can apply minor things after the MW. If you go at this
pace, it helps noone really. So just take it easy, carefully review the patches
etc.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
2013/1/29 Gabor Juhos :
> The patch adds an unified linker script file which
> can be used for all currently supported MIPS targets.
>
> Signed-off-by: Gabor Juhos
> Cc: Daniel Schwierzeck
> Cc: Vlad Lungu
> Cc: Thomas Sailer
> Cc: Stefan Roese
> Cc: Wolfgang Denk
> Cc: Thomas Lange
> Cc: Xiangfu Liu
AFAIK you can remove Vlad Lungu and Thomas Lange from the list of
board maintainers
> ---
> arch/mips/cpu/u-boot.lds | 90
> ++
> 1 file changed, 90 insertions(+)
> create mode 100644 arch/mips/cpu/u-boot.lds
>
> diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
> new file mode 100644
> index 000..988764d
> --- /dev/null
> +++ b/arch/mips/cpu/u-boot.lds
> @@ -0,0 +1,90 @@
> +/*
> + * (C) Copyright 2003
> + * Wolfgang Denk Engineering,
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#if defined(CONFIG_64BIT)
> +#define ELF_FMTelf64
> +#define PTR_COUNT_SHIFT3
> +#else
> +#define ELF_FMTelf32
> +#define PTR_COUNT_SHIFT2
> +#endif
> +
> +#if defined(CONFIG_SYS_LITTLE_ENDIAN)
> +#define ELF_ENDIAN tradlittlemips
> +#else
> +#define ELF_ENDIAN tradbigmips
> +#endif
> +
> +#define _MIPS_FORMAT2(x) #x
> +#define _MIPS_FORMAT(x,y) _MIPS_FORMAT2(x-y)
> +
> +#define MIPS_FORMAT_MIPS_FORMAT(ELF_FMT,ELF_ENDIAN)
> +
> +OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
we need to get rid of OUTPUT_FORMAT. This was always misused due to
some endianess and toolchain problems which have been resolved in the meantime.
We should use gcc flags like it is done in linux kernel. The config.mk
of mips64 already
has those flags. Mips32 and xburst need to be extended with:
PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
ifdef CONFIG_SYS_BIG_ENDIAN
PLATFORM_LDFLAGS += -m elf32btsmip
else
PLATFORM_LDFLAGS += -m elf32ltsmip
endif
> +OUTPUT_ARCH(mips)
> +ENTRY(_start)
> +SECTIONS
> +{
> + . = 0x;
> +
> + . = ALIGN(4);
> + .text :
> + {
> + *(.text*)
> + }
please fix the style globally to
.text : {
*(.text*)
}
> +
> + . = ALIGN(4);
> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> +
> + . = ALIGN(4);
> + .data : { *(.data*) }
> +
> + . = .;
> + _gp = ALIGN(16) +0x7ff0;
> +
> + .got : {
> + __got_start = .;
> + *(.got)
> + __got_end = .;
> + }
> +
> + . = ALIGN(4);
> + .sdata : { *(.sdata*) }
*(.sdata*) should be merged with .data
> +
> + . = ALIGN(4);
> + .u_boot_list : {
> + #include
> + }
> +
> + uboot_end_data = .;
> +
> + num_got_entries = (__got_end - __got_start) >> PTR_COUNT_SHIFT;
> +
> + . = ALIGN(4);
> + .sbss : { *(.sbss*) }
> + .bss : {
> + *(.bss*)
> + . = ALIGN(4);
> + }
. = ALIGN(4);
.bss : {
*(.bss*)
*(.sbss*)
. = ALIGN(4);
}
> + uboot_end = .;
> +}
> --
> 1.7.10
>
--
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/4] mx23_olinuxino: Enable USB support
This enabled USB support for the mx23_olinuxino board. Signed-off-by: Otavio Salvador --- Changes in v4: None Changes in v3: - Add a obvious commitlog; Changes in v2: None include/configs/mx23_olinuxino.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 968aec8..7e17809 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -58,6 +58,7 @@ #defineCONFIG_CMD_GPIO #defineCONFIG_CMD_LED #defineCONFIG_CMD_MMC +#defineCONFIG_CMD_USB /* * Memory configurations @@ -138,6 +139,15 @@ */ #define CONFIG_APBH_DMA +/* USB */ +#ifdef CONFIG_CMD_USB +#defineCONFIG_USB_EHCI +#defineCONFIG_USB_EHCI_MXS +#defineCONFIG_EHCI_MXS_PORT 0 +#defineCONFIG_EHCI_IS_TDI +#defineCONFIG_USB_STORAGE +#endif + /* * Boot Linux */ -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/4] mx23_olinuxino: Add ethernet support
This adds support to the LAN9512 chip included in the board and extend
the environment to easy netboot use.
Signed-off-by: Otavio Salvador
---
Changes in v4:
- Fix build warning due missing gpio.h
Changes in v3:
- Remove useless newlines
- Add NOPULL in MUX setup
- Fix commitlog to say the right chip number
- Use CONFIG_CMD_USB to disable GPIO setting
Changes in v2:
- Move GPIO initialization to board_early_init_f;
- Extend commitlog;
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +
board/olimex/mx23_olinuxino/spl_boot.c | 4 +++
include/configs/mx23_olinuxino.h | 40 +---
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
index 2501417..9ed7718 100644
--- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
+++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include
#include
@@ -45,6 +46,11 @@ int board_early_init_f(void)
/* SSP0 clock at 96MHz */
mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+#ifdef CONFIG_CMD_USB
+ /* Enable LAN9512 */
+ gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);
+#endif
+
return 0;
}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index 3bbf5ad..a96c293 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP,
MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP,
MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
+
+ /* Ethernet */
+ MX23_PAD_GPMI_ALE__GPIO_0_17 |
+ (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),
};
void board_init_ll(void)
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index 7e17809..42de557 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -53,11 +53,13 @@
#defineCONFIG_DOS_PARTITION
#defineCONFIG_CMD_CACHE
+#defineCONFIG_CMD_DHCP
#defineCONFIG_CMD_EXT2
#defineCONFIG_CMD_FAT
#defineCONFIG_CMD_GPIO
#defineCONFIG_CMD_LED
#defineCONFIG_CMD_MMC
+#defineCONFIG_CMD_NET
#defineCONFIG_CMD_USB
/*
@@ -148,6 +150,12 @@
#defineCONFIG_USB_STORAGE
#endif
+/* Ethernet */
+#ifdef CONFIG_CMD_NET
+#defineCONFIG_USB_HOST_ETHER
+#defineCONFIG_USB_ETHER_SMSC95XX
+#endif
+
/*
* Boot Linux
*/
@@ -173,6 +181,7 @@
/*
* Extra Environments
*/
+
#define CONFIG_EXTRA_ENV_SETTINGS \
"update_sd_firmware_filename=u-boot.sd\0" \
"update_sd_firmware=" /* Update the SD firmware partition */ \
@@ -189,6 +198,7 @@
"fdt_file=imx23-olinuxino.dtb\0" \
"fdt_addr=0x4100\0" \
"boot_fdt=try\0" \
+ "ip_dyn=yes\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
"mmcroot=/dev/mmcblk0p3 rw rootwait\0" \
@@ -214,6 +224,31 @@
"fi; " \
"else " \
"bootm; " \
+ "fi;\0" \
+ "netargs=setenv bootargs console=${console_mainline},${baudrate} " \
+ "root=/dev/nfs " \
+ "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+ "netboot=echo Booting from net ...; " \
+ "usb start; " \
+ "run netargs; " \
+ "if test ${ip_dyn} = yes; then " \
+ "setenv get_cmd dhcp; " \
+ "else " \
+ "setenv get_cmd tftp; " \
+ "fi; " \
+ "${get_cmd} ${uimage}; " \
+ "if test ${boot_fdt} = yes; then " \
+ "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
+ "bootm ${loadaddr} - ${fdt_addr}; " \
+ "else " \
+ "if test ${boot_fdt} = try; then " \
+ "bootm; " \
+ "else " \
+ "echo WARN: Cannot load the DT; " \
+ "fi;" \
+ "fi; " \
+ "else " \
+ "bootm; " \
"fi;\0"
#define CONFIG_BOOTCOMMAND \
@@ -223,10 +258,9 @@
"else " \
"if run loaduimage; then " \
"run mmcboot; " \
- "else " \
- "echo ERR: Fail to boot from MMC; " \
+ "else run netboot; " \
"fi; " \
"fi; " \
- "else exit; fi"
+ "else run netboot; fi"
#endif /* __MX23_OLINUXINO_CONFIG_H__ */
--
1.8.1
___
U-Boot mailing list
U-Boot@list
[U-Boot] [PATCH v4 2/4] mx23evk: Enable USB support
This enabled USB support for the mx23evk board. Signed-off-by: Otavio Salvador --- Changes in v4: None Changes in v3: - Add a obvious commitlog; Changes in v2: None include/configs/mx23evk.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/configs/mx23evk.h b/include/configs/mx23evk.h index d206c95..99dfb8f 100644 --- a/include/configs/mx23evk.h +++ b/include/configs/mx23evk.h @@ -58,6 +58,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_MMC +#define CONFIG_CMD_USB #define CONFIG_CMD_BOOTZ /* Memory configurations */ @@ -122,6 +123,15 @@ #define CONFIG_MXS_MMC #endif +/* USB */ +#ifdef CONFIG_CMD_USB +#defineCONFIG_USB_EHCI +#defineCONFIG_USB_EHCI_MXS +#defineCONFIG_EHCI_MXS_PORT 0 +#defineCONFIG_EHCI_IS_TDI +#defineCONFIG_USB_STORAGE +#endif + /* Boot Linux */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/4] usb: mxs: Disable USB Port 1 for i.MX23
The i.MX23 just one USB port so disable the second controller probe
when building for i.MX23.
Signed-off-by: Otavio Salvador
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/usb/host/ehci-mxs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 5062af5..28c8cde 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -50,10 +50,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port)
usb_base = MXS_USBCTRL0_BASE;
phy_base = MXS_USBPHY0_BASE;
break;
+#ifdef CONFIG_MX28
case 1:
usb_base = MXS_USBCTRL1_BASE;
phy_base = MXS_USBPHY1_BASE;
break;
+#endif
default:
printf("CONFIG_EHCI_MXS_PORT (port = %d)\n", port);
return -1;
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/3] mx23_olinuxino: Add support for status LED
This allow user to know if the bootloader is running, even without a
serial console.
Signed-off-by: Otavio Salvador
---
Changes in v6:
- Use GPIO number
Changes in v5: None
Changes in v4:
- Use MUX PIN macro
Changes in v3:
- Added the MUX settings back (requested by Fabio)
- Added name of the PIN in the board config file
Changes in v2:
- Remove MUX setting - not need
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 +++
board/olimex/mx23_olinuxino/spl_boot.c | 4
include/configs/mx23_olinuxino.h | 12
3 files changed, 23 insertions(+)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
index 6a6053b..2501417 100644
--- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
+++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -67,5 +70,9 @@ int board_init(void)
/* Adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_STATE);
+#endif
+
return 0;
}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index 7def8bc..3bbf5ad 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -84,6 +84,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_EMI_RASN__EMI_RASN | MUX_CONFIG_EMI,
MX23_PAD_EMI_WEN__EMI_WEN | MUX_CONFIG_EMI,
+ /* Green LED */
+ MX23_PAD_SSP1_DETECT__GPIO_2_1 |
+ (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL),
+
/* MMC 0 */
MX23_PAD_SSP1_CMD__SSP1_CMD | MUX_CONFIG_SSP,
MX23_PAD_SSP1_DATA0__SSP1_DATA0 | MUX_CONFIG_SSP,
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index 7983c5d..968aec8 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -56,6 +56,7 @@
#defineCONFIG_CMD_EXT2
#defineCONFIG_CMD_FAT
#defineCONFIG_CMD_GPIO
+#defineCONFIG_CMD_LED
#defineCONFIG_CMD_MMC
/*
@@ -112,6 +113,17 @@
#defineCONFIG_BAUDRATE 115200 /* Default baud rate */
/*
+ * Status LED
+ */
+#defineCONFIG_STATUS_LED
+#defineCONFIG_GPIO_LED
+#defineCONFIG_BOARD_SPECIFIC_LED
+#defineSTATUS_LED_BOOT 0
+#defineSTATUS_LED_BIT 10
+#defineSTATUS_LED_STATESTATUS_LED_ON
+#defineSTATUS_LED_PERIOD (CONFIG_SYS_HZ / 2)
+
+/*
* MMC Driver
*/
#ifdef CONFIG_CMD_MMC
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/3] mxs: Fix iomux.h to not break build during assembly stage
This fixes the build failure when included in mx23_olinuxino.h board config; the addition of "asm/types.h" is due "u32" being otherwise undefined. Signed-off-by: Otavio Salvador --- Changes in v6: None Changes in v5: - Extend commit log Changes in v4: - New patch Changes in v3: None Changes in v2: None arch/arm/include/asm/arch-mxs/iomux.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 7abdf58..4288715 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -21,6 +21,10 @@ #ifndef __MACH_MXS_IOMUX_H__ #define __MACH_MXS_IOMUX_H__ +#ifndef __ASSEMBLY__ + +#include + /* * IOMUX/PAD Bit field definitions * @@ -165,4 +169,5 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad); */ int mxs_iomux_setup_multiple_pads(const iomux_cfg_t *pad_list, unsigned count); +#endif /* __ASSEMBLY__ */ #endif /* __MACH_MXS_IOMUX_H__*/ -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/3] led: Use STATUS_LED_ON and STATUS_LED_OFF when calling __led_set
This fixes the gpio_led driver which needs to compare againt a STATUS_LED_ON to enable a led. Signed-off-by: Otavio Salvador --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None common/cmd_led.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/common/cmd_led.c b/common/cmd_led.c index 7f5ab43..84f79fa 100644 --- a/common/cmd_led.c +++ b/common/cmd_led.c @@ -110,13 +110,15 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (led_commands[i].on) led_commands[i].on(); else - __led_set(led_commands[i].mask, 1); + __led_set(led_commands[i].mask, + STATUS_LED_ON); break; case LED_OFF: if (led_commands[i].off) led_commands[i].off(); else - __led_set(led_commands[i].mask, 0); + __led_set(led_commands[i].mask, + STATUS_LED_OFF); break; case LED_TOGGLE: if (led_commands[i].toggle) -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] mx23evk: Adjust DRAM control register to use full 128MB of RAM
Signed-off-by: Otavio Salvador
---
Changes in v3: None
Changes in v2: None
board/freescale/mx23evk/spl_boot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index 6007433..b6f4e7e 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = {
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
};
+#define HW_DRAM_CTL14 (0x38 >> 2)
+#define CS_MAP 0x3
+#define INTAREF0x2
+#define HW_DRAM_CTL14_CONFIG (INTAREF << 8 | CS_MAP)
+
+void mxs_adjust_memory_params(uint32_t *dram_vals)
+{
+ dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;
+}
+
void board_init_ll(void)
{
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] mx23: Document the tRAS lockout setting in memory initialization
Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to enable the 'Fast Auto Pre-Charge' found in the memory chip. The setting is applied after memory initialization and it is worth document it. Signed-off-by: Otavio Salvador --- Changes in v3: - Revert initialization change and comment the code Changes in v2: - Improve commit message arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -119,6 +119,7 @@ static void initialize_dram_values(void) writel(dram_vals[i], MXS_DRAM_BASE + (4 * i)); #ifdef CONFIG_MX23 + /* Enable tRAS lockout in HW_DRAM_CTL08 */ writel((1 << 24), MXS_DRAM_BASE + (4 * 8)); #endif } -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to CONFIG_SPL_MXS_PSWITCH_WAIT
The power switch option is compatible with i.MX23 and i.MX28 so the
configration option needs to reflect it. We choose
'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Signed-off-by: Otavio Salvador
---
Changes in v3: None
Changes in v2:
- Rewrite short description as per Marek's request
arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +-
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
index 2ddc5bc..084def5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
@@ -30,7 +30,7 @@ void early_delay(int delay);
void mxs_power_init(void);
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void);
#else
static inline void mxs_power_wait_pswitch(void) { }
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index e9d6302..287c698 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -921,7 +921,7 @@ void mxs_power_init(void)
early_delay(1000);
}
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void)
{
struct mxs_power_regs *power_regs =
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] MIPS: vct: remove custom u-boot.lds script
2013.01.29. 10:05 keltezéssel, Stefan Roese írta: > On 01/29/2013 09:31 AM, Gabor Juhos wrote: >> Remove the board specific linker script. It is not >> needed anymore, the unified MIPS linker script can >> be used instead. >> >> All vct targets are producing identical binary >> images after the change than before. >> >> Signed-off-by: Gabor Juhos >> Cc: Daniel Schwierzeck >> Cc: Stefan Roese > > I can't really test this, but it looks good. So: > > Acked-by: Stefan Roese Thanks! -Gabor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: Reset the EMI block on mx23
On Tue, Jan 29, 2013 at 12:46 AM, Marek Vasut wrote: > The real reason for memory instability was the fact that the EMI block > was gated and not reset throughout the boards' operation. This patch > resets the EMI block properly while also reverts the memory voltage bump. > The memory stability issues were caused by the EMI not being reset properly > and thus there is no longer need to run the memory at higher voltage than > it ought to run at. > > This partly reverts 8303ed128a55519f19c5f11087032d4bc4e0537a . > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Otavio Salvador > Cc: Stefano Babic > --- > arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > NOTE: Please apply _SEVERE_ testing! > I did a test with and without the patch. *Without* this patch I see an error in memony but it takes some time to it to error out. With the patch, the error is mostly instantaneous: => mtest Pattern FFDD Writing... Reading... Mem error @ 0x40087F6C: found BFFDE002, expected FFFDE002 So it seems to make it worse; but I am not sure if something else is missing too. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
