Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On 03/11/2013 08:25 PM, Tom Rini wrote: Hello, The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 76b40ab41eff1f402ee52ba768b09daad293b9bb: Merge u-boot/master into u-boot-ti/master (2013-03-11 12:16:13 -0400) [...] Nikita Kiryanov (14): omap: consolidate common mmc definitions omap_hsmmc: fix out of bounds array access omap_hsmmc: introduce omap_hsmmc_data struct omap_hsmmc: implement driver check for card detection cm-t35: implement board specific card detect check mmc: add support for write protection omap_hsmmc: add driver check for write protection omap3: add useful dss defines omap3: allow dynamic selection of gfx_format 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 lcd: implement a callback for splashimage cm_t35: prevent splashimage from being set to a bad value I noticed that the patch "cm-t35: add support for loading splash image from NAND" is missing from the above. As I mentioned here http://lists.denx.de/pipermail/u-boot/2013-February/146361.html V1 is still part of the CM-T35 splash screen and should be included with the rest of the patchset. -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Nikita, On Tue, 12 Mar 2013 09:03:24 +0200, Nikita Kiryanov wrote: > Hi Tom, > > On 03/11/2013 08:25 PM, Tom Rini wrote: > > Hello, > > > > The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: > > > >x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) > > > > are available in the git repository at: > > > >git://git.denx.de/u-boot-ti.git master > > > > for you to fetch changes up to 76b40ab41eff1f402ee52ba768b09daad293b9bb: > > > >Merge u-boot/master into u-boot-ti/master (2013-03-11 12:16:13 -0400) > > > > > > > [...] > > > > Nikita Kiryanov (14): > >omap: consolidate common mmc definitions > >omap_hsmmc: fix out of bounds array access > >omap_hsmmc: introduce omap_hsmmc_data struct > >omap_hsmmc: implement driver check for card detection > >cm-t35: implement board specific card detect check > >mmc: add support for write protection > >omap_hsmmc: add driver check for write protection > >omap3: add useful dss defines > >omap3: allow dynamic selection of gfx_format > >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 > >lcd: implement a callback for splashimage > >cm_t35: prevent splashimage from being set to a bad value > > > > I noticed that the patch "cm-t35: add support for loading splash image > from NAND" is missing from the above. As I mentioned here > http://lists.denx.de/pipermail/u-boot/2013-February/146361.html > V1 is still part of the CM-T35 splash screen and should be included > with the rest of the patchset. Tom: also, the automatic "Conflicts:" lines were left (voluntarily or involuntarily) in the ToT commit's message. I suggest they be removed or, if left as a warning sign that the merge contains resolutions, be replaced with a non-default description. Do you want to re-do this PR or can I take it in as-is? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB patches
Dear Simon Glass, > Hi Marek, > > On Mon, Mar 11, 2013 at 9:16 AM, Simon Glass wrote: > > Hi Marek, > > > > As requested here is an email about the USB patches. I have put them in a > > bundle here: > > > > http://patchwork.ozlabs.org/bundle/sjg/for-marex/ > > But unfortunately I found a problem in patch 4. Here is an updated version > which includes errno.h. > > http://patchwork.ozlabs.org/patch/226713/ > > Regards, > Simon I applied 1,2,3 and 5 ; 4 doesn't apply. I pushed those to u-boot-usb/master 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 0/8 v11] Add TMU support for Exynos5250 based SMDK5250
On 25/02/13 20:12, Akshay Saraswat wrote: > This patch series adds support for TMU driver using device tree for Exynos5250 > based SMDK5250 board. > > Changes since v10: > - Patch-1: Renamed asm/arch/exynos-tmu.h to asm/arch/tmu.h. > - Patch-2: None. > - Patch-3: None. > - Patch-4: None. > - Patch-5: None. > - Patch-6: None. > - Patch-7: None. > - Patch-8: None. > > Akshay Saraswat (8): > Exynos5: TMU: Add driver for Thermal Management Unit > Exynos5: FDT: Add TMU device node values > Exynos5: TMU: Add TMU init and status check > Exynos5: Config: Enable support for Exynos TMU driver > TMU: Add TMU support in dtt command > Exynos5: Config: Enable dtt command for TMU > Exynos5: TMU: Add hardware tripping > Exynos5: FDT: Add a H/W-trip member to TMU node > > arch/arm/cpu/armv7/exynos/power.c | 12 ++ > arch/arm/dts/exynos5250.dtsi | 5 + > arch/arm/include/asm/arch-exynos/power.h | 4 + > arch/arm/include/asm/arch-exynos/tmu.h| 58 ++ > board/samsung/dts/exynos5250-smdk5250.dts | 13 ++ > board/samsung/smdk5250/smdk5250.c | 39 > common/cmd_dtt.c | 32 ++- > doc/device-tree-bindings/exynos/tmu.txt | 44 + > drivers/power/Makefile| 1 + > drivers/power/exynos-tmu.c| 319 > ++ > include/configs/exynos5250-dt.h | 5 + > include/fdtdec.h | 1 + > include/tmu.h | 46 + > lib/fdtdec.c | 1 + > 14 files changed, 579 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/include/asm/arch-exynos/tmu.h > create mode 100644 doc/device-tree-bindings/exynos/tmu.txt > create mode 100644 drivers/power/exynos-tmu.c > create mode 100644 include/tmu.h > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2 V4] EXYNOS5: SNOW: Add initial dts and config file
On 28/02/13 20:40, Rajeshwari Shinde wrote: > This patch set adds initial dts and configuration file for snow. > > Changes in V2: > - Added Maintainer. > Changes in V3: > - Added Maintainer in aphabetical order. > Changes in V4: > - Removed ethernet support > > Rajeshwari Shinde (2): > EXYNOS5: Add initial DTS file for Snow. > EXYNOS5: Snow: Add a configuration file > > MAINTAINERS |4 ++ > board/samsung/dts/exynos5250-snow.dts | 58 > + > boards.cfg|1 + > include/configs/snow.h| 33 ++ > 4 files changed, 96 insertions(+), 0 deletions(-) > create mode 100644 board/samsung/dts/exynos5250-snow.dts > create mode 100644 include/configs/snow.h > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization
Dear Lukasz, On 11/03/13 17:22, Lukasz Majewski wrote: > Dear All, > >> Hi Tom, >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 02/21/2013 06:33 PM, Jaehoon Chung wrote: Hi Tom, On 02/22/2013 02:45 AM, Tom Rini wrote: On 02/21/2013 12:21 PM, Lukasz Majewski wrote: >>> Dear All, >>> >>> I'd like to kindly ask for any feedback on this patch. >>> >>> It is now more than month on the u-boot mailing list... OK, sorry, the generic name of the driver threw me for a minute. I'm fine with this change going up u-boot-samsung -> u-boot-arm -> master since it's a samsung-only driver right now. Does this work for you? > I think that this driver didn't use samsung-only. going up > u-boot-samsung? I'm not sure that. >>> >>> Unless the context got very wrong, it touches drivers/mmc/sdhci.c >>> which is controlled by CONFIG_SDHCI which is only turned on in what >>> look like samsung platforms to me. >>> >> >> There is a /asm/arch-pantheon/config.h file which sets the >> CONFIG_SDHCI flag. It was added by Lei Wen (who is CC'ed to this >> thread) and looks like ARM926EJS (Marwell Semiconductor) processor >> based system. >> >> Other systems are indeed samsung based processors. >> >> I don't mind if this patch would go via u-boot-samsung tree. >> >> Moreover, since this change "touches" Lei system, I think that he >> should have expressed his opinion. Sadly this didn't happened > > Any feedback? If not, please pull this patch to u-boot mainline. > > Today it is 2 months since this patch has been posted on ML. No reply > from interested people. > Since Andy seems absent, applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] bfin: Remove spi dma function in bf5xx.
On Monday 04 March 2013 02:20:08 Sonic Zhang wrote: > From: Scott Jiang > > BF5xx rx dma causes spi flash random read error. > Accually spi controller has problems both on tx and rx dma. > So remove spi dma support in u-boot. this is wrong, and imo, unnecessary. it's wrong because using DMA gains a lot of speed increases, and works for in many cases (i haven't seen cases where it didn't work, but i haven't been actively developing in the last year of course). it's unnecessary because there's already a CONFIG_xxx option to disable it if your platform is having problems and you can't figure things out, and don't need the speed gains. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] arm: at91/configs: add libfdt to configuration
Dear Bo Shen, Bo Shen writes: >From: Nicolas Ferre > >support to boot device tree Linux kernel > >Signed-off-by: Nicolas Ferre >[Add libftd for at91rm9200, at91sam9263, at91sam9rl] >Signed-off-by: Bo Shen > >--- >include/configs/at91rm9200ek.h |2 ++ > include/configs/at91sam9260ek.h |2 ++ > include/configs/at91sam9263ek.h |2 ++ > include/configs/at91sam9rlek.h |2 ++ > 4 files changed, 8 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] arm: at91/configs: add bootz to configuration
Dear Bo Shen, Bo Shen writes: >From: Nicolas Ferre > >Support to boot zImage > >Signed-off-by: Nicolas Ferre >[Add bootz for at91rm9200, at91sam9263, at91sam9rl] >Signed-off-by: Bo Shen > >--- >include/configs/at91rm9200ek.h |1 + > include/configs/at91sam9260ek.h|1 + > include/configs/at91sam9263ek.h|1 + > include/configs/at91sam9m10g45ek.h |1 + > include/configs/at91sam9rlek.h |1 + > include/configs/at91sam9x5ek.h |1 + > 6 files changed, 6 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/3] ARM: at91: change nand flash table
Dear Bo Shen, Bo Shen writes: >Change nand flash partition tablke according to www.at91.com/linux4sam > >more information: >http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Linux4SAM_NandFlash_demo_Memory > >Signed-off-by: Bo Shen >Signed-off-by: Bo Shen > >--- >include/configs/at91sam9260ek.h| 18 +- > include/configs/at91sam9261ek.h| 19 +-- > include/configs/at91sam9263ek.h| 17 + > include/configs/at91sam9m10g45ek.h | 16 > include/configs/at91sam9x5ek.h | 11 ++- > 5 files changed, 41 insertions(+), 40 deletions(-) applied with some minor changes in commit message to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: at91sam9x5: Using CPU string directly
Dear Bo Shen, Bo Shen writes: >As the CPU name is not configurable, using CPU string directly > >Signed-off-by: Bo Shen > >--- >arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c | 14 +++--- > arch/arm/include/asm/arch-at91/at91sam9x5.h |6 -- > 2 files changed, 7 insertions(+), 13 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: sam9x5: fix ethernet pins in MII mode
Dear Bo Shen, Bo Shen writes: >From: Jesse Gilles > >Fix pin setting in MII mode > >Signed-off-by: Jesse Gilles > >--- >arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] please pull u-boot-atmel/master
Dear Albert Aribaud, please pull the following changes into u-boot-arm/master. The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b: Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42 -0500) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 08f0533a147ca37546a6539b43fce3916e82811a: ARM: sam9x5: fix ethernet pins in MII mode (2013-03-12 13:02:20 +0100) Bo Shen (3): ARM: atmel: add at91sam9g20ek_2mmc nand boot support ARM: at91: change nand flash table ARM: at91sam9x5: Using CPU string directly Jesse Gilles (1): ARM: sam9x5: fix ethernet pins in MII mode Nicolas Ferre (2): arm: at91/configs: add libfdt to configuration arm: at91/configs: add bootz to configuration arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c | 30 +++--- arch/arm/include/asm/arch-at91/at91sam9x5.h |6 - board/atmel/at91sam9260ek/at91sam9260ek.c|7 - boards.cfg |1 + include/configs/at91rm9200ek.h |3 +++ include/configs/at91sam9260ek.h | 23 ++--- include/configs/at91sam9261ek.h | 19 +++--- include/configs/at91sam9263ek.h | 20 +-- include/configs/at91sam9m10g45ek.h | 17 ++-- include/configs/at91sam9rlek.h |3 +++ include/configs/at91sam9x5ek.h | 12 + 11 files changed, 79 insertions(+), 62 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c: s3c24xx: add hsi2c controller support
Add support for hsi2c controller available on exynos5420.
Note: driver currently supports only fast speed mode 100kbps
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: R. Chandrasekar
---
drivers/i2c/s3c24x0_i2c.c | 389 ++---
drivers/i2c/s3c24x0_i2c.h | 33
2 files changed, 397 insertions(+), 25 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index 769a2ba..3117ab7 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#else
#include
#endif
@@ -50,6 +51,60 @@
#define I2C_NOK_LA 3 /* Lost arbitration */
#define I2C_NOK_TOUT 4 /* time out */
+/* HSI2C specific register description */
+
+/* I2C_CTL Register bits */
+#define HSI2C_FUNC_MODE_I2C(1u << 0)
+#define HSI2C_MASTER (1u << 3)
+#define HSI2C_RXCHON (1u << 6) /* Write/Send */
+#define HSI2C_TXCHON (1u << 7) /* Read/Receive */
+#define HSI2C_SW_RST (1u << 31)
+
+/* I2C_FIFO_CTL Register bits */
+#define HSI2C_RXFIFO_EN(1u << 0)
+#define HSI2C_TXFIFO_EN(1u << 1)
+#define HSI2C_TXFIFO_TRIGGER_LEVEL (0x20 << 16)
+#define HSI2C_RXFIFO_TRIGGER_LEVEL (0x20 << 4)
+
+/* I2C_TRAILING_CTL Register bits */
+#define HSI2C_TRAILING_COUNT (0xff)
+
+/* I2C_INT_EN Register bits */
+#define HSI2C_INT_TX_ALMOSTEMPTY_EN(1u << 0)
+#define HSI2C_INT_RX_ALMOSTFULL_EN (1u << 1)
+#define HSI2C_INT_TRAILING_EN (1u << 6)
+#define HSI2C_INT_I2C_EN (1u << 9)
+
+/* I2C_CONF Register bits */
+#define HSI2C_AUTO_MODE(1u << 31)
+#define HSI2C_10BIT_ADDR_MODE (1u << 30)
+#define HSI2C_HS_MODE (1u << 29)
+
+/* I2C_AUTO_CONF Register bits */
+#define HSI2C_READ_WRITE (1u << 16)
+#define HSI2C_STOP_AFTER_TRANS (1u << 17)
+#define HSI2C_MASTER_RUN (1u << 31)
+
+/* I2C_TIMEOUT Register bits */
+#define HSI2C_TIMEOUT_EN (1u << 31)
+
+/* I2C_TRANS_STATUS register bits */
+#define HSI2C_MASTER_BUSY (1u << 17)
+#define HSI2C_SLAVE_BUSY (1u << 16)
+#define HSI2C_NO_DEV (1u << 3)
+#define HSI2C_NO_DEV_ACK (1u << 2)
+#define HSI2C_TRANS_ABORT (1u << 1)
+#define HSI2C_TRANS_DONE (1u << 0)
+#define HSI2C_TIMEOUT_AUTO (0u << 0)
+
+#define HSI2C_SLV_ADDR_MAS(x) ((x & 0x3ff) << 10)
+
+/* Controller operating frequency, timing values for operation
+ * are calculated against this frequency
+ */
+#define HSI2C_FS_TX_CLOCK 100
+
+/* S3C I2C Controller bits */
#define I2CSTAT_BSY0x20/* Busy bit */
#define I2CSTAT_NACK 0x01/* Nack bit */
#define I2CCON_ACKGEN 0x80/* Acknowledge generation */
@@ -61,6 +116,7 @@
#define I2C_TIMEOUT 1 /* 1 second */
+#defineHSI2C_TIMEOUT 100
/*
* For SPL boot some boards need i2c before SDRAM is initialised so force
@@ -120,9 +176,23 @@ static int WaitForXfer(struct s3c24x0_i2c *i2c)
return (readl(&i2c->iiccon) & I2CCON_IRPND) ? I2C_OK : I2C_NOK_TOUT;
}
-static int IsACK(struct s3c24x0_i2c *i2c)
+static int hsi2c_wait_for_irq(struct exynos5_hsi2c *i2c)
{
- return !(readl(&i2c->iicstat) & I2CSTAT_NACK);
+ int i = HSI2C_TIMEOUT * 10;
+ int ret = I2C_NOK_TOUT;
+
+ while (i > 0) {
+ /* wait for a while and retry */
+ udelay(50);
+ if (readl(&i2c->usi_int_stat) &
+ (HSI2C_INT_I2C_EN | HSI2C_INT_TX_ALMOSTEMPTY_EN)) {
+ ret = I2C_OK;
+ break;
+ }
+ i--;
+ }
+
+ return ret;
}
static void ReadWriteByte(struct s3c24x0_i2c *i2c)
@@ -130,6 +200,22 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
writel(readl(&i2c->iiccon) & ~I2CCON_IRPND, &i2c->iiccon);
}
+static void hsi2c_clear_irqpd(struct exynos5_hsi2c *i2c)
+{
+ writel(readl(&i2c->usi_int_stat), &i2c->usi_int_stat);
+}
+
+static int hsi2c_isack(struct exynos5_hsi2c *i2c)
+{
+ return readl(&i2c->usi_trans_status) &
+ (HSI2C_NO_DEV | HSI2C_NO_DEV_ACK);
+}
+
+static int IsACK(struct s3c24x0_i2c *i2c)
+{
+ return !(readl(&i2c->iicstat) & I2CSTAT_NACK);
+}
+
static struct s3c24x0_i2c *get_base_i2c(void)
{
#ifdef CONFIG_EXYNOS4
@@ -147,6 +233,18 @@ static struct s3c24x0_i2c *get_base_i2c(void)
#endif
}
+static struct exynos5_hsi2c *get_base_hsi2c(void)
+{
+ struct exynos5_hsi2c *i2c = NULL;
+ int bus = g_current_bus;
+
+ if (proid_is_exynos5420())
+ i2c = (struct exynos5_hsi2c *)(EXYNOS5420_I2C_BASE +
+ ((bus) * EXYNOS5_I2C_SPACING));
+
+ return i2c;
+}
+
static void
[U-Boot] [Question][i.MX6q] Is it possible to configure and use the USB-OTG as EHCI host only?
Hi All, I am Rafal and this is my first post here, so I would like to say hello to everyone :) I have been using the Sabrelite board (i.MX6Q) from Boundary Devices for some time and now I have been working on U-Boot. The code I use is based on the mainline U-Boot. The current implementation supports USB Host1 only, but I would like to use OTG configured as host (I do not need support for device mode). I wanted to implemet the lowest layer for the EHCI driver like it is done for Host1 (in fact the offset of the USB controller's registers set is different and few things like GPIOs) but it does not seem to work. The result is that the U-Boot creates the EHCI hub, but no device is detected on Port 1. I am expecting something like "Port 1 Status 503 Change 1" but I get "Port 1 Status 502 Change 0". I suppose it is possible to use USG-OTG instead of Host1 as EHCI host in U-Boot somehow. Is there something I am missing? By the way, the device is connected via special adapter and the power (5V) is provided to it. Kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Tue, Mar 12, 2013 at 09:03:24AM +0200, Nikita Kiryanov wrote: > Hi Tom, > > On 03/11/2013 08:25 PM, Tom Rini wrote: > >Hello, > > > >The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: > > > > x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) > > > >are available in the git repository at: > > > > git://git.denx.de/u-boot-ti.git master > > > >for you to fetch changes up to 76b40ab41eff1f402ee52ba768b09daad293b9bb: > > > > Merge u-boot/master into u-boot-ti/master (2013-03-11 12:16:13 -0400) > > > > > > > [...] > > > >Nikita Kiryanov (14): > > omap: consolidate common mmc definitions > > omap_hsmmc: fix out of bounds array access > > omap_hsmmc: introduce omap_hsmmc_data struct > > omap_hsmmc: implement driver check for card detection > > cm-t35: implement board specific card detect check > > mmc: add support for write protection > > omap_hsmmc: add driver check for write protection > > omap3: add useful dss defines > > omap3: allow dynamic selection of gfx_format > > 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 > > lcd: implement a callback for splashimage > > cm_t35: prevent splashimage from being set to a bad value > > I noticed that the patch "cm-t35: add support for loading splash image > from NAND" is missing from the above. As I mentioned here > http://lists.denx.de/pipermail/u-boot/2013-February/146361.html > V1 is still part of the CM-T35 splash screen and should be included > with the rest of the patchset. OK, I missed that, sorry. -- 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] Please pull u-boot-ti/master
On Tue, Mar 12, 2013 at 08:14:24AM +0100, Albert ARIBAUD wrote: > Hi Nikita, > > On Tue, 12 Mar 2013 09:03:24 +0200, Nikita Kiryanov > wrote: > > > Hi Tom, > > > > On 03/11/2013 08:25 PM, Tom Rini wrote: > > > Hello, > > > > > > The following changes since commit > > > fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: > > > > > >x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) > > > > > > are available in the git repository at: > > > > > >git://git.denx.de/u-boot-ti.git master > > > > > > for you to fetch changes up to 76b40ab41eff1f402ee52ba768b09daad293b9bb: > > > > > >Merge u-boot/master into u-boot-ti/master (2013-03-11 12:16:13 -0400) > > > > > > > > > > > [...] > > > > > > Nikita Kiryanov (14): > > >omap: consolidate common mmc definitions > > >omap_hsmmc: fix out of bounds array access > > >omap_hsmmc: introduce omap_hsmmc_data struct > > >omap_hsmmc: implement driver check for card detection > > >cm-t35: implement board specific card detect check > > >mmc: add support for write protection > > >omap_hsmmc: add driver check for write protection > > >omap3: add useful dss defines > > >omap3: allow dynamic selection of gfx_format > > >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 > > >lcd: implement a callback for splashimage > > >cm_t35: prevent splashimage from being set to a bad value > > > > > > > I noticed that the patch "cm-t35: add support for loading splash image > > from NAND" is missing from the above. As I mentioned here > > http://lists.denx.de/pipermail/u-boot/2013-February/146361.html > > V1 is still part of the CM-T35 splash screen and should be included > > with the rest of the patchset. > > Tom: also, the automatic "Conflicts:" lines were left (voluntarily or > involuntarily) in the ToT commit's message. I suggest they be removed > or, if left as a warning sign that the merge contains resolutions, be > replaced with a non-default description. Conflicts: is how it's left in the kernel logs as well, so I'd really lean towards keeping it as-is. > Do you want to re-do this PR or can I take it in as-is? As-is please, I've got a few other things I want to pull in still and I don't want to pile more things on top of the merge to master. -- 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] i2c: s3c24xx: add hsi2c controller support
Hi Naveen,
On Tue, Mar 12, 2013 at 3:58 AM, Naveen Krishna Chatradhi <
ch.nav...@samsung.com> wrote:
> Add support for hsi2c controller available on exynos5420.
>
> Note: driver currently supports only fast speed mode 100kbps
>
> Signed-off-by: Naveen Krishna Chatradhi
> Signed-off-by: R. Chandrasekar
>
I just commented on the Linux driver, so some comments may apply here also.
> ---
> drivers/i2c/s3c24x0_i2c.c | 389
> ++---
> drivers/i2c/s3c24x0_i2c.h | 33
> 2 files changed, 397 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
> index 769a2ba..3117ab7 100644
> --- a/drivers/i2c/s3c24x0_i2c.c
> +++ b/drivers/i2c/s3c24x0_i2c.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #else
> #include
> #endif
> @@ -50,6 +51,60 @@
> #define I2C_NOK_LA 3 /* Lost arbitration */
> #define I2C_NOK_TOUT 4 /* time out */
>
> +/* HSI2C specific register description */
> +
> +/* I2C_CTL Register bits */
> +#define HSI2C_FUNC_MODE_I2C(1u << 0)
> +#define HSI2C_MASTER (1u << 3)
> +#define HSI2C_RXCHON (1u << 6) /* Write/Send */
> +#define HSI2C_TXCHON (1u << 7) /* Read/Receive */
> +#define HSI2C_SW_RST (1u << 31)
> +
> +/* I2C_FIFO_CTL Register bits */
> +#define HSI2C_RXFIFO_EN(1u << 0)
> +#define HSI2C_TXFIFO_EN(1u << 1)
> +#define HSI2C_TXFIFO_TRIGGER_LEVEL (0x20 << 16)
> +#define HSI2C_RXFIFO_TRIGGER_LEVEL (0x20 << 4)
> +
> +/* I2C_TRAILING_CTL Register bits */
> +#define HSI2C_TRAILING_COUNT (0xff)
> +
> +/* I2C_INT_EN Register bits */
> +#define HSI2C_INT_TX_ALMOSTEMPTY_EN(1u << 0)
> +#define HSI2C_INT_RX_ALMOSTFULL_EN (1u << 1)
> +#define HSI2C_INT_TRAILING_EN (1u << 6)
> +#define HSI2C_INT_I2C_EN (1u << 9)
> +
> +/* I2C_CONF Register bits */
> +#define HSI2C_AUTO_MODE(1u << 31)
> +#define HSI2C_10BIT_ADDR_MODE (1u << 30)
> +#define HSI2C_HS_MODE (1u << 29)
> +
> +/* I2C_AUTO_CONF Register bits */
> +#define HSI2C_READ_WRITE (1u << 16)
> +#define HSI2C_STOP_AFTER_TRANS (1u << 17)
> +#define HSI2C_MASTER_RUN (1u << 31)
> +
> +/* I2C_TIMEOUT Register bits */
> +#define HSI2C_TIMEOUT_EN (1u << 31)
> +
> +/* I2C_TRANS_STATUS register bits */
> +#define HSI2C_MASTER_BUSY (1u << 17)
> +#define HSI2C_SLAVE_BUSY (1u << 16)
> +#define HSI2C_NO_DEV (1u << 3)
> +#define HSI2C_NO_DEV_ACK (1u << 2)
> +#define HSI2C_TRANS_ABORT (1u << 1)
> +#define HSI2C_TRANS_DONE (1u << 0)
> +#define HSI2C_TIMEOUT_AUTO (0u << 0)
> +
> +#define HSI2C_SLV_ADDR_MAS(x) ((x & 0x3ff) << 10)
> +
> +/* Controller operating frequency, timing values for operation
> + * are calculated against this frequency
> + */
> +#define HSI2C_FS_TX_CLOCK 100
> +
> +/* S3C I2C Controller bits */
> #define I2CSTAT_BSY0x20/* Busy bit */
> #define I2CSTAT_NACK 0x01/* Nack bit */
> #define I2CCON_ACKGEN 0x80/* Acknowledge generation */
> @@ -61,6 +116,7 @@
>
> #define I2C_TIMEOUT 1 /* 1 second */
>
> +#defineHSI2C_TIMEOUT 100
>
> /*
> * For SPL boot some boards need i2c before SDRAM is initialised so force
> @@ -120,9 +176,23 @@ static int WaitForXfer(struct s3c24x0_i2c *i2c)
> return (readl(&i2c->iiccon) & I2CCON_IRPND) ? I2C_OK :
> I2C_NOK_TOUT;
> }
>
> -static int IsACK(struct s3c24x0_i2c *i2c)
> +static int hsi2c_wait_for_irq(struct exynos5_hsi2c *i2c)
> {
> - return !(readl(&i2c->iicstat) & I2CSTAT_NACK);
> + int i = HSI2C_TIMEOUT * 10;
> + int ret = I2C_NOK_TOUT;
> +
> + while (i > 0) {
> + /* wait for a while and retry */
> + udelay(50);
> + if (readl(&i2c->usi_int_stat) &
> + (HSI2C_INT_I2C_EN | HSI2C_INT_TX_ALMOSTEMPTY_EN)) {
> + ret = I2C_OK;
> + break;
> + }
> + i--;
>
Please can we use the get_timer() method for timeouts instead of udelay()?
> + }
> +
> + return ret;
> }
>
> static void ReadWriteByte(struct s3c24x0_i2c *i2c)
> @@ -130,6 +200,22 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
> writel(readl(&i2c->iiccon) & ~I2CCON_IRPND, &i2c->iiccon);
> }
>
> +static void hsi2c_clear_irqpd(struct exynos5_hsi2c *i2c)
> +{
> + writel(readl(&i2c->usi_int_stat), &i2c->usi_int_stat);
> +}
> +
> +static int hsi2c_isack(struct exynos5_hsi2c *i2c)
> +{
> + return readl(&i2c->usi_trans_status) &
> + (HSI2C_NO_DEV | HSI2C_NO_DEV_ACK);
> +}
> +
> +static int IsACK(struct s3c24x0_i2c *i2c)
>
There are two functions - hsi2c_isack() a
[U-Boot] [PATCH v5] usb: Add multiple controllers support for EHCI PCI
From: Vincent Palatin
Use the ability to have several active EHCI controller on a system
in the PCI EHCI controller implementation.
Signed-off-by: Simon Glass
---
Changes in v5:
- Rebase to usb/master
Changes in v4:
- Add errno.h header file to ehci-pci
Changes in v2:
- Add blank line before function return
drivers/usb/host/ehci-pci.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 001d141..90d7a6f 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -34,7 +34,7 @@ static struct pci_device_id ehci_pci_ids[] = {
{0, 0}
};
#else
-static pci_dev_t ehci_find_class(void)
+static pci_dev_t ehci_find_class(int index)
{
int bus;
int devnum;
@@ -54,7 +54,8 @@ static pci_dev_t ehci_find_class(void)
bdf += PCI_BDF(0, 0, 1)) {
pci_read_config_dword(bdf, PCI_CLASS_REVISION,
&class);
- if (class >> 8 == PCI_CLASS_SERIAL_USB_EHCI)
+ if ((class >> 8 == PCI_CLASS_SERIAL_USB_EHCI)
+ && !index--)
return bdf;
}
}
@@ -68,29 +69,35 @@ static pci_dev_t ehci_find_class(void)
* Create the appropriate control structures to manage
* a new EHCI host controller.
*/
-int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+int ehci_hcd_init(int index, struct ehci_hccr **ret_hccr,
+ struct ehci_hcor **ret_hcor)
{
pci_dev_t pdev;
uint32_t cmd;
+ struct ehci_hccr *hccr;
+ struct ehci_hcor *hcor;
#ifdef CONFIG_PCI_EHCI_DEVICE
pdev = pci_find_devices(ehci_pci_ids, CONFIG_PCI_EHCI_DEVICE);
#else
- pdev = ehci_find_class();
+ pdev = ehci_find_class(index);
#endif
if (pdev < 0) {
printf("EHCI host controller not found\n");
return -1;
}
- *hccr = (struct ehci_hccr *)pci_map_bar(pdev,
+ hccr = (struct ehci_hccr *)pci_map_bar(pdev,
PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
- *hcor = (struct ehci_hcor *)((uint32_t) *hccr +
- HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+ hcor = (struct ehci_hcor *)((uint32_t) hccr +
+ HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
debug("EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n",
- (uint32_t)*hccr, (uint32_t)*hcor,
- (uint32_t)HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+ (uint32_t)hccr, (uint32_t)hcor,
+ (uint32_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
+ *ret_hccr = hccr;
+ *ret_hcor = hcor;
/* enable busmaster */
pci_read_config_dword(pdev, PCI_COMMAND, &cmd);
--
1.8.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB patches
Hi Marek, On Tue, Mar 12, 2013 at 12:58 AM, Marek Vasut wrote: > Dear Simon Glass, > >> Hi Marek, >> >> On Mon, Mar 11, 2013 at 9:16 AM, Simon Glass wrote: >> > Hi Marek, >> > >> > As requested here is an email about the USB patches. I have put them in a >> > bundle here: >> > >> > http://patchwork.ozlabs.org/bundle/sjg/for-marex/ >> >> But unfortunately I found a problem in patch 4. Here is an updated version >> which includes errno.h. >> >> http://patchwork.ozlabs.org/patch/226713/ >> >> Regards, >> Simon > > I applied 1,2,3 and 5 ; 4 doesn't apply. I pushed those to u-boot-usb/master Thanks - sorry, for some reason I thought the original PCI patch was already in mainline, so the first patch was correct. Just to be clear, I have sent out a rebased v5 patch and it is here: http://patchwork.ozlabs.org/patch/227027/ Regards, Simon > > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On Mon, 11 Mar 2013 14:25:44 -0400, Tom Rini wrote: > Hello, > > The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: > > x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to 76b40ab41eff1f402ee52ba768b09daad293b9bb: > > Merge u-boot/master into u-boot-ti/master (2013-03-11 12:16:13 -0400) > > > > Enric Balletbo i Serra (4): > SPL: ONENAND: Fix some ONENAND related defines. > SPL: ONENAND: Fix onenand_spl_load_image implementation. > SPL: ONENAND: Support SPL to boot u-boot from OneNAND. > OMAP3: Initialize gpmc if SPL_ONENAND_SUPPORT is enabled. > > Lokesh Vutla (13): > ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register > ARM: OMAP4+: Cleanup emif specific files > ARM: OMAP4+: Make control module register structure generic > ARM: OMAP5: Clean up iosettings code > ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs > ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup > arm: dra7xx: clock: Add the prcm changes > arm: dra7xx: clock: Add the dplls data > arm: dra7xx: Add control module changes > arm: dra7xx: Add DDR related data for DRA752 ES1.0 > arm: dra7xx: Add board files for DRA7XX socs > arm: dra7xx: Add dra7xx_evm build support > arm: dra7xx: Add silicon id support for DRA752 soc > > Mark Jackson (1): > Allow AM33xx boards to setup GPMC chipselects. > > Mugunthan V N (1): > am335x: cpsw: optimize cpsw_send to increase network performance > > Nikita Kiryanov (14): > omap: consolidate common mmc definitions > omap_hsmmc: fix out of bounds array access > omap_hsmmc: introduce omap_hsmmc_data struct > omap_hsmmc: implement driver check for card detection > cm-t35: implement board specific card detect check > mmc: add support for write protection > omap_hsmmc: add driver check for write protection > omap3: add useful dss defines > omap3: allow dynamic selection of gfx_format > 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 > lcd: implement a callback for splashimage > cm_t35: prevent splashimage from being set to a bad value > > SRICHARAN R (6): > ARM: OMAP4+: Change the PRCM structure prototype common for all Socs > ARM: OMAP4+: Cleanup the clocks layer > ARM: OMAP4+: Clean up the pmic code > ARM: OMAP5: Add silicon id support for ES2.0 revision. > ARM: OMAP5: clock: Add the prcm register changes required for ES2.0 > ARM: OMAP4/5: clocks: Add the required OPP settings as per the latest > addendum > > Tom Rini (8): > am335x_evm: Never set CONFIG_EXTRA_ENV_SETTINGS in SPL > am335x_evm: Add am335x_evm_usbspl build target > am33xx: Update DDR3 EMIF configuration sequence > am335x_evm: Enable CONFIG_CMD_BOOTZ > omap5_evm: Enable CONFIG_CMD_BOOTZ > omap3_beagle: Enable CONFIG_CMD_BOOTZ > omap4_common: Enable CONFIG_CMD_BOOTZ > Merge u-boot/master into u-boot-ti/master > > The following diffstat is a little "funny" since to generate something > close to correct I had to make a manual merge branch of > u-boot-arm/master + u-boot/master and compare vs that. > > MAINTAINERS |1 + > README | 19 + > arch/arm/cpu/arm1136/mx35/generic.c |2 +- > arch/arm/cpu/armv7/am33xx/board.c |4 +- > arch/arm/cpu/armv7/am33xx/ddr.c | 12 +- > arch/arm/cpu/armv7/omap-common/boot-common.c|7 +- > arch/arm/cpu/armv7/omap-common/clocks-common.c | 312 +--- > arch/arm/cpu/armv7/omap-common/emif-common.c| 73 +- > arch/arm/cpu/armv7/omap-common/hwinit-common.c | 23 +- > arch/arm/cpu/armv7/omap-common/vc.c | 11 +- > arch/arm/cpu/armv7/omap3/board.c|6 +- > arch/arm/cpu/armv7/omap4/Makefile |3 +- > arch/arm/cpu/armv7/omap4/clocks.c | 517 > arch/arm/cpu/armv7/omap4/hw_data.c | 491 > arch/arm/cpu/armv7/omap4/hwinit.c | 36 +- > arch/arm/cpu/armv7/omap4/prcm-regs.c| 315 > arch/arm/cpu/armv7/omap4/sdram_elpida.c | 34 +- > arch/arm/cpu/armv7/omap5/Makefile |3 +- > arch/arm/cpu/armv7/omap5/clocks.c | 494 > arch/arm/cpu/armv7/omap5/hw_data.c | 596 ++ > arch/arm/cpu/armv7/omap5/hwinit.c | 292 --- > arch/arm/cpu/armv7/omap5/prcm-regs.c| 958 > ++
Re: [U-Boot] [PATCH v5] Introduced btrfs file-system with btrload command
Hi Adnan,
On Mon, Mar 11, 2013 at 6:18 AM, Adnan Ali wrote:
> Introduces btrfs file-system to read file from
> volume/sub-volumes with btrload command. This
> implementation has read-only support.
> This btrfs implementation is based on syslinux btrfs
> code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d.
>
> v5: merged with master.
> v4: btrls command added.
> v3: patch re-formated.
> v2: patch error removed.
>
> Signed-off-by: Adnan Ali
> ---
> Makefile |1 +
> common/Makefile|1 +
> common/cmd_btr.c | 65 +++
> fs/btrfs/Makefile | 51 ++
> fs/btrfs/btrfs.c | 1348
>
> fs/btrfs/crc32_c.c | 54 ++
> fs/fs.c| 10 +
> include/btrfs.h| 416 ++
> include/config_fallbacks.h |4 +
> include/fs.h |1 +
> 10 files changed, 1951 insertions(+)
> create mode 100644 common/cmd_btr.c
> create mode 100644 fs/btrfs/Makefile
> create mode 100644 fs/btrfs/btrfs.c
> create mode 100644 fs/btrfs/crc32_c.c
> create mode 100644 include/btrfs.h
>
I have ignored the code before this point in btrfs.c since it is
imported and you want to keep the code style as is, but if you don't
mind I will make a few comments after that point>
> +struct btrfs_info fs;
> +
> +/*
> + * mount btrfs file-system
> + */
> +int btrfs_probe(block_dev_desc_t *rbdd, disk_partition_t *info)
> +{
> +btrfs_block_dev_desc = rbdd;
> +part_info = info;
> +btr_part_offset = info->start;
> + if (btrfs_fs_init(&fs) < 0 ) {
> + debug("btrfs probe failed\n");
> + return -1;
> + }
You should use tabs for intend (some of this bit uses spaces, some uses tabs).
> +
> + return 0;
> +}
> +
> +/*
> + * Read file data
> + */
> +int btrfs_read_file(const char *filename, void *buf, int offset, int len)
> +{
> + int file_len=0;
> +int len_read;
> +struct com32_filedata filedata;
> +int handle;
> +if (offset != 0) {
> +debug("** Cannot support non-zero offset **\n");
> +return -1;
> +}
> +
> +handle=btrfs_open_file(filename, &filedata);
> +if (handle < 0) {
> +debug("** File not found %s Invalid handle**\n", filename);
> +return -1;
> +}
> +
> +/*file handle is valid get the size of the file*/
> +len = filedata.size;
> +if (len == 0)
> +len = file_len;
> +
> +len_read = getfssec(&filedata, (char *)buf);
> +if (len_read != len) {
> +debug("** Unable to read file %s **\n", filename);
> +return -1;
> +}
> +
> +return len_read;
> +
> +}
> +
> +/*
> + * Show directory entries
> + */
> +char btrfs_ls(char *dirname)
> +{
> + struct btrfs_dirent *de;
> + struct _DIR_ *dir;
> +
> + if(*dirname == '/' && *(dirname+1) == 0)
> + *dirname = '.';
> +
> + dir = opendir(dirname);
> + if (dir == NULL)
> +return -1;
> +
> + while ((de = readdir(dir)) != NULL)
> +;
This doesn't seem to print anything.
> +
> + return 0;
> +}
> +
> +/*
> + * umount btrfs file-system
> + */
> +void btrfs_close(void)
> +{
> +
Remove blank line
> +}
> diff --git a/fs/btrfs/crc32_c.c b/fs/btrfs/crc32_c.c
> new file mode 100644
> index 000..78d0447
> --- /dev/null
> +++ b/fs/btrfs/crc32_c.c
> @@ -0,0 +1,54 @@
> +/*
> + * Copied from Linux kernel crypto/crc32c.c
> + * Copyright (c) 2004 Cisco Systems, Inc.
> + * Copyright (c) 2008 Herbert Xu
> + *
> + * 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 is the CRC-32C table
> + * Generated with:
> + * width = 32 bits
> + * poly = 0x1EDC6F41
> + * reflect input bytes = true
> + * reflect output bytes = true
> + */
Old comment?
> +
> +/*
> + * Steps through buffer one byte at at time, calculates reflected
> + * crc using table.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +inline u32 crc32c_cal(u32 crc, const char *data, size_t length, u32
> *crc32c_table)
> +{
> + while (length--)
> + crc = crc32c_table[(u8)(crc ^ *data++)] ^ (crc >> 8);
> +
> + return crc;
> +}
> +
> +inline void crc32c_init(u32 *crc32c_table, u32 pol)
The 'inline' isn't needed.
> +{
> + int i, j;
> + u32 v;
> + const u32 poly = pol; /* Bit-reflected CRC32C polynomial */
> +
> + for (i = 0; i < 256; i++) {
> + v = i;
> + for (j = 0; j < 8; j++) {
Can remove this inner {} since you only have one line of code.
> + v = (v >> 1) ^ ((v & 1) ? poly : 0);
> +
Re: [U-Boot] [PATCH] i2c: s3c24xx: add hsi2c controller support
On 12 March 2013 22:11, Simon Glass wrote:
> Hi Naveen,
>
> On Tue, Mar 12, 2013 at 3:58 AM, Naveen Krishna Chatradhi <
> ch.nav...@samsung.com> wrote:
>
>> Add support for hsi2c controller available on exynos5420.
>>
>> Note: driver currently supports only fast speed mode 100kbps
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> Signed-off-by: R. Chandrasekar
>>
>
> I just commented on the Linux driver, so some comments may apply here also.
>
>
>> ---
>> drivers/i2c/s3c24x0_i2c.c | 389
>> ++---
>> drivers/i2c/s3c24x0_i2c.h | 33
>> 2 files changed, 397 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
>> index 769a2ba..3117ab7 100644
>> --- a/drivers/i2c/s3c24x0_i2c.c
>> +++ b/drivers/i2c/s3c24x0_i2c.c
>> @@ -32,6 +32,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #else
>> #include
>> #endif
>> @@ -50,6 +51,60 @@
>> #define I2C_NOK_LA 3 /* Lost arbitration */
>> #define I2C_NOK_TOUT 4 /* time out */
>>
>> +/* HSI2C specific register description */
>> +
>> +/* I2C_CTL Register bits */
>> +#define HSI2C_FUNC_MODE_I2C(1u << 0)
>> +#define HSI2C_MASTER (1u << 3)
>> +#define HSI2C_RXCHON (1u << 6) /* Write/Send */
>> +#define HSI2C_TXCHON (1u << 7) /* Read/Receive */
>> +#define HSI2C_SW_RST (1u << 31)
>> +
>> +/* I2C_FIFO_CTL Register bits */
>> +#define HSI2C_RXFIFO_EN(1u << 0)
>> +#define HSI2C_TXFIFO_EN(1u << 1)
>> +#define HSI2C_TXFIFO_TRIGGER_LEVEL (0x20 << 16)
>> +#define HSI2C_RXFIFO_TRIGGER_LEVEL (0x20 << 4)
>> +
>> +/* I2C_TRAILING_CTL Register bits */
>> +#define HSI2C_TRAILING_COUNT (0xff)
>> +
>> +/* I2C_INT_EN Register bits */
>> +#define HSI2C_INT_TX_ALMOSTEMPTY_EN(1u << 0)
>> +#define HSI2C_INT_RX_ALMOSTFULL_EN (1u << 1)
>> +#define HSI2C_INT_TRAILING_EN (1u << 6)
>> +#define HSI2C_INT_I2C_EN (1u << 9)
>> +
>> +/* I2C_CONF Register bits */
>> +#define HSI2C_AUTO_MODE(1u << 31)
>> +#define HSI2C_10BIT_ADDR_MODE (1u << 30)
>> +#define HSI2C_HS_MODE (1u << 29)
>> +
>> +/* I2C_AUTO_CONF Register bits */
>> +#define HSI2C_READ_WRITE (1u << 16)
>> +#define HSI2C_STOP_AFTER_TRANS (1u << 17)
>> +#define HSI2C_MASTER_RUN (1u << 31)
>> +
>> +/* I2C_TIMEOUT Register bits */
>> +#define HSI2C_TIMEOUT_EN (1u << 31)
>> +
>> +/* I2C_TRANS_STATUS register bits */
>> +#define HSI2C_MASTER_BUSY (1u << 17)
>> +#define HSI2C_SLAVE_BUSY (1u << 16)
>> +#define HSI2C_NO_DEV (1u << 3)
>> +#define HSI2C_NO_DEV_ACK (1u << 2)
>> +#define HSI2C_TRANS_ABORT (1u << 1)
>> +#define HSI2C_TRANS_DONE (1u << 0)
>> +#define HSI2C_TIMEOUT_AUTO (0u << 0)
>> +
>> +#define HSI2C_SLV_ADDR_MAS(x) ((x & 0x3ff) << 10)
>> +
>> +/* Controller operating frequency, timing values for operation
>> + * are calculated against this frequency
>> + */
>> +#define HSI2C_FS_TX_CLOCK 100
>> +
>> +/* S3C I2C Controller bits */
>> #define I2CSTAT_BSY0x20/* Busy bit */
>> #define I2CSTAT_NACK 0x01/* Nack bit */
>> #define I2CCON_ACKGEN 0x80/* Acknowledge generation */
>> @@ -61,6 +116,7 @@
>>
>> #define I2C_TIMEOUT 1 /* 1 second */
>>
>> +#defineHSI2C_TIMEOUT 100
>>
>> /*
>> * For SPL boot some boards need i2c before SDRAM is initialised so force
>> @@ -120,9 +176,23 @@ static int WaitForXfer(struct s3c24x0_i2c *i2c)
>> return (readl(&i2c->iiccon) & I2CCON_IRPND) ? I2C_OK :
>> I2C_NOK_TOUT;
>> }
>>
>> -static int IsACK(struct s3c24x0_i2c *i2c)
>> +static int hsi2c_wait_for_irq(struct exynos5_hsi2c *i2c)
>> {
>> - return !(readl(&i2c->iicstat) & I2CSTAT_NACK);
>> + int i = HSI2C_TIMEOUT * 10;
>> + int ret = I2C_NOK_TOUT;
>> +
>> + while (i > 0) {
>> + /* wait for a while and retry */
>> + udelay(50);
>> + if (readl(&i2c->usi_int_stat) &
>> + (HSI2C_INT_I2C_EN | HSI2C_INT_TX_ALMOSTEMPTY_EN)) {
>> + ret = I2C_OK;
>> + break;
>> + }
>> + i--;
>>
>
> Please can we use the get_timer() method for timeouts instead of udelay()?
Sure thing
>
>
>> + }
>> +
>> + return ret;
>> }
>>
>> static void ReadWriteByte(struct s3c24x0_i2c *i2c)
>> @@ -130,6 +200,22 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
>> writel(readl(&i2c->iiccon) & ~I2CCON_IRPND, &i2c->iiccon);
>> }
>>
>> +static void hsi2c_clear_irqpd(struct exynos5_hsi2c *i2c)
>> +{
>> + writel(readl(&i2c->usi_int_stat), &i2c->usi_int_stat);
>> +}
>> +
>> +static int hsi2c_isack(struct exynos5_hsi2c *i2c)
>> +{
>>
Re: [U-Boot] USB patches
Dear Simon Glass, > Hi Marek, > > On Tue, Mar 12, 2013 at 12:58 AM, Marek Vasut wrote: > > Dear Simon Glass, > > > >> Hi Marek, > >> > >> On Mon, Mar 11, 2013 at 9:16 AM, Simon Glass wrote: > >> > Hi Marek, > >> > > >> > As requested here is an email about the USB patches. I have put them > >> > in a bundle here: > >> > > >> > http://patchwork.ozlabs.org/bundle/sjg/for-marex/ > >> > >> But unfortunately I found a problem in patch 4. Here is an updated > >> version which includes errno.h. > >> > >> http://patchwork.ozlabs.org/patch/226713/ > >> > >> Regards, > >> Simon > > > > I applied 1,2,3 and 5 ; 4 doesn't apply. I pushed those to > > u-boot-usb/master > > Thanks - sorry, for some reason I thought the original PCI patch was > already in mainline, so the first patch was correct. Just to be clear, > I have sent out a rebased v5 patch and it is here: > > http://patchwork.ozlabs.org/patch/227027/ Thanks! 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 v5] Introduced btrfs file-system with btrload command
Hi
On 12/03/13 14:15, Simon Glass wrote:
Hi Adnan,
On Mon, Mar 11, 2013 at 6:18 AM, Adnan Ali wrote:
Introduces btrfs file-system to read file from
volume/sub-volumes with btrload command. This
implementation has read-only support.
This btrfs implementation is based on syslinux btrfs
code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d.
v5: merged with master.
v4: btrls command added.
v3: patch re-formated.
v2: patch error removed.
Signed-off-by: Adnan Ali
---
Makefile |1 +
common/Makefile|1 +
common/cmd_btr.c | 65 +++
fs/btrfs/Makefile | 51 ++
fs/btrfs/btrfs.c | 1348
fs/btrfs/crc32_c.c | 54 ++
fs/fs.c| 10 +
include/btrfs.h| 416 ++
include/config_fallbacks.h |4 +
include/fs.h |1 +
10 files changed, 1951 insertions(+)
create mode 100644 common/cmd_btr.c
create mode 100644 fs/btrfs/Makefile
create mode 100644 fs/btrfs/btrfs.c
create mode 100644 fs/btrfs/crc32_c.c
create mode 100644 include/btrfs.h
I have ignored the code before this point in btrfs.c since it is
imported and you want to keep the code style as is, but if you don't
mind I will make a few comments after that point>
Here are my comments
+struct btrfs_info fs;
+
+/*
+ * mount btrfs file-system
+ */
+int btrfs_probe(block_dev_desc_t *rbdd, disk_partition_t *info)
+{
+btrfs_block_dev_desc = rbdd;
+part_info = info;
+btr_part_offset = info->start;
+ if (btrfs_fs_init(&fs) < 0 ) {
+ debug("btrfs probe failed\n");
+ return -1;
+ }
You should use tabs for intend (some of this bit uses spaces, some uses tabs).
Some how i missed will check it again. Ack
+
+ return 0;
+}
+
+/*
+ * Read file data
+ */
+int btrfs_read_file(const char *filename, void *buf, int offset, int len)
+{
+ int file_len=0;
+int len_read;
+struct com32_filedata filedata;
+int handle;
+if (offset != 0) {
+debug("** Cannot support non-zero offset **\n");
+return -1;
+}
+
+handle=btrfs_open_file(filename, &filedata);
+if (handle < 0) {
+debug("** File not found %s Invalid handle**\n", filename);
+return -1;
+}
+
+/*file handle is valid get the size of the file*/
+len = filedata.size;
+if (len == 0)
+len = file_len;
+
+len_read = getfssec(&filedata, (char *)buf);
+if (len_read != len) {
+debug("** Unable to read file %s **\n", filename);
+return -1;
+}
+
+return len_read;
+
+}
+
+/*
+ * Show directory entries
+ */
+char btrfs_ls(char *dirname)
+{
+ struct btrfs_dirent *de;
+ struct _DIR_ *dir;
+
+ if(*dirname == '/' && *(dirname+1) == 0)
+ *dirname = '.';
+
+ dir = opendir(dirname);
+ if (dir == NULL)
+return -1;
+
+ while ((de = readdir(dir)) != NULL)
+;
This doesn't seem to print anything.
readdir->btrfs_read, prints contents on media.
+
+ return 0;
+}
+
+/*
+ * umount btrfs file-system
+ */
+void btrfs_close(void)
+{
+
Remove blank line
Ack
+}
diff --git a/fs/btrfs/crc32_c.c b/fs/btrfs/crc32_c.c
new file mode 100644
index 000..78d0447
--- /dev/null
+++ b/fs/btrfs/crc32_c.c
@@ -0,0 +1,54 @@
+/*
+ * Copied from Linux kernel crypto/crc32c.c
+ * Copyright (c) 2004 Cisco Systems, Inc.
+ * Copyright (c) 2008 Herbert Xu
+ *
+ * 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 is the CRC-32C table
+ * Generated with:
+ * width = 32 bits
+ * poly = 0x1EDC6F41
+ * reflect input bytes = true
+ * reflect output bytes = true
+ */
Old comment?
this crc was part of port
+
+/*
+ * Steps through buffer one byte at at time, calculates reflected
+ * crc using table.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+inline u32 crc32c_cal(u32 crc, const char *data, size_t length, u32
*crc32c_table)
+{
+ while (length--)
+ crc = crc32c_table[(u8)(crc ^ *data++)] ^ (crc >> 8);
+
+ return crc;
+}
+
+inline void crc32c_init(u32 *crc32c_table, u32 pol)
The 'inline' isn't needed.
Ack
+{
+ int i, j;
+ u32 v;
+ const u32 poly = pol; /* Bit-reflected CRC32C polynomial */
+
+ for (i = 0; i < 256; i++) {
+ v = i;
+ for (j = 0; j < 8; j++) {
Can remove this inner {} since you only have one line of code.
Ack
+ v = (v >> 1) ^ ((v & 1) ? poly : 0);
+ }
+ crc32c_table[i] = v;
+ }
+}
I suggest you move your cr
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood wrote: > On 03/08/2013 02:59:47 PM, Tom Rini wrote: > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >On 03/08/2013 03:34 PM, Scott Wood wrote: > >> On 03/08/2013 02:27:48 PM, Tom Rini wrote: > >>> On Thu, Dec 20, 2012 at 11:51:05AM -, Scott Wood wrote: > >>> > SPL doesn't write to the environment. These list entries > prevent the functions from being garbage-collected, even > though nothing will > >>> look at > the list. This caused several SPL builds (e.g. > P2020RDB-PC_NAND) to break due to size limitations and/or > unresolved symbols. > > A static inline function is used to provide a context in which > we can consume the callback, and thus avoid unused function > warnings. > > Signed-off-by: Scott Wood Acked-by: > Joe Hershberger Acked-by: Kim > Phillips > >>> > >>> OK, this isn't quite right. On am335x_evm where SPL does use the > >>> "full" version of the environment, rather than the restricted > >>> version that say a3m071 we need these these callbacks to be > >>> generated. We usually build successfully since in these cases > >>> our #include of picks up the one in include that the > >>> main SPL generates. But with enough cores we build SPL before > >>> we build this list for non-SPL, and the build fails. I shall > >>> submit a patch shortly for this. > >> > >> What does am335x_evm do in the SPL that requires modifying the > >> environment, and how does omitting the callbacks cause a build > >> break? > > > >It requires the full network stack which in turn means we can't just > >discard most of the environment related functions. And some parts of > >the callback infrastructure aren't opt-in'able. > > I still don't follow -- the only effect of this patch should be that > the callbacks don't get called, which is only relevant when writing > to the environment. We're not ripping out anything, just declining > to reference the callback functions. If something else still > references them, they'll be retained. It's not that they don't get called, it's that they don't get put into the special section. > >> The u-boot.lst issue sounds unrelated to this patch. > > > >The problem is undefined references at link time to > >_u_boot_env_clbk__start/__end from common/env_callbacks.c where it > >tries to look at our empty list of callbacks (we are able to discard > >all of those). > > Why would eliminating all individual callbacks cause start/end to go > away? If that's the way the list mechanism works, the mechanism > needs fixing. Yes, that's how the mechanism works. Rather than having to declare that you expect to have a linker list of name $foo, we dynamically determine what linker lists we have and setup the linker section entry. I'm not sure it's broken exactly, I think maybe we just need to say no env callback support in SPL since it's not really user editable. I've got an idea that I'm going to go test now and then if it works, post patches for. > >And part of the issue is that we're always using the > >wrong u-boot.lst file for SPL. It's just that in most cases the wrong > >one (the main U-Boot one) is also fine enough for SPL since it's just > >a few extra symbols and we aren't so constrained for space that we've > >noticed. > > That sounds familiar: a6d0f62a0ccac7669b1efe320e28c276b1b8084b > :-) Not quite the same problem. This one shows up with separate obj directories too. It really is that with a small enough job number we generate include/u-boot.lst before trying to link u-boot-spl, and that is used, and gives us the start/end symbols (at the same address as we've discarded the callbacks themselves). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra114: fdt: Move aliases from dtsi to dts file as per other Tegras
All other Tegra boards have their aliase nodes in the .dts file
Signed-off-by: Tom Warren
---
arch/arm/dts/tegra114.dtsi|8
board/nvidia/dts/tegra114-dalmore.dts |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index dfeac53..701c0f9 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -3,14 +3,6 @@
/ {
compatible = "nvidia,tegra114";
- aliases {
- i2c0 = "/i2c@7000d000";
- i2c1 = "/i2c@7000c000";
- i2c2 = "/i2c@7000c400";
- i2c3 = "/i2c@7000c500";
- i2c4 = "/i2c@7000c700";
- };
-
tegra_car: clock {
compatible = "nvidia,tegra114-car";
reg = <0x60006000 0x1000>;
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
index 3e1e1ea..30cf1fb 100644
--- a/board/nvidia/dts/tegra114-dalmore.dts
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -6,6 +6,14 @@
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>;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra114: Dalmore: Add pad config tables/code based on pinmux code
Pad config registers exist in APB_MISC_GP space, and control slew
rate, drive strengh, schmidt, high-speed, and low-power modes for
all of the pingroups in Tegra30. This builds off of the pinmux
way of constructing init tables to configure select pads (SDIOCFG,
for instance) during pinmux_init().
Currently, no padcfg entries exist. SDIO3CFG will be added when the
MMC driver is added as per the TRM to work with the SD-card slot on
Dalmore E1611.
Signed-off-by: Tom Warren
---
arch/arm/cpu/tegra114-common/pinmux.c| 188 ++
arch/arm/include/asm/arch-tegra114/pinmux.h | 75 ++-
board/nvidia/dalmore/pinmux-config-dalmore.h | 16 +++
3 files changed, 274 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/tegra114-common/pinmux.c
b/arch/arm/cpu/tegra114-common/pinmux.c
index 27b5f69..f037320 100644
--- a/arch/arm/cpu/tegra114-common/pinmux.c
+++ b/arch/arm/cpu/tegra114-common/pinmux.c
@@ -39,6 +39,19 @@ struct tegra_pingroup_desc {
#define PMUX_IO_RESET_SHIFT8
#define PMUX_RCV_SEL_SHIFT 9
+#define PGRP_HSM_SHIFT 2
+#define PGRP_SCHMT_SHIFT 3
+#define PGRP_LPMD_SHIFT4
+#define PGRP_LPMD_MASK (3 << PGRP_LPMD_SHIFT)
+#define PGRP_DRVDN_SHIFT 12
+#define PGRP_DRVDN_MASK(0x7F << PGRP_DRVDN_SHIFT)
+#define PGRP_DRVUP_SHIFT 20
+#define PGRP_DRVUP_MASK(0x7F << PGRP_DRVUP_SHIFT)
+#define PGRP_SLWR_SHIFT28
+#define PGRP_SLWR_MASK (3 << PGRP_SLWR_SHIFT)
+#define PGRP_SLWF_SHIFT30
+#define PGRP_SLWF_MASK (3 << PGRP_SLWF_SHIFT)
+
/* Convenient macro for defining pin group properties */
#define PIN(pg_name, vdd, f0, f1, f2, f3, iod) \
{ \
@@ -544,3 +557,178 @@ void pinmux_config_table(struct pingroup_config *config,
int len)
for (i = 0; i < len; i++)
pinmux_config_pingroup(&config[i]);
}
+
+static int padgrp_set_drvup_slwf(enum pdrive_pingrp pad,
+ int slwf)
+{
+ struct pmux_tri_ctlr *pmt =
+ (struct pmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
+ u32 *pad_slwf = &pmt->pmt_drive[pad];
+ u32 reg;
+
+ /* Error check on pad and slwf */
+ assert(pmux_padgrp_isvalid(pad));
+ assert(pmux_pad_slw_isvalid(slwf));
+
+ /* NONE means unspecified/do not change/use POR value */
+ if (slwf == PGRP_SLWF_NONE)
+ return 0;
+
+ reg = readl(pad_slwf);
+ reg &= ~PGRP_SLWF_MASK;
+ reg |= (slwf << PGRP_SLWF_SHIFT);
+ writel(reg, pad_slwf);
+
+ return 0;
+}
+
+static int padgrp_set_drvdn_slwr(enum pdrive_pingrp pad, int slwr)
+{
+ struct pmux_tri_ctlr *pmt =
+ (struct pmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
+ u32 *pad_slwr = &pmt->pmt_drive[pad];
+ u32 reg;
+
+ /* Error check on pad and slwr */
+ assert(pmux_padgrp_isvalid(pad));
+ assert(pmux_pad_slw_isvalid(slwr));
+
+ /* NONE means unspecified/do not change/use POR value */
+ if (slwr == PGRP_SLWR_NONE)
+ return 0;
+
+ reg = readl(pad_slwr);
+ reg &= ~PGRP_SLWR_MASK;
+ reg |= (slwr << PGRP_SLWR_SHIFT);
+ writel(reg, pad_slwr);
+
+ return 0;
+}
+
+static int padgrp_set_drvup(enum pdrive_pingrp pad, int drvup)
+{
+ struct pmux_tri_ctlr *pmt =
+ (struct pmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
+ u32 *pad_drvup = &pmt->pmt_drive[pad];
+ u32 reg;
+
+ /* Error check on pad and drvup */
+ assert(pmux_padgrp_isvalid(pad));
+ assert(pmux_pad_drv_isvalid(drvup));
+
+ /* NONE means unspecified/do not change/use POR value */
+ if (drvup == PGRP_DRVUP_NONE)
+ return 0;
+
+ reg = readl(pad_drvup);
+ reg &= ~PGRP_DRVUP_MASK;
+ reg |= (drvup << PGRP_DRVUP_SHIFT);
+ writel(reg, pad_drvup);
+
+ return 0;
+}
+
+static int padgrp_set_drvdn(enum pdrive_pingrp pad, int drvdn)
+{
+ struct pmux_tri_ctlr *pmt =
+ (struct pmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
+ u32 *pad_drvdn = &pmt->pmt_drive[pad];
+ u32 reg;
+
+ /* Error check on pad and drvdn */
+ assert(pmux_padgrp_isvalid(pad));
+ assert(pmux_pad_drv_isvalid(drvdn));
+
+ /* NONE means unspecified/do not change/use POR value */
+ if (drvdn == PGRP_DRVDN_NONE)
+ return 0;
+
+ reg = readl(pad_drvdn);
+ reg &= ~PGRP_DRVDN_MASK;
+ reg |= (drvdn << PGRP_DRVDN_SHIFT);
+ writel(reg, pad_drvdn);
+
+ return 0;
+}
+
+static int padgrp_set_lpmd(enum pdrive_pingrp pad, enum pgrp_lpmd lpmd)
+{
+ struct pmux_tri_ctlr *pmt =
+ (struct pmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
+ u32 *pad_lpmd = &pmt->pmt_drive[pad];
+ u32 reg;
+
+ /* Error check pad and lpmd value */
+ assert(pmux_padgrp_isvalid(pad));
[U-Boot] [PATCH 1/2] env_callback: Mark find_env_callback as static
This is not called outside of env_callback.c so mark static, remove from
Cc: Joe Hershberger
Signed-off-by: Tom Rini
---
common/env_callback.c |2 +-
include/env_callback.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/common/env_callback.c b/common/env_callback.c
index 78ca367..78aafb4 100644
--- a/common/env_callback.c
+++ b/common/env_callback.c
@@ -31,7 +31,7 @@ DECLARE_GLOBAL_DATA_PTR;
/*
* Look up a callback function pointer by name
*/
-struct env_clbk_tbl *find_env_callback(const char *name)
+static struct env_clbk_tbl *find_env_callback(const char *name)
{
struct env_clbk_tbl *clbkp;
int i;
diff --git a/include/env_callback.h b/include/env_callback.h
index 62428d1..dfc41ae 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -67,7 +67,6 @@ struct env_clbk_tbl {
int flags);
};
-struct env_clbk_tbl *find_env_callback(const char *);
void env_callback_init(ENTRY *var_entry);
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] SPL: Fix build of CONFIG_SPL_NET_SUPPORT
With CONFIG_SPL_NET_SUPPORT set we bring in most of the environment
related code. This in turn means that while we discard the callback
saftey checks in the environment, we had still needed their
__start/__end linker symbols. In most cases this had been working
because we generated u-boot.lst for the main U-Boot build prior to
creating u-boot-spl.lds. With a sufficiently large machine this is not
the case and exposed this latent bug which is that as of f8cfcf1 there
are no callback linker entries so not __start/__end symbol was
generated.
As the environment is not user modifiable in this particular run-time
(for any variable that had a callback associated with it) we simply
provide an empty env_callback_init in SPL.
Cc: Joe Hershberger
Cc: Scott Wood
Tested-by: Tom Rini (Ran with am335x_evm_usbspl build)
Signed-off-by: Tom Rini
---
common/Makefile |3 ---
common/spl/spl.c | 12
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/common/Makefile b/common/Makefile
index 719fc23..0e11964 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -211,10 +211,7 @@ COBJS-y += cmd_nvedit.o
COBJS-y += env_common.o
COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
-COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o
-COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o
-COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 6715e0d..1ac2e4b 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -271,3 +272,14 @@ void preloader_console_init(void)
spl_display_print();
#endif
}
+
+/*
+ * When CONFIG_SPL_NET_SUPPORT is set, we bring in and require a large
+ * subset of the environment code. However, as the environment is not
+ * modifable interactively in this case we remove the environment
+ * callback support from the binary. To do so we must provide an empty
+ * env_callback_init function.
+ */
+void env_callback_init(ENTRY *var_entry)
+{
+}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Tegra114: fdt: Add SDMMC (sdhci) nodes for T114 boards (Dalmore for now)
Took these values directly from the kernel dts files.
Signed-off-by: Tom Warren
---
arch/arm/dts/tegra114.dtsi| 32
board/nvidia/dts/tegra114-dalmore.dts | 13 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index 701c0f9..5dbe3b2 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -75,4 +75,36 @@
clocks = <&tegra_car 47>;
status = "disabled";
};
+
+ sdhci@7800 {
+ compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
+ reg = <0x7800 0x200>;
+ interrupts = <0 14 0x04>;
+ clocks = <&tegra_car 14>;
+ status = "disable";
+ };
+
+ sdhci@78000200 {
+ compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
+ reg = <0x78000200 0x200>;
+ interrupts = <0 15 0x04>;
+ clocks = <&tegra_car 9>;
+ status = "disable";
+ };
+
+ sdhci@78000400 {
+ compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
+ reg = <0x78000400 0x200>;
+ interrupts = <0 19 0x04>;
+ clocks = <&tegra_car 69>;
+ status = "disable";
+ };
+
+ sdhci@78000600 {
+ compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
+ reg = <0x78000600 0x200>;
+ interrupts = <0 31 0x04>;
+ clocks = <&tegra_car 15>;
+ status = "disable";
+ };
};
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
index 30cf1fb..7d0ce5b 100644
--- a/board/nvidia/dts/tegra114-dalmore.dts
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -12,6 +12,8 @@
i2c2 = "/i2c@7000c400";
i2c3 = "/i2c@7000c500";
i2c4 = "/i2c@7000c700";
+ sdhci0 = "/sdhci@78000600";
+ sdhci1 = "/sdhci@78000400";
};
memory {
@@ -43,4 +45,15 @@
status = "okay";
clock-frequency = <40>;
};
+
+ sdhci@78000400 {
+ cd-gpios = <&gpio 170 1>; /* gpio PV2 */
+ bus-width = <4>;
+ status = "okay";
+ };
+
+ sdhci@78000600 {
+ bus-width = <8>;
+ status = "okay";
+ };
};
--
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/4] Tegra114: Dalmore: Add SDIO3 pad config to pinctrl_config table
SDIO1 (the SD-card slot on Dalmore) needs to have its pads setup
before the MMC driver is added.
Signed-off-by: Tom Warren
---
arch/arm/include/asm/arch-tegra114/gp_padctrl.h |7 +++
board/nvidia/dalmore/dalmore.c |4
board/nvidia/dalmore/pinmux-config-dalmore.h|2 ++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra114/gp_padctrl.h
b/arch/arm/include/asm/arch-tegra114/gp_padctrl.h
index c538bdd..82c70cb 100644
--- a/arch/arm/include/asm/arch-tegra114/gp_padctrl.h
+++ b/arch/arm/include/asm/arch-tegra114/gp_padctrl.h
@@ -56,4 +56,11 @@ struct apb_misc_gp_ctlr {
u32 sdio1cfg; /* 0xEC: APB_MISC_GP_SDIO1CFGPADCTRL */
};
+/* SDMMC1/3 settings from section 27.5 of T114 TRM */
+#define SDIOCFG_DRVUP_SLWF 0
+#define SDIOCFG_DRVDN_SLWR 0
+#define SDIOCFG_DRVUP 0x24
+#define SDIOCFG_DRVDN 0x14
+#define SDIOCFG_HSM1
+
#endif /* _TEGRA114_GP_PADCTRL_H_ */
diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
index 2020a5f..7449b5b 100644
--- a/board/nvidia/dalmore/dalmore.c
+++ b/board/nvidia/dalmore/dalmore.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include "pinmux-config-dalmore.h"
/*
@@ -32,4 +33,7 @@ void pinmux_init(void)
pinmux_config_table(unused_pins_lowpower,
ARRAY_SIZE(unused_pins_lowpower));
+
+ /* Initialize any non-default pad configs (APB_MISC_GP regs) */
+ padgrp_config_table(dalmore_padctrl, ARRAY_SIZE(dalmore_padctrl));
}
diff --git a/board/nvidia/dalmore/pinmux-config-dalmore.h
b/board/nvidia/dalmore/pinmux-config-dalmore.h
index e6fe842..7af3f75 100644
--- a/board/nvidia/dalmore/pinmux-config-dalmore.h
+++ b/board/nvidia/dalmore/pinmux-config-dalmore.h
@@ -364,5 +364,7 @@ static struct pingroup_config
tegra114_pinmux_set_nontristate[] = {
static struct padctrl_config dalmore_padctrl[] = {
/* (_padgrp, _slwf, _slwr, _drvup, _drvdn, _lpmd, _schmt, _hsm) */
+ DEFAULT_PADCFG(SDIO3, SDIOCFG_DRVUP_SLWF, SDIOCFG_DRVDN_SLWR, \
+ SDIOCFG_DRVUP, SDIOCFG_DRVDN, NONE, DISABLE, ENABLE),
};
#endif /* PINMUX_CONFIG_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 0/4] Tegra114: MMC: Add MMC driver for T114/Dalmore
This patchset adds SDMMC device-tree support to the Tegra114 dts files, and enables the Tegra MMC driver on Tegra114 Dalmore. Tested on my Dalmore E1611 board, eMMC and SD-Card work fine, can load a kernel off of a SD card OK, card detect works, and the env is now stored in eMMC (end of the 2nd 'boot' sector, same as Tegra20/30). Tom Warren (4): Tegra114: fdt: Add SDMMC (sdhci) nodes for T114 boards (Dalmore for now) Tegra114: Dalmore: Add SDIO3 pad config to pinctrl_config table Tegra114: MMC: Add SD bus power-rail init routine Tegra114: MMC: Enable DT MMC driver support for Tegra114 Dalmore boards arch/arm/dts/tegra114.dtsi | 32 + arch/arm/include/asm/arch-tegra114/gp_padctrl.h |7 ++ board/nvidia/dalmore/dalmore.c | 79 +++ board/nvidia/dalmore/pinmux-config-dalmore.h|2 + board/nvidia/dts/tegra114-dalmore.dts | 13 include/configs/dalmore.h | 12 +++- 6 files changed, 144 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Tegra114: MMC: Enable DT MMC driver support for Tegra114 Dalmore boards
Tested on my Dalmore E1611 board, eMMC and SD-Card work fine, can load a kernel off of an SD card OK, card detect works, and the env is now stored in eMMC (end of the 2nd 'boot' sector, same as Tegra20/30). Signed-off-by: Tom Warren --- include/configs/dalmore.h | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/include/configs/dalmore.h b/include/configs/dalmore.h index b1a6e34..afce56a 100644 --- a/include/configs/dalmore.h +++ b/include/configs/dalmore.h @@ -50,7 +50,17 @@ #define CONFIG_SYS_I2C_SPEED 10 #define CONFIG_CMD_I2C -#define CONFIG_ENV_IS_NOWHERE +/* SD/MMC */ +#define CONFIG_MMC +#define CONFIG_GENERIC_MMC +#define CONFIG_TEGRA_MMC +#define CONFIG_CMD_MMC + +/* Environment in eMMC, at the end of 2nd "boot sector" */ +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_ENV_OFFSET ((512 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_SYS_MMC_ENV_DEV 0 +#define CONFIG_SYS_MMC_ENV_PART2 #define MACH_TYPE_DALMORE 4304/* not yet in mach-types.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 3/4] Tegra114: MMC: Add SD bus power-rail init routine
T114 requires SD bus power-rail bringup for the SDIO card on SDMMC3.
Signed-off-by: Tom Warren
---
board/nvidia/dalmore/dalmore.c | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
index 7449b5b..43f377b 100644
--- a/board/nvidia/dalmore/dalmore.c
+++ b/board/nvidia/dalmore/dalmore.c
@@ -18,6 +18,11 @@
#include
#include
#include "pinmux-config-dalmore.h"
+#include
+
+#define BAT_I2C_ADDRESS0x48/* TPS65090 charger */
+#define PMU_I2C_ADDRESS0x58/* TPS65913 PMU */
+#define MAX_I2C_RETRY 3
/*
* Routine: pinmux_init
@@ -37,3 +42,73 @@ void pinmux_init(void)
/* Initialize any non-default pad configs (APB_MISC_GP regs) */
padgrp_config_table(dalmore_padctrl, ARRAY_SIZE(dalmore_padctrl));
}
+
+#if defined(CONFIG_TEGRA_MMC)
+/*
+ * Do I2C/PMU writes to bring up SD card bus power
+ *
+ */
+void board_sdmmc_voltage_init(void)
+{
+ uchar reg, data_buffer[1];
+ int i, ret;
+
+ ret = i2c_set_bus_num(0);/* PMU is on bus 0 */
+ if (ret)
+ printf("%s: i2c_set_bus_num returned %d\n", __func__, ret);
+
+ /* TPS65913: LDO9_VOLTAGE = 3.3V */
+ data_buffer[0] = 0x31;
+ reg = 0x61;
+
+ for (i = 0; i < MAX_I2C_RETRY; ++i) {
+ ret = i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1);
+ if (ret) {
+ udelay(100);
+ printf("%s: PMU i2c_write %02X<-%02X returned %d\n",
+ __func__, reg, data_buffer[0], ret);
+ }
+ }
+
+ /* TPS65913: LDO9_CTRL = Active */
+ data_buffer[0] = 0x01;
+ reg = 0x60;
+
+ for (i = 0; i < MAX_I2C_RETRY; ++i) {
+ ret = i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1);
+ if (ret) {
+ udelay(100);
+ printf("%s: PMU i2c_write %02X<-%02X returned %d\n",
+__func__, reg, data_buffer[0], ret);
+ }
+ }
+
+ /* TPS65090: FET6_CTRL = enable output auto discharge, enable FET6 */
+ data_buffer[0] = 0x03;
+ reg = 0x14;
+
+ for (i = 0; i < MAX_I2C_RETRY; ++i) {
+ ret = i2c_write(BAT_I2C_ADDRESS, reg, 1, data_buffer, 1);
+ if (ret) {
+ udelay(100);
+ printf("%s: BAT i2c_write %02X<-%02X returned %d\n",
+ __func__, reg, data_buffer[0], ret);
+ }
+ }
+}
+
+/*
+ * Routine: pin_mux_mmc
+ * Description: setup the MMC muxes, power rails, etc.
+ */
+void pin_mux_mmc(void)
+{
+ /*
+* NOTE: We don't do mmc-specific pin muxes here.
+* They were done globally in pinmux_init().
+*/
+
+ /* Bring up the SDIO3 power rail */
+ board_sdmmc_voltage_init();
+}
+#endif /* MMC */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_mem.c: Fix warning when CONFIG_CMD_MEMTEST is not set
mem_test_quick and mem_test_alt functions are only called by
do_mem_mtest, so move them under the #ifdef
Signed-off-by: Tom Rini
---
common/cmd_mem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 53572f7..64dd76a 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -631,6 +631,7 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
#endif /* CONFIG_LOOPW */
+#ifdef CONFIG_CMD_MEMTEST
static ulong mem_test_alt(vu_long *buf, ulong start_addr, ulong end_addr,
vu_long *dummy)
{
@@ -910,7 +911,6 @@ static ulong mem_test_quick(vu_long *buf, ulong start_addr,
ulong end_addr,
return 0;
}
-#ifdef CONFIG_CMD_MEMTEST
/*
* Perform a memory test. A more complete alternative test can be
* configured using CONFIG_SYS_ALT_MEMTEST. The complete test loops until
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_mem.c: Fix warning when CONFIG_CMD_MEMTEST is not set
On Tue, Mar 12, 2013 at 12:43:39PM -0400, Tom Rini wrote: > mem_test_quick and mem_test_alt functions are only called by > do_mem_mtest, so move them under the #ifdef > > Signed-off-by: Tom Rini As I've build-tested this on arm (where a few platforms didn't have CONFIG_CMD_MTEST) and one of the PowerPC boards I also saw this on, applied to u-boot/master. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Patches pushed on 2013-03-12
Hey all, I'm going to try this, rather than replying to N different short patches. The following have been applied to u-boot/master now, thanks all! $ git log a268170..68149e9 --pretty=short commit 68149e94053d18b54a63c9a44c87f178f59a169e Author: Tom Rini cmd_mem.c: Fix warning when CONFIG_CMD_MEMTEST is not set commit d514544fe04e1b83ca2f9a1f64b885d153a2d2d5 Author: Joe Hershberger CONFIG_BOOTDELAY default should not affect runtime commit fe492cee35f0628c9d813f1799e4d49ef6b4e6d4 Author: Barak Wasserstrom common/main: move set_working_fdt_addr to enable usage of $fdtaddr commit 7d85591dda47f62e73d878d2d0ea5bd0ff2528ad Author: Wolfgang Denk env: fix "env ask" command commit 01fac041cb32408a4fc5f4617381da6ec609a8dc Author: Tom Rini cmd_fat.c: Note in fatread help about alignment requirements commit f1932b78505aa52fc29e5862ed8588a6f1bbe3ec Author: Lubomir Rintel env: Allow accessing non-mtd devices commit c8b5f556c069fcb82e0c5289189dc31f4d5d62f1 Author: Robert P. J. Day cmd_df.c: Delete this clearly unused source file. commit a22bf16bea6312ec20bc188051b54f61866fb2b1 Author: Robert P. J. Day cmd_mtdparts.c: Correct "reseting" to "resetting" in error msgs commit be2e5a09e63baaaec345c6d74744fa7401ba1ca0 Author: Joe Hershberger Allow u-boot to be silent without forcing Linux to be commit 55011539172b6ca6022e0f5581c73eaa30b57882 Author: Robert P. J. Day Fix a couple typoes in tools/env/README commit d45a6ae2419412098007798eb148c3fbf4cc530a Author: Kim Phillips tools: update checkpatch to latest upstream version commit e3e2d0095341407b939f6fef9da7c9ac29eff827 Author: Kim Phillips tools: enable more checkpatch tests by default commit 92668d68c1ccdbe41ace6cc3066e5d1e0113e719 Author: Stephen Warren cmd_part: don't print cmd name twice in help commit 6bdd9f89673e694df8a1bac6c129b21739ed8a7c Author: Andreas Bie??mann MAKEALL: fix kill_children for BSD hosts commit c08349e77c2353f23397ff60b6faec3cd0304061 Author: Gray Remlin mvsata_ide.c: Correction of typo in comments commit 7c9e89bd1f62ccd76eee8ad4c36185057576dd95 Author: Stefan Roese ppc: Remove PCIPPC2 and PCIPPC6 boards commit efd7c11404e59874d4da86d04cab4acacf77d793 Author: Andreas Bie??mann display_options:print_buffer: align ASCII print -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On 03/12/2013 10:30:40 AM, Tom Rini wrote: On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood wrote: > Why would eliminating all individual callbacks cause start/end to go > away? If that's the way the list mechanism works, the mechanism > needs fixing. Yes, that's how the mechanism works. Rather than having to declare that you expect to have a linker list of name $foo, we dynamically determine what linker lists we have and setup the linker section entry. So it would break just as hard if we happened to turn off all of the things that register callbacks. I'm not sure it's broken exactly, I think maybe we just need to say no env callback support in SPL since it's not really user editable. That's fine, but it's still a bad mechanism. -SCott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: > On 03/12/2013 10:30:40 AM, Tom Rini wrote: > >On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood wrote: > >> Why would eliminating all individual callbacks cause start/end to go > >> away? If that's the way the list mechanism works, the mechanism > >> needs fixing. > > > >Yes, that's how the mechanism works. Rather than having to > >declare that > >you expect to have a linker list of name $foo, we dynamically > >determine > >what linker lists we have and setup the linker section entry. > > So it would break just as hard if we happened to turn off all of the > things that register callbacks. > > >I'm not sure it's broken exactly, I think maybe we just need to > >say no env > >callback support in SPL since it's not really user editable. > > That's fine, but it's still a bad mechanism. Yes, the mechanism has a breaking condition on trying to reference an empty list (which is what SPL ends up with, in this case). Poking Albert and Marek in case they have any ideas, but this seems like a feature not a bug. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On 03/12/2013 12:02:56 PM, Tom Rini wrote: On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: > On 03/12/2013 10:30:40 AM, Tom Rini wrote: > >On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood wrote: > >> Why would eliminating all individual callbacks cause start/end to go > >> away? If that's the way the list mechanism works, the mechanism > >> needs fixing. > > > >Yes, that's how the mechanism works. Rather than having to > >declare that > >you expect to have a linker list of name $foo, we dynamically > >determine > >what linker lists we have and setup the linker section entry. > > So it would break just as hard if we happened to turn off all of the > things that register callbacks. > > >I'm not sure it's broken exactly, I think maybe we just need to > >say no env > >callback support in SPL since it's not really user editable. > > That's fine, but it's still a bad mechanism. Yes, the mechanism has a breaking condition on trying to reference an empty list (which is what SPL ends up with, in this case). Poking Albert and Marek in case they have any ideas, but this seems like a feature not a bug. How is it a feature? One of the main benefit of linker lists is for things to just work when things are configured in/out without needing ifdefs and such. Why should "everything configured out" be a special case requiring an ifdef? If we want to save some code by ifdeffing the listwalking code for SPL, that's a separate matter. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
Hi Scott, On Tue, 12 Mar 2013 12:06:53 -0500, Scott Wood wrote: > On 03/12/2013 12:02:56 PM, Tom Rini wrote: > > On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: > > > On 03/12/2013 10:30:40 AM, Tom Rini wrote: > > > >On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood wrote: > > > >> Why would eliminating all individual callbacks cause start/end > > to go > > > >> away? If that's the way the list mechanism works, the mechanism > > > >> needs fixing. > > > > > > > >Yes, that's how the mechanism works. Rather than having to > > > >declare that > > > >you expect to have a linker list of name $foo, we dynamically > > > >determine > > > >what linker lists we have and setup the linker section entry. > > > > > > So it would break just as hard if we happened to turn off all of the > > > things that register callbacks. > > > > > > >I'm not sure it's broken exactly, I think maybe we just need to > > > >say no env > > > >callback support in SPL since it's not really user editable. > > > > > > That's fine, but it's still a bad mechanism. > > > > Yes, the mechanism has a breaking condition on trying to reference an > > empty list (which is what SPL ends up with, in this case). Poking > > Albert and Marek in case they have any ideas, but this seems like a > > feature not a bug. > > How is it a feature? One of the main benefit of linker lists is for > things to just work when things are configured in/out without needing > ifdefs and such. Why should "everything configured out" be a special > case requiring an ifdef? > > If we want to save some code by ifdeffing the listwalking code for SPL, > that's a separate matter. Normally my reworked linker_list code should work fine with some code going through an empty list, precisely because list start and end symbols, like list entries, are generated by the compiler irrespective of one another and then whatever was generated is sorted by the linker. So an empty list ends up as two symbols at the same address (and indeed, env callbacks, in many boards, showed this pattern in the map file). > -Scott Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patches pushed on 2013-03-12
On 03/12/2013 10:48 AM, Tom Rini wrote: > Hey all, > > I'm going to try this, rather than replying to N different short > patches. The following have been applied to u-boot/master now, > thanks all! The downsides here are that: a) The contributors aren't CC'd on this mail, so they might not see it. b) People searching list archives won't see any response in the original thread, so the archives won't reflect the latest state. But, it does avoid a bunch of separate emails, it's true. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] please pull u-boot-atmel/master
Hi Andreas, On Tue, 12 Mar 2013 13:09:38 +0100, Andreas Bießmann wrote: > Dear Albert Aribaud, > > please pull the following changes into u-boot-arm/master. > > The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b: > > Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42 > -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-atmel.git master > > for you to fetch changes up to 08f0533a147ca37546a6539b43fce3916e82811a: > > ARM: sam9x5: fix ethernet pins in MII mode (2013-03-12 13:02:20 +0100) > > > Bo Shen (3): > ARM: atmel: add at91sam9g20ek_2mmc nand boot support > ARM: at91: change nand flash table > ARM: at91sam9x5: Using CPU string directly > > Jesse Gilles (1): > ARM: sam9x5: fix ethernet pins in MII mode > > Nicolas Ferre (2): > arm: at91/configs: add libfdt to configuration > arm: at91/configs: add bootz to configuration > > arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c | 30 > +++--- > arch/arm/include/asm/arch-at91/at91sam9x5.h |6 - > board/atmel/at91sam9260ek/at91sam9260ek.c|7 - > boards.cfg |1 + > include/configs/at91rm9200ek.h |3 +++ > include/configs/at91sam9260ek.h | 23 ++--- > include/configs/at91sam9261ek.h | 19 +++--- > include/configs/at91sam9263ek.h | 20 +-- > include/configs/at91sam9m10g45ek.h | 17 ++-- > include/configs/at91sam9rlek.h |3 +++ > include/configs/at91sam9x5ek.h | 12 + > 11 files changed, 79 insertions(+), 62 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra114: fdt: Move aliases from dtsi to dts file as per other Tegras
On 03/12/2013 10:08 AM, Tom Warren wrote: > All other Tegra boards have their aliase nodes in the .dts file 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] Tegra114: Dalmore: Add pad config tables/code based on pinmux code
On 03/12/2013 10:09 AM, Tom Warren wrote: > Pad config registers exist in APB_MISC_GP space, and control slew > rate, drive strengh, schmidt, high-speed, and low-power modes for > all of the pingroups in Tegra30. This builds off of the pinmux > way of constructing init tables to configure select pads (SDIOCFG, > for instance) during pinmux_init(). > > Currently, no padcfg entries exist. SDIO3CFG will be added when the > MMC driver is added as per the TRM to work with the SD-card slot on > Dalmore E1611. Much of the pinmux driver code here is common with Tegra30. We should at least file a bug to move it to a common file at some point. > diff --git a/arch/arm/include/asm/arch-tegra114/pinmux.h > b/arch/arm/include/asm/arch-tegra114/pinmux.h > +#define PGRP_SLWF_NONE -1 > +#define PGRP_SLWF_MAX3 > +#define PGRP_SLWR_NONE PGRP_SLWF_NONE > +#define PGRP_SLWR_MAXPGRP_SLWF_MAX > + > +#define PGRP_DRVUP_NONE -1 > +#define PGRP_DRVUP_MAX 127 > +#define PGRP_DRVDN_NONE PGRP_DRVUP_NONE > +#define PGRP_DRVDN_MAX PGRP_DRVUP_MAX There seems to be some mixed use of TABs/spaces there. Feel free to fix up when you apply it. Aside from that, Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2013 01:19 PM, Albert ARIBAUD wrote: > Hi Scott, > > On Tue, 12 Mar 2013 12:06:53 -0500, Scott Wood > wrote: > >> On 03/12/2013 12:02:56 PM, Tom Rini wrote: >>> On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: On 03/12/2013 10:30:40 AM, Tom Rini wrote: > On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood > wrote: >> Why would eliminating all individual callbacks cause >> start/end >>> to go >> away? If that's the way the list mechanism works, the >> mechanism needs fixing. > > Yes, that's how the mechanism works. Rather than having to > declare that you expect to have a linker list of name $foo, > we dynamically determine what linker lists we have and > setup the linker section entry. So it would break just as hard if we happened to turn off all of the things that register callbacks. > I'm not sure it's broken exactly, I think maybe we just > need to say no env callback support in SPL since it's not > really user editable. That's fine, but it's still a bad mechanism. >>> >>> Yes, the mechanism has a breaking condition on trying to >>> reference an empty list (which is what SPL ends up with, in >>> this case). Poking Albert and Marek in case they have any >>> ideas, but this seems like a feature not a bug. >> >> How is it a feature? One of the main benefit of linker lists is >> for things to just work when things are configured in/out >> without needing ifdefs and such. Why should "everything >> configured out" be a special case requiring an ifdef? >> >> If we want to save some code by ifdeffing the listwalking code >> for SPL, that's a separate matter. > > Normally my reworked linker_list code should work fine with some > code going through an empty list, precisely because list start and > end symbols, like list entries, are generated by the compiler > irrespective of one another and then whatever was generated is > sorted by the linker. So an empty list ends up as two symbols at > the same address (and indeed, env callbacks, in many boards, > showed this pattern in the map file). OK, where's the latest/greatest of this re-work? I'll see if it also solves the problem I have. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRP2o0AAoJENk4IS6UOR1WbE0QAKZDcVBQZYlWtqSOExpuYBEk mfCiRw9kyCWDQSsZo9yfqEi2CkPoexZWphqNjI0oCsAemGfh2UeK1Foqlbb3oAS5 A/R2p1zd5eNZbFx9SfUlMr09FhaYwOe1O7PQcHohsCnzU/8yXXAHGe+kz5HePtpU 3R6wZNUjcA7wXGex8o4ygvI8GUctZgDT95hlrdNihrD+TkwQdjmMG3XR2ifz/LrM I5VXq/9mT/UMvWvrtbpeLGd4VGwYZywrHBAkI0s1GjxQsjGoFfkA1HmZUdS2Hf6x BzniSGWYypnecWQPhbxetQaRmxUgGolbK2G+JOM5xDHVqUgZJ2zuEeGR9BdBqVGx slhrI7FNTy2vRmlcYTMoma0q5+gEh+0/YvACXSDNrhySB5y/9Q/pCYFQisvX2ohA n6IxTGiiQ3SYwvYeLGSx6OLneDzM08IV0nixY0lbPrWKndlPP6lkO+IwjotYcynO P8fLjXzcTLtU30VkTKchOYt+M6jqMz8eiPgsfifS5CrEll/fPCa9m+ri1/w7O5ZI zuHN32DlJzdj8DZxoyRsyvED0pUHU1ji4ECzk22ZJ+fcm2uZgLlRvZmzNwIW7zzk Xmopl2/OCTPl9BDahNxeZCE8Tg6prgBclKQgnLi2hargxPI2L1GUepm0Xm6gdz1H +IXXBJUL4VGugf8IZPKR =VwGC -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra114: Dalmore: Add pad config tables/code based on pinmux code
Stephen, > -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Tuesday, March 12, 2013 10:41 AM > To: Tom Warren > Cc: u-boot@lists.denx.de; Stephen Warren; Tom Warren > Subject: Re: [U-Boot] [PATCH] Tegra114: Dalmore: Add pad config > tables/code based on pinmux code > > On 03/12/2013 10:09 AM, Tom Warren wrote: > > Pad config registers exist in APB_MISC_GP space, and control slew > > rate, drive strengh, schmidt, high-speed, and low-power modes for all > > of the pingroups in Tegra30. This builds off of the pinmux way of > > constructing init tables to configure select pads (SDIOCFG, for > > instance) during pinmux_init(). > > > > Currently, no padcfg entries exist. SDIO3CFG will be added when the > > MMC driver is added as per the TRM to work with the SD-card slot on > > Dalmore E1611. > > Much of the pinmux driver code here is common with Tegra30. We should at > least file a bug to move it to a common file at some point. I'd planned on sending a patchset after this was reviewed/accepted, but I'll file a bug as a reminder. > > > diff --git a/arch/arm/include/asm/arch-tegra114/pinmux.h > > b/arch/arm/include/asm/arch-tegra114/pinmux.h > > > +#define PGRP_SLWF_NONE -1 > > +#define PGRP_SLWF_MAX 3 > > +#definePGRP_SLWR_NONE PGRP_SLWF_NONE > > +#define PGRP_SLWR_MAX PGRP_SLWF_MAX > > + > > +#define PGRP_DRVUP_NONE-1 > > +#define PGRP_DRVUP_MAX 127 > > +#definePGRP_DRVDN_NONE PGRP_DRVUP_NONE > > +#define PGRP_DRVDN_MAX PGRP_DRVUP_MAX > > There seems to be some mixed use of TABs/spaces there. Feel free to fix up > when you apply it. Will do. Thanks. > > Aside from that, > Reviewed-by: Stephen Warren -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Tegra114: Dalmore: Add SDIO3 pad config to pinctrl_config table
On 03/12/2013 10:17 AM, Tom Warren wrote:
> SDIO1 (the SD-card slot on Dalmore) needs to have its pads setup
> before the MMC driver is added.
> diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
> + /* Initialize any non-default pad configs (APB_MISC_GP regs) */
> + padgrp_config_table(dalmore_padctrl, ARRAY_SIZE(dalmore_padctrl));
Given that you're only using this table for the very first time here ...
> diff --git a/board/nvidia/dalmore/pinmux-config-dalmore.h
> b/board/nvidia/dalmore/pinmux-config-dalmore.h
> static struct padctrl_config dalmore_padctrl[] = {
> /* (_padgrp, _slwf, _slwr, _drvup, _drvdn, _lpmd, _schmt, _hsm) */
> + DEFAULT_PADCFG(SDIO3, SDIOCFG_DRVUP_SLWF, SDIOCFG_DRVDN_SLWR, \
> + SDIOCFG_DRVUP, SDIOCFG_DRVDN, NONE, DISABLE, ENABLE),
> };
... and it was empty before now, I'd be inclined to remove the *dalmore*
files from the Tegra114 pinmux series that implemented
padgrp_config_table(), and just do all the Dalmore-specific stuff in
this patch.
But it's not a big deal.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] Tegra114: MMC: Add SD bus power-rail init routine
On 03/12/2013 10:17 AM, Tom Warren wrote:
> T114 requires SD bus power-rail bringup for the SDIO card on SDMMC3.
> diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
> +#if defined(CONFIG_TEGRA_MMC)
It always is for Dalmore, right?
> +void board_sdmmc_voltage_init(void)
> + /* TPS65913: LDO9_VOLTAGE = 3.3V */
> + data_buffer[0] = 0x31;
> + reg = 0x61;
> +
> + for (i = 0; i < MAX_I2C_RETRY; ++i) {
> + ret = i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1);
> + if (ret) {
> + udelay(100);
> + printf("%s: PMU i2c_write %02X<-%02X returned %d\n",
> + __func__, reg, data_buffer[0], ret);
> + }
> + }
Is there actually a need to retry these transactions; is there any
evidence they're expected to fail? Hopefully the HW isn't flaky like that.
AFAIK, the kernel driver for the PMIC doesn't retry these if they fail.
Hopefully it doesn't need to start doing so.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Tegra114: MMC: Enable DT MMC driver support for Tegra114 Dalmore boards
On 03/12/2013 10:17 AM, Tom Warren wrote: > Tested on my Dalmore E1611 board, eMMC and SD-Card work fine, can load > a kernel off of an SD card OK, card detect works, and the env is now > stored in eMMC (end of the 2nd 'boot' sector, same as Tegra20/30). > diff --git a/include/configs/dalmore.h b/include/configs/dalmore.h > +/* Environment in eMMC, at the end of 2nd "boot sector" */ > +#define CONFIG_ENV_IS_IN_MMC > +#define CONFIG_ENV_OFFSET((512 * 1024) - CONFIG_ENV_SIZE) > +#define CONFIG_SYS_MMC_ENV_DEV 0 > +#define CONFIG_SYS_MMC_ENV_PART 2 I believe that Dalmore's eMMC "boot" sectors are 4MiB in size, so that'd want to be (4096 - 512) * 1024) - CONFIG_ENV_SIZE. At least, that's what "mmcinfo" told me when running our downstream U-Boot on my Dalmore. Aside from the comments I've made, the series, 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 2/4] Tegra114: Dalmore: Add SDIO3 pad config to pinctrl_config table
Stephen,
On Tue, Mar 12, 2013 at 10:52 AM, Stephen Warren wrote:
> On 03/12/2013 10:17 AM, Tom Warren wrote:
>> SDIO1 (the SD-card slot on Dalmore) needs to have its pads setup
>> before the MMC driver is added.
>
>> diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
>
>> + /* Initialize any non-default pad configs (APB_MISC_GP regs) */
>> + padgrp_config_table(dalmore_padctrl, ARRAY_SIZE(dalmore_padctrl));
>
> Given that you're only using this table for the very first time here ...
>
>> diff --git a/board/nvidia/dalmore/pinmux-config-dalmore.h
>> b/board/nvidia/dalmore/pinmux-config-dalmore.h
>
>> static struct padctrl_config dalmore_padctrl[] = {
>> /* (_padgrp, _slwf, _slwr, _drvup, _drvdn, _lpmd, _schmt, _hsm) */
>> + DEFAULT_PADCFG(SDIO3, SDIOCFG_DRVUP_SLWF, SDIOCFG_DRVDN_SLWR, \
>> + SDIOCFG_DRVUP, SDIOCFG_DRVDN, NONE, DISABLE, ENABLE),
>> };
>
> ... and it was empty before now, I'd be inclined to remove the *dalmore*
> files from the Tegra114 pinmux series that implemented
> padgrp_config_table(), and just do all the Dalmore-specific stuff in
> this patch.
>
> But it's not a big deal.
Yeah, I thought of doing that, but I already had this all
working/tested/MAKEALL'd, and have to take off early today, so I sent
the patchset as-is.
Thanks,
Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] Tegra114: MMC: Add SD bus power-rail init routine
Stephen,
On Tue, Mar 12, 2013 at 10:54 AM, Stephen Warren wrote:
> On 03/12/2013 10:17 AM, Tom Warren wrote:
>> T114 requires SD bus power-rail bringup for the SDIO card on SDMMC3.
>
>> diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
>
>> +#if defined(CONFIG_TEGRA_MMC)
>
> It always is for Dalmore, right?
Yep, but I always like to provide the means to disable a feature
(whether it be SPI, or MMC, or USB) so you can build a stripped-down
or de-featured version for testing.
Having said that, I haven't tested lately whether T114 (or T20 or T30)
will build OK w/MMC undefined/removed.
>
>> +void board_sdmmc_voltage_init(void)
>
>> + /* TPS65913: LDO9_VOLTAGE = 3.3V */
>> + data_buffer[0] = 0x31;
>> + reg = 0x61;
>> +
>> + for (i = 0; i < MAX_I2C_RETRY; ++i) {
>> + ret = i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1);
>> + if (ret) {
>> + udelay(100);
>> + printf("%s: PMU i2c_write %02X<-%02X returned %d\n",
>> + __func__, reg, data_buffer[0], ret);
>> + }
>> + }
>
> Is there actually a need to retry these transactions; is there any
> evidence they're expected to fail? Hopefully the HW isn't flaky like that.
This is how it was done in the original internal U-Boot code I got the
I2C writes from (also done this way on T30). I did add the printf
error writes, though, when I was having a PWR_I2C/I2C5/dev 0 problem.
I think Whistler does something similar.
>
> AFAIK, the kernel driver for the PMIC doesn't retry these if they fail.
> Hopefully it doesn't need to start doing so.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] Tegra114: MMC: Add SD bus power-rail init routine
On 03/12/2013 12:05 PM, Tom Warren wrote:
> Stephen,
>
> On Tue, Mar 12, 2013 at 10:54 AM, Stephen Warren
> wrote:
>> On 03/12/2013 10:17 AM, Tom Warren wrote:
>>> T114 requires SD bus power-rail bringup for the SDIO card on SDMMC3.
>>
>>> diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
>>> +void board_sdmmc_voltage_init(void)
>>
>>> + /* TPS65913: LDO9_VOLTAGE = 3.3V */
>>> + data_buffer[0] = 0x31;
>>> + reg = 0x61;
>>> +
>>> + for (i = 0; i < MAX_I2C_RETRY; ++i) {
>>> + ret = i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1);
>>> + if (ret) {
>>> + udelay(100);
>>> + printf("%s: PMU i2c_write %02X<-%02X returned %d\n",
>>> + __func__, reg, data_buffer[0], ret);
>>> + }
>>> + }
>>
>> Is there actually a need to retry these transactions; is there any
>> evidence they're expected to fail? Hopefully the HW isn't flaky like that.
>
> This is how it was done in the original internal U-Boot code I got the
> I2C writes from (also done this way on T30). I did add the printf
> error writes, though, when I was having a PWR_I2C/I2C5/dev 0 problem.
> I think Whistler does something similar.
Whistler doesn't do any retries. That's why I was surprised by this. I
would assert we should remove the retry logic unless there's a specific
need for it, in which case we need to port it to the kernel too.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] env_callback: Mark find_env_callback as static
Hi Tom, On Tue, Mar 12, 2013 at 11:16 AM, Tom Rini wrote: > This is not called outside of env_callback.c so mark static, remove from > > > Cc: Joe Hershberger > Signed-off-by: Tom Rini > --- > http://lists.denx.de/mailman/listinfo/u-boot Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-i2c
Hello Tom, please pull from u-boot-i2c: The following changes since commit 68149e94053d18b54a63c9a44c87f178f59a169e: cmd_mem.c: Fix warning when CONFIG_CMD_MEMTEST is not set (2013-03-12 12:43:31 -0400) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to cb466c056a878dcae27b76eb86a124e0c5203e7a: I2C: S3C24X0: Bug fixes in i2c_transfer (2013-03-12 19:33:11 +0100) Rajeshwari Shinde (2): I2C: S3C24X0: Remove the dead code I2C: S3C24X0: Bug fixes in i2c_transfer drivers/i2c/s3c24x0_i2c.c | 21 ++--- 1 Datei geändert, 6 Zeilen hinzugefügt(+), 15 Zeilen entfernt(-) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SPL: Fix build of CONFIG_SPL_NET_SUPPORT
Hi Tom, On Tue, Mar 12, 2013 at 11:16 AM, Tom Rini wrote: > With CONFIG_SPL_NET_SUPPORT set we bring in most of the environment > related code. This in turn means that while we discard the callback > saftey checks in the environment, we had still needed their > __start/__end linker symbols. In most cases this had been working > because we generated u-boot.lst for the main U-Boot build prior to > creating u-boot-spl.lds. With a sufficiently large machine this is not > the case and exposed this latent bug which is that as of f8cfcf1 there > are no callback linker entries so not __start/__end symbol was > generated. > > As the environment is not user modifiable in this particular run-time > (for any variable that had a callback associated with it) we simply > provide an empty env_callback_init in SPL. > > Cc: Joe Hershberger > Cc: Scott Wood > Tested-by: Tom Rini (Ran with am335x_evm_usbspl build) > Signed-off-by: Tom Rini > --- Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
On Mon, 11 Mar 2013 17:53:37 -0700 Simon Glass wrote: > On Mon, Mar 11, 2013 at 5:44 PM, Kim Phillips > wrote: > > On Thu, 7 Mar 2013 19:11:16 -0800 > > Simon Glass wrote: > > > OK so let's look at adding the hash_register() idea. But not in this > > > series. That should come later in a revision of the hash.c > > > infrastructure, since it needs to adjust sha1, sha255 and crc32. > > > > I don't understand: why not s/ace/hw/g in common/ and include/ on > > this patchseries, then move straight to the device model at some > > later point? It's a compromise, but it works fine for the time > > being - other vendors can add their hash support without having to > > touch common code, code size is not affected, etc. > > Fine with me. The effect is the same - this is just a rename. Should not be > done in the ace.h file though, only in the naming of the functions called > from hash.c, right? the ace_sha_hash_digest() declaration should be removed from ace_sha.h (it's only needed by the driver, which is ok without it being there). ACE_SHA_TYPE_SHA* definitions belong in the driver too - they're ACE h/w-specific. Rename the filename ace_sha.h to hw_sha.h, and all remaining ACE references contained in it. If the 'hw_' nomenclature is undesired, other possibilities are 'accel_', 'hw_accel_', 'alt_'... Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] power: twl6035: cleanup register access API
commit 21144298 (power: twl6035: add palmas PMIC support)
introduced twl6035_i2c_[read|write]_u8
Then, commit dd23e59d (omap5: pbias ldo9 turn on)
introduced palmas_[read|write]_u8
for precisely the same access function. TWL6035 belongs to
the palmas family, so instead of having an palmas API,
we could use twl6035 API instead (which is used elsewhere
as well).
Account for the parameter change while doing the change and
remove palmas register accessors.
Cc: Balaji T K
Cc: Sricharan R
Reported-by: Ruchika Kharwar
Signed-off-by: Nishanth Menon
---
drivers/power/twl6035.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/power/twl6035.c b/drivers/power/twl6035.c
index d3de698..b0b2406 100644
--- a/drivers/power/twl6035.c
+++ b/drivers/power/twl6035.c
@@ -34,17 +34,6 @@ int twl6035_i2c_read_u8(u8 chip_no, u8 *val, u8 reg)
return i2c_read(chip_no, reg, 1, val, 1);
}
-/* To align with i2c mw/mr address, reg, val command syntax */
-static inline int palmas_write_u8(u8 chip_no, u8 reg, u8 val)
-{
- return i2c_write(chip_no, reg, 1, &val, 1);
-}
-
-static inline int palmas_read_u8(u8 chip_no, u8 reg, u8 *val)
-{
- return i2c_read(chip_no, reg, 1, val, 1);
-}
-
void twl6035_init_settings(void)
{
return;
@@ -57,7 +46,7 @@ int twl6035_mmc1_poweron_ldo(void)
/* set LDO9 TWL6035 to 3V */
val = 0x2b; /* (3 -.9)*28 +1 */
- if (palmas_write_u8(0x48, LDO9_VOLTAGE, val)) {
+ if (twl6035_i2c_write_u8(0x48, val, LDO9_VOLTAGE)) {
printf("twl6035: could not set LDO9 voltage.\n");
return 1;
}
@@ -65,7 +54,7 @@ int twl6035_mmc1_poweron_ldo(void)
/* TURN ON LDO9 */
val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
- if (palmas_write_u8(0x48, LDO9_CTRL, val)) {
+ if (twl6035_i2c_write_u8(0x48, val, LDO9_CTRL)) {
printf("twl6035: could not turn on LDO9.\n");
return 1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
Hi Tom, On Tue, 12 Mar 2013 13:47:33 -0400, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/12/2013 01:19 PM, Albert ARIBAUD wrote: > > Hi Scott, > > > > On Tue, 12 Mar 2013 12:06:53 -0500, Scott Wood > > wrote: > > > >> On 03/12/2013 12:02:56 PM, Tom Rini wrote: > >>> On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: > On 03/12/2013 10:30:40 AM, Tom Rini wrote: > > On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood > > wrote: > >> Why would eliminating all individual callbacks cause > >> start/end > >>> to go > >> away? If that's the way the list mechanism works, the > >> mechanism needs fixing. > > > > Yes, that's how the mechanism works. Rather than having to > > declare that you expect to have a linker list of name $foo, > > we dynamically determine what linker lists we have and > > setup the linker section entry. > > So it would break just as hard if we happened to turn off > all of the things that register callbacks. > > > I'm not sure it's broken exactly, I think maybe we just > > need to say no env callback support in SPL since it's not > > really user editable. > > That's fine, but it's still a bad mechanism. > >>> > >>> Yes, the mechanism has a breaking condition on trying to > >>> reference an empty list (which is what SPL ends up with, in > >>> this case). Poking Albert and Marek in case they have any > >>> ideas, but this seems like a feature not a bug. > >> > >> How is it a feature? One of the main benefit of linker lists is > >> for things to just work when things are configured in/out > >> without needing ifdefs and such. Why should "everything > >> configured out" be a special case requiring an ifdef? > >> > >> If we want to save some code by ifdeffing the listwalking code > >> for SPL, that's a separate matter. > > > > Normally my reworked linker_list code should work fine with some > > code going through an empty list, precisely because list start and > > end symbols, like list entries, are generated by the compiler > > irrespective of one another and then whatever was generated is > > sorted by the linker. So an empty list ends up as two symbols at > > the same address (and indeed, env callbacks, in many boards, > > showed this pattern in the map file). > > OK, where's the latest/greatest of this re-work? I'll see if it also > solves the problem I have. In patchwork (assigned to me, and soon to be applied on u-boot-arm if this works for you): http://patchwork.ozlabs.org/patch/222904/ http://patchwork.ozlabs.org/patch/222905/ http://patchwork.ozlabs.org/patch/222906/ http://patchwork.ozlabs.org/patch/222908/ (http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/152754/focus=154634) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Introduced btrfs file-system with btrload command
Hi Adnan,
On Tue, Mar 12, 2013 at 7:53 AM, Adnan Ali wrote:
> Hi
>
>
> On 12/03/13 14:15, Simon Glass wrote:
>>
>> Hi Adnan,
>>
>> On Mon, Mar 11, 2013 at 6:18 AM, Adnan Ali
>> wrote:
>>>
>>> Introduces btrfs file-system to read file from
>>> volume/sub-volumes with btrload command. This
>>> implementation has read-only support.
>>> This btrfs implementation is based on syslinux btrfs
>>> code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d.
>>>
>>> v5: merged with master.
>>> v4: btrls command added.
>>> v3: patch re-formated.
>>> v2: patch error removed.
>>>
>>> Signed-off-by: Adnan Ali
>>> ---
>>> Makefile |1 +
>>> common/Makefile|1 +
>>> common/cmd_btr.c | 65 +++
>>> fs/btrfs/Makefile | 51 ++
>>> fs/btrfs/btrfs.c | 1348
>>>
>>> fs/btrfs/crc32_c.c | 54 ++
>>> fs/fs.c| 10 +
>>> include/btrfs.h| 416 ++
>>> include/config_fallbacks.h |4 +
>>> include/fs.h |1 +
>>> 10 files changed, 1951 insertions(+)
>>> create mode 100644 common/cmd_btr.c
>>> create mode 100644 fs/btrfs/Makefile
>>> create mode 100644 fs/btrfs/btrfs.c
>>> create mode 100644 fs/btrfs/crc32_c.c
>>> create mode 100644 include/btrfs.h
>>>
>> I have ignored the code before this point in btrfs.c since it is
>> imported and you want to keep the code style as is, but if you don't
>> mind I will make a few comments after that point>
>
> Here are my comments
>
>>
>>> +struct btrfs_info fs;
>>> +
>>> +/*
>>> + * mount btrfs file-system
>>> + */
>>> +int btrfs_probe(block_dev_desc_t *rbdd, disk_partition_t *info)
>>> +{
>>> +btrfs_block_dev_desc = rbdd;
>>> +part_info = info;
>>> +btr_part_offset = info->start;
>>> + if (btrfs_fs_init(&fs) < 0 ) {
>>> + debug("btrfs probe failed\n");
>>> + return -1;
>>> + }
>>
>> You should use tabs for intend (some of this bit uses spaces, some uses
>> tabs).
>
>Some how i missed will check it again. Ack
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Read file data
>>> + */
>>> +int btrfs_read_file(const char *filename, void *buf, int offset, int
>>> len)
>>> +{
>>> + int file_len=0;
>>> +int len_read;
>>> +struct com32_filedata filedata;
>>> +int handle;
>>> +if (offset != 0) {
>>> +debug("** Cannot support non-zero offset **\n");
>>> +return -1;
>>> +}
>>> +
>>> +handle=btrfs_open_file(filename, &filedata);
>>> +if (handle < 0) {
>>> +debug("** File not found %s Invalid handle**\n",
>>> filename);
>>> +return -1;
>>> +}
>>> +
>>> +/*file handle is valid get the size of the file*/
>>> +len = filedata.size;
>>> +if (len == 0)
>>> +len = file_len;
>>> +
>>> +len_read = getfssec(&filedata, (char *)buf);
>>> +if (len_read != len) {
>>> +debug("** Unable to read file %s **\n", filename);
>>> +return -1;
>>> +}
>>> +
>>> +return len_read;
>>> +
>>> +}
>>> +
>>> +/*
>>> + * Show directory entries
>>> + */
>>> +char btrfs_ls(char *dirname)
>>> +{
>>> + struct btrfs_dirent *de;
>>> + struct _DIR_ *dir;
>>> +
>>> + if(*dirname == '/' && *(dirname+1) == 0)
>>> + *dirname = '.';
>>> +
>>> + dir = opendir(dirname);
>>> + if (dir == NULL)
>>> +return -1;
>>> +
>>> + while ((de = readdir(dir)) != NULL)
>>> +;
>>
>> This doesn't seem to print anything.
>
> readdir->btrfs_read, prints contents on media.
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * umount btrfs file-system
>>> + */
>>> +void btrfs_close(void)
>>> +{
>>> +
>>
>> Remove blank line
>
>Ack
>
>>
>>> +}
>>> diff --git a/fs/btrfs/crc32_c.c b/fs/btrfs/crc32_c.c
>>> new file mode 100644
>>> index 000..78d0447
>>> --- /dev/null
>>> +++ b/fs/btrfs/crc32_c.c
>>> @@ -0,0 +1,54 @@
>>> +/*
>>> + * Copied from Linux kernel crypto/crc32c.c
>>> + * Copyright (c) 2004 Cisco Systems, Inc.
>>> + * Copyright (c) 2008 Herbert Xu
>>> + *
>>> + * 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 is the CRC-32C table
>>> + * Generated with:
>>> + * width = 32 bits
>>> + * poly = 0x1EDC6F41
>>> + * reflect input bytes = true
>>> + * reflect output bytes = true
>>> + */
>>
>> Old comment?
>
>this crc was part of port
>
>>
>>> +
>>> +/*
>>> + * Steps through buffer one byte at at time, calculates reflected
>>> + * crc using table.
>>> + */
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
Re: [U-Boot] [PATCH v6] Exynos5: Pinmux: Add fdt for pinmux
On Sun, Mar 10, 2013 at 11:53 PM, Akshay Saraswat wrote: > This patch adds fdt nodes for peripherals which require > pin muxing and configuration. Device tree bindings for pinctrl > are kept same as required for Linux. Existing pinmux code > modified to retrieve gpio range and function related info from fdt. > > Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature > URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html > > Signed-off-by: Akshay Saraswat Acked-by: Simon Glass > --- > Changes since v1: > - Device tree bindings changed to linux style. > - Added documentation for samsung pinctrl. > > Changes since v2: > - Rebased as per new version of GPIO numbering patch-set. > > Changes since v3: > - Added comments to reduce ambiguity and increase readability. > - Fixed few other nits. > > Changes since v4: > - Added support for reading peripheral pinctrl subnode names from > preipheral's node instead of hard coding. > > Changes since v5: > - Changed compatible strings for uart, mshc, i2s and pinctrl to make > them similar to kernel in lib/fdtdec.c. > - Changed "samsung,pinctrl-names" to "pinctrl-names" in > exynos5250.dtsi > to make it same as kernel. > - Added explanation for "pinctrl-names" in bindings documentation > samsung-pinctrl.txt. > > arch/arm/cpu/armv7/exynos/pinmux.c | 357 +++--- > arch/arm/dts/exynos5250-pinctrl.dtsi | 675 > +++ > arch/arm/dts/exynos5250.dtsi | 88 > board/samsung/dts/exynos5250-smdk5250.dts| 11 + > doc/device-tree-bindings/samsung-pinctrl.txt | 258 ++ > include/fdtdec.h | 4 + > lib/fdtdec.c | 4 + > 7 files changed, 1232 insertions(+), 165 deletions(-) > create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi > create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
Hi Kim, On Tue, Mar 12, 2013 at 12:32 PM, Kim Phillips wrote: > On Mon, 11 Mar 2013 17:53:37 -0700 > Simon Glass wrote: > >> On Mon, Mar 11, 2013 at 5:44 PM, Kim Phillips >> wrote: >> > On Thu, 7 Mar 2013 19:11:16 -0800 >> > Simon Glass wrote: >> > > OK so let's look at adding the hash_register() idea. But not in this >> > > series. That should come later in a revision of the hash.c >> > > infrastructure, since it needs to adjust sha1, sha255 and crc32. >> > >> > I don't understand: why not s/ace/hw/g in common/ and include/ on >> > this patchseries, then move straight to the device model at some >> > later point? It's a compromise, but it works fine for the time >> > being - other vendors can add their hash support without having to >> > touch common code, code size is not affected, etc. >> >> Fine with me. The effect is the same - this is just a rename. Should not be >> done in the ace.h file though, only in the naming of the functions called >> from hash.c, right? > > the ace_sha_hash_digest() declaration should be removed from > ace_sha.h (it's only needed by the driver, which is ok without it > being there). ACE_SHA_TYPE_SHA* definitions belong in the driver > too - they're ACE h/w-specific. Rename the filename ace_sha.h to > hw_sha.h, and all remaining ACE references contained in it. Maybe I misunderstand - are you saying that that all the ACE symbols in the driver should be renamed to hw? That doesn't make a lot of sense to me - why is this needed? > > If the 'hw_' nomenclature is undesired, other possibilities are > 'accel_', 'hw_accel_', 'alt_'... > > Kim > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] C99 and dynamic arrays
On Tue, Mar 12, 2013 at 7:22 PM, Simon Glass wrote: > Hi, > > Given that we seem to allow C99 features in U-Boot I wonder if it > would be OK to use dynamic arrays in SPL? > > I am trying to replace: > > ptr = malloc(size); > > with: > > char ptr[size]; > > to avoid use of malloc in SPL. Can I assume that is permitted? Without knowing the underlying mechanics of how that works, "maybe". And we already have malloc in SPL thanks to FAT support. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
On Tue, 12 Mar 2013 16:40:38 -0700
Simon Glass wrote:
> Hi Kim,
>
> On Tue, Mar 12, 2013 at 12:32 PM, Kim Phillips
> wrote:
> > On Mon, 11 Mar 2013 17:53:37 -0700
> > Simon Glass wrote:
> >
> >> On Mon, Mar 11, 2013 at 5:44 PM, Kim Phillips
> >> wrote:
> >> > On Thu, 7 Mar 2013 19:11:16 -0800
> >> > Simon Glass wrote:
> >> > > OK so let's look at adding the hash_register() idea. But not in this
> >> > > series. That should come later in a revision of the hash.c
> >> > > infrastructure, since it needs to adjust sha1, sha255 and crc32.
> >> >
> >> > I don't understand: why not s/ace/hw/g in common/ and include/ on
> >> > this patchseries, then move straight to the device model at some
> >> > later point? It's a compromise, but it works fine for the time
> >> > being - other vendors can add their hash support without having to
> >> > touch common code, code size is not affected, etc.
> >>
> >> Fine with me. The effect is the same - this is just a rename. Should not be
> >> done in the ace.h file though, only in the naming of the functions called
> >> from hash.c, right?
> >
> > the ace_sha_hash_digest() declaration should be removed from
> > ace_sha.h (it's only needed by the driver, which is ok without it
> > being there). ACE_SHA_TYPE_SHA* definitions belong in the driver
> > too - they're ACE h/w-specific. Rename the filename ace_sha.h to
> > hw_sha.h, and all remaining ACE references contained in it.
>
> Maybe I misunderstand - are you saying that that all the ACE symbols
> in the driver should be renamed to hw? That doesn't make a lot of
> sense to me - why is this needed?
no, only the entry points to the driver should be renamed - they are
currently called ace_sha{1,256}(). The include/ace_sha.h file as it
is currently can be made completely h/w agnostic.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] video: exynos_fb: Remove callbacks from the driver
Hi, On Fri, Feb 22, 2013 at 1:52 AM, Ajay Kumar wrote: > Replaced the functionality of callbacks by using a standard set of functions. > Instead of implementing and hooking up a callback, put the same code in one of > the standard set of functions by overriding it. > > This patch is tested only on SMDK5250. > For Trats and universal_c210 board, it is only compile tested. Can I ask please why you are doing this? It seems like the existing interface is better. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
Hi Kim,
On Tue, Mar 12, 2013 at 5:03 PM, Kim Phillips
wrote:
> On Tue, 12 Mar 2013 16:40:38 -0700
> Simon Glass wrote:
>
>> Hi Kim,
>>
>> On Tue, Mar 12, 2013 at 12:32 PM, Kim Phillips
>> wrote:
>> > On Mon, 11 Mar 2013 17:53:37 -0700
>> > Simon Glass wrote:
>> >
>> >> On Mon, Mar 11, 2013 at 5:44 PM, Kim Phillips
>> >> wrote:
>> >> > On Thu, 7 Mar 2013 19:11:16 -0800
>> >> > Simon Glass wrote:
>> >> > > OK so let's look at adding the hash_register() idea. But not in this
>> >> > > series. That should come later in a revision of the hash.c
>> >> > > infrastructure, since it needs to adjust sha1, sha255 and crc32.
>> >> >
>> >> > I don't understand: why not s/ace/hw/g in common/ and include/ on
>> >> > this patchseries, then move straight to the device model at some
>> >> > later point? It's a compromise, but it works fine for the time
>> >> > being - other vendors can add their hash support without having to
>> >> > touch common code, code size is not affected, etc.
>> >>
>> >> Fine with me. The effect is the same - this is just a rename. Should not
>> >> be
>> >> done in the ace.h file though, only in the naming of the functions called
>> >> from hash.c, right?
>> >
>> > the ace_sha_hash_digest() declaration should be removed from
>> > ace_sha.h (it's only needed by the driver, which is ok without it
>> > being there). ACE_SHA_TYPE_SHA* definitions belong in the driver
>> > too - they're ACE h/w-specific. Rename the filename ace_sha.h to
>> > hw_sha.h, and all remaining ACE references contained in it.
>>
>> Maybe I misunderstand - are you saying that that all the ACE symbols
>> in the driver should be renamed to hw? That doesn't make a lot of
>> sense to me - why is this needed?
>
> no, only the entry points to the driver should be renamed - they are
> currently called ace_sha{1,256}(). The include/ace_sha.h file as it
> is currently can be made completely h/w agnostic.
OK, that sounds better.
Regards,
Simon
>
> Kim
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] DOS_PBR block type is also valid dos block type.
Hi Stephen, On Tue, Mar 12, 2013 at 11:09 AM, Stephen Warren wrote: > On 03/11/2013 08:57 PM, Sonic Zhang wrote: >> Hi Stephen, >> >> >> On Tue, Mar 12, 2013 at 1:28 AM, Stephen Warren >> wrote: >>> On 03/11/2013 03:56 AM, sonic@gmail.com wrote: From: Sonic Zhang - Should return 0 for both DOS_MBR and DOS_PBR block types in test_part_dos(). >>> >>> What problem does this solve? >>> >>> I don't believe this change is correct. The purpose of test_part_dos() >>> is to determine whether a block device contains an MS-DOS partition table. >>> >>> Such a partition table is present in an MBR, but not a PBR. A PBR >>> contains a *FAT file-system, and does not include a partition table. >> >> The SD card formated by windows 7 into one FAT partition can't be >> initialized correct in u-boot function init_part() after you reuses >> function test_block_type() in function test_part_dos(). So, files on >> that partition can't be displayed when run command "fatls mmc 0". >> >> The only difference in your change is to mark dos partition with flag >> DOS_PBR invalid. > > I did test a raw FAT filesystem on an SD card without any partition > table, and it worked fine. Admittedly I created the layout/filesystem > with Linux rather than Windows, but I don't think the layout would be > any difference. What if you "fatls mmc 0:0" rather than "fatls mmc 0"; > does that make any difference? "fatls mmc 0:0" makes no difference. Regards, Sonic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hang issue when applied patch "spi: Add SPI flash test"
Hi Mingkai,
On Wed, Mar 6, 2013 at 2:15 AM, Hu Mingkai-B21284 wrote:
>
>
>> -Original Message-
>> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> Sent: Monday, March 04, 2013 9:59 PM
>> To: Hu Mingkai-B21284
>> Cc: U-Boot Mailing List
>> Subject: Re: Hang issue when applied patch "spi: Add SPI flash test"
>>
>> +U-Boot mailing list
>>
>> Hi Mingkai,
>>
>> On Mon, Mar 4, 2013 at 12:48 AM, Hu Mingkai-B21284
>> wrote:
>> > Hi Simon,
>> >
>> >
>> >
>> > After applied following patch, read from SPI flash will hang on
>> > p2041rdb board.
>> >
>> >
>> >
>> > From 2400727318a0a1ecf15a9deae85b0719c4c47aba Mon Sep 17 00:00:00 2001
>> >
>> > From: Simon Glass
>> >
>> > Date: Mon, 8 Oct 2012 13:16:02 +
>> >
>> > Subject: [PATCH] spi: Add SPI flash test
>> >
>> >
>> >
>> > It is useful to have a basic SPI flash test, which tests that the SPI
>> > chip,
>> >
>> > the SPI bus and the driver are behaving.
>> >
>> >
>> >
>> > This test erases part of the flash, writes data and reads it back as a
>> >
>> > sanity check that all is well.
>> >
>> >
>> >
>> > Use CONFIG_SF_TEST to enable it.
>> >
>> >
>> >
>> > Signed-off-by: Simon Glass s...@chromium.org
>> >
>> >
>> >
>> > If included the div64 header file after common.h, it doesn't hang
>> anymore.
>> >
>> > Do you have any suggestions?
>> >
>> >
>> >
>> > +#include
>> >
>> > #include
>> >
>> >
>>
>> Well I think div64.h should be after common, so it is fine to move it.
>> I am not sure why that causes a hang though - do you have more details
>> - e.g. what did you do when it hangs, what is console output? Also do you
>> define CONFIG_CMD_SF_TEST?
>>
> I used "sf read 100 0 1" command to read from SPI flash. I didn't
> Define CONFIG_CMD_SF_TEST.
>
> The header file div64.h includes which defines the phys_addr_t
> according to the macro CONFIG_PHYS_64BIT, while the macro CONFIG_PHYS_64BIT
> is included in common.h, so the phys_addr_t in file cmd_sf.c will be defined
> as
> "unsigned long" and will be defined as "unsigned long long" in other files
> when CONFIG_PHYS_64BIT is defined.
>
> In this case, when we pass 32bit address to map_physmem, the address will be
> put into higher 32 bit, and lower 32bit is a wild value owning to call
> conventions.
>
> static int do_spi_flash_read_write(int argc, char * const argv[])
> {
> map_physmem(addr, len, MAP_WRBACK);
> }
>
> For example, when we use "sf read 0x100 0 1000" to read SPI flash, the
> address
> 0x100 will be passed into map_physmem, but we get address
> 0x1a in
> function addrmap_phys_to_virt. Obviously the value 0x1a is out of
> the
> range of address_map which will return memory address 0x for memory
> map.
>
> The interrupt vectors in U-Boot are put at address 0x100/0x200/0x300 etc, so
> sf read
> command will overlap the interrupt vectors which will cause unexpected
> behavior.
>
> I will submit a patch for this later.
Thank you for the details explanation. I look forward to the patch.
Regards,
Simon
>
> Thanks,
> Mingkai
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: twl6035: cleanup register access API
On Wednesday 13 March 2013 02:09 AM, Nishanth Menon wrote:
> commit 21144298 (power: twl6035: add palmas PMIC support)
> introduced twl6035_i2c_[read|write]_u8
> Then, commit dd23e59d (omap5: pbias ldo9 turn on)
> introduced palmas_[read|write]_u8
> for precisely the same access function. TWL6035 belongs to
> the palmas family, so instead of having an palmas API,
> we could use twl6035 API instead (which is used elsewhere
> as well).
>
> Account for the parameter change while doing the change and
> remove palmas register accessors.
>
> Cc: Balaji T K
> Cc: Sricharan R
> Reported-by: Ruchika Kharwar
> Signed-off-by: Nishanth Menon
> ---
> drivers/power/twl6035.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/twl6035.c b/drivers/power/twl6035.c
> index d3de698..b0b2406 100644
> --- a/drivers/power/twl6035.c
> +++ b/drivers/power/twl6035.c
> @@ -34,17 +34,6 @@ int twl6035_i2c_read_u8(u8 chip_no, u8 *val, u8 reg)
> return i2c_read(chip_no, reg, 1, val, 1);
> }
>
> -/* To align with i2c mw/mr address, reg, val command syntax */
> -static inline int palmas_write_u8(u8 chip_no, u8 reg, u8 val)
> -{
> - return i2c_write(chip_no, reg, 1, &val, 1);
> -}
> -
> -static inline int palmas_read_u8(u8 chip_no, u8 reg, u8 *val)
> -{
> - return i2c_read(chip_no, reg, 1, val, 1);
> -}
> -
> void twl6035_init_settings(void)
> {
> return;
> @@ -57,7 +46,7 @@ int twl6035_mmc1_poweron_ldo(void)
> /* set LDO9 TWL6035 to 3V */
> val = 0x2b; /* (3 -.9)*28 +1 */
>
> - if (palmas_write_u8(0x48, LDO9_VOLTAGE, val)) {
> + if (twl6035_i2c_write_u8(0x48, val, LDO9_VOLTAGE)) {
> printf("twl6035: could not set LDO9 voltage.\n");
> return 1;
> }
> @@ -65,7 +54,7 @@ int twl6035_mmc1_poweron_ldo(void)
> /* TURN ON LDO9 */
> val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
>
> - if (palmas_write_u8(0x48, LDO9_CTRL, val)) {
> + if (twl6035_i2c_write_u8(0x48, val, LDO9_CTRL)) {
> printf("twl6035: could not turn on LDO9.\n");
> return 1;
> }
Reviewed-by: R Sricharan
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Make tzpc initialization common for exynos4 and exynos5
Hi Inder, On 6 March 2013 11:11, Inderpal Singh wrote: > The first patch moves the tzpc_init file from smdk5250 to armv7/exynos. > The second makes tzpc_init common for exynos4 and exynos5. And the third > makes necessary changes to exynos4 based origen and smdkv310 boards. > > The patchset has been tested on exynos4 based origen and exynos5 based > Arndale board. > > Inderpal Singh (3): > exynos: move tzpc_init to armv7/exynos > exynos: update tzpc_init to make it common for exynos4 and exynos5 > exynos: Update origen and smdkv310 to use common tzpc_init > > arch/arm/cpu/armv7/exynos/Makefile |2 +- > arch/arm/cpu/armv7/exynos/tzpc_init.c | 57 + > arch/arm/cpu/armv7/s5p-common/Makefile |2 ++ > arch/arm/include/asm/arch-exynos/tzpc.h | 28 +++ > board/samsung/origen/lowlevel_init.S| 44 ++- > board/samsung/origen/origen_setup.h | 25 - > board/samsung/smdk5250/Makefile |1 - > board/samsung/smdk5250/lowlevel_init.S |2 ++ > board/samsung/smdk5250/setup.h | 25 - > board/samsung/smdk5250/tzpc_init.c | 48 - > board/samsung/smdkv310/lowlevel_init.S | 60 > ++- > include/configs/exynos5250-dt.h |2 -- > include/configs/origen.h|2 ++ > include/configs/smdkv310.h |2 ++ > spl/Makefile|4 +++ > 15 files changed, 102 insertions(+), 202 deletions(-) > create mode 100644 arch/arm/cpu/armv7/exynos/tzpc_init.c > delete mode 100644 board/samsung/smdk5250/tzpc_init.c > > -- > 1.7.9.5 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Seems good to me. Acked-by: Chander Kashyap -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] integrator: pass a Device Tree by default
This, enabled the FDT library for the Integrators, updates the Integrator/CP default command to load and pass a Device Tree when booting the kernel from the on-board ethernet, define same environment for the Integrator/AP and move the load address around to something even. Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Replace $servip by $serverip as is custom in other configs. ChangeLog v1->v2: - Skip definition of $loadaddr, rely on CONFIG_LOAD_ADDR instead. --- include/configs/integrator-common.h | 3 ++- include/configs/integratorap.h | 7 +-- include/configs/integratorcp.h | 9 ++--- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/include/configs/integrator-common.h b/include/configs/integrator-common.h index 564b418..f4a182c 100644 --- a/include/configs/integrator-common.h +++ b/include/configs/integrator-common.h @@ -30,7 +30,7 @@ #define CONFIG_SYS_MEMTEST_END 0x1000 #define CONFIG_SYS_HZ 1000 #define CONFIG_SYS_TIMERBASE 0x13000100 /* Timer1 */ -#define CONFIG_SYS_LOAD_ADDR 0x7fc0 /* default load address */ +#define CONFIG_SYS_LOAD_ADDR 0x800 /* default load address */ #define CONFIG_SYS_LONGHELP #define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size*/ @@ -41,6 +41,7 @@ #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_OF_LIBFDT /* enable passing a Device Tree */ #define CONFIG_MISC_INIT_R /* call misc_init_r during start up */ /* diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index c6907b5..6aaafba 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -62,9 +62,12 @@ */ #include -#define CONFIG_BOOTDELAY 2 +#define CONFIG_BOOTDELAY 0 #define CONFIG_BOOTARGS"root=/dev/mtdblock0 console=ttyAM0 console=tty" -#define CONFIG_BOOTCOMMAND "" +#define CONFIG_BOOTCOMMAND "setenv serverip 192.168.1.100 ; " \ + "setenv fdtaddr 0x0080 ; " \ + "echo \"$loadaddr = $loadaddr, $fdtaddr=$fdtaddr\" ; " \ + "echo \"load binaries then: bootm $loadaddr - $fdtaddr\"" /* * Miscellaneous configurable options diff --git a/include/configs/integratorcp.h b/include/configs/integratorcp.h index ca02a6f..0844d18 100644 --- a/include/configs/integratorcp.h +++ b/include/configs/integratorcp.h @@ -60,11 +60,14 @@ #include #define CONFIG_BOOTDELAY 2 -#define CONFIG_BOOTARGS"root=/dev/mtdblock0 console=ttyAMA0 console=tty ip=dhcp netdev=27,0,0xfc80,0xfc800010,eth0 video=clcdfb:0" -#define CONFIG_BOOTCOMMAND "tftpboot ; bootm" #define CONFIG_SERVERIP 192.168.1.100 #define CONFIG_IPADDR 192.168.1.104 -#define CONFIG_BOOTFILE "uImage" +#define CONFIG_BOOTARGS"root=/dev/mtdblock0 console=ttyAMA0 console=tty ip=dhcp netdev=27,0,0xfc80,0xfc800010,eth0 video=clcdfb:0" +#define CONFIG_BOOTCOMMAND "setenv serverip 192.168.1.100 ; " \ + "setenv fdtaddr 0x0080 ; " \ + "bootp $loadaddr $serverip:uImage ; " \ + "bootp $fdtaddr $serverip:integratorcp.dtb ; " \ + "bootm $loadaddr - $fdtaddr" /* * Miscellaneous configurable options -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spl:falcon:trats: Fix SPL image size computing.
"spl_imgsize" was set as decimal variable by "setexpr"
and this causes wrong image size written by "ext4write".
Preset this val with "0x" prefix allow to fix this issue.
Signed-off-by: Przemyslaw Marczak
Signed-off-by: Kyungmin Park
Cc: Minkyu Kang
---
include/configs/trats.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 63745ac..1fd7943 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -199,6 +199,7 @@
"splfile=falcon.bin\0" \
"spl_export=" \
"setexpr spl_imgsize ${splsize} + 8 ;" \
+ "setenv spl_imgsize 0x${spl_imgsize};" \
"setexpr spl_imgaddr ${spladdr} - 8 ;" \
"setexpr spl_addr_tmp ${spladdr} - 4 ;" \
"mw.b ${spl_imgaddr} 0x00 ${spl_imgsize};run loaduimage;" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] bfin: Remove spi dma function in bf5xx.
Mike, test case is [#6887], if you save data and read out to compare it sometimes fail. I agree that we can keep this patch, but it introduces problems to test engineer. This is a random error, she is difficult to know which board and which case we should enable this function. 2013/3/12 Mike Frysinger : > On Monday 04 March 2013 02:20:08 Sonic Zhang wrote: >> From: Scott Jiang >> >> BF5xx rx dma causes spi flash random read error. >> Accually spi controller has problems both on tx and rx dma. >> So remove spi dma support in u-boot. > > this is wrong, and imo, unnecessary. it's wrong because using DMA gains a lot > of speed increases, and works for in many cases (i haven't seen cases where it > didn't work, but i haven't been actively developing in the last year of > course). it's unnecessary because there's already a CONFIG_xxx option to > disable it if your platform is having problems and you can't figure things > out, > and don't need the speed gains. > -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
Hi, On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass wrote: > This series creates a generic board init implementation which contains > the essential functions of the major arch/xxx/lib/board.c files. It is > split into two parts: board_f.c for pre-relocation and board_r.c for > post-relocation. I forgot to mention that if anyone wants to try this out on their board, the tree is at http://git.denx.de/u-boot-x86.git branch 'us-board-v11' Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
