Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
Dear Simon, In message you wrote: > > Thanks for looking at this so closely - it's just an RFC at this > stage, but I think it has promise. Agreed. > > I think config_* is not a good name to use here - it has never been a > > reserved prefix so far, so it is IMO a bad idea to turn it into one > > now . We already have quite a number such variable names in the code > > all over the place (not sure I caught them all): ... > These are variables, so won't conflict with the function macros used > by this patch. But maybe we should try for something like cfg_...()? You are wrong. This includes a number of functions, and macros, too, for example: void config_sdram(const struct emif_regs *regs); void config_ddr_phy(const struct emif_regs *regs); void config_cmd_ctrl(const struct cmd_control *cmd); void config_ddr_data(int data_macrono, ...) void config_io_ctrl(unsigned long val); void config_ddr(unsigned int pll, unsigned int ioctrl, void config_data_eye_leveling_samples(u32 emif_base); static int config_pll_clk(enum pll_clocks index, ...) static int config_core_clk(u32 ref, u32 freq) # define config_fifo(dir, idx, addr) And cfg_ is not much better: #define cfg_read(val, addr, type, op) #define cfg_write(val, addr, type, op) u16 cfg_type = 0; unsigned cfg_val; u32 *cfg_reg; uintcfg_addr; uintcfg_data; ... > I did for the 'sed' step - it was a 2-3 seconds to regenerate the header > files. > > Full reconfig/recompile goes from about about 30s to 34s. > Incremental build doesn't change noticeably. I'm mostly concerned about build time for the autobuilder, which does full config / build cycles for all boards. Here more than 10% increase hurt... > I also tried recompiling both the mainline U-Boot's main.c 100 times, > and then this one. I could not see any time difference, which is a > little surprising. Maybe the C compiler's DCE is pretty early in the > the process? This is a surprising result, indeed. > >> + if (config_autoboot_delay_str() && delaykey[0].str == NULL) > >> + delaykey[0].str = config_autoboot_delay_str(); > > > > Hm constructs like these make me think about side effects. As is, > > your implementation does not pretect against any. This may be > > dangerous - you are evaluating the macro multiple times now, while > > before it was only a defined() test, folowed by a single evaluation. You did not comment on this remark. I think it is something to keep in mind! > > And to be honest - I find the old code easier to read. :-) > But if you have time, please take a look at the sed scripts and the Makefile. Sorry, but I can't find the audacity to bend my mind around these currently ;-) But you might have a look at "tools/scripts/define2mk.sed" and either use this as is, or base your code on this. I would find it good to use the same code for the same (or so very similar) purposes. > The background here is that I have been wondering about this for a > while, but have never really come up with a good way (in the absence > of a unified Kconfig) of getting a complete list of CONFIG variables. Does not the already existing "include/autoconf.mk" contain this information? In any case, please check "tools/scripts/define2mk.sed" > There was a mailing list post about this a few weeks ago. But then > David Hendrix complained about main.c which spurred me into action, > and I thought maybe we could just live with a brute force > 'find/grep/sed' approach for now, rather than trying to be too clever. > That's what I have done here. Understood, and appreciated. > I will come back to this when I have time - will be a week or two. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] *** SUBJECT HERE ***
Dear Sonic Zhang, please provide a useful Subject: line - "*** SUBJECT HERE ***" is not exactly helpful. In message <1361257266-3722-1-git-send-email-sonic@gmail.com> you wrote: > > The v2 patches > 1) fix most checkpatch issues mentioned by Wolfgang Hm... I'm sorry, but this information is not really helpful. So it seems you decided not to fix all issues, but you don't tell us which ones you ignored, or why. I still see thousands of lines over 80 characters, plus a number of trailing statements should be on next line, code indent should use tabs where possible, do not add new typedefs, Whitespace before semicolon, warnings and errors. Please fix these!! > 2) remove unrelated dma structure change patch > 3) replace unreable macro in dma and uart structures with normal types. > 4) replace unreable macro in uart peripheral portmux configuration with clear > inline function. > 5) clean up and merge redundant #ifdef's > 6) spearate declarations and code by a blankline > 7) remove the values for variables in blackfin config headers whose values > are useless > 8) replace run-time variable with new macro when adding 4M byte CPLB entries. Please provide a more detailed list which review comments you processed, and which you decided to ignore, and why. Please provide a more detailed list which review comments you processed, and which you decided to ignore, and why. Note: this history of changes is supposed to be (also) in the patches itself, not (only) in the cover letter. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't get paid for the hour. You get paid for the value you bring to the hour. - Jim Rohn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] Blackfin: bf60x: new processor header files
Dear Sonic Zhang, In message <1361257266-3722-2-git-send-email-sonic@gmail.com> you wrote: > > Add header files for blackfin new processor bf60x. ... > arch/blackfin/include/asm/mach-bf609/BF609_def.h | 3758 > + This is a bit excessive, isn't it? Do we really all thse many thousands lines of defines? > diff --git a/arch/blackfin/include/asm/mach-bf609/BF609_def.h > b/arch/blackfin/include/asm/mach-bf609/BF609_def.h > new file mode 100644 > index 000..39b740f > --- /dev/null > +++ b/arch/blackfin/include/asm/mach-bf609/BF609_def.h > @@ -0,0 +1,3758 @@ > +/* DO NOT EDIT THIS FILE > + * Automatically generated by generate-def-headers.xsl > + * DO NOT EDIT THIS FILE > + */ > + > +#ifndef __BFIN_DEF_ADSP_BF609_proc__ > +#define __BFIN_DEF_ADSP_BF609_proc__ > + > +#include "../mach-common/ADSP-EDN-core_def.h" > + > +#define CNT_CFG 0xFFC00400 /* CNT0 Configuration > Register */ > +#define CNT_IMSK0xFFC00404 /* CNT0 Interrupt > Mask Register */ > +#define CNT_STAT0xFFC00408 /* CNT0 Status > Register */ > +#define CNT_CMD 0xFFC0040C /* CNT0 Command > Register */ > +#define CNT_DEBNCE 0xFFC00410 /* CNT0 Debounce > Register */ > +#define CNT_CNTR0xFFC00414 /* CNT0 Counter > Register */ > +#define CNT_MAX 0xFFC00418 /* CNT0 Maximum Count > Register */ > +#define CNT_MIN 0xFFC0041C /* CNT0 Minimum Count > Register */ > + > +#define RSI_CLK_CONTROL 0xFFC00604 /* RSI0 Clock Control > Register */ > +#define RSI_ARGUMENT0xFFC00608 /* RSI0 Argument > Register */ > +#define RSI_COMMAND 0xFFC0060C /* RSI0 Command > Register */ > +#define RSI_RESP_CMD0xFFC00610 /* RSI0 Response > Command Register */ > +#define RSI_RESPONSE0 0xFFC00614 /* RSI0 Response 0 > Register */ > +#define RSI_RESPONSE1 0xFFC00618 /* RSI0 Response 1 > Register */ > +#define RSI_RESPONSE2 0xFFC0061C /* RSI0 Response 2 > Register */ > +#define RSI_RESPONSE3 0xFFC00620 /* RSI0 Response 3 > Register */ > +#define RSI_DATA_TIMER 0xFFC00624 /* RSI0 Data Timer > Register */ > +#define RSI_DATA_LGTH 0xFFC00628 /* RSI0 Data Length > Register */ > +#define RSI_DATA_CONTROL0xFFC0062C /* RSI0 Data Control > Register */ > +#define RSI_DATA_CNT0xFFC00630 /* RSI0 Data Count > Register */ > +#define RSI_STATUS 0xFFC00634 /* RSI0 Status > Register */ > +#define RSI_STATUSCL0xFFC00638 /* RSI0 Status Clear > Register */ > +#define RSI_IMSK0 0xFFC0063C /* RSI0 Interrupt 0 > Mask Register */ > +#define RSI_IMSK1 0xFFC00640 /* RSI0 Interrupt 1 > Mask Register */ > +#define RSI_FIFO_CNT0xFFC00648 /* RSI0 FIFO Counter > Register */ ... I think I mentioned before that device registers have to be described using C structs in U-Boot, and proper I/O accessors must be used to access these. In any case, please trim to the really needed definitions. > --- /dev/null > +++ b/arch/blackfin/include/asm/mach-bf609/anomaly.h > @@ -0,0 +1,103 @@ > +/* > + * DO NOT EDIT THIS FILE > + * This file is under version control at > + * > svn://sources.blackfin.uclinux.org/toolchain/trunk/proc-defs/header-frags/ > + * and can be replaced with that version at any time > + * DO NOT EDIT THIS FILE This makes no sense to me. > + * Copyright 2004-2012 Analog Devices Inc. > + * Licensed under the ADI BSD license. > + * https://docs.blackfin.uclinux.org/doku.php?id=adi_bsd > + */ I'm not sure if this has been discussed before - is this really GPL compatible? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Harrison's Postulate: For every action, there is an equal and opposite criticism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: atmel: add at91sam9g20ek_2mmc nand boot support
Dear Bo Shen, > Add at91sam9g20_2mmc nand boot support. on this board, there is no > dataflash, so disable it > > change one commet for at91sam9g20ek board > > Signed-off-by: Bo Shen > > --- > board/atmel/at91sam9260ek/at91sam9260ek.c |7 ++- > boards.cfg|1 + > include/configs/at91sam9260ek.h |2 ++ > 3 files changed, 9 insertions(+), 1 deletion(-) 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] [PATCH v7 06/19] nand: mxc: Use appropriate page number in syndrome functions
Hi Scott,
On Tuesday, February 19, 2013 1:30:23 AM, Scott Wood wrote:
> On 02/15/2013 02:54:12 PM, Benoît Thébaudeau wrote:
> > The syndrome functions should use the page number passed as argument
> > instead of
> > the page number saved upon NAND_CMD_READ0.
> >
> > This does not make any difference if the NAND_NO_AUTOINCR option is
> > set, but
> > otherwise this fixes accesses to the wrong pages.
> >
> > Signed-off-by: Benoît Thébaudeau
> > ---
> > Changes in v7: None
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4:
> > - New patch.
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> > drivers/mtd/nand/mxc_nand.c |6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > index 249328e..001c2c0 100644
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -504,7 +504,7 @@ static int mxc_nand_read_page_raw_syndrome(struct
> > mtd_info *mtd,
> > int n;
> >
> > _mxc_nand_enable_hwecc(mtd, 0);
> > - chip->cmdfunc(mtd, NAND_CMD_READ0, 0x00, host->page_addr);
> > + chip->cmdfunc(mtd, NAND_CMD_READ0, 0x00, page);
> >
> > for (n = 0, steps = chip->ecc.steps; steps > 0; n++, steps--) {
> > host->col_addr = n * eccsize;
> > @@ -548,7 +548,7 @@ static int mxc_nand_read_page_syndrome(struct
> > mtd_info *mtd,
> > uint8_t *oob = chip->oob_poi;
> >
> > MTDDEBUG(MTD_DEBUG_LEVEL1, "Reading page %u to buf %p oob %p\n",
> > - host->page_addr, buf, oob);
> > + page, buf, oob);
> >
> > /* first read the data area and the available portion of OOB */
> > for (n = 0; eccsteps; n++, eccsteps--, p += eccsize) {
> > @@ -586,7 +586,7 @@ static int mxc_nand_read_page_syndrome(struct
> > mtd_info *mtd,
> >
> > /* Then switch ECC off and read the OOB area to get the ECC
> > code */
> > _mxc_nand_enable_hwecc(mtd, 0);
> > - chip->cmdfunc(mtd, NAND_CMD_READOOB, mtd->writesize,
> > host->page_addr);
> > + chip->cmdfunc(mtd, NAND_CMD_READOOB, mtd->writesize, page);
> > eccsteps = chip->ecc.steps;
> > oob = chip->oob_poi + chip->ecc.prepad;
> > for (n = 0; eccsteps; n++, eccsteps--, p += eccsize) {
>
> The debug print in mxc_nand_read_oob_syndrome() also needs to be fixed.
Yes, but this is done by 05/19.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Mon, Feb 18, 2013 at 06:56:36PM -0300, Otavio Salvador wrote : > The point of using the Falcon mode here would be to allow boot onto > interactive mode, when need, and boot fast by default. The whoosh goal > is *very* nice but it is different. :-) > Yeah, exactly, the use case is different but it was not clearly stated that using u-boot was mandatory in the first mail ;) Anyway, last time I looked, SPL was not supported on i.mx6, is it now ? -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Mon, Feb 18, 2013 at 02:59:24PM -0700, Chaves, Kevin wrote : > This is almost exactly what we want to do, we just want to be able to hold a > key down during the boot and switch it to a recovery settings with a > different kernel/rfs, would this be supported as well? > No, that is not supported and probably won't be. Some people will argue that you probably don't need a bootloader once you are able to boot a linux kernel as you can probably do everything you want from there. -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
Dear Alexandre Belloni, In message <20130219112532.gb24...@piout.net> you wrote: > > No, that is not supported and probably won't be. Some people will argue I think you are wrong. This is definitely a "not supported _yet_". > that you probably don't need a bootloader once you are able to boot a > linux kernel as you can probably do everything you want from there. Yes, some people will think so, and some will actually do that. Others (and I would expect these to be the majority) will realize the benefits of being able to switch on demand (say, key press, jumper setting, etc.) between different boot modes, boot images, etc. I am absolutely sure that SPL support for iMX6 will be added rather sooner than later. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 8) Use common sense in routing cable. Avoid wrapping coax around sources of strong electric or magnetic fields. Do not wrap the cable around flourescent light ballasts or cyclotrons, for example. - Ethernet Headstart Product, Information and Installation Guide, Bell Technologies, pg. 11 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/10] mx23_olinuxino: Enable USB support
On Mon, Feb 18, 2013 at 10:38 PM, Marek Vasut wrote: > Dear Otavio Salvador, > >> On Mon, Feb 18, 2013 at 8:16 PM, Fabio Estevam wrote: >> > On Sun, Feb 17, 2013 at 4:45 PM, Otavio Salvador >> > >> > wrote: >> >> +#ifdef CONFIG_CMD_USB >> >> + /* Enable LAN9512 */ >> >> + gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1); >> >> +#endif >> > >> > What about doing like we do with other imx devices and write something >> > like: >> > >> > gpio_direction_output(MXS_GPIO_NR(0, 17), 1); >> > >> > ,where >> > >> > #define MXS_GPIO_NR(bank, nr) ((bank) * 32 + (nr)) >> > >> > This also aligns with the kernel style. >> >> Awesome; I have added it to v5. Thx! > > This will bring in quite a lot of inconsistency, will it not? Really? why? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] I2C: S3C24X0: Bug fixes in i2c_transfer
This patch corrects the following issues
1) Write the correct M/T Stop value to I2CSTAT after i2c write.
According to the spec, after finish the data transmission, we should
write a M/T Stop (I2C_MODE_MT | I2C_TXRX_ENA) to I2CSTAT instead of
a M/R Stop (I2C_MODE_MR | I2C_TXRX_ENA).
2) Not split the write to I2CSTAT into 2 steps in i2c read.
According to the spec, we should write the combined M/R Start value to
I2CSTAT after setting the slave address to I2CDS
3) Fix the mistake of making an equality check to an assignment.
In the case of I2C write with the zero-length address, while tranfering the
data, it should be an equality check (==) instead of an assignment (=).
Signed-off-by: Tom Wai-Hong Tam
Signed-off-by: Rajeshwari Shinde
---
drivers/i2c/s3c24x0_i2c.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index 00308b5..46d2506 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -324,7 +324,7 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
writel(I2C_MODE_MT | I2C_TXRX_ENA | I2C_START_STOP,
&i2c->iicstat);
i = 0;
- while ((i < data_len) && (result = I2C_OK)) {
+ while ((i < data_len) && (result == I2C_OK)) {
result = WaitForXfer(i2c);
writel(data[i], &i2c->iicds);
ReadWriteByte(i2c);
@@ -336,17 +336,16 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
result = WaitForXfer(i2c);
/* send STOP */
- writel(I2C_MODE_MR | I2C_TXRX_ENA, &i2c->iicstat);
+ writel(I2C_MODE_MT | I2C_TXRX_ENA, &i2c->iicstat);
ReadWriteByte(i2c);
break;
case I2C_READ:
if (addr && addr_len) {
- writel(I2C_MODE_MT | I2C_TXRX_ENA, &i2c->iicstat);
writel(chip, &i2c->iicds);
/* send START */
- writel(readl(&i2c->iicstat) | I2C_START_STOP,
- &i2c->iicstat);
+ writel(I2C_MODE_MT | I2C_TXRX_ENA | I2C_START_STOP,
+ &i2c->iicstat);
result = WaitForXfer(i2c);
if (IsACK(i2c)) {
i = 0;
@@ -380,11 +379,10 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
}
} else {
- writel(I2C_MODE_MR | I2C_TXRX_ENA, &i2c->iicstat);
writel(chip, &i2c->iicds);
/* send START */
- writel(readl(&i2c->iicstat) | I2C_START_STOP,
- &i2c->iicstat);
+ writel(I2C_MODE_MR | I2C_TXRX_ENA | I2C_START_STOP,
+ &i2c->iicstat);
result = WaitForXfer(i2c);
if (IsACK(i2c)) {
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/10] mx23_olinuxino: Enable USB support
Dear Otavio Salvador, > On Mon, Feb 18, 2013 at 10:38 PM, Marek Vasut wrote: > > Dear Otavio Salvador, > > > >> On Mon, Feb 18, 2013 at 8:16 PM, Fabio Estevam wrote: > >> > On Sun, Feb 17, 2013 at 4:45 PM, Otavio Salvador > >> > > >> > wrote: > >> >> +#ifdef CONFIG_CMD_USB > >> >> + /* Enable LAN9512 */ > >> >> + gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1); > >> >> +#endif > >> > > >> > What about doing like we do with other imx devices and write something > >> > like: > >> > > >> > gpio_direction_output(MXS_GPIO_NR(0, 17), 1); > >> > > >> > ,where > >> > > >> > #define MXS_GPIO_NR(bank, nr) ((bank) * 32 + (nr)) > >> > > >> > This also aligns with the kernel style. > >> > >> Awesome; I have added it to v5. Thx! > > > > This will bring in quite a lot of inconsistency, will it not? > > Really? why? Because this will not be used globally with all GPIOs, but only locally for this one case. So my suggestion is to postpone this change and do this in one large swipe afterwards. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/10] mx23_olinuxino: Enable USB support
On Tue, Feb 19, 2013 at 9:21 AM, Marek Vasut wrote: > Dear Otavio Salvador, > >> On Mon, Feb 18, 2013 at 10:38 PM, Marek Vasut wrote: >> > Dear Otavio Salvador, >> > >> >> On Mon, Feb 18, 2013 at 8:16 PM, Fabio Estevam wrote: >> >> > On Sun, Feb 17, 2013 at 4:45 PM, Otavio Salvador >> >> > >> >> > wrote: >> >> >> +#ifdef CONFIG_CMD_USB >> >> >> + /* Enable LAN9512 */ >> >> >> + gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1); >> >> >> +#endif >> >> > >> >> > What about doing like we do with other imx devices and write something >> >> > like: >> >> > >> >> > gpio_direction_output(MXS_GPIO_NR(0, 17), 1); >> >> > >> >> > ,where >> >> > >> >> > #define MXS_GPIO_NR(bank, nr) ((bank) * 32 + (nr)) >> >> > >> >> > This also aligns with the kernel style. >> >> >> >> Awesome; I have added it to v5. Thx! >> > >> > This will bring in quite a lot of inconsistency, will it not? >> >> Really? why? > > Because this will not be used globally with all GPIOs, but only locally for > this > one case. So my suggestion is to postpone this change and do this in one large > swipe afterwards. I see; I agree with you. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patch to support Xilinx 1000BASE-X phy (GTX)
and here it is again, in-line
commit 39695029bc15041c809df3db4ba19bd729c447fa
Author: Charles Coldwell
Date: Tue Feb 19 08:27:33 2013 -0500
Changes to support the Xilinx 1000BASE-X phy (GTX/MGT)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d0ed766..8a38ccb 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -75,6 +75,10 @@ static int genphy_config_advert(struct phy_device *phydev)
adv |= ADVERTISE_PAUSE_CAP;
if (advertise & ADVERTISED_Asym_Pause)
adv |= ADVERTISE_PAUSE_ASYM;
+ if (advertise & ADVERTISED_1000baseX_Half)
+ adv |= ADVERTISE_1000XHALF;
+ if (advertise & ADVERTISED_1000baseX_Full)
+ adv |= ADVERTISE_1000XFULL;
if (adv != oldadv) {
err = phy_write(phydev, MDIO_DEVAD_NONE, MII_ADVERTISE, adv);
@@ -288,6 +292,7 @@ static int genphy_parse_link(struct phy_device *phydev)
if (mii_reg & BMSR_ANEGCAPABLE) {
u32 lpa = 0;
u32 gblpa = 0;
+ u32 estatus = 0;
/* Check for gigabit capability */
if (mii_reg & BMSR_ERCAP) {
@@ -327,6 +332,17 @@ static int genphy_parse_link(struct phy_device *phydev)
} else if (lpa & LPA_10FULL)
phydev->duplex = DUPLEX_FULL;
+
+ if (mii_reg & BMSR_ESTATEN)
+ estatus = phy_read(phydev, MDIO_DEVAD_NONE, MII_ESTATUS);
+
+ if (estatus & (ESTATUS_1000_XFULL | ESTATUS_1000_XHALF |
+ ESTATUS_1000_TFULL | ESTATUS_1000_THALF)) {
+ phydev->speed = SPEED_1000;
+ if (estatus & (ESTATUS_1000_XFULL | ESTATUS_1000_TFULL))
+ phydev->duplex = DUPLEX_FULL;
+ }
+
} else {
u32 bmcr = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
@@ -384,6 +400,10 @@ int genphy_config(struct phy_device *phydev)
features |= SUPPORTED_1000baseT_Full;
if (val & ESTATUS_1000_THALF)
features |= SUPPORTED_1000baseT_Half;
+ if (val & ESTATUS_1000_XFULL)
+ features |= SUPPORTED_1000baseX_Full;
+ if (val & ESTATUS_1000_XHALF)
+ features |= SUPPORTED_1000baseX_Full;
}
phydev->supported = features;
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index fcb20fe..f6dbdb0 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -580,6 +580,8 @@ enum ethtool_sfeatures_retval_bits {
#define SUPPORTED_1baseKX4_Full (1 << 18)
#define SUPPORTED_1baseKR_Full (1 << 19)
#define SUPPORTED_1baseR_FEC (1 << 20)
+#define SUPPORTED_1000baseX_Half (1 << 21)
+#define SUPPORTED_1000baseX_Full (1 << 22)
/* Indicates what features are advertised by the interface. */
#define ADVERTISED_10baseT_Half (1 << 0)
@@ -603,6 +605,8 @@ enum ethtool_sfeatures_retval_bits {
#define ADVERTISED_1baseKX4_Full (1 << 18)
#define ADVERTISED_1baseKR_Full (1 << 19)
#define ADVERTISED_1baseR_FEC (1 << 20)
+#define ADVERTISED_1000baseX_Half (1 << 21)
+#define ADVERTISED_1000baseX_Full (1 << 22)
/* The following are all involved in forcing a particular link
* mode for the device for setting things. When getting the
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 8b92692..66b83d8 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -115,6 +115,8 @@
#define EXPANSION_MFAULTS 0x0010 /* Multiple faults detected*/
#define EXPANSION_RESV 0xffe0 /* Unused... */
+#define ESTATUS_1000_XFULL 0x8000 /* Can do 1000BX Full */
+#define ESTATUS_1000_XHALF 0x4000 /* Can do 1000BX Half */
#define ESTATUS_1000_TFULL 0x2000 /* Can do 1000BT Full */
#define ESTATUS_1000_THALF 0x1000 /* Can do 1000BT Half */
On Tue, Feb 19, 2013 at 8:35 AM, Charles Coldwell wrote:
> Attached is a (small) patch that enabled me to use the 1000BASE-X phy
> on the Xilinx Virtex-6 hard TEMAC (i.e. the one that uses the GTX
> transceivers).
>
> --
> Charles M. Coldwell, W1CMC
> Belmont, Massachusetts, New England
> "Turn on, log in, tune out"
--
Charles M. Coldwell, W1CMC
Belmont, Massachusetts, New England
"Turn on, log in, tune out"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Tue, Feb 19, 2013 at 12:35:01PM +0100, Wolfgang Denk wrote : > Dear Alexandre Belloni, > > In message <20130219112532.gb24...@piout.net> you wrote: > > > > No, that is not supported and probably won't be. Some people will argue > > I think you are wrong. This is definitely a "not supported _yet_". > > > that you probably don't need a bootloader once you are able to boot a > > linux kernel as you can probably do everything you want from there. > > Yes, some people will think so, and some will actually do that. > Others (and I would expect these to be the majority) will realize the > benefits of being able to switch on demand (say, key press, jumper > setting, etc.) between different boot modes, boot images, etc. > > I am absolutely sure that SPL support for iMX6 will be added rather > sooner than later. > Yeah, don't misinterpret me, I was just saying that it will not be supported in whoosh. I also believe that SPL and falcon mode will come to i.mx6 and I'm also interested in getting that support ;) -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2 v1] Exynos5: spl: Reduce spl size
This patch set tries to gain some space in spl by restructuring and reorganising some code in two different clock init's for two different times of execution. Akshay Saraswat (2): Exynos5: spl: Reorganize mem_timing struct to gain space in spl Exynos5: spl: Reduce clock init in spl board/samsung/smdk5250/Makefile |3 +- board/samsung/smdk5250/clock_init.c | 506 +-- board/samsung/smdk5250/clock_init.h | 57 ++-- board/samsung/smdk5250/dmc_common.c | 40 +-- board/samsung/smdk5250/dmc_init_ddr3.c | 116 +++ board/samsung/smdk5250/lowlevel_init.S |4 +- board/samsung/smdk5250/setup.h | 16 +- board/samsung/smdk5250/smdk5250.c |4 + board/samsung/smdk5250/spl_clock_init.c | 469 9 files changed, 625 insertions(+), 590 deletions(-) create mode 100644 board/samsung/smdk5250/spl_clock_init.c -- 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/2] Exynos5: spl: Reorganize mem_timing struct to gain space in spl
Distributes struct mem_timings into new different structures
to gain space in spl by removing necessity of maintaining
two big and almost similar mem_timings instances.
Signed-off-by: Akshay Saraswat
---
board/samsung/smdk5250/clock_init.c| 177
board/samsung/smdk5250/clock_init.h| 55 ++
board/samsung/smdk5250/dmc_common.c| 40
board/samsung/smdk5250/dmc_init_ddr3.c | 116 +++--
board/samsung/smdk5250/setup.h | 15 ++-
5 files changed, 193 insertions(+), 210 deletions(-)
diff --git a/board/samsung/smdk5250/clock_init.c
b/board/samsung/smdk5250/clock_init.c
index c009ae5..30cbdcf 100644
--- a/board/samsung/smdk5250/clock_init.c
+++ b/board/samsung/smdk5250/clock_init.c
@@ -127,14 +127,17 @@ struct arm_clk_ratios arm_clk_ratios[] = {
.arm_ratio = 0x0,
}
};
-struct mem_timings mem_timings[] = {
- {
- .mem_manuf = MEM_MANUF_ELPIDA,
- .mem_type = DDR_MODE_DDR3,
- .frequency_mhz = 800,
+
+struct spl_clock_div spl_clock_div = {
.mpll_mdiv = 0xc8,
.mpll_pdiv = 0x3,
.mpll_sdiv = 0x0,
+ .bpll_mdiv = 0x64,
+ .bpll_pdiv = 0x3,
+ .bpll_sdiv = 0x0,
+};
+
+struct non_spl_clock_div non_spl_clock_div = {
.cpll_mdiv = 0xde,
.cpll_pdiv = 0x4,
.cpll_sdiv = 0x2,
@@ -147,14 +150,10 @@ struct mem_timings mem_timings[] = {
.vpll_mdiv = 0x96,
.vpll_pdiv = 0x3,
.vpll_sdiv = 0x2,
+};
- .bpll_mdiv = 0x64,
- .bpll_pdiv = 0x3,
- .bpll_sdiv = 0x0,
+struct mem_timings mem_timings = {
.pclk_cdrex_ratio = 0x5,
- .direct_cmd_msr = {
- 0x00020018, 0x0003, 0x00010042, 0x0d70
- },
.timing_ref = 0x00bb,
.timing_row = 0x8c36650e,
.timing_data = 0x3630580b,
@@ -163,8 +162,6 @@ struct mem_timings mem_timings[] = {
.phy1_dqs = 0x08080808,
.phy0_dq = 0x08080808,
.phy1_dq = 0x08080808,
- .phy0_tFS = 0x4,
- .phy1_tFS = 0x4,
.phy0_pulld_dqs = 0xf,
.phy1_pulld_dqs = 0xf,
@@ -186,10 +183,6 @@ struct mem_timings mem_timings[] = {
.rd_fetch = 0x3,
- .zq_mode_dds = 0x7,
- .zq_mode_term = 0x1,
- .zq_mode_noterm = 0,
-
/*
* Dynamic Clock: Always Running
* Memory Burst length: 8
@@ -229,114 +222,49 @@ struct mem_timings mem_timings[] = {
.chips_per_channel = 2,
.chips_to_configure = 1,
.send_zq_init = 1,
+};
+
+struct mem_params mem_params[] = {
+ {
+ .mem_manuf = MEM_MANUF_ELPIDA,
+ .mem_type = DDR_MODE_DDR3,
+ .frequency_mhz = 800,
+
+ .direct_cmd_msr = {
+ 0x00020018, 0x0003, 0x00010042, 0x0d70
+ },
+
+ .phy0_tFS = 0x4,
+ .phy1_tFS = 0x4,
+
+ .zq_mode_dds = 0x7,
+ .zq_mode_term = 0x1,
+ .zq_mode_noterm = 0,
+
.impedance = IMP_OUTPUT_DRV_30_OHM,
.gate_leveling_enable = 0,
}, {
.mem_manuf = MEM_MANUF_SAMSUNG,
.mem_type = DDR_MODE_DDR3,
.frequency_mhz = 800,
- .mpll_mdiv = 0xc8,
- .mpll_pdiv = 0x3,
- .mpll_sdiv = 0x0,
- .cpll_mdiv = 0xde,
- .cpll_pdiv = 0x4,
- .cpll_sdiv = 0x2,
- .gpll_mdiv = 0x215,
- .gpll_pdiv = 0xc,
- .gpll_sdiv = 0x1,
- .epll_mdiv = 0x60,
- .epll_pdiv = 0x3,
- .epll_sdiv = 0x3,
- .vpll_mdiv = 0x96,
- .vpll_pdiv = 0x3,
- .vpll_sdiv = 0x2,
- .bpll_mdiv = 0x64,
- .bpll_pdiv = 0x3,
- .bpll_sdiv = 0x0,
- .pclk_cdrex_ratio = 0x5,
.direct_cmd_msr = {
0x00020018, 0x0003, 0x0001, 0x0d70
},
- .timing_ref = 0x00bb,
- .timing_row = 0x8c36650e,
- .timing_data = 0x3630580b,
- .timing_power = 0x41000a44,
- .phy0_dqs = 0x08080808,
- .phy1_dqs = 0x08080808,
- .phy0_dq = 0x08080808,
- .phy1_dq = 0x08080808,
+
.phy0_tFS = 0x8,
.phy1_tFS = 0x8,
- .phy0_pulld_dqs = 0xf,
- .phy1_pulld_dqs = 0xf,
-
- .lpddr3_ctrl_phy_reset = 0x1,
- .ctrl_start_point = 0x10,
- .ctrl_inc = 0x10,
-
[U-Boot] [PATCH 2/2] Exynos5: spl: Reduce clock init in spl
This patch subtracts a part of clock init from spl
and executes it after relocation. spl_clock_init
executes in spl and system_clock_init executes after
relocation in u-boot. This is done to gain some space by
removing initially not necessary code.
Signed-off-by: Akshay Saraswat
---
board/samsung/smdk5250/Makefile |3 +-
board/samsung/smdk5250/clock_init.c | 429 +---
board/samsung/smdk5250/clock_init.h |2 +
board/samsung/smdk5250/lowlevel_init.S |4 +-
board/samsung/smdk5250/setup.h |1 +
board/samsung/smdk5250/smdk5250.c |4 +
board/samsung/smdk5250/spl_clock_init.c | 469 +++
7 files changed, 482 insertions(+), 430 deletions(-)
create mode 100644 board/samsung/smdk5250/spl_clock_init.c
diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
index 47c6a5a..3ceb7e2 100644
--- a/board/samsung/smdk5250/Makefile
+++ b/board/samsung/smdk5250/Makefile
@@ -26,12 +26,13 @@ LIB = $(obj)lib$(BOARD).o
SOBJS := lowlevel_init.o
-COBJS := clock_init.o
+COBJS := spl_clock_init.o
COBJS += dmc_common.o dmc_init_ddr3.o
COBJS += tzpc_init.o
COBJS += smdk5250_spl.o
ifndef CONFIG_SPL_BUILD
+COBJS += clock_init.o
COBJS += smdk5250.o
endif
diff --git a/board/samsung/smdk5250/clock_init.c
b/board/samsung/smdk5250/clock_init.c
index 30cbdcf..fe3cd8a 100644
--- a/board/samsung/smdk5250/clock_init.c
+++ b/board/samsung/smdk5250/clock_init.c
@@ -34,109 +34,6 @@
DECLARE_GLOBAL_DATA_PTR;
-struct arm_clk_ratios arm_clk_ratios[] = {
- {
- .arm_freq_mhz = 600,
-
- .apll_mdiv = 0xc8,
- .apll_pdiv = 0x4,
- .apll_sdiv = 0x1,
-
- .arm2_ratio = 0x0,
- .apll_ratio = 0x1,
- .pclk_dbg_ratio = 0x1,
- .atb_ratio = 0x2,
- .periph_ratio = 0x7,
- .acp_ratio = 0x7,
- .cpud_ratio = 0x1,
- .arm_ratio = 0x0,
- }, {
- .arm_freq_mhz = 800,
-
- .apll_mdiv = 0x64,
- .apll_pdiv = 0x3,
- .apll_sdiv = 0x0,
-
- .arm2_ratio = 0x0,
- .apll_ratio = 0x1,
- .pclk_dbg_ratio = 0x1,
- .atb_ratio = 0x3,
- .periph_ratio = 0x7,
- .acp_ratio = 0x7,
- .cpud_ratio = 0x2,
- .arm_ratio = 0x0,
- }, {
- .arm_freq_mhz = 1000,
-
- .apll_mdiv = 0x7d,
- .apll_pdiv = 0x3,
- .apll_sdiv = 0x0,
-
- .arm2_ratio = 0x0,
- .apll_ratio = 0x1,
- .pclk_dbg_ratio = 0x1,
- .atb_ratio = 0x4,
- .periph_ratio = 0x7,
- .acp_ratio = 0x7,
- .cpud_ratio = 0x2,
- .arm_ratio = 0x0,
- }, {
- .arm_freq_mhz = 1200,
-
- .apll_mdiv = 0x96,
- .apll_pdiv = 0x3,
- .apll_sdiv = 0x0,
-
- .arm2_ratio = 0x0,
- .apll_ratio = 0x3,
- .pclk_dbg_ratio = 0x1,
- .atb_ratio = 0x5,
- .periph_ratio = 0x7,
- .acp_ratio = 0x7,
- .cpud_ratio = 0x3,
- .arm_ratio = 0x0,
- }, {
- .arm_freq_mhz = 1400,
-
- .apll_mdiv = 0xaf,
- .apll_pdiv = 0x3,
- .apll_sdiv = 0x0,
-
- .arm2_ratio = 0x0,
- .apll_ratio = 0x3,
- .pclk_dbg_ratio = 0x1,
- .atb_ratio = 0x6,
- .periph_ratio = 0x7,
- .acp_ratio = 0x7,
- .cpud_ratio = 0x3,
- .arm_ratio = 0x0,
- }, {
- .arm_freq_mhz = 1700,
-
- .apll_mdiv = 0x1a9,
- .apll_pdiv = 0x6,
- .apll_sdiv = 0x0,
-
- .arm2_ratio = 0x0,
- .apll_ratio = 0x3,
- .pclk_dbg_ratio = 0x1,
- .atb_ratio = 0x6,
- .periph_ratio = 0x7,
- .acp_ratio = 0x7,
- .cpud_ratio = 0x3,
- .arm_ratio = 0x0,
- }
-};
-
-struct spl_clock_div spl_clock_div = {
- .mpll_mdiv = 0xc8,
- .mpll_pdiv = 0x3,
- .mpll_sdiv = 0x0,
- .bpll_mdiv = 0x64,
- .bpll_pdiv = 0x3,
- .bpll_sdiv = 0x0,
-};
-
struct non_spl_clock_div non_spl_clock_div = {
.cpll_mdiv = 0xde,
.cpll_pdiv = 0x4,
@@ -152,255 +49,20 @@ struct non_spl_clock_div non_spl_clock_div = {
.vpll_sdiv = 0x2,
};
-struct mem_timings mem_timings = {
- .pclk_cdrex_ratio = 0x5,
- .timing_ref = 0x00bb,
- .timing_row = 0x8c36650e,
- .timing_data = 0x3630580b,
- .timing_power = 0x41000a44,
- .phy0_dq
Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
I'm not sure if this has been discussed, but I've found as a new u-boot user there are often features that require enabling other CONFIG macros that I think should just be auto-enabled as dependencies. Please keep this in mind for any future designs. For example, when enabling CONFIG_CMD_UBI and CONFIG_CMD_UBIFS, my builds failed with linker errors because I didn't know that I needed to also define CONFIG_RBTREE and CONFIG_LZO. Thanks, Harvey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix omap5 hyp mode for second cpu
Make it work on PandaBoard 5 with 5432 ES2 and Linux.
Signed-off-by: Vincent Stehlé
---
Hi,
Here are some necessary adaptations for OMAP5 ES2, as magic value has changed.
In the mean time, we make the secondary cpu routine a bit closer to what
romcode does.
Best regards,
V.
arch/arm/lib/bootm.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 02852d6..dd8f42e 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -56,16 +56,21 @@ asm (
"ldr r12, =0x102\n"
"mov r0, pc\n"
"smc 0x1\n"
- "ldr r1, =0x48281804\n" // AUX_CORE_BOOT_1
+ "ldr r1, =0x48281800\n" /* AUX_CORE_BOOT_0 */
"mov r2, #0\n"
- "str r2, [r1]\n"
+ "str r2, [r1]\n"/* AUX_CORE_BOOT_0 */
+ "str r2, [r1, #4]\n"/* AUX_CORE_BOOT_1 */
"isb\n"
"dsb\n"
+ "mov r3, #0xf0\n"
"1: wfe\n"
- "ldr r2, [r1]\n"
- "cmp r2, #0\n"
- "movne pc, r2\n"
- "b 1b\n"
+ "ldr r2, [r1]\n" /* AUX_CORE_BOOT_0 */
+ "ands r2, r2, r3\n"
+ "beq 1b\n"
+ "ldr r2, [r1, #4]\n" /* AUX_CORE_BOOT_1 */
+ "cmp r2, #0\n"
+ "beq 1b\n"
+ "bx r2\n"
".popsection\n"
);
@@ -378,7 +383,7 @@ void hyp_enable(void) {
"ldr r1, =0x48281800\n" // AUX_CORE_BOOT_1
"ldr r2, =__hyp_init_sec\n"
"str r2, [r1, #4]\n"
- "mov r2, #0x200\n"
+ "mov r2, #0x20\n"
"str r2, [r1]\n"// AUX_CORE_BOOT_0
"isb\n"
"dmb\n"
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AM335x : failure to boot SPL from NAND
On 18/02/13 14:54, Tom Rini wrote: > On Mon, Feb 18, 2013 at 02:43:47PM +, Mark Jackson wrote: >> On 15/02/13 21:13, Tom Rini wrote: >>> On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote: >>> I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Just a quick update (in case anyone else is in the same boat) ... Looks like the upper data bus (AD[15:8]) needs to have pullups on it, even though you're booting from an 8bit device. I guess the AM335x internal boot code assumes everything is 16bit (even though SYSBOOT[8] is used to configure 8/16bit device). Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
Thanks for the response, so the whoosh does not support holding a key to get into another image? I guess that won't work. So if I wanted to support the SPL on the nitrogent6x are there any instruction on what requirements it has to support it. I'm guessing all the work I'd need to do is in board/boundary/nitrogen6x? Also how would I normally configure and build an spl for a working board. There is a lot of config options in the README for the spl. -Original Message- From: Alexandre Belloni [mailto:alexandre.bell...@piout.net] Sent: Tuesday, February 19, 2013 9:00 AM To: Wolfgang Denk Cc: Chaves, Kevin; u-boot@lists.denx.de; Dirk Behme Subject: Re: [U-Boot] imx6, spl and falcon boot On Tue, Feb 19, 2013 at 12:35:01PM +0100, Wolfgang Denk wrote : > Dear Alexandre Belloni, > > In message <20130219112532.gb24...@piout.net> you wrote: > > > > No, that is not supported and probably won't be. Some people will > > argue > > I think you are wrong. This is definitely a "not supported _yet_". > > > that you probably don't need a bootloader once you are able to boot > > a linux kernel as you can probably do everything you want from there. > > Yes, some people will think so, and some will actually do that. > Others (and I would expect these to be the majority) will realize the > benefits of being able to switch on demand (say, key press, jumper > setting, etc.) between different boot modes, boot images, etc. > > I am absolutely sure that SPL support for iMX6 will be added rather > sooner than later. > Yeah, don't misinterpret me, I was just saying that it will not be supported in whoosh. I also believe that SPL and falcon mode will come to i.mx6 and I'm also interested in getting that support ;) -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello, 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-ti.git master for you to fetch changes up to 4adfcd68cc10449e2fda0f9fac8b09f2b5c09a02: am335x evm: Add am335x_evm_spiboot target (2013-02-18 13:51:20 -0500) Chase Maupin (3): am335x_evm: Add NAND environment variables am335x_evm: Add SPI environment variables am335x_evm: Add NET environment variables Enric Balletbo i Serra (3): OMAP3: igep00x0: use official board names. OMAP3: igep00x0: add missing include mach-types.h OMAP3: igep00x0: Add new IGEP COM PROTON. Howard Gray (1): omap3: mvblx: change console to ttyO0 and make silent by default. Ilya Yanok (4): spl: support for booting via usbeth am33xx: support for booting via usbeth am335x_evm: enable support for booting via USB doc/SPL/README.am335x-network: Document using ethernet (and USB) SPL Lars Poeschel (1): am33xx: pcm051: Remove wp pin mux for sd-card Michael Jones (2): omap3: mvblx: select fpgafilename according to orientation omap3: mvblx: pass FPGA version to the kernel Tom Rini (1): am335x evm: Add am335x_evm_spiboot target Tomas Novotny (2): da8xx: ea20: Add the configuration define for the exact SoC variant da8xx: Add the missing pinmux for da830 to the gpio driver robertcnel...@gmail.com (2): beagle: expansion boards: retry i2c_read with 16bit addressing beagle: expansion boards: add LSR COM6L adapter MAINTAINERS |1 + arch/arm/cpu/armv7/omap-common/boot-common.c |3 + arch/arm/include/asm/arch-am33xx/spl.h |1 + arch/arm/include/asm/arch-davinci/gpio.h |4 + board/isee/igep00x0/igep00x0.h |7 +- board/matrix_vision/mvblx/fpga.c | 14 ++- board/matrix_vision/mvblx/sys_eeprom.c | 24 + board/phytec/pcm051/mux.c|1 - board/ti/am335x/board.c | 38 board/ti/beagle/beagle.c | 14 +++ boards.cfg |2 + common/spl/spl.c |5 + doc/SPL/README.am335x-network| 92 ++ drivers/gpio/da8xx_gpio.c| 133 ++ include/configs/am335x_evm.h | 82 +++- include/configs/ea20.h |1 + include/configs/igep00x0.h |7 +- include/configs/omap3_mvblx.h| 25 +++-- spl/Makefile |2 + 19 files changed, 424 insertions(+), 32 deletions(-) create mode 100644 doc/SPL/README.am335x-network -- 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 0/5] am335x_evm: Misc environment enhancements
On Fri, Feb 08, 2013 at 04:20:10PM -0500, Tom Rini wrote: > Hey all, > > The bulk of this series adds environemnt variables to better support > working with NAND, SPI or ethernet. In the case of SPI we also add a > spiboot target which will change environment to be looked for on SPI > rather than NAND. This also documents how to use the network SPL > options. Applied to u-boot-ti/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] am335x_evm: Fix CPSW ethernet on GP EVM and EVM-SK
On Tue, Feb 12, 2013 at 03:07:43PM -0500, Tom Rini wrote: > In commit cfd4ff6 we implemented part of advisory 1.0.10 (internal delay > for RGMII mode not supported). This in turn however requires that we > set the tx clock delay feature in the PHY itself. > > Signed-off-by: Tom Rini Applied to u-boot-ti/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] [U-Boot, 1/2] da8xx: ea20: Add the configuration define for the exact SoC variant
On Fri, Feb 01, 2013 at 06:44:06AM -, Tomas Novotny wrote: > Signed-off-by: Tomas Novotny > Cc: Tom Rini > Cc: Stefano Babic > Acked-by: Stefano Babic This and 2/2 have been applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] beagle: expansion boards: retry i2c_read with 16bit addressing
On Mon, Feb 04, 2013 at 06:03:10AM -, robertcnel...@gmail.com wrote: > Some expansion boards now ship with at24 eeproms that need to communicate > via 16bit addressing. > > Signed-off-by: Robert Nelson This and 2/2 have been applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am33xx: pcm051: Remove wp pin mux for sd-card
On Mon, Feb 04, 2013 at 11:13:58PM -, Lars Poeschel wrote: > From: Lars Poeschel > > The pcm051 does not have the wp pin connected to the sd-card socket. > Therefore remove the pinmux for the pin. The was a carry-over from > the am335x evm code. > > Signed-off-by: Lars Poeschel Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv2, 1/3] OMAP3: igep00x0: use official board names.
On Thu, Feb 07, 2013 at 12:40:04AM -, Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > This trivial patch only changes current boards names for the official > names. > > Signed-off-by: Enric Balletbo i Serra This as well as the rest of the series are now applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] omap3: mvblx: change console to ttyO0 and make silent by default.
On Thu, Feb 07, 2013 at 11:53:35PM -, Michael Jones wrote: > From: Howard Gray > > Also, change bootdelay to 0 but allow pressing 'S' to stop at U-Boot prompt. > > Signed-off-by: Michael Jones > Signed-off-by: Howard Gray > Signed-off-by: Michael Jones This along with the rest of the series have been applied to u-boot-ti/msater, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] USB SPL support for AM33xx / am335x_evm
On Tue, Feb 05, 2013 at 04:36:23PM -0500, Tom Rini wrote: > Hey all, > > The following is a slight update to Ilya's previous series for USB SPL > on am33xx platforms. The changes are that I've dropped two patches > needed to force usage on older platforms (where a ROM bug prevents USB > from being usable in ROM, so we had to feed SPL via UART, then feed > U-Boot via USB, which is useful for proof of concept) and a change to > make usb_ether determine the MAC to use, and follow the ROMs behavior > here. This is now applied to u-boot-ti/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 1/1] Add support for new SomIQ-AM37 system on module from MENTOREL Ltd SomIQ-AM37 is based on TI AM37/DM37 processors
On Thu, Jan 24, 2013 at 03:30:00PM +0300, Maxim Podbereznyy wrote:
> From: Maxim Podberezny
>
>
> Signed-off-by: Maxim Podberezny
Sorry I missed this at first.
First problem, you don't update the MAINTAINERS file for this board.
Next:
> diff --git a/arch/arm/include/asm/mach-types.h
> b/arch/arm/include/asm/mach-types.h
> index a676b6d..817e0e6 100644
> --- a/arch/arm/include/asm/mach-types.h
> +++ b/arch/arm/include/asm/mach-types.h
> @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
> #define MACH_TYPE_OMAP5_SEVM 3777
> #define MACH_TYPE_ARMADILLO_800EVA 3863
> #define MACH_TYPE_KZM9G4140
> +#define MACH_TYPE_SOMIQ_AM37 4196
Please do this in the config file as we only change mach-types on
re-sync with the kernel.
[snip]
> +++ b/include/configs/somiq_am37.h
[snip]
> +/*
> + * High Level Configuration Options
> + */
> +#define CONFIG_OMAP 1 /* in a TI OMAP core */
Just #define CONFIG_FOO
> +#define CONFIG_OMAP34XX 1 /* which is a 34XX */
> +#define CONFIG_SOMIQ_AM371 /* working with SomIQ-AM37 */
And we don't use CONFIG_SOMIQ_AM37 anywhere, so please don't.
> +#define CONFIG_SYS_BAUDRATE_TABLE{4800, 9600, 19200, 38400, 57600,\
> + 115200}
Please drop this and use the default table.
--
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] imx6, spl and falcon boot
Hi Kevin, I'm a bit late to this party, but have a couple of comments... On 02/19/2013 08:20 AM, Chaves, Kevin wrote: Thanks for the response, so the whoosh does not support holding > a key to get into another image? I guess that won't work. > Note that there's already support for key-handling in our Nitrogen6X code: https://github.com/boundarydevices/u-boot-imx6/blob/production/board/boundary/nitrogen6x/nitrogen6x.c#L779 So if I wanted to support the SPL on the nitrogent6x are there any instruction on what requirements it has to > support it. The use of SPL seems to be a separate topic. Is your objective simply a faster boot? We don't have any specific plans to add SPL support for Nitrogen6x, but are interested in hearing what you're after. I'm guessing all the work I'd need to do is in board/boundary/nitrogen6x? > Also how would I normally configure and build an spl for > a working board. There is a lot of config options > in the README for the spl. -Original Message- From: Alexandre Belloni [mailto:alexandre.bell...@piout.net] Sent: Tuesday, February 19, 2013 9:00 AM To: Wolfgang Denk Cc: Chaves, Kevin; u-boot@lists.denx.de; Dirk Behme Subject: Re: [U-Boot] imx6, spl and falcon boot On Tue, Feb 19, 2013 at 12:35:01PM +0100, Wolfgang Denk wrote : Dear Alexandre Belloni, In message <20130219112532.gb24...@piout.net> you wrote: No, that is not supported and probably won't be. Some people will argue I think you are wrong. This is definitely a "not supported _yet_". that you probably don't need a bootloader once you are able to boot a linux kernel as you can probably do everything you want from there. Yes, some people will think so, and some will actually do that. Others (and I would expect these to be the majority) will realize the benefits of being able to switch on demand (say, key press, jumper setting, etc.) between different boot modes, boot images, etc. I am absolutely sure that SPL support for iMX6 will be added rather sooner than later. Yeah, don't misinterpret me, I was just saying that it will not be > supported in whoosh. I also believe that SPL and falcon mode will > come to i.mx6 and I'm also interested in getting that support ;) Whoosh seems pretty compelling with such a small code base. Does it really boot faster though? Do you have any numbers for TTP (Time-to-penguin) on a SABRE Lite or SABRE SD? Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
On Thu, Jan 24, 2013 at 09:39:19PM -0600, Rob Herring wrote: > From: Rob Herring > > Currently, u-boot will always fixup the DT memory node on ARM. If the dtb > has correct memory information, then we don't want or need u-boot to touch > the memory node. Allow platforms to skip this by not filling in dram bank > information. > > Signed-off-by: Rob Herring OK. With the notion that it's best to not fiddle with already correct things, we should have a way "out" there. But this patch means that bd->bi_dram is never set which looks to have some bad side-effects for cache (see arch/arm/lib/cache-cp15.c) so can we come up with some other way out here? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
Hi Wolfgang, On Tue, Feb 19, 2013 at 1:19 AM, Wolfgang Denk wrote: > Dear Simon, > > In message > you > wrote: >> >> Thanks for looking at this so closely - it's just an RFC at this >> stage, but I think it has promise. > > Agreed. > >> > I think config_* is not a good name to use here - it has never been a >> > reserved prefix so far, so it is IMO a bad idea to turn it into one >> > now . We already have quite a number such variable names in the code >> > all over the place (not sure I caught them all): > ... >> These are variables, so won't conflict with the function macros used >> by this patch. But maybe we should try for something like cfg_...()? > > You are wrong. This includes a number of functions, and macros, too, > for example: > > void config_sdram(const struct emif_regs *regs); > void config_ddr_phy(const struct emif_regs *regs); > void config_cmd_ctrl(const struct cmd_control *cmd); > void config_ddr_data(int data_macrono, ...) > void config_io_ctrl(unsigned long val); > void config_ddr(unsigned int pll, unsigned int ioctrl, > void config_data_eye_leveling_samples(u32 emif_base); > static int config_pll_clk(enum pll_clocks index, ...) > static int config_core_clk(u32 ref, u32 freq) > # define config_fifo(dir, idx, addr) I will see if I can think of some other sane and obvious name that is little used in the source. Ideas welcome. But this isn't a very large number. It seems to be that we could easily adjust these symbols if we wanted to (and bear in mind that there are currently no conflicts, it is just confusing) - here are the files: for str in $(find . -name *.c -or -name *.h |xargs sed -n -f /tmp/s |sort |uniq); do echo $str; find . -name *.c -or -name *.h |xargs grep "[^a-zA-Z0-9_<]$str"; done config_aneg( ./drivers/qe/uec.c: err = curphy->config_aneg(uec->mii_info); config_buf( ./drivers/usb/gadget/ether.c: value = config_buf(gadget, req->buf, ./drivers/usb/gadget/composite.c:static int config_buf(struct usb_configuration *config, ./drivers/usb/gadget/composite.c: return config_buf(c, speed, cdev->req->buf, type); config_clock( ./arch/arm/cpu/armv7/tegra20/usb.c:static void config_clock(const u32 timing[]) ./arch/arm/cpu/armv7/tegra20/usb.c: config_clock(usb_pll[freq]); config_ddr( ./board/phytec/pcm051/board.c: config_ddr(DDR_CLK_MHZ, MT41J256M8HX15E_IOCTRL_VALUE, &ddr3_data, ./board/ti/am335x/board.c: config_ddr(303, MT41J128MJT125_IOCTRL_VALUE, &ddr3_data, ./board/ti/am335x/board.c: config_ddr(303, MT41J512M8RH125_IOCTRL_VALUE, &ddr3_evm_data, ./board/ti/am335x/board.c: config_ddr(266, MT47H128M16RT25E_IOCTRL_VALUE, &ddr2_data, ./arch/arm/include/asm/arch-am33xx/ddr_defs.h:void config_ddr(unsigned int pll, unsigned int ioctrl, ./arch/arm/cpu/armv7/am33xx/emif4.c:void config_ddr(unsigned int pll, unsigned int ioctrl, config_desc( ./drivers/usb/gadget/composite.c:static int config_desc(struct usb_composite_dev *cdev, unsigned w_value) ./drivers/usb/gadget/composite.c: value = config_desc(cdev, w_value); config_device( ./drivers/pci/pci.c:cfg->config_device(hose, dev, cfg); config_fifo( ./drivers/usb/musb/musb_core.c:# define config_fifo(dir, idx, addr) ./drivers/usb/musb/musb_core.c:# define config_fifo(dir, idx, addr) \ ./drivers/usb/musb/musb_core.c: config_fifo(tx, idx, fifoaddr); ./drivers/usb/musb/musb_core.c: config_fifo(rx, idx, fifoaddr); config_pin( ./drivers/gpio/db8500_gpio.c:static void config_pin(unsigned long cfg) ./drivers/gpio/db8500_gpio.c: * Configures several pins using config_pin(). Refer to that function for ./drivers/gpio/db8500_gpio.c: config_pin(cfgs[i]); config_sdram( ./arch/arm/include/asm/arch-am33xx/ddr_defs.h:void config_sdram(const struct emif_regs *regs); ./arch/arm/cpu/armv7/am33xx/emif4.c:config_sdram(regs); ./arch/arm/cpu/armv7/am33xx/ddr.c:void config_sdram(const struct emif_regs *regs) config_vtp( ./arch/arm/cpu/armv7/am33xx/emif4.c:static void config_vtp(void) ./arch/arm/cpu/armv7/am33xx/emif4.c:config_vtp(); > > And cfg_ is not much better: > > #define cfg_read(val, addr, type, op) > #define cfg_write(val, addr, type, op) > u16 cfg_type = 0; > unsigned cfg_val; > u32 *cfg_reg; > uintcfg_addr; > uintcfg_data; > ... ./drivers/video/exynos_fb.c:vid->cfg_gpio(); cfg_ldo( ./drivers/video/exynos_fb.c:vid->cfg_ldo(); cfg_oc( ./board/netta/pcmcia.c:static void cfg_oc(void) ./board/netta/pcmcia.c: cfg_oc(); cfg_read( ./drivers/pci/pci_indirect.c:#define cfg_read(val, addr, type, op) *val = op((type)(addr)) ./arch/x86/lib/pci_type1.c:#define cfg_read(val, addr, op) (*val = op((int)(addr))) ./arch/powerpc/cpu/mpc83xx/pcie.c:#define cfg_read(val, addr, type, op) \
Re: [U-Boot] [PATCH v1] Exynos5: Pinmux: Add fdt for pinmux
On 02/15/2013 12:00 PM, Akshay Saraswat wrote: > This patch adds fdt nodes for peripherals which require > pin muxing and configuration. Existing pinmux code modified > to retrieve gpio range and function related info from fdt. Is this the same DT binding that the Linux kernel uses; has it been reviewed/implemented by the kernel pinctrl maintainers and device tree maintainers? Where is the DT binding documentation file that describes the binding? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] Tegra: MMC: Add DT support to MMC driver for all T20 boards
On 02/18/2013 04:10 PM, Andy Fleming wrote:
> On Thu, Feb 14, 2013 at 3:04 PM, Tom Warren wrote:
>
>> tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
>> Tested on Seaboard, fully functional.
>>
>> Tamonten boards (medcom-wide, plutux, and tec) use a different/new
>> dtsi file w/common settings.
...
>> +void tegra_mmc_init(void)
>> +{
>> + int node_list[MAX_HOSTS], count;
>> + const void *blob = gd->fdt_blob;
>> + debug("%s entry\n", __func__);
>> +
>> + count = fdtdec_find_aliases_for_id(blob, "sdhci",
>> + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
>> + debug("%s: count of sdhci nodes is %d\n", __func__, count);
>> +
>> + if (process_nodes(blob, node_list, count)) {
>> + printf("%s: Error processing mmc node(s)!\n", __func__);
>> + return;
>> + }
>> +}
>
> Hmmm what does fdtdec_find_aliases_for_id() do? It looks like you are
> attempting to go through all of the sdhci nodes, and I can't help but
> wonder why you wouldn't use the approach the kernel uses --
> for_each_compatible_node()? I'm a little worried that "aliases" are being
> overused, here.
IIRC, the implementation of fdtdec_find_aliases_for_id() basically is
for_each_compatible_node(), followed by looking up any alias definitions
for alias name "sdhci" that reference those nodes.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
It's not so much a faster boot I'm looking for but just relying less on uboot to initialize the device. The initial idea by my superiors is make an infallible way to update uboot, since they think they'll screw it up and have to support a field update. So we wanted to make two images with uboot/kernel/rfs, one for recovery and have a way to switch the settings on startup. That way we have a small first stage boot that won't ever need to be updated so long as it can boot from two different partitions. I realized it probably wasn't that useful to keep uboot around since the spl+falcon will increase the boot time. Figured I could kill two birds with one stone here. Faster boot, and no need to update the bootloader in the field, or at least minimize how much could change in its start up procedure so there is less to "fix" in the future. -Original Message- From: Eric Nelson [mailto:eric.nel...@boundarydevices.com] Sent: Tuesday, February 19, 2013 11:34 AM To: Chaves, Kevin Cc: Alexandre Belloni; Wolfgang Denk; u-boot@lists.denx.de; Dirk Behme Subject: Re: [U-Boot] imx6, spl and falcon boot Hi Kevin, I'm a bit late to this party, but have a couple of comments... On 02/19/2013 08:20 AM, Chaves, Kevin wrote: > Thanks for the response, so the whoosh does not support holding > a key to get into another image? I guess that won't work. > Note that there's already support for key-handling in our Nitrogen6X code: https://github.com/boundarydevices/u-boot-imx6/blob/production/board/boundary/nitrogen6x/nitrogen6x.c#L779 > So if I wanted to support the SPL on the nitrogent6x are there any > instruction on what requirements it has to > support it. > The use of SPL seems to be a separate topic. Is your objective simply a faster boot? We don't have any specific plans to add SPL support for Nitrogen6x, but are interested in hearing what you're after. > I'm guessing all the work I'd need to do is in board/boundary/nitrogen6x? > Also how would I normally configure and build an spl for > a working > board. There is a lot of config options > in the README for the spl. > > -Original Message- > From: Alexandre Belloni [mailto:alexandre.bell...@piout.net] > Sent: Tuesday, February 19, 2013 9:00 AM > To: Wolfgang Denk > Cc: Chaves, Kevin; u-boot@lists.denx.de; Dirk Behme > Subject: Re: [U-Boot] imx6, spl and falcon boot > > On Tue, Feb 19, 2013 at 12:35:01PM +0100, Wolfgang Denk wrote : >> Dear Alexandre Belloni, >> >> In message <20130219112532.gb24...@piout.net> you wrote: >>> >>> No, that is not supported and probably won't be. Some people will >>> argue >> >> I think you are wrong. This is definitely a "not supported _yet_". >> >>> that you probably don't need a bootloader once you are able to boot >>> a linux kernel as you can probably do everything you want from there. >> >> Yes, some people will think so, and some will actually do that. >> Others (and I would expect these to be the majority) will realize the >> benefits of being able to switch on demand (say, key press, jumper >> setting, etc.) between different boot modes, boot images, etc. >> >> I am absolutely sure that SPL support for iMX6 will be added rather >> sooner than later. >> > > Yeah, don't misinterpret me, I was just saying that it will not be > supported in whoosh. I also believe that SPL and falcon mode will > come to > i.mx6 and I'm also interested in getting that support ;) > Whoosh seems pretty compelling with such a small code base. Does it really boot faster though? Do you have any numbers for TTP (Time-to-penguin) on a SABRE Lite or SABRE SD? Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Tue, Feb 19, 2013 at 3:22 PM, Chaves, Kevin wrote: > It's not so much a faster boot I'm looking for but just relying less on uboot > to initialize the device. The initial idea by my superiors is make an > infallible way to update uboot, since they think they'll screw it up and have > to support a field update. So we wanted to make two images with > uboot/kernel/rfs, one for recovery and have a way to switch the settings on > startup. That way we have a small first stage boot that won't ever need to be > updated so long as it can boot from two different partitions. > > I realized it probably wasn't that useful to keep uboot around since the > spl+falcon will increase the boot time. Figured I could kill two birds with > one stone here. Faster boot, and no need to update the bootloader in the > field, or at least minimize how much could change in its start up procedure > so there is less to "fix" in the future. If you just want the fallback and upgrade mode, you can get it with current u-boot + whatdog + bootcount and fw_env in target (or kexec). Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DFU on OMAP4?
Greetings, I've been trying to do some feasibility (performance / features) testing of DFU to see if it might work on a project I'm involved with. Due to architecture similarities I'm trying to do this using a custom-built u-boot from Denx mainline on a OMAP4460 ES1.1 Pandaboard. But I've been having problems. I'm not sure I have the right set of CONFIG options. The DFU-relevant ones (I think) are: #define CONFIG_CMD_DFU #define CONFIG_DFU_FUNCTION #define CONFIG_DFU_MMC #define CONFIG_USBDOWNLOAD_GADGET #define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_OMAP #define CONFIG_USB_GADGET_VBUS_DRAW 500 #define CONFIG_G_DNL_MANUFACTURER "TI"// just #define CONFIG_G_DNL_VENDOR_NUM 0x0451 // for #define CONFIG_G_DNL_PRODUCT_NUM0xd022 // evaluation #define CONFIG_DFU_ALT \ "ipl mmc 100 100;" \ "u-boot mmc 200 200\0" \ … #define CONFIG_EXTRA_ENV_SETTINGS \ "dfu_alt_info=" CONFIG_DFU_ALT \ … With this I get unresolved symbols at link time: /home/cashwell/eval/u-boot/common/cmd_dfu.c:64: undefined reference to `usb_gadget_handle_interrupts' drivers/usb/gadget/libusb_gadget.o: In function `usb_composite_unregister': /home/cashwell/eval/u-boot/drivers/usb/gadget/composite.c:1081: undefined reference to `usb_gadget_unregister_driver' drivers/usb/gadget/libusb_gadget.o: In function `usb_composite_register': /home/cashwell/eval/u-boot/drivers/usb/gadget/composite.c:1067: undefined reference to `usb_gadget_register_driver' The only possibilities I can find that might resolve those missing functions are in the files: ./drivers/usb/musb-new/musb_uboot.c ./drivers/usb/gadget/s3c_udc_otg.c ./drivers/usb/gadget/pxa25x_udc.c ./drivers/usb/gadget/mv_udc.c But I'm confused by the relationship between musb, musb-new, and the UDC gadget drivers. I also can't find UDC code for OMAP4 that would work for DFU. Am I trying to do something that's impossible on OMAP4 using its built-in OTG controller and PHY or am I just doing something dumb? Has anyone used u-boot DFU on a Pandaboard? Sorry for the n00b question but I've been banging my head on this for several days and I just can't sort out which part is the horse and which the cart. Best regards, -Michael Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
So uboot can recover if it's bad using watchdog? How does this work if the binary is clobbered? -Original Message- From: otavio.salva...@gmail.com [mailto:otavio.salva...@gmail.com] On Behalf Of Otavio Salvador Sent: Tuesday, February 19, 2013 1:34 PM To: Chaves, Kevin Cc: Eric Nelson; u-boot@lists.denx.de; Dirk Behme Subject: Re: [U-Boot] imx6, spl and falcon boot On Tue, Feb 19, 2013 at 3:22 PM, Chaves, Kevin wrote: > It's not so much a faster boot I'm looking for but just relying less on uboot > to initialize the device. The initial idea by my superiors is make an > infallible way to update uboot, since they think they'll screw it up and have > to support a field update. So we wanted to make two images with > uboot/kernel/rfs, one for recovery and have a way to switch the settings on > startup. That way we have a small first stage boot that won't ever need to be > updated so long as it can boot from two different partitions. > > I realized it probably wasn't that useful to keep uboot around since the > spl+falcon will increase the boot time. Figured I could kill two birds with > one stone here. Faster boot, and no need to update the bootloader in the > field, or at least minimize how much could change in its start up procedure > so there is less to "fix" in the future. If you just want the fallback and upgrade mode, you can get it with current u-boot + whatdog + bootcount and fw_env in target (or kexec). Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Tue, Feb 19, 2013 at 3:48 PM, Chaves, Kevin wrote: > So uboot can recover if it's bad using watchdog? How does this work if the > binary is clobbered? Watchdog + bootcount. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patch to support Xilinx 1000BASE-X phy (GTX)
Dear Charles Coldwell, In message you wrote: > and here it is again, in-line > > commit 39695029bc15041c809df3db4ba19bd729c447fa > Author: Charles Coldwell > Date: Tue Feb 19 08:27:33 2013 -0500 > > Changes to support the Xilinx 1000BASE-X phy (GTX/MGT) > > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > index d0ed766..8a38ccb 100644 > --- a/drivers/net/phy/phy.c > +++ b/drivers/net/phy/phy.c > @@ -75,6 +75,10 @@ static int genphy_config_advert(struct phy_device *phydev) > adv |= ADVERTISE_PAUSE_CAP; > if (advertise & ADVERTISED_Asym_Pause) > adv |= ADVERTISE_PAUSE_ASYM; > + if (advertise & ADVERTISED_1000baseX_Half) > + adv |= ADVERTISE_1000XHALF; > + if (advertise & ADVERTISED_1000baseX_Full) > + adv |= ADVERTISE_1000XFULL; Your patch is white space corrupted. Please fix your mailer. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
Dear Simon Glass, In message you wrote: > > > You are wrong. This includes a number of functions, and macros, too, > > for example: ... > That's a very manageable and small series of patches I think if we > want to use either. I do like an obvious name, and we already have > CONFIG_... I think we really need to define a new, so far unused name space for these, and reserve it for such purpose. > Yes this will definitely increase the time. The current brute force > 'sed' of all headers isn't very efficient. How impossible would it be > to regenerate this only when someone adds a new CONFIG, and then check > it into the source? Doesn't work - assume you are hacking on your new code (without checking in) - and if runs haywire because the needed re-scan is not done... > > Does not the already existing "include/autoconf.mk" contain this > > information? In any case, please check "tools/scripts/define2mk.sed" > > It only has a list of CONFIG variables that are enabled for the board. > The C code will then get compile errors if it uses a config that is > not enabled. So we need to define all the others to be 0 so that the > code still compiles. I see. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human race is faced with a cruel choice: work or daytime tele- vision. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
Dear Rob Herring,
In message <1359085160-28675-1-git-send-email-robherri...@gmail.com> you wrote:
>
> Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
> has correct memory information, then we don't want or need u-boot to touch
> the memory node. Allow platforms to skip this by not filling in dram bank
> information.
Well, if this is what you want, then please implement just this, and
do not do much more.
> void __dram_init_banksize(void)
> {
> +#if CONFIG_NR_DRAM_BANKS
> gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> gd->bd->bi_dram[0].size = gd->ram_size;
> +#endif
> }
This change will leave the memory information in struct bd_info
uninitialized, so the "bdinfo" command will print just bogus data.
This is not a good idea.
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -79,6 +79,7 @@ void arch_lmb_reserve(struct lmb *lmb)
> #ifdef CONFIG_OF_LIBFDT
> static int fixup_memory_node(void *blob)
> {
> +#if CONFIG_NR_DRAM_BANKS
> bd_t*bd = gd->bd;
> int bank;
> u64 start[CONFIG_NR_DRAM_BANKS];
> @@ -90,6 +91,9 @@ static int fixup_memory_node(void *blob)
> }
>
> return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
> +#else
> + return 0;
> +#endif
I dislike this. If you want to make a property of your device tree
"immutable", then you should mark it there as such. Instead of
removing the code here, U-Boot should then check for such a property
and leave the value unchanged.
Actually you are reaching here a point where it seems necessary that
U-Boot itself is able to read the DT to configure itself correctly,
i. e. the memory size information it holds should then also be
extracted from the DT.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The faster I go, the behinder I get. -- Lewis Carroll
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: highbank: remove DRAM bank setup
Dear Rob Herring,
In message <1359085160-28675-2-git-send-email-robherri...@gmail.com> you wrote:
>
> The memory sizes in highbank dtb's are already correct, so remove the DRAM
> bank setup so the memory node is not fixed up by u-boot.
I think you do more here...
> -void dram_init_banksize(void)
> -{
> - gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> - gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> -}
...
> -#define CONFIG_NR_DRAM_BANKS 1
> +#define CONFIG_NR_DRAM_BANKS 0
I think this is a very bad idea, as you will now be no longer possible
to get information about memory sizes from U-Boot. For exmaple,
"bdinfo" will not print any reasonable value any more.
Please don't do that!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Ever try. Ever fail. No matter. Try again. Fail again. Fail better.
-- S. Beckett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/10] mx23_olinuxino: Enable USB support
On Tue, Feb 19, 2013 at 10:22 AM, Otavio Salvador wrote: >> Because this will not be used globally with all GPIOs, but only locally for >> this >> one case. So my suggestion is to postpone this change and do this in one >> large >> swipe afterwards. > > I see; I agree with you. I can take care of this GPIO change later then. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] V2: i.MX6: updates to support boards with multiple CPU options
V2 includes Copyright fixes and addition of MX6_ prefix as requested by Jason Liu. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/6] i.MX6: mx6qsabrelite: indent with tabs
This patch has no functional changes and simply replaces
leading spaces with tabs.
Signed-off-by: Eric Nelson
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 106 -
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index f010d0c..c6c64c3 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -46,12 +46,12 @@
DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
- PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
- PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
- PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \
- PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+ PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \
+ PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
#define ENET_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
@@ -72,9 +72,9 @@ DECLARE_GLOBAL_DATA_PTR;
int dram_init(void)
{
- gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
+ gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
- return 0;
+ return 0;
}
iomux_v3_cfg_t const uart1_pads[] = {
@@ -83,8 +83,8 @@ iomux_v3_cfg_t const uart1_pads[] = {
};
iomux_v3_cfg_t const uart2_pads[] = {
- MX6Q_PAD_EIM_D26__UART2_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6Q_PAD_EIM_D27__UART2_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6Q_PAD_EIM_D26__UART2_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6Q_PAD_EIM_D27__UART2_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
};
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
@@ -132,23 +132,23 @@ struct i2c_pads_info i2c_pad_info2 = {
};
iomux_v3_cfg_t const usdhc3_pads[] = {
- MX6Q_PAD_SD3_CLK__USDHC3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD3_CMD__USDHC3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD3_DAT5__GPIO_7_0| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */
+ MX6Q_PAD_SD3_CLK__USDHC3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD3_CMD__USDHC3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD3_DAT5__GPIO_7_0| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */
};
iomux_v3_cfg_t const usdhc4_pads[] = {
- MX6Q_PAD_SD4_CLK__USDHC4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD4_CMD__USDHC4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6Q_PAD_NANDF_D6__GPIO_2_6| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */
+ MX6Q_PAD_SD4_CLK__USDHC4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD4_CMD__USDHC4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6Q_PAD_NANDF_D6__GPIO_2_6| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */
};
iomux_v3_cfg_t const enet_pads1[] = {
@@ -227,7 +227,7 @@ iomux_v3_cfg_t const usb_pads[] = {
static void setup_iomux_uart(void)
{
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
- imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads));
+ imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads));
}
#ifdef CONFIG_USB_EHCI_MX6
@@ -246,55 +246,55 @@ int board_ehci_hcd_init(int port)
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg usdhc_cfg[2] = {
- {USDHC3_BASE_ADDR},
- {USDHC4_BASE_ADDR},
+ {USDHC3_BASE_ADDR},
+ {USDHC4_BASE_ADDR},
};
int board_mmc_getcd(struct mmc *mmc)
{
- struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
- int ret;
+ struct fsl_esdhc_cfg
[U-Boot] [PATCH V2 3/6] i.MX6: crm_regs: define CCM_CCGRx for use in board config files
Signed-off-by: Eric Nelson
---
arch/arm/include/asm/arch-mx6/crm_regs.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index d670f30..7676457 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -20,6 +20,17 @@
#ifndef __ARCH_ARM_MACH_MX6_CCM_REGS_H__
#define __ARCH_ARM_MACH_MX6_CCM_REGS_H__
+#define CCM_CCGR0 0x020C4068
+#define CCM_CCGR1 0x020C406c
+#define CCM_CCGR2 0x020C4070
+#define CCM_CCGR3 0x020C4074
+#define CCM_CCGR4 0x020C4078
+#define CCM_CCGR5 0x020C407c
+#define CCM_CCGR6 0x020C4080
+
+#define PMU_MISC2 0x020C8170
+
+#ifndef __ASSEMBLY__
struct mxc_ccm_reg {
u32 ccr;/* 0x */
u32 ccdr;
@@ -105,6 +116,7 @@ struct mxc_ccm_reg {
u32 analog_pfd_528_clr;
u32 analog_pfd_528_tog;
};
+#endif
/* Define the bits in register CCR */
#define MXC_CCM_CCR_RBC_EN (1 << 27)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 5/6] i.MX6DL: define IOMUX pads NANDF_CS1-3 for use as GPIO
Signed-off-by: Eric Nelson
---
arch/arm/include/asm/arch-mx6/mx6dl_pins.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index 0395357..9494e41 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -105,6 +105,9 @@ enum {
MX6_PAD_KEY_COL3__GPIO_4_12 = IOMUX_PAD(0x0638, 0x0250, 5,
0x, 0, 0),
MX6_PAD_KEY_ROW3__I2C2_SDA = IOMUX_PAD(0x064C, 0x0264, 4 |
IOMUX_CONFIG_SION, 0x0874, 1, 0),
MX6_PAD_KEY_ROW3__GPIO_4_13 = IOMUX_PAD(0x064C, 0x0264, 5,
0x, 0, 0),
+ MX6_PAD_NANDF_CS1__GPIO_6_14= IOMUX_PAD(0x0660, 0x0278, 5,
0x, 0, 0),
+ MX6_PAD_NANDF_CS2__GPIO_6_15= IOMUX_PAD(0x0664, 0x027C, 5,
0x, 0, 0),
+ MX6_PAD_NANDF_CS3__GPIO_6_16= IOMUX_PAD(0x0668, 0x0280, 5,
0x, 0, 0),
MX6_PAD_NANDF_D1__GPIO_2_1 = IOMUX_PAD(0x0670, 0x0288, 5,
0x, 0, 0),
MX6_PAD_NANDF_D2__GPIO_2_2 = IOMUX_PAD(0x0674, 0x028C, 5,
0x, 0, 0),
MX6_PAD_NANDF_D3__GPIO_2_3 = IOMUX_PAD(0x0678, 0x0290, 5,
0x, 0, 0),
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/6] i.MX6: Add DDR controller registers
Signed-off-by: Eric Nelson --- arch/arm/include/asm/arch-mx6/mx6-ddr.h | 85 + arch/arm/include/asm/arch-mx6/mx6dl-ddr.h | 71 arch/arm/include/asm/arch-mx6/mx6q-ddr.h | 69 +++ 3 files changed, 225 insertions(+) create mode 100644 arch/arm/include/asm/arch-mx6/mx6-ddr.h create mode 100644 arch/arm/include/asm/arch-mx6/mx6dl-ddr.h create mode 100644 arch/arm/include/asm/arch-mx6/mx6q-ddr.h diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h b/arch/arm/include/asm/arch-mx6/mx6-ddr.h new file mode 100644 index 000..1fdc1d4 --- /dev/null +++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h @@ -0,0 +1,85 @@ +/* + * Copyright (C) 2013 Boundary Devices Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ +#ifndef __ASM_ARCH_MX6_DDR_H__ +#define __ASM_ARCH_MX6_DDR_H__ + +#ifdef CONFIG_MX6Q +#include "mx6q-ddr.h" +#else +#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S) +#include "mx6dl-ddr.h" +#else +#error "Please select cpu" +#endif /* CONFIG_MX6DL or CONFIG_MX6S */ +#endif /* CONFIG_MX6Q */ + +#define MX6_MMDC_P0_MDCTL 0x021b +#define MX6_MMDC_P0_MDPDC 0x021b0004 +#define MX6_MMDC_P0_MDOTC 0x021b0008 +#define MX6_MMDC_P0_MDCFG0 0x021b000c +#define MX6_MMDC_P0_MDCFG1 0x021b0010 +#define MX6_MMDC_P0_MDCFG2 0x021b0014 +#define MX6_MMDC_P0_MDMISC 0x021b0018 +#define MX6_MMDC_P0_MDSCR 0x021b001c +#define MX6_MMDC_P0_MDREF 0x021b0020 +#define MX6_MMDC_P0_MDRWD 0x021b002c +#define MX6_MMDC_P0_MDOR 0x021b0030 +#define MX6_MMDC_P0_MDASP 0x021b0040 +#define MX6_MMDC_P0_MAPSR 0x021b0404 +#define MX6_MMDC_P0_MPZQHWCTRL 0x021b0800 +#define MX6_MMDC_P0_MPWLDECTRL00x021b080c +#define MX6_MMDC_P0_MPWLDECTRL10x021b0810 +#define MX6_MMDC_P0_MPODTCTRL 0x021b0818 +#define MX6_MMDC_P0_MPRDDQBY0DL0x021b081c +#define MX6_MMDC_P0_MPRDDQBY1DL0x021b0820 +#define MX6_MMDC_P0_MPRDDQBY2DL0x021b0824 +#define MX6_MMDC_P0_MPRDDQBY3DL0x021b0828 +#define MX6_MMDC_P0_MPDGCTRL0 0x021b083c +#define MX6_MMDC_P0_MPDGCTRL1 0x021b0840 +#define MX6_MMDC_P0_MPRDDLCTL 0x021b0848 +#define MX6_MMDC_P0_MPWRDLCTL 0x021b0850 +#define MX6_MMDC_P0_MPMUR0 0x021b08b8 + +#define MX6_MMDC_P1_MDCTL 0x021b4000 +#define MX6_MMDC_P1_MDPDC 0x021b4004 +#define MX6_MMDC_P1_MDOTC 0x021b4008 +#define MX6_MMDC_P1_MDCFG0 0x021b400c +#define MX6_MMDC_P1_MDCFG1 0x021b4010 +#define MX6_MMDC_P1_MDCFG2 0x021b4014 +#define MX6_MMDC_P1_MDMISC 0x021b4018 +#define MX6_MMDC_P1_MDSCR 0x021b401c +#define MX6_MMDC_P1_MDREF 0x021b4020 +#define MX6_MMDC_P1_MDRWD 0x021b402c +#define MX6_MMDC_P1_MDOR 0x021b4030 +#define MX6_MMDC_P1_MDASP 0x021b4040 +#define MX6_MMDC_P1_MAPSR 0x021b4404 +#define MX6_MMDC_P1_MPZQHWCTRL 0x021b4800 +#define MX6_MMDC_P1_MPWLDECTRL00x021b480c +#define MX6_MMDC_P1_MPWLDECTRL10x021b4810 +#define MX6_MMDC_P1_MPODTCTRL 0x021b4818 +#define MX6_MMDC_P1_MPRDDQBY0DL0x021b481c +#define MX6_MMDC_P1_MPRDDQBY1DL0x021b4820 +#define MX6_MMDC_P1_MPRDDQBY2DL0x021b4824 +#define MX6_MMDC_P1_MPRDDQBY3DL0x021b4828 +#define MX6_MMDC_P1_MPDGCTRL0 0x021b483c +#define MX6_MMDC_P1_MPDGCTRL1 0x021b4840 +#define MX6_MMDC_P1_MPRDDLCTL 0x021b4848 +#define MX6_MMDC_P1_MPWRDLCTL 0x021b4850 +#define MX6_MMDC_P1_MPMUR0 0x021b48b8 + +#endif /*__ASM_ARCH_MX6_DDR_H__ */ diff --git a/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h b/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h new file mode 100644 index 000..325da33 --- /dev/null +++ b/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h @@ -0,0 +1,71 @@ +/* + * Copyright (C) 2013 Boundary Devices Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + + * You should have received a copy of the GNU General Public L
[U-Boot] [PATCH V2 4/6] i.MX6: crm_regs: define IOMUXC_GPR4/6/7
Signed-off-by: Eric Nelson --- arch/arm/include/asm/arch-mx6/iomux.h |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/include/asm/arch-mx6/iomux.h b/arch/arm/include/asm/arch-mx6/iomux.h index d23abd7..d67f600 100644 --- a/arch/arm/include/asm/arch-mx6/iomux.h +++ b/arch/arm/include/asm/arch-mx6/iomux.h @@ -16,6 +16,11 @@ #ifndef __ASM_ARCH_IOMUX_H__ #define __ASM_ARCH_IOMUX_H__ + +#define MX6_IOMUXC_GPR40x020e0010 +#define MX6_IOMUXC_GPR60x020e0018 +#define MX6_IOMUXC_GPR70x020e001c + /* * IOMUXC_GPR13 bit fields */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6: Add hdmidet command
Hi Stefano, This seems to have gotten lost in the shuffle. It's showing as "Changes requested" in Patchwork: http://patchwork.ozlabs.org/patch/186280/ Is there something you'd like changed? Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6: Add hdmidet command
On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson wrote: > Hi Stefano, > > This seems to have gotten lost in the shuffle. > > It's showing as "Changes requested" in Patchwork: > > http://patchwork.ozlabs.org/patch/186280/ > > Is there something you'd like changed? > > Please advise, I'd say to use space between the '+' as done in other code. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] to support Xilinx 1000BASE-X phy (GTX)
On Tue, 19 Feb 2013, Wolfgang Denk wrote:
>
> Your patch is white space corrupted. Please fix your mailer.
commit 39695029bc15041c809df3db4ba19bd729c447fa
Author: Charles Coldwell
Date: Tue Feb 19 08:27:33 2013 -0500
Changes to support the Xilinx 1000BASE-X phy (GTX/MGT)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d0ed766..8a38ccb 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -75,6 +75,10 @@ static int genphy_config_advert(struct phy_device *phydev)
adv |= ADVERTISE_PAUSE_CAP;
if (advertise & ADVERTISED_Asym_Pause)
adv |= ADVERTISE_PAUSE_ASYM;
+ if (advertise & ADVERTISED_1000baseX_Half)
+ adv |= ADVERTISE_1000XHALF;
+ if (advertise & ADVERTISED_1000baseX_Full)
+ adv |= ADVERTISE_1000XFULL;
if (adv != oldadv) {
err = phy_write(phydev, MDIO_DEVAD_NONE, MII_ADVERTISE, adv);
@@ -288,6 +292,7 @@ static int genphy_parse_link(struct phy_device *phydev)
if (mii_reg & BMSR_ANEGCAPABLE) {
u32 lpa = 0;
u32 gblpa = 0;
+ u32 estatus = 0;
/* Check for gigabit capability */
if (mii_reg & BMSR_ERCAP) {
@@ -327,6 +332,17 @@ static int genphy_parse_link(struct phy_device *phydev)
} else if (lpa & LPA_10FULL)
phydev->duplex = DUPLEX_FULL;
+
+ if (mii_reg & BMSR_ESTATEN)
+ estatus = phy_read(phydev, MDIO_DEVAD_NONE,
MII_ESTATUS);
+
+ if (estatus & (ESTATUS_1000_XFULL | ESTATUS_1000_XHALF |
+ ESTATUS_1000_TFULL | ESTATUS_1000_THALF)) {
+ phydev->speed = SPEED_1000;
+ if (estatus & (ESTATUS_1000_XFULL | ESTATUS_1000_TFULL))
+ phydev->duplex = DUPLEX_FULL;
+ }
+
} else {
u32 bmcr = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
@@ -384,6 +400,10 @@ int genphy_config(struct phy_device *phydev)
features |= SUPPORTED_1000baseT_Full;
if (val & ESTATUS_1000_THALF)
features |= SUPPORTED_1000baseT_Half;
+ if (val & ESTATUS_1000_XFULL)
+ features |= SUPPORTED_1000baseX_Full;
+ if (val & ESTATUS_1000_XHALF)
+ features |= SUPPORTED_1000baseX_Full;
}
phydev->supported = features;
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index fcb20fe..f6dbdb0 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -580,6 +580,8 @@ enum ethtool_sfeatures_retval_bits {
#define SUPPORTED_1baseKX4_Full(1 << 18)
#define SUPPORTED_1baseKR_Full (1 << 19)
#define SUPPORTED_1baseR_FEC (1 << 20)
+#define SUPPORTED_1000baseX_Half (1 << 21)
+#define SUPPORTED_1000baseX_Full (1 << 22)
/* Indicates what features are advertised by the interface. */
#define ADVERTISED_10baseT_Half(1 << 0)
@@ -603,6 +605,8 @@ enum ethtool_sfeatures_retval_bits {
#define ADVERTISED_1baseKX4_Full (1 << 18)
#define ADVERTISED_1baseKR_Full(1 << 19)
#define ADVERTISED_1baseR_FEC (1 << 20)
+#define ADVERTISED_1000baseX_Half (1 << 21)
+#define ADVERTISED_1000baseX_Full (1 << 22)
/* The following are all involved in forcing a particular link
* mode for the device for setting things. When getting the
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 8b92692..66b83d8 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -115,6 +115,8 @@
#define EXPANSION_MFAULTS 0x0010 /* Multiple faults detected*/
#define EXPANSION_RESV 0xffe0 /* Unused... */
+#define ESTATUS_1000_XFULL 0x8000 /* Can do 1000BX Full */
+#define ESTATUS_1000_XHALF 0x4000 /* Can do 1000BX Half */
#define ESTATUS_1000_TFULL 0x2000 /* Can do 1000BT Full */
#define ESTATUS_1000_THALF 0x1000 /* Can do 1000BT Half */
--
Charles M. Coldwell, W1CMC
"Turn on, log in, tune out"
Somerville, Massachusetts, New England (FN42kj)
GPG ID: 852E052F
GPG FPR: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible GPL violation
Hi, Short version: Is there anyone that can support me with enforcing GPL compliance on company that ships product with binary u-boot? Or did that in the past? Long version: Polish market is flooded with cheap DVB-T receivers (we're switching to digital tv now), android tablets etc. They're "made" (branded is probably better word) by local companies, and my guess is that most of them is violating GPL. Some time ago I've bought WIWA HD100 DVB-T receiver. I have coverage issues, so I decided to play a bit with this device, just to have fun (also to try to port Linux there). I already knew that other models made by this vendor are using u-boot, so I played a bit with HW, found serial port and: Hello U-Boot U-Boot 1.1.6 (Oct 13 2011 - 00:32:14) Board: MSTAR KRNOUS (CPU Speed 552 MHz) DRAM: 64 X 0 MBytes U-Boot is running at DRAM 0x8760 I also disassembled parts of asm code (AFAIR it was mips_cache_reset, but I may be wrong). I'd love to have sources (porting Linux to unknown, closed SOC is painful without documentation, u-boot sources are very helpful), so I wrote to manufacturer and called them several times. Unfortunately they either don't understand what I'm asking for, or deliberately ignoring my requests. I can't do much myself (except for nagging them for source code), as it's not my copyrights that they're infringing. Is there a chance that you can help me or should I try using GPL-Violations mailing list? Regards, Mateusz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Hi Eric, On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: [--snip--] > diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > new file mode 100644 > index 000..45b8879 > --- /dev/null > +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg [--snip--] > +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 > +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 ^A? > +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 > +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB > +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 > +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 ^A? > +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 > +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 > +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 > +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A > +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 > +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 > +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 > +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 > +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 > +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 > +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 > +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 > +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A > +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 > +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E > +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 > +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 > +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B > +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E > +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B > +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 > +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 > +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 > +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x > +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 [--snip--] tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
On 02/19/2013 01:26 PM, Wolfgang Denk wrote:
> Dear Rob Herring,
>
> In message <1359085160-28675-1-git-send-email-robherri...@gmail.com> you
> wrote:
>>
>> Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
>> has correct memory information, then we don't want or need u-boot to touch
>> the memory node. Allow platforms to skip this by not filling in dram bank
>> information.
>
> Well, if this is what you want, then please implement just this, and
> do not do much more.
>
>> void __dram_init_banksize(void)
>> {
>> +#if CONFIG_NR_DRAM_BANKS
>> gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>> gd->bd->bi_dram[0].size = gd->ram_size;
>> +#endif
>> }
>
> This change will leave the memory information in struct bd_info
> uninitialized, so the "bdinfo" command will print just bogus data.
>
> This is not a good idea.
This hunk can be dropped I think.
>> --- a/arch/arm/lib/bootm.c
>> +++ b/arch/arm/lib/bootm.c
>> @@ -79,6 +79,7 @@ void arch_lmb_reserve(struct lmb *lmb)
>> #ifdef CONFIG_OF_LIBFDT
>> static int fixup_memory_node(void *blob)
>> {
>> +#if CONFIG_NR_DRAM_BANKS
>> bd_t*bd = gd->bd;
>> int bank;
>> u64 start[CONFIG_NR_DRAM_BANKS];
>> @@ -90,6 +91,9 @@ static int fixup_memory_node(void *blob)
>> }
>>
>> return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
>> +#else
>> +return 0;
>> +#endif
>
> I dislike this. If you want to make a property of your device tree
> "immutable", then you should mark it there as such. Instead of
> removing the code here, U-Boot should then check for such a property
> and leave the value unchanged.
There is no such way defined to flag that and I'm not going to invent
one. It's not that the memory node is immutable, but the default should
not be "needs fixups". No one puts purposely wrong data in their DT. So
therefore all data should be immutable? What happens when we need to
fixup immutable data?
What I would really prefer to do is like powerpc where platforms
override this if they need the fixup and the default behavior is no
fixup. But that would require knowing which platforms do and don't need
the fixup. It only going to get harder to change that.
> Actually you are reaching here a point where it seems necessary that
> U-Boot itself is able to read the DT to configure itself correctly,
> i. e. the memory size information it holds should then also be
> extracted from the DT.
I thought about doing this. That's really an orthogonal issue. The
problem is you cannot adjust the amount of memory u-boot uses to be
different than the amount of RAM in the /memory node. If you adjust the
size in u-boot, the adjusted size is passed to the kernel no matter what.
There's issues with LPAE systems having >4GB of RAM as all the size and
address values are 32-bit. This could be fixed, but I'm not sure there
is much value in u-boot knowing about memory above 4GB as it can't
really access all of it and it would be purely informational.
Rob
>
> Best regards,
>
> Wolfgang Denk
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] timing issue - uboot freeze after pringing header
Hello Bo Shen, On Mon, 2013-02-18 at 11:06 +0800, Bo Shen wrote: > Hi John, > > On 02/16/2013 12:45 AM, John Stile wrote: > > I am trying to move from uboot-1.3.6 to uboot 2013.01, where the old > > works, the new prints this before freezing: > > > > U-Boot 2013.01 (Feb 14 2013 - 16:24:13) > > > > CPU: AT91SAM9G20 > > Crystal frequency: 18.432 MHz > > CPU clock: 396.288 MHz > > Master clock : 132.096 MHz > > > > My board is the at91sam9g20ek_2mmc. > > at91bootstrap-1.1.6 loads uboot. > > Please update the at91bootstrap to new version. > You can get the it from: git://github.com/linux4sam/at91bootstrap.git > using tag: v3.5.2 > or master branch > > For new bootstrap, the memory map for NAND flash has changed. More > information: > http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Linux4SAM_NandFlash_demo_Memory > > So, you need flash u-boot to 0x4 address, and change u-boot env as > the memory map (I will send patches for this later). > > Best Regards, > Bo Shen > > > I am trying both nandflash and dataflash versions, using > > include/configs/at91sam9260ek.h > > > > Messing with settings I have got it back to a state of not printing > > anything. I was wrong. it isn't a timing issue. In at91boostrap, I specified the wrong IMG_SIZE, and specifying the correct size solved the problem. I had only copied part of the binary to SDRAM, which lead to the program sometimes showing the initial banner before crashing. In my situation, I use buildroot-2011.11, which downloads at91boostrap from: ftp://www.at91.com/pub/at91bootstrap/ version AT91Bootstrap1.16.zip, and though updates are the available I have modified my st91boostrap and uboot, so upgrades are not so simple. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] am335x_evm: Enable CONFIG_CMD_BOOTZ
With v3.9 and later of the Linux Kernel defaulting to multi-platform images with omap2plus_defconfig, uImage isn't builtable anymore by default. Add CONFIG_CMD_BOOTZ so that we can still boot something the kernel spits out. Signed-off-by: Tom Rini --- include/configs/am335x_evm.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 33ee2c4..11ebd5c 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -35,6 +35,7 @@ #define CONFIG_MACH_TYPE MACH_TYPE_TIAM335EVM #define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG -- 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/4] omap5_evm: Enable CONFIG_CMD_BOOTZ
With v3.9 and later of the Linux Kernel defaulting to multi-platform images with omap2plus_defconfig, uImage isn't builtable anymore by default. Add CONFIG_CMD_BOOTZ so that we can still boot something the kernel spits out. Cc: Sricharan R Signed-off-by: Tom Rini --- include/configs/omap5_evm.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h index 623da77..85ea88b 100644 --- a/include/configs/omap5_evm.h +++ b/include/configs/omap5_evm.h @@ -55,6 +55,7 @@ #define CONFIG_MISC_INIT_R #define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] omap3_beagle: Enable CONFIG_CMD_BOOTZ
With v3.9 and later of the Linux Kernel defaulting to multi-platform images with omap2plus_defconfig, uImage isn't builtable anymore by default. Add CONFIG_CMD_BOOTZ so that we can still boot something the kernel spits out. Signed-off-by: Tom Rini --- include/configs/omap3_beagle.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 59255c4..48ce4c0 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -53,7 +53,8 @@ #define CONFIG_MISC_INIT_R -#define CONFIG_OF_LIBFDT 1 +#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ #define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] omap4_common: Enable CONFIG_CMD_BOOTZ
With v3.9 and later of the Linux Kernel defaulting to multi-platform images with omap2plus_defconfig, uImage isn't builtable anymore by default. Add CONFIG_CMD_BOOTZ so that we can still boot something the kernel spits out. Cc: Sricharan R Signed-off-by: Tom Rini --- include/configs/omap4_common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index 180cb24..6ae6a0f 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -52,7 +52,7 @@ #define CONFIG_MISC_INIT_R #define CONFIG_OF_LIBFDT 1 - +#define CONFIG_CMD_BOOTZ #define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS 1 #define CONFIG_INITRD_TAG 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] imx6, spl and falcon boot
Hi Eric, On Tue, Feb 19, 2013 at 09:33:58AM -0700, Eric Nelson wrote : > Whoosh seems pretty compelling with such a small code base. > Does it really boot faster though? Do you have any numbers > for TTP (Time-to-penguin) on a SABRE Lite or SABRE SD? > I don't exactly have that number but I believe you can go under 100ms. If you have a look at my presentation at ELCE [1] or that video on youtube [2], we basically are able too boot an start an openGL application under 600ms from reset. But that is a lot of self advertising, we can continue to discuss that off the ML if you want. [1] http://www.elinux.org/images/d/d1/Alexandre_Belloni_boottime_optimizations.pdf [2] https://www.youtube.com/watch?v=KPU4_QVPFZ0 Regards, -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote: Hi Eric, On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: [--snip--] diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg new file mode 100644 index 000..45b8879 --- /dev/null +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg [--snip--] +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 ^A? +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 ^A? +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 +DATA 4, MX6_MMDC_P0_MDSCR, 0x +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 [--snip--] tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. Thanks Benoît, I was going to bring this up in a separate thread. While working through the details of our 800MHz variants (Solo, Dual-Lite), and x256mx16 variants, I re-worked these numbers and it seems that we have an off-by-one issue with those fields. According to the JEDEC spec and data sheets, both tXS and tXPR should be 10nS greater than tRFC. Since the nominal clock for i.MX6 is 528MHz (1.89nS), this should be a delta of 6 clocks, not 5. This change should apply to mx6q_4x_mt41j128.cfg as well. There are some other things in that file that should be fixed as well. The biggest among them is the settings for P1_MPWLDECTRL0/1. These settings are indicative of a fly-by topology, which isn't used on SABRE Lite, and I don't think is used on SABRE SD. DATA 4 0x021b480c 0x00440044 DATA 4 0x021b4810 0x00440044 This was the primary thing that caused crashes under stress on SABRE Lite and led to our flurry of calibration tests as discussed here: http://boundarydevices.com/i-mx-6dq-u-boot-updates/ Should we take this up in a separate thread? It seems un-related to our Nitrogen6X board. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: Add new command to set USB 2.0 port test modes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2013 04:29 PM, Julius Werner wrote: > Hi Tom, > > This patch is not really target specific, it works on all platforms > that support USB 2.0. I just wrapped it in a new config option > because most people probably won't need it… it is only really > useful for hardware verification, so I figured whoever needs it can > hack in the config option himself. However, I could also just > remove the #ifdef and activate it by default if you prefer that. No > new code will get executed unless you type the new command, so it > should not have any negative effect besides a negligible code size > increase. Well, we should enable it at least on the board config you've tested the code with, and you can show how negligible the size difference is. The point is that adding code that's not enabled somewhere leads to bitrot. Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRI/rVAAoJENk4IS6UOR1W5yoP/jA1KZaqH/1a+uiF4TkMhOqO 1ureFhSUBG875EqnqJsjdGgYt/SZfwBtku5i+qZDtE5jAN6KpPOEV4grRUAYhWll dWpb503TK9Ow+sJKYk8KF+k+awyMwt60L2gZEYxtl2C8ZCGiC6MzEmA25W24pBKh Vj3g6Sg5tgoFPWFBFFXtP3UNgcIzDrmSE4UJzyzKXInap4dwHt+b6Z6EwZ4+iQ6t ekNYxMlEVgdmw2KeuGmDlvjQpmVpaavMYCEON6NbUuCeg830555ETxzC/k37obDq K+PPITocXiR6dm8J42nBA1kaoaG58oRLjCSFlPogVxQ/VdtuAf2RhX9MOBofBw4j VdyV4d90rTCMHdKqids71gdB2YxqkIVdschN7jjpeNHDUEk54dVB5dAW49UJmxhD SWMF03YAfM055W4F0h2CsoZHr/hYqRwDo2J3ljazCAAsSfYav0kdaI6HzZI1zFmd hjs+ThO3A3Ek+lGsSx3Gh0JKKGv/FyfstnrFMVpF098SNkblN7WP7BmCTcWD6ARq h+GecKlSnguzuOVkDjuLCLgJnPVLY2m4D9ixaTuVMGDgNyFCiC4n/TRamHgG7duW HgEyni0hgk3dV3YV9olFeNPaZv0DW+iF0dkQeUI61KfDl8Xi/2Vc4b0ds53NJQmQ fR0w3/FsjQbksD2/aGac =eCCl -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
On Tuesday, February 19, 2013 10:53:48 PM, Eric Nelson wrote: > On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote: > > Hi Eric, > > > > On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: > > [--snip--] > >> diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > >> b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > >> new file mode 100644 > >> index 000..45b8879 > >> --- /dev/null > >> +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > > [--snip--] > >> +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 > >> +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 > > ^A? > >> +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 > >> +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB > >> +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 > >> +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 > >^A? > >> +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 > >> +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 > >> +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 > >> +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A > >> +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 > >> +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 > >> +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 > >> +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 > >> +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 > >> +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 > >> +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 > >> +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 > >> +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 > >> +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 > >> +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 > >> +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 > >> +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A > >> +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 > >> +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E > >> +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 > >> +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 > >> +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B > >> +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E > >> +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B > >> +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 > >> +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 > >> +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 > >> +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 > >> +DATA 4, MX6_MMDC_P0_MDSCR, 0x > >> +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 > > [--snip--] > > > > tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. > > > > Thanks Benoît, > > I was going to bring this up in a separate thread. > > While working through the details of our 800MHz > variants (Solo, Dual-Lite), and x256mx16 variants, > I re-worked these numbers and it seems that we > have an off-by-one issue with those fields. Probably because it has been missed that the bit-field value is the number of clock cycles minus 1. > According to the JEDEC spec and data sheets, > both tXS and tXPR should be 10nS greater than tRFC. Indeed, or more precisely, max(5 nCK, tRFC + 10 ns). > Since the nominal clock for i.MX6 is 528MHz (1.89nS), I used 532 MHz because this is a more standard value, and I found several close different values in the documentation, so in the doubt, I chose the worst case. With 528 MHz, the bit-field value would be 0x59. > this should be a delta of 6 clocks, not 5. Delta with what? > This change should apply to mx6q_4x_mt41j128.cfg as well. Sure. > There are some other things in that file that should > be fixed as well. The biggest among them is the settings > for P1_MPWLDECTRL0/1. Note that in this series, I have only reviewed the register values that changed in my series, and only for 1066mhz_4x128mx16.cfg. > These settings are indicative of a fly-by topology, > which isn't used on SABRE Lite, and I don't think > is used on SABRE SD. > > DATA 4 0x021b480c 0x00440044 > DATA 4 0x021b4810 0x00440044 > > This was the primary thing that caused crashes > under stress on SABRE Lite and led to our flurry of > calibration tests as discussed here: > > http://boundarydevices.com/i-mx-6dq-u-boot-updates/ OK. I had not looked in detail into this. > Should we take this up in a separate thread? It seems > un-related to our Nitrogen6X board. As you prefer. This is related to this series, but a very specific subject per se. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] am335x_evm: Enable CONFIG_CMD_BOOTZ
> "Tom" == Tom Rini writes: Tom> With v3.9 and later of the Linux Kernel defaulting to multi-platform Tom> images with omap2plus_defconfig, uImage isn't builtable anymore by Tom> default. Add CONFIG_CMD_BOOTZ so that we can still boot something the Tom> kernel spits out. Tom> Signed-off-by: Tom Rini Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Hi Benoît, On 02/19/2013 03:31 PM, Benoît Thébaudeau wrote: On Tuesday, February 19, 2013 10:53:48 PM, Eric Nelson wrote: On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote: Hi Eric, On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: [--snip--] diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg new file mode 100644 index 000..45b8879 --- /dev/null +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg [--snip--] +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 ^A? +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 ^A? +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 +DATA 4, MX6_MMDC_P0_MDSCR, 0x +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 [--snip--] tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. Thanks Benoît, I was going to bring this up in a separate thread. While working through the details of our 800MHz variants (Solo, Dual-Lite), and x256mx16 variants, I re-worked these numbers and it seems that we have an off-by-one issue with those fields. Probably because it has been missed that the bit-field > value is the number of clock cycles minus 1. Right. All of these fields are plus 1. MDCFG0.tRFC MDCFG0.tXS MDOR.tXPR Since they're all in the same units, the requirements are: MDCFG0.tXS >= MDCFG0.tRFC + 10nS and MDOR.tXPR >= MDCFG0.tRFC + 10nS Since we operate at ~528MHz, each clock is less than 2 nS, and we need 6 more clocks for each. According to the JEDEC spec and data sheets, both tXS and tXPR should be 10nS greater than tRFC. Indeed, or more precisely, max(5 nCK, tRFC + 10 ns). Yep. I shortened because nothing approaches 5nCK. And note that this is the minimum spec, not the target. Since the nominal clock for i.MX6 is 528MHz (1.89nS), I used 532 MHz because this is a more standard value, and I found several close different values in the documentation, so in the doubt, I chose the worst case. With 528 MHz, the bit-field value would be 0x59. Either way, we need 6 clocks to get > 10nS. this should be a delta of 6 clocks, not 5. Delta with what? Sorry. I meant the Delta between MDCFG0.tRFC and the other two fields. This change should apply to mx6q_4x_mt41j128.cfg as well. Sure. There are some other things in that file that should be fixed as well. The biggest among them is the settings for P1_MPWLDECTRL0/1. Note that in this series, I have only reviewed the register values that > changed in my series, and only for 1066mhz_4x128mx16.cfg. Thanks for that. More eyeballs are better, especially when looking at bit-fields... Also note that these relationships make a pretty good case for having expression support in these files. It would be nice to express tXS and tXPR as tRFC+6. But this is a topic for another day. These settings are indicative of a fly-by topology, which isn't used on SABRE Lite, and I don't think is used on SABRE SD. DATA 4 0x021b480c 0x00440044 DATA 4 0x021b4810 0x00440044 This was the primary thing that caused crashes under stress on SABRE Lite and led to our flurry of calibration tests as discussed here: http://boundarydevices.com/i-mx-6dq-u-boot-updates/ OK. I had not looked in detail into this. Should we take this up in a separate thread? It seems un-related to our Nitrogen6X board. As you prefer. This is related to this series, but a very > specific subject per se. I'll start a separate thread regarding the SABRE-Lite and SABRE SD memory settings. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.
Re: [U-Boot] i.MX6: Add hdmidet command
Hi Otavio, On 02/19/2013 01:30 PM, Otavio Salvador wrote: On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson wrote: Hi Stefano, This seems to have gotten lost in the shuffle. It's showing as "Changes requested" in Patchwork: http://patchwork.ozlabs.org/patch/186280/ Is there something you'd like changed? Please advise, I'd say to use space between the '+' as done in other code. I must be dense. Which '+' needs a space? Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
Dear Rob Herring, In message <5123e311.1070...@gmail.com> you wrote: > > > I dislike this. If you want to make a property of your device tree > > "immutable", then you should mark it there as such. Instead of > > removing the code here, U-Boot should then check for such a property > > and leave the value unchanged. > > There is no such way defined to flag that and I'm not going to invent > one. It's not that the memory node is immutable, but the default should > not be "needs fixups". No one puts purposely wrong data in their DT. So > therefore all data should be immutable? What happens when we need to > fixup immutable data? There is for example the "status" property, which can take the values "okay" or "disabled". This is used in other places for not so unsimilar purposes. > What I would really prefer to do is like powerpc where platforms > override this if they need the fixup and the default behavior is no > fixup. But that would require knowing which platforms do and don't need > the fixup. It only going to get harder to change that. Normally we use get_ramsize() to check / verify the amount of available RAM. And on PPC, we nearly always set the ram size in the DT. I don't know why you think the default was no fixup; this is not true. It's the other way round. > > Actually you are reaching here a point where it seems necessary that > > U-Boot itself is able to read the DT to configure itself correctly, > > i. e. the memory size information it holds should then also be > > extracted from the DT. > > I thought about doing this. That's really an orthogonal issue. The > problem is you cannot adjust the amount of memory u-boot uses to be > different than the amount of RAM in the /memory node. If you adjust the > size in u-boot, the adjusted size is passed to the kernel no matter what. > > There's issues with LPAE systems having >4GB of RAM as all the size and > address values are 32-bit. This could be fixed, but I'm not sure there > is much value in u-boot knowing about memory above 4GB as it can't > really access all of it and it would be purely informational. Well, let's face it - no matter what you do, if the RAM sizes as used in U-Boot and in Linux differ, at least one of these is wrong. This is a bug that should be fixed. What you attempt to do is implementing a method to paper over such bugs. This is not a good thing to do. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I've got a bad feeling about this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
Hello Alexandre, On 02/19/2013 10:26 PM, Alexandre Belloni wrote: Hi Eric, On Tue, Feb 19, 2013 at 09:33:58AM -0700, Eric Nelson wrote : Whoosh seems pretty compelling with such a small code base. Does it really boot faster though? Do you have any numbers for TTP (Time-to-penguin) on a SABRE Lite or SABRE SD? I don't exactly have that number but I believe you can go under 100ms. If you have a look at my presentation at ELCE [1] or that video on youtube [2], we basically are able too boot an start an openGL application under 600ms from reset. But that is a lot of self advertising, we can continue to discuss that off the ML if you want. Do you have a link for the sources of opengl application? So I can make some comparison (I might have some time this weekend, just for the fun of it...) Or even later if opengl support bites me... I have a ti / spl boot so might be interesting to compare. Out of curiosity, do you have any numbers for QNX? Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4] nand: Hack to support 4k page in fsl_elbc_nand
On Tue, Jul 03, 2012 at 11:07:26AM -, Rafael Beims wrote: > Freescale FCM controller has a 2K size limitation of buffer RAM. In order > to support the Nand flash chip with pagesize larger than 2K bytes, > we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save > them to a large buffer. > Because of this, the in flash layout of the oob is different from the > default for 4096kiB page sizes. Therefore, we need to migrate the > factory bad block markers from the original position to the new layout. > > Signed-off-by: Shengzhou Liu > Signed-off-by: Liu Shuo > Signed-off-by: Rafael Beims > > --- > Changes in v2: > - Added check to disallow the migration code to run in devices with > page size <= 2048 > > Changes in v3: > - Corrected memset writing beyond newoob buffer > - Corrected various code formatting errors > - Cosmetic changes > - Generated random magic number for migration marker > - Removed direct references to nand_bbt.c code > - Removed useless bbt free > - Removed useless dir variable > - Removed vmalloc and kmalloc calls. Only malloc() and free() used now > - Start searching the migration marker from the end of NAND > > Changes in v4: > - Read all the pages of the block until migrated marker is found > - Write the marker in all pages of the block > > drivers/mtd/nand/fsl_elbc_nand.c | 443 > +++--- > 1 files changed, 415 insertions(+), 28 deletions(-) > >"index %x, pes %d ps %d\n", > @@ -256,13 +291,14 @@ static int fsl_elbc_run_command(struct mtd_info *mtd) Sorry for the delay, but this patch is mangled and cannot be applied. E.g. the above diff chunk is missing the header that indicates the file it is for (I can guess, but "git am" can't, and it suggests that part of the patch may be missing). > @@ -295,6 +331,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, > unsigned int command, There is also line wrapping. I'd also like to see at least the larger portions of the code that this adds be ifdeffed to avoid increasing image size further for boards that don't need it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] env_nand.c: do warn only if really no valid environment could be loaded
On 11/21/2012 06:59:20 AM, Phil Sutter wrote:
The warning is misleading, since there is no equivalent success note
when reading the other copy succeeds.
Signed-off-by: Phil Sutter
---
common/env_nand.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/env_nand.c b/common/env_nand.c
index 895532b..58ba558 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -315,6 +315,7 @@ int get_nand_env_oob(nand_info_t *nand, unsigned
long *result)
void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
+ int read1_fail = 0, read2_fail = 0;
int crc1_ok = 0, crc2_ok = 0;
env_t *ep, *tmp_env1, *tmp_env2;
@@ -326,11 +327,11 @@ void env_relocate_spec(void)
goto done;
}
- if (readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1))
- puts("No Valid Environment Area found\n");
+ read1_fail = readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1);
+ read2_fail = readenv(CONFIG_ENV_OFFSET_REDUND, (u_char *)
tmp_env2);
- if (readenv(CONFIG_ENV_OFFSET_REDUND, (u_char *) tmp_env2))
- puts("No Valid Redundant Environment Area found\n");
+ if (read1_fail && read2_fail)
+ puts("No Valid Environment Area found\n");
crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) == tmp_env1->crc;
crc2_ok = crc32(0, tmp_env2->data, ENV_SIZE) == tmp_env2->crc;
We should still say something if one of the copies failed to load -- we
just need to word it better (see env_flash.c for an example).
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6: Add hdmidet command
On Tue, Feb 19, 2013 at 8:03 PM, Eric Nelson wrote: > Hi Otavio, > > > On 02/19/2013 01:30 PM, Otavio Salvador wrote: >> >> On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson >> wrote: >>> >>> Hi Stefano, >>> >>> This seems to have gotten lost in the shuffle. >>> >>> It's showing as "Changes requested" in Patchwork: >>> >>> http://patchwork.ozlabs.org/patch/186280/ >>> >>> Is there something you'd like changed? >>> >>> Please advise, >> >> >> I'd say to use space between the '+' as done in other code. >> > > I must be dense. > > Which '+' needs a space? It seems usually when dealing with offsets we have ' + '. Personally I think it is clear to read too. But it's not my call so it is up to you and Stefano. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] imls: Add support to list images in NAND device
On 12/17/2012 02:32:48 AM, Vipin Kumar wrote:
This patch adds support to list images in NAND flash through imls
Signed-off-by: Vipin Kumar
---
Changes in v4
- Keep stdout dumps in one line
- Continue even after read errors for all the blocks
README | 3 +-
common/cmd_bootm.c | 167
-
2 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 2077c3b..46fd21d 100644
--- a/README
+++ b/README
@@ -831,7 +831,8 @@ The following options need to be configured:
CONFIG_CMD_I2C * I2C serial bus support
CONFIG_CMD_IDE * IDE harddisk support
CONFIG_CMD_IMIiminfo
- CONFIG_CMD_IMLS List all found images
+ CONFIG_CMD_IMLS List all images found in NOR
flash
+ CONFIG_CMD_IMLS_NAND List all images found in NAND
flash
CONFIG_CMD_IMMAP* IMMR dump support
CONFIG_CMD_IMPORTENV* import an environment
CONFIG_CMD_INI * import data from an ini file
into the env
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d256ddf..938e500 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -80,9 +80,15 @@ static int image_info(unsigned long addr);
#include
#include
extern flash_info_t flash_info[]; /* info for FLASH chips */
+#endif
+
+#if defined(CONFIG_CMD_IMLS) || defined(CONFIG_CMD_IMLS_NAND)
static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[]);
#endif
+#include
+#include
+
#ifdef CONFIG_SILENT_CONSOLE
static void fixup_silent_linux(void);
#endif
@@ -1175,7 +1181,7 @@ U_BOOT_CMD(
/* imls - list all images found in flash */
/***/
#if defined(CONFIG_CMD_IMLS)
-static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
+static int do_imls_nor(void)
{
flash_info_t *info;
int i, j;
@@ -1224,6 +1230,161 @@ next_sector:;
}
next_bank: ;
}
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_CMD_IMLS_NAND)
+static int nand_imls_legacyimage(nand_info_t *nand, int nand_dev,
loff_t off,
+ size_t len)
+{
+ void *imgdata;
+ int ret;
+
+ imgdata = malloc(len);
+ if (!imgdata) {
+ printf("May be a Legacy Image at NAND device %d offset
%08llX:\n",
+ nand_dev, off);
+ printf(" Low memory(cannot allocate memory for
image)\n");
+ return -ENOMEM;
+ }
So, it looks like any reasonably-sized kernel image is going to hit
this out-of-memory condition given how unreasonably small U-Boot malloc
heaps generally are.
As a side note, running this showed U-Boot itself as "may be a legacy
image"... it seems that for some reason all the ppc arches start with
the uImage header, but otherwise aren't valid uImages.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6: Add hdmidet command
On 02/19/2013 05:42 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 8:03 PM, Eric Nelson
wrote:
Hi Otavio,
On 02/19/2013 01:30 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson
wrote:
Hi Stefano,
This seems to have gotten lost in the shuffle.
It's showing as "Changes requested" in Patchwork:
http://patchwork.ozlabs.org/patch/186280/
Is there something you'd like changed?
Please advise,
I'd say to use space between the '+' as done in other code.
I must be dense.
Which '+' needs a space?
It seems usually when dealing with offsets we have ' + '. Personally I
think it is clear to read too. But it's not my call so it is up to you
and Stefano.
Gotcha.
You mean here:
+{
+ u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0);
^
That's the trouble with commenting on the patchwork link...
No context.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6: Add hdmidet command
On Tue, Feb 19, 2013 at 10:16 PM, Eric Nelson
wrote:
> On 02/19/2013 05:42 PM, Otavio Salvador wrote:
>>
>> On Tue, Feb 19, 2013 at 8:03 PM, Eric Nelson
>> wrote:
>>>
>>> Hi Otavio,
>>>
>>>
>>> On 02/19/2013 01:30 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson
wrote:
>
>
> Hi Stefano,
>
> This seems to have gotten lost in the shuffle.
>
> It's showing as "Changes requested" in Patchwork:
>
> http://patchwork.ozlabs.org/patch/186280/
>
> Is there something you'd like changed?
>
> Please advise,
I'd say to use space between the '+' as done in other code.
>>>
>>> I must be dense.
>>>
>>> Which '+' needs a space?
>>
>>
>> It seems usually when dealing with offsets we have ' + '. Personally I
>> think it is clear to read too. But it's not my call so it is up to you
>> and Stefano.
>>
> Gotcha.
>
> You mean here:
>
> +{
> + u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0);
>^
>
> That's the trouble with commenting on the patchwork link...
Yes; a space between both macros.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6: Add hdmidet command
On 02/19/2013 06:19 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 10:16 PM, Eric Nelson
wrote:
On 02/19/2013 05:42 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 8:03 PM, Eric Nelson
wrote:
Hi Otavio,
On 02/19/2013 01:30 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson
wrote:
Hi Stefano,
This seems to have gotten lost in the shuffle.
It's showing as "Changes requested" in Patchwork:
http://patchwork.ozlabs.org/patch/186280/
Is there something you'd like changed?
Please advise,
I'd say to use space between the '+' as done in other code.
I must be dense.
Which '+' needs a space?
It seems usually when dealing with offsets we have ' + '. Personally I
think it is clear to read too. But it's not my call so it is up to you
and Stefano.
Gotcha.
You mean here:
+{
+ u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0);
^
That's the trouble with commenting on the patchwork link...
Yes; a space between both macros.
And a run through checkpatch...
I am dense today.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] Blackfin: bf60x: new processor header files
Hi Wolfgang, On Tue, Feb 19, 2013 at 6:15 PM, Wolfgang Denk wrote: > Dear Sonic Zhang, > > In message <1361257266-3722-2-git-send-email-sonic@gmail.com> you wrote: >> >> Add header files for blackfin new processor bf60x. > ... >> arch/blackfin/include/asm/mach-bf609/BF609_def.h | 3758 >> + > > This is a bit excessive, isn't it? Do we really all thse many > thousands lines of defines? > > >> diff --git a/arch/blackfin/include/asm/mach-bf609/BF609_def.h >> b/arch/blackfin/include/asm/mach-bf609/BF609_def.h >> new file mode 100644 >> index 000..39b740f >> --- /dev/null >> +++ b/arch/blackfin/include/asm/mach-bf609/BF609_def.h >> @@ -0,0 +1,3758 @@ >> +/* DO NOT EDIT THIS FILE >> + * Automatically generated by generate-def-headers.xsl >> + * DO NOT EDIT THIS FILE >> + */ >> + >> +#ifndef __BFIN_DEF_ADSP_BF609_proc__ >> +#define __BFIN_DEF_ADSP_BF609_proc__ >> + >> +#include "../mach-common/ADSP-EDN-core_def.h" >> + >> +#define CNT_CFG 0xFFC00400 /* CNT0 >> Configuration Register */ >> +#define CNT_IMSK0xFFC00404 /* CNT0 Interrupt >> Mask Register */ >> +#define CNT_STAT0xFFC00408 /* CNT0 Status >> Register */ >> +#define CNT_CMD 0xFFC0040C /* CNT0 Command >> Register */ >> +#define CNT_DEBNCE 0xFFC00410 /* CNT0 Debounce >> Register */ >> +#define CNT_CNTR0xFFC00414 /* CNT0 Counter >> Register */ >> +#define CNT_MAX 0xFFC00418 /* CNT0 Maximum >> Count Register */ >> +#define CNT_MIN 0xFFC0041C /* CNT0 Minimum >> Count Register */ >> + >> +#define RSI_CLK_CONTROL 0xFFC00604 /* RSI0 Clock >> Control Register */ >> +#define RSI_ARGUMENT0xFFC00608 /* RSI0 Argument >> Register */ >> +#define RSI_COMMAND 0xFFC0060C /* RSI0 Command >> Register */ >> +#define RSI_RESP_CMD0xFFC00610 /* RSI0 Response >> Command Register */ >> +#define RSI_RESPONSE0 0xFFC00614 /* RSI0 Response 0 >> Register */ >> +#define RSI_RESPONSE1 0xFFC00618 /* RSI0 Response 1 >> Register */ >> +#define RSI_RESPONSE2 0xFFC0061C /* RSI0 Response 2 >> Register */ >> +#define RSI_RESPONSE3 0xFFC00620 /* RSI0 Response 3 >> Register */ >> +#define RSI_DATA_TIMER 0xFFC00624 /* RSI0 Data Timer >> Register */ >> +#define RSI_DATA_LGTH 0xFFC00628 /* RSI0 Data Length >> Register */ >> +#define RSI_DATA_CONTROL0xFFC0062C /* RSI0 Data Control >> Register */ >> +#define RSI_DATA_CNT0xFFC00630 /* RSI0 Data Count >> Register */ >> +#define RSI_STATUS 0xFFC00634 /* RSI0 Status >> Register */ >> +#define RSI_STATUSCL0xFFC00638 /* RSI0 Status Clear >> Register */ >> +#define RSI_IMSK0 0xFFC0063C /* RSI0 Interrupt 0 >> Mask Register */ >> +#define RSI_IMSK1 0xFFC00640 /* RSI0 Interrupt 1 >> Mask Register */ >> +#define RSI_FIFO_CNT0xFFC00648 /* RSI0 FIFO Counter >> Register */ > ... > > I think I mentioned before that device registers have to be described > using C structs in U-Boot, and proper I/O accessors must be used to > access these. > > In any case, please trim to the really needed definitions. OK. I will trim the head file to those that are really used in drivers. > >> --- /dev/null >> +++ b/arch/blackfin/include/asm/mach-bf609/anomaly.h >> @@ -0,0 +1,103 @@ >> +/* >> + * DO NOT EDIT THIS FILE >> + * This file is under version control at >> + * >> svn://sources.blackfin.uclinux.org/toolchain/trunk/proc-defs/header-frags/ >> + * and can be replaced with that version at any time >> + * DO NOT EDIT THIS FILE > > This makes no sense to me. OK, I will remove these lines. > >> + * Copyright 2004-2012 Analog Devices Inc. >> + * Licensed under the ADI BSD license. >> + * https://docs.blackfin.uclinux.org/doku.php?id=adi_bsd >> + */ > > I'm not sure if this has been discussed before - is this really GPL > compatible? > The adi_bsd license comment is the same as those in the head files for BF5xx, which were already merged in to the U-boot mainline git tree. As the document says "The ADI BSD License is similar to the Clear BSD License, which the Free Software Foundation indicates is compatible with both GPLv2 and GPLv3." I think this has already been discussed when Mike Frysinger got the Blackfin architecture code merged upstream. Regards, Sonic > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@
Re: [U-Boot] [PATCH v4] imls: Add support to list images in NAND device
On 2/20/2013 6:45 AM, Scott Wood wrote:
On 12/17/2012 02:32:48 AM, Vipin Kumar wrote:
This patch adds support to list images in NAND flash through imls
Signed-off-by: Vipin Kumar
---
Changes in v4
- Keep stdout dumps in one line
- Continue even after read errors for all the blocks
README | 3 +-
common/cmd_bootm.c | 167
-
2 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 2077c3b..46fd21d 100644
--- a/README
+++ b/README
@@ -831,7 +831,8 @@ The following options need to be configured:
CONFIG_CMD_I2C * I2C serial bus support
CONFIG_CMD_IDE * IDE harddisk support
CONFIG_CMD_IMIiminfo
- CONFIG_CMD_IMLS List all found images
+ CONFIG_CMD_IMLS List all images found in NOR
flash
+ CONFIG_CMD_IMLS_NAND List all images found in NAND
flash
CONFIG_CMD_IMMAP* IMMR dump support
CONFIG_CMD_IMPORTENV* import an environment
CONFIG_CMD_INI * import data from an ini file
into the env
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d256ddf..938e500 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -80,9 +80,15 @@ static int image_info(unsigned long addr);
#include
#include
extern flash_info_t flash_info[]; /* info for FLASH chips */
+#endif
+
+#if defined(CONFIG_CMD_IMLS) || defined(CONFIG_CMD_IMLS_NAND)
static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[]);
#endif
+#include
+#include
+
#ifdef CONFIG_SILENT_CONSOLE
static void fixup_silent_linux(void);
#endif
@@ -1175,7 +1181,7 @@ U_BOOT_CMD(
/* imls - list all images found in flash */
/***/
#if defined(CONFIG_CMD_IMLS)
-static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
+static int do_imls_nor(void)
{
flash_info_t *info;
int i, j;
@@ -1224,6 +1230,161 @@ next_sector:;
}
next_bank:;
}
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_CMD_IMLS_NAND)
+static int nand_imls_legacyimage(nand_info_t *nand, int nand_dev,
loff_t off,
+ size_t len)
+{
+ void *imgdata;
+ int ret;
+
+ imgdata = malloc(len);
+ if (!imgdata) {
+ printf("May be a Legacy Image at NAND device %d offset
%08llX:\n",
+ nand_dev, off);
+ printf(" Low memory(cannot allocate memory for
image)\n");
+ return -ENOMEM;
+ }
So, it looks like any reasonably-sized kernel image is going to hit
this out-of-memory condition given how unreasonably small U-Boot malloc
heaps generally are.
Yes, that's right. And it is a pity
As a side note, running this showed U-Boot itself as "may be a legacy
image"... it seems that for some reason all the ppc arches start with
the uImage header, but otherwise aren't valid uImages.
This "may be a legacy image" print is when we have successfully copied
and validated the 64 byte mkimage header and are not able to allocate
the memory from heap for the image data. What it means is that although
the whole image might be a good "Legacy image" but we can not guarantee
because we have not yet validated the dcrc.
Thats why this print "May be a legacy image"
-Vipin
-Scott
.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
Hi Tom, First of all, sorry for late reply. > On Mon, Feb 18, 2013 at 11:01:42AM +0100, Lukasz Majewski wrote: > > Hi Tom, > > > > > On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > > > > > > > We didn't support upload/download larger than available memory. > > > > This is pretty bad when you have to update your root filesystem > > > > for example. > > > > > > > > This patch removes the limitation (and the crashes when you > > > > transfered any file larger than 4MB). > > > > On top of that reduces the huge dfu buffer from 4MB to just 64K, > > > > which was over the top. > > > > > > > > The sequence number is a 16 bit counter; make sure we > > > > handle rollover correctly. This fixes the wrong transfers for > > > > large (> 256MB) images. > > > > > > > > Also utilize a variable to handle initialization, so that we > > > > don't rely on just the counter sent by the host. > > > > > > > > Signed-off-by: Pantelis Antoniou > > > > > > To be clear, patches 1-8 are good and we should take, but this one > > > means we can't use FAT/EXT* partitions without more work. I would > > > suggest that we set this part aside for a moment and perhaps limit > > > transfers that are larget than RAM to RAW only where we can write > > > in chunks today. > > > > > > > As fair as I remember, some additional work needs to be done with > > composite.c file (to remove nasty #ifdefs). There was a problem with > > newer version of dfu-utils (new handling of descriptors). > > I see you and Pantelis talking about if some changes were really > needed in composite.c or not, but nothing about dfu-utils. Changes in composite.c (adding some #ifdefs) were made because dfu-util developers made the significant change in descriptors handling between dfu-utils ver. 0.1 (which I've been using on my antic/test machine debian) and the newest dfu-utils (which Pantelis was using, and which is now available on recent debian). To be honest the current DFU code (v2013.01) works with the dfu-utils ver 0.1 (the old one). It breaks with new one. > Were you > objecting to the composite.c changes because you didn't need them, or > because they in turn broke trats (can I get one of these somewhere?) I'm objecting to adding a "quick hack style" #ifdefs to generic composite.c code. As fair as I remember this corrected code works with DFU, but I'd need to check if those composite.c changes will not break the UMS patches posted recently. Regarding TRATS: It is an official Tizen development board (mobile phone): http://www.youtube.com/watch?v=ya7ucT1wzOA It was distributed on some fair show, but I cannot tell how to obtain one. > The only other unresolved thing was about board_usb_init() which I > think was settled on trats needing to change behavior. As fair as I remember trats follows u-boot policy to enable things only when they are really needed. But I will not be stubborn here. On the end I might end up with a weak function (or enabling USB by default). I think, that this is a minor issue when compared to composite.c My proposition: - Now we have middle of Feb, we can add Pantelis Patches, UMS patches to u-boot tree (from Marek's USB tree) and fix conflicts up till v2013.03 release. I can point two big sets of patches (related only to Samsung boards) floating around without a common "base": Pantelis DFU work and UMS support patches. - I plan to work on composite/DFU (and potential UMS problems) at next week (up Friday I'm totally buried with other work) -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DFU on OMAP4?
Hi Michael, > Greetings, > > I've been trying to do some feasibility (performance / features) > testing of DFU to see if it might work on a project I'm involved > with. Due to architecture similarities I'm trying to do this using a > custom-built u-boot from Denx mainline on a OMAP4460 ES1.1 > Pandaboard. But I've been having problems. > > I'm not sure I have the right set of CONFIG options. The DFU-relevant > ones (I think) are: > > #define CONFIG_CMD_DFU > #define CONFIG_DFU_FUNCTION > #define CONFIG_DFU_MMC > #define CONFIG_USBDOWNLOAD_GADGET > #define CONFIG_USB_GADGET > #define CONFIG_USB_GADGET_OMAP > #define CONFIG_USB_GADGET_VBUS_DRAW 500 > > #define CONFIG_G_DNL_MANUFACTURER "TI"// just > #define CONFIG_G_DNL_VENDOR_NUM 0x0451 // for > #define CONFIG_G_DNL_PRODUCT_NUM 0xd022 // evaluation > > #define CONFIG_DFU_ALT \ > "ipl mmc 100 100;" \ > "u-boot mmc 200 200\0" \ > … > #define CONFIG_EXTRA_ENV_SETTINGS \ > "dfu_alt_info=" CONFIG_DFU_ALT \ > … > Those are CONFIGS needed for DFU running. > With this I get unresolved symbols at link time: > > /home/cashwell/eval/u-boot/common/cmd_dfu.c:64: undefined reference > to `usb_gadget_handle_interrupts' drivers/usb/gadget/libusb_gadget.o: > In function > `usb_composite_unregister': > /home/cashwell/eval/u-boot/drivers/usb/gadget/composite.c:1081: > undefined reference to `usb_gadget_unregister_driver' > drivers/usb/gadget/libusb_gadget.o: In function > `usb_composite_register': > /home/cashwell/eval/u-boot/drivers/usb/gadget/composite.c:1067: > undefined reference to `usb_gadget_register_driver' > > The only possibilities I can find that might resolve those missing > functions are in the files: > > ./drivers/usb/musb-new/musb_uboot.c > ./drivers/usb/gadget/s3c_udc_otg.c I can only speak of Samsung code. The s3c_udc_otg.c shall be regarded as a reference (at least for the current DFU implementation). In this file you will find a UDC (USB Device Controller) driver, which exports USB Gadget (ported from linux) API. Please notice, that "usb_gadget_register_driver" is one of those calls. > ./drivers/usb/gadget/pxa25x_udc.c > ./drivers/usb/gadget/mv_udc.c > > But I'm confused by the relationship between musb, musb-new, and the > UDC gadget drivers. I also can't find UDC code for OMAP4 that would > work for DFU. UDC/GADGET/DFU can be depicted as: -- - | DFU code (high level code) | | UMS (USB Mass Storage)| -- - || \|/ | -/| |Composite (composite.c)|-- -\ | \|/ |UDC driver + Gadget API exported | | s3c_udc_otg.c for Samsung| | \|/ | USB HW | It seems that UDC driver, which you are using is not exporting proper API which is used by composite.c layer. But I think, that Linux kernel UDC driver (for Pandaboard) shall have a good support for Gadget API. You can look there for a reference. > > Am I trying to do something that's impossible on OMAP4 using its > built-in OTG controller and PHY or am I just doing something dumb? What I can advice is: - Look for TI's UDC driver for anadboard. Especially pay attention for the Gadget API export. - Then compare this code with current UDC implementation at U-boot - they shall match in a larger part. - Add missing API calls. > > Has anyone used u-boot DFU on a Pandaboard? You probably are the first one :-) > > Sorry for the n00b question but I've been banging my head on this for > several days and I just can't sort out which part is the horse and > which the cart. I hope, that the ASCII picture will help you to understand the stuff. When we were developing the feature for Samsung boards, we were trying to stick to Linux reference code as much as possible (of course we had to add a small compatibility layer, but the UDC driver was almost not changed). > > Best regards, > -Michael Cashwell > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2 V3] SMDK5250: Set Initial PMIC Values
On 13/02/13 15:40, Rajeshwari Shinde wrote: > These patches add PMIC MAX77686 voltage settings for SMDK5250. > > Changes in V2: > - Corrected the multi line comment style > Changes in V3: > - Renamed the ps hold function. > Rajeshwari Shinde (2): > EXYNOS5: Add function to setup set ps hold > SMDK5250: Add PMIC voltage settings > > arch/arm/cpu/armv7/exynos/power.c| 16 > arch/arm/include/asm/arch-exynos/power.h |9 +++ > board/samsung/smdk5250/smdk5250.c| 113 > +- > include/power/max77686_pmic.h| 32 + > 4 files changed, 168 insertions(+), 2 deletions(-) > 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
