Re: [U-Boot] [PATCH v1 1/2] tpm: Rename generic_lpc_tpm to tpm_tis_lpc
On Mon, Dec 19, 2011 at 7:38 PM, Wolfgang Denk w...@denx.de wrote: Dear Che-liang Chiou, In message canjuy2jq3nf2mjpxrs-8jgksiv1zg2sfcnqdmrksaqpifup...@mail.gmail.com you wrote: Should we not rather remove all this dead code again? Until today there are no users for this code in mainline, and no patches have been submitted that intend to use it. Chrome/Chromium OS uses TPM for its secure boot. So I would say it is quite a lot of usage on the critical path of booting. I do not see any such code in mainline. So for mainline, this is just dead code, i. e. it adds maintenance efforts without benefit for any mainline users. The code that uses TPM did not send to the mainline because the mainline did not have a TPM driver until very recently. Well, the patche shave been submitted long time ago, so I would have expected to see such code soon after. But so far, nothign happened. Now you are trying to add even more code, with still no users in sight. The board that I test the TPM driver is Seaboard (a tegra2-based board). The config settings enabling TPM are literally pasted as follows. However, I can't submit the confis settings (so that Seaboard would be the first mainline user of the TPM driver) as part of this patchset because the tegra i2c driver is not yet in the mainline and so enabling TPM will break mainline's Seaboard build. I am 100% certain that tegra i2c driver will be submitted. It just take a few time to polish before sending out for review. And after that I will submit a patch enabling TPM in Seaboard. Would this be sufficient for you? diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 7d29144..7c96826 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -42,6 +42,13 @@ #define CONFIG_BOARD_EARLY_INIT_F +/* TPM */ +#define CONFIG_TPM +#define CONFIG_TPM_TIS_I2C +#define CONFIG_TPM_TIS_I2C_BUS_NUMBER 2 +#define CONFIG_TPM_TIS_I2C_SLAVE_ADDRESS 0x20 +#define CONFIG_TPM_TIS_I2C_BURST_LIMITATION3 + /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC And, I am still figuring out how to submit the TPM user code. I guess it would be better to organize it in a command-line toolkit so that it can be interleaved in between other commands. What do you think? I don't understand what you mean. Didn't you just write there was code ready to be submitted? So that code is not ready and not intended for mainline? I thought you might be interested in Chrome/Chromium OS secure boot, which is implemented as a single monolithic command, and I guess it would be more interested to you if I break it into smaller sub-commands. Anyway, never mind. 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 Never ascribe to malice that which can adequately be explained by stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] mmc: Implement central card-detection.
This series of patches implements central card-detection within the MMC framework. Before this patch series, many boards actually did implement the board_mmc_getcd() function, but it wasn't used except by one driver (fsl_esdhc). Unfortunately, implementations interpreted the meaning of the cd parameter differently, some taking it to signal card absence and others using it to detect card presence. Furthermore, the signature of the board_mmc_getcd() function was not at all consistent with other MMC related functions. The first patch in this series therefore changes the board_mmc_getcd() function signature and consolidates all current implementations. The second patch adds a central card-detection implementation within the MMC framework by using the new board_mmc_getcd() function and adds a hook that can be provided by drivers to serve as a default card-detect mechanism if no board-specific implementation is provided. The third and fourth patches implement this driver hook for the fsl_esdhc and the tegra2 MMC drivers. For reference, the following email thread contains the discussion that led to this patch series: http://lists.denx.de/pipermail/u-boot/2011-November/110180.html Changes in v3: - reword subject line of patch 1 to be less confusing - address coding style issues raised by Marek Vasut Changes in v2: - add a better rationale for the series and a reference to the email thread that started it - add an explanation to patch 3 why the call to board_mmc_getcd() is removed from the fsl_esdhc driver - add a cover letter which explains the series' goal Thierry Reding (4): mmc: Change board_mmc_getcd() function prototype. mmc: Implement card detection. mmc: fsl_esdhc: Implement card-detect hook. mmc: tegra2: Implement card-detect hook. board/efikamx/efikamx.c |9 + board/emk/top9000/top9000.c | 12 ++-- board/freescale/mx51evk/mx51evk.c |9 + board/freescale/mx53ard/mx53ard.c |9 + board/freescale/mx53evk/mx53evk.c |9 + board/freescale/mx53loco/mx53loco.c |9 + board/freescale/mx53smd/mx53smd.c |6 ++ doc/README.atmel_mci| 12 ++-- drivers/mmc/arm_pl180_mmci.c|1 + drivers/mmc/bfin_sdh.c |1 + drivers/mmc/davinci_mmc.c |1 + drivers/mmc/fsl_esdhc.c | 27 --- drivers/mmc/ftsdc010_esdhc.c|1 + drivers/mmc/gen_atmel_mci.c |1 + drivers/mmc/mmc.c | 22 -- drivers/mmc/mmc_spi.c |1 + drivers/mmc/mxcmmc.c|1 + drivers/mmc/mxsmmc.c|1 + drivers/mmc/omap_hsmmc.c|1 + drivers/mmc/pxa_mmc_gen.c |1 + drivers/mmc/s5p_mmc.c |1 + drivers/mmc/sdhci.c |1 + drivers/mmc/sh_mmcif.c |1 + drivers/mmc/tegra2_mmc.c| 28 +--- include/mmc.h |4 +++- 25 files changed, 92 insertions(+), 77 deletions(-) -- 1.7.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] mmc: tegra2: Implement card-detect hook.
On Tegra2, card-detection is implemented by passing the card-detection
GPIOs to the MMC driver at initialization time. Instead of implementing
the board_mmc_getcd() function, use the card-detect hook and allow
boards to override it by providing their own board_mmc_getcd()
implementation.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/tegra2_mmc.c | 28 +---
1 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
index fe562ed..5b4c9f6 100644
--- a/drivers/mmc/tegra2_mmc.c
+++ b/drivers/mmc/tegra2_mmc.c
@@ -474,6 +474,18 @@ static int mmc_core_init(struct mmc *mmc)
return 0;
}
+int tegra2_mmc_getcd(struct mmc *mmc)
+{
+ struct mmc_host *host = (struct mmc_host *)mmc-priv;
+
+ debug(tegra2_mmc_getcd called\n);
+
+ if (host-cd_gpio = 0)
+ return !gpio_get_value(host-cd_gpio);
+
+ return 1;
+}
+
int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio)
{
struct mmc_host *host;
@@ -512,6 +524,7 @@ int tegra2_mmc_init(int dev_index, int bus_width, int
pwr_gpio, int cd_gpio)
mmc-send_cmd = mmc_send_cmd;
mmc-set_ios = mmc_set_ios;
mmc-init = mmc_core_init;
+ mmc-getcd = tegra2_mmc_getcd;
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
if (bus_width == 8)
@@ -535,18 +548,3 @@ int tegra2_mmc_init(int dev_index, int bus_width, int
pwr_gpio, int cd_gpio)
return 0;
}
-
-/* this is a weak define that we are overriding */
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
-{
- struct mmc_host *host = (struct mmc_host *)mmc-priv;
-
- debug(board_mmc_getcd called\n);
-
- if (host-cd_gpio = 0)
- *cd = !gpio_get_value(host-cd_gpio);
- else
- *cd = 1;
-
- return 0;
-}
--
1.7.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Coding Style cleanup
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, December 19, 2011 9:07 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] Coding Style cleanup Dear Premi, Sanjeev, In message e28aafd00efaa646ae3df9b89cd24a8909b...@dbde01.ent.ti.com you wrote: @@ -563,6 +556,7 @@ extern unsigned long=20 get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; =09 \ bootm $loadaddr - $fdtaddr =20 + #define CONFIG_RAMBOOTCOMMAND=09 This appears to be a stray addition. ...which appears to be added by your mailer. I don;t see it in the patch. I was referring to the extra line added by the + sign. [quoting from original patch] @@ -563,6 +556,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; \ bootm $loadaddr - $fdtaddr + #define CONFIG_RAMBOOTCOMMAND \ setenv bootargs root=/dev/ram rw \ console=$consoledev,$baudrate $othbootargs; \ [/quote] ~sanjeev 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 When the ax entered the forest, the trees said, The handle is one of us! -- Turkish proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] mmc: Change board_mmc_getcd() function prototype.
The new API no longer uses the extra cd parameter that was used to store
the card presence state. Instead, this information is returned via the
function's return value. board_mmc_getcd() returns -1 to indicate that
no card-detection mechanism is implemented; 0 indicates that no card is
present and 1 is returned if it was detected that a card is present.
The rationale for this change can be found in the following email
thread:
http://lists.denx.de/pipermail/u-boot/2011-November/110180.html
In summary, the old API was not consistent with the rest of the MMC API
which always passes a struct mmc as the first parameter. Furthermore the
cd parameter was used to mean card absence in some implementations and
card presence in others.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
board/efikamx/efikamx.c |9 +
board/emk/top9000/top9000.c | 12 ++--
board/freescale/mx51evk/mx51evk.c |9 +
board/freescale/mx53ard/mx53ard.c |9 +
board/freescale/mx53evk/mx53evk.c |9 +
board/freescale/mx53loco/mx53loco.c |9 +
board/freescale/mx53smd/mx53smd.c |6 ++
doc/README.atmel_mci| 12 ++--
drivers/mmc/fsl_esdhc.c |8 +---
drivers/mmc/mmc.c |4 ++--
include/mmc.h |2 +-
11 files changed, 39 insertions(+), 50 deletions(-)
diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
index b78bf6c..d632469 100644
--- a/board/efikamx/efikamx.c
+++ b/board/efikamx/efikamx.c
@@ -309,17 +309,18 @@ static inline uint32_t efika_mmc_cd(void)
return MX51_PIN_EIM_CS2;
}
-int board_mmc_getcd(u8 *absent, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
uint32_t cd = efika_mmc_cd();
+ int ret;
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *absent = gpio_get_value(IOMUX_TO_GPIO(cd));
+ ret = !gpio_get_value(IOMUX_TO_GPIO(cd));
else
- *absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
+ ret = !gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
diff --git a/board/emk/top9000/top9000.c b/board/emk/top9000/top9000.c
index 61dee62..d156e32 100644
--- a/board/emk/top9000/top9000.c
+++ b/board/emk/top9000/top9000.c
@@ -108,17 +108,9 @@ int board_mmc_init(bd_t *bd)
}
/* this is a weak define that we are overriding */
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
- /*
-* the only currently existing use of this function
-* (fsl_esdhc.c) suggests this function must return
-* *cs = TRUE if a card is NOT detected - in most
-* cases the value of the pin when the detect switch
-* closes to GND
-*/
- *cd = at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN) ? 1 : 0;
- return 0;
+ return !at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN);
}
#endif
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 37e6e4d..46b4830 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -261,16 +261,17 @@ static void power_init(void)
}
#ifdef CONFIG_FSL_ESDHC
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret;
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *cd = gpio_get_value(0);
+ ret = !gpio_get_value(0);
else
- *cd = gpio_get_value(6);
+ ret = !gpio_get_value(6);
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
diff --git a/board/freescale/mx53ard/mx53ard.c
b/board/freescale/mx53ard/mx53ard.c
index be32aee..58f0549 100644
--- a/board/freescale/mx53ard/mx53ard.c
+++ b/board/freescale/mx53ard/mx53ard.c
@@ -83,16 +83,17 @@ struct fsl_esdhc_cfg esdhc_cfg[2] = {
{MMC_SDHC2_BASE_ADDR, 1 },
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret;
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *cd = gpio_get_value(1); /*GPIO1_1*/
+ ret = !gpio_get_value(1); /* GPIO1_1 */
else
- *cd = gpio_get_value(4); /*GPIO1_4*/
+ ret = !gpio_get_value(4); /* GPIO1_4 */
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
diff --git a/board/freescale/mx53evk/mx53evk.c
b/board/freescale/mx53evk/mx53evk.c
index 335661f..c6c022f 100644
--- a/board/freescale/mx53evk/mx53evk.c
+++ b/board/freescale/mx53evk/mx53evk.c
@@ -208,16 +208,17 @@ struct fsl_esdhc_cfg esdhc_cfg[2] = {
Re: [U-Boot] [PATCH] overo: add SPL support
Dear Tom Rini, In message CA+M6bXn_ZBqA8rosE4L4O+4Eu+grAhWgCZ=u=2nomb6wcyl...@mail.gmail.com you wrote: I guess you really, really must use i2c before relocation? =A0If possible, this should be avoided in the first place. Yes, board rev detection to know how to configure SDRAM. I don't consider this a valid reason (reading the SPD EEPROM would be such a reason). In almost all other cases it should be suffucient to configure the maximum number of memory banks and the maximum size of the memory banks and then use get_ram_size() to determine the actual amount of memory and to correctly initialize the memory controller. Note that I don't insist on any changes to existing code here. This is just a recommendation which you may (or may not) consider for any future ports / implementations. 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 How much net work could a network work, if a network could net work? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] tpm: Rename generic_lpc_tpm to tpm_tis_lpc
Dear Che-liang Chiou, In message canjuy2jzerkmuske4zes3u6oo0ms3wfjfa+awu0od2mvbf_...@mail.gmail.com you wrote: The board that I test the TPM driver is Seaboard (a tegra2-based board). The config settings enabling TPM are literally pasted as follows. However, I can't submit the confis settings (so that Seaboard would be the first mainline user of the TPM driver) as part of this patchset because the tegra i2c driver is not yet in the mainline and so enabling TPM will break mainline's Seaboard build. I am 100% certain that tegra i2c driver will be submitted. It just take a few time to polish before sending out for review. And after that I will submit a patch enabling TPM in Seaboard. Would this be sufficient for you? I suggest you submit this all on a single patch series together, then. 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 Parkinson's Law: Work expands to fill the time alloted it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset Status on MPC83xx
Dear Sridhar Addagada, In message 1324360794.59571.yahoomail...@web120203.mail.ne1.yahoo.com you wrote: In an effort to find the cause of reboot from linux userspace, which was always returning hardreset, i traced the reason for the reset status register being cleared is from file arch/powerpc/cpu/mpc83xx/cpu_init.c, /* RSR - Reset Status Register - clear all status (4.6.1.3) */ gd-reset_status __raw_readl(im-reset.rsr); __raw_writel(~(RSR_RES), im-reset.rsr); Can anyone throw some light why it is getting cleared and what is 4.6.1.3 (4.6.1.3) usually means the relevant section in the respective user's manual (MPC8349E PowerQUICC II Pro Integrated Host Processor Family Reference Manual, Rev. 1), here section 4.6.1.3 Reset Status Register (RSR) on page 4-37 ff. The Note also explains why it makes sense to clear the register (so you can get a sane state for only the next reset/reboot). 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 What can it profit a man to gain the whole world and to come to his property with a gastric ulcer, a blown prostate, and bifocals? -- John Steinbeck, _Cannery Row_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
Dear Paul Gortmaker, In message CAP=VYLqd4kn7iQwwjDN3PMh3osBY4SsP+XXkzx2FBW=-xfy...@mail.gmail.com you wrote: ... or you can just snap in a JTAG debugger, connect GDB and throw some break/watch points here and there ;-) And how exactly is a JTAG going to help him resolve compile time issues he's currently having? Sure, JTAG is nice for things, and Obviously it does not help for compile time errors. some are lucky enough to have access to one. But $ means it is not something everyone has, and it is not a substitute for thinking your way through a problem. I'm more apt to use one to restore a bad flash image than anything else more complicated. Indeed there are people who rarely ever use a debugger; instead they use printf() or even plain LEDs (or other GPIOs) for debugging. feel free to chose any method you feel comfortable with. Fact is, that a good debugger like GDB is a powerful tool for the experienced user that can save _lots_ of time. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is a good thing for an uneducated man to read books of quotations. - Sir Winston Churchill _My Early Life_ ch. 9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
On Tuesday, December 20, 2011 12:41:08 PM you wrote: Dear Tom Rini, In message CA+M6bXn_ZBqA8rosE4L4O+4Eu+grAhWgCZ=u=2Nomb6WcyL6- w...@mail.gmail.com you wrote: I guess you really, really must use i2c before relocation? =A0If possible, this should be avoided in the first place. Yes, board rev detection to know how to configure SDRAM. I don't consider this a valid reason (reading the SPD EEPROM would be such a reason). In almost all other cases it should be suffucient to configure the maximum number of memory banks and the maximum size of the memory banks and then use get_ram_size() to determine the actual amount of memory and to correctly initialize the memory controller. Note that I don't insist on any changes to existing code here. This is just a recommendation which you may (or may not) consider for any future ports / implementations. Dear Wolfgang Denk, I agree to your concerns but - as I understood Steve Sakoman - here the situation is slightly different: At elder overo boards TWL4030 RTC irq is connected to gpio112. Unfortunately this pin is also used for binary revision detection. Therefore we need to send 'shut-up' to TWL4030 via i2c to avoid reading wrong revision. In SPL this must be done *before* SDRAM (timing) is set up, because the type of SDRAM is revision dependent. Hope this helps Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
Dear Michael Kebe, In message CAKKM46u=4UrB9+9Sn3HDMvdOdtHvO9p6HWdzTY2WpNExXrD_=a...@mail.gmail.com you wrote: Is the U-Boot code the address CONFIG_SYS_UBOOT_BASE should be set to? If so, then both addresses are the same, is that ok? Thanks for the discussion about how to port a new board into U-Boot. But I think these questions are forgotten, any further hints? Not forgotten. But you must not expect that we solve all problems for you. CONFIG_SYS_UBOOT_BASE is an undocumented and largely unused variable. Only very, very few boards define it, and the only plase it ever gets used is in arch/arm/cpu/arm1176/start.S, and then only if CONFIG_ENABLE_MMU is set. We don't know your hardware, we don't know your code. You will have to figure out yourself if this is something that is imprtant to you. Please note that the TEXT_BASE value you found looks a bit wrong for recent versions of U-Boot. One of the major changes we have in the past few years was that now U-Boot gets relocated to the end of physical RAM, and not just copied to a compile-time determined fix address as before. I speculate that this setting predates the relocation, so you need to change the related parts. 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 Wait! You have not been prepared! -- Mr. Atoz, Tomorrow is Yesterday, stardate 3113.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28: remove omap specific config options
Config options for OMAP are not used with i.MX28 so remove dead code. Signed-off-by: Veli-Pekka Peltola veli-pekka.pelt...@bluegiga.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/arm926ejs/mx28/start.S |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx28/start.S b/arch/arm/cpu/arm926ejs/mx28/start.S index 94696d6..2cd4d73 100644 --- a/arch/arm/cpu/arm926ejs/mx28/start.S +++ b/arch/arm/cpu/arm926ejs/mx28/start.S @@ -40,12 +40,6 @@ #include common.h #include version.h -#if defined(CONFIG_OMAP1610) -#include ./configs/omap1510.h -#elif defined(CONFIG_OMAP730) -#include ./configs/omap730.h -#endif - /* * * -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Coding Style cleanup
Dear Sanjeev, In message e28aafd00efaa646ae3df9b89cd24a8909d...@dbde01.ent.ti.com you wrote: I was referring to the extra line added by the + sign. Ah, I see. Indeed. Strange. 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 All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws intro- duced by earlier fixes. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot jumps to some location
hi, I am new to u-boot and have few doubts. I am trying to run uboot on custom board. I am using jtag(XDS 510 USB) to debug board. I have am3517 processor from ti. I have MT29C4G48MAZAPAKQ-5 IT chip which contains nand flash and lpddr. While making hardware I have not connected chip select 0 to this chip so I am not able to boot code from nand. So I am loading x-loader on internal sram at 0x40208800 and its running and I am getting message x-loader hangs on terminal Then I am loading uboot on ddr at 0x80e8. When I run the code in step mode the code is running upto start_armboot() function (u-boot/lib_arm/board.c) and goes into a for loop where it cheks for init_sequence. While code reaches upto this point some times it jumps to unkown location like 0x000C and then stops working and the same thing happens when it is in init_sequence when i reach to that point I am not understanding why is it happenig?? Is there any relation of CS0 to be connected to nand in order to run u-boot because I have seen lot places CS0 being used in code. I am using am3517_craneboard files. thank you ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
Dear Andreas, In message 201112201253.46991.schnitzelt...@gmx.de you wrote: I agree to your concerns but - as I understood Steve Sakoman - here the situation is slightly different: I think you misunderstand. At elder overo boards TWL4030 RTC irq is connected to gpio112. Unfortunately this pin is also used for binary revision detection. Therefore we need to send 'shut-up' to TWL4030 via i2c to avoid reading wrong revision. In SPL this must be done *before* SDRAM (timing) is set up, because the type of SDRAM is revision dependent. My suggestion was to check if memory initialization can not rather be done _without_ reading (and without otherwise knowing) the board type or revision. Usually this is possible, and I always prefer such auto-adjusting solutions over hard-wired approaches that break down when any of the expected inout data is not correct or not available. 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 We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Where I'm going with x86 board.c
With Simon's work on generic relocation support, I thought I would throw in
what I am planning for arch/x86/lib/board.c
Now this is not a patch, it is a work-in-progress complete version of the
file (compiles, will test soon) - If feedback is positive, I'll add this to
an upcoming patch set
Notice the amount of wrapping around void functions - If all other arch's
follow this lead, most of this wrapping can be removed by changing the
function signatures.
Lines 428 - 585 are effectively the generic init sequence - The rest is
wrappers, init sequence arrays, or fluff that should be moved
I noticed something along the way - gd is no longer special... let me
explain...
Some arch's use a dedicated register for the gd pointer - This allows the
pointer to be written to prior to relocation. For x86, the gd pointer is
simply passed around as a function parameter early - If the init_sequence_f
functions accepted a gd pointer as a parameter, there would be no need for
it to be global prior to relocation and therefore no need to allocate a
permanent register for it - Of course do_init_loop() would no longer be
generic for both pre and post relocation. This does mess with the
stand-alone API, but as discussed before, stand alone applications should
not be accessing gd anyway, so there should be no API to break ;)
And on that note, the following comment is well and truly wrong:
* The requirements for any new initalization function is simple: it
* receives a pointer to the global data structure as it's only
* argument, and returns an integer return code, where 0 means
* continue and != 0 means fatal error, hang the system.
And finally, here 'tis:
/*
* (C) Copyright 2008-2011
* Graeme Russ, graeme.r...@gmail.com
*
* (C) Copyright 2002
* Daniel Engström, Omicron Ceti AB, dan...@omicron.se
*
* (C) Copyright 2002
* Wolfgang Denk, DENX Software Engineering, w...@denx.de
*
* (C) Copyright 2002
* Sysgo Real-Time Solutions, GmbH www.elinos.com
* Marius Groeger mgroe...@sysgo.de
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
#include common.h
#include watchdog.h
#include command.h
#include stdio_dev.h
#include version.h
#include malloc.h
#include net.h
#include ide.h
#include serial.h
#include asm/u-boot-x86.h
#include elf.h
#ifdef CONFIG_BITBANGMII
#include miiphy.h
#endif
/*
* Pointer to initial global data area
*
* Here we initialize it.
*/
#undef XTRN_DECLARE_GLOBAL_DATA_PTR
#define XTRN_DECLARE_GLOBAL_DATA_PTR/* empty = allocate here */
DECLARE_GLOBAL_DATA_PTR = (gd_t *) (CONFIG_SYS_INIT_GD_ADDR);
/
* Init Utilities *
* Some of this code should be moved into the core functions,
* or dropped completely,
* but let's get it working (again) first...
*/
static int init_baudrate(void)
{
gd-baudrate = getenv_ulong(baudrate, 10, CONFIG_BAUDRATE);
return 0;
}
static int display_banner(void)
{
printf(\n\n%s\n\n, version_string);
return 0;
}
static int display_dram_config(void)
{
int i;
puts(DRAM Configuration:\n);
for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
printf(Bank #%d: %08lx , i, gd-bd-bi_dram[i].start);
print_size(gd-bd-bi_dram[i].size, \n);
}
return 0;
}
#ifndef CONFIG_SYS_NO_FLASH
static void display_flash_config(ulong size)
{
puts(Flash: );
print_size(size, \n);
}
#endif
/*
* Breath some life into the board...
*
* Initialize an SMC for serial comms, and carry out some hardware
* tests.
*
* The first part of initialization is running from Flash memory;
* its main purpose is to initialize the RAM so that we
* can relocate the monitor code to RAM.
*/
/*
* All attempts to come up with a common initialization sequence
* that works for all boards and architectures failed: some of the
* requirements are just _too_ different. To get rid of the resulting
* mess of board dependend #ifdef'ed code we now make the whole
* initialization sequence configurable to the user.
*
* The requirements for any new initalization
Re: [U-Boot] [PATCH] mx28: remove omap specific config options
On Tue, Dec 20, 2011 at 10:00 AM, Veli-Pekka Peltola veli-pekka.pelt...@bluegiga.com wrote: Config options for OMAP are not used with i.MX28 so remove dead code. Signed-off-by: Veli-Pekka Peltola veli-pekka.pelt...@bluegiga.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam fabio.este...@freescale.com Acked-by: Fabio Estevam fabio.este...@freescale.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28: remove omap specific config options
On 20/12/2011 13:00, Veli-Pekka Peltola wrote: Config options for OMAP are not used with i.MX28 so remove dead code. Signed-off-by: Veli-Pekka Peltola veli-pekka.pelt...@bluegiga.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/arm926ejs/mx28/start.S |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx28/start.S b/arch/arm/cpu/arm926ejs/mx28/start.S index 94696d6..2cd4d73 100644 --- a/arch/arm/cpu/arm926ejs/mx28/start.S +++ b/arch/arm/cpu/arm926ejs/mx28/start.S @@ -40,12 +40,6 @@ #include common.h #include version.h -#if defined(CONFIG_OMAP1610) -#include ./configs/omap1510.h -#elif defined(CONFIG_OMAP730) -#include ./configs/omap730.h -#endif Thanks to point out - I will not postpone the release for this, but I will apply it to the next branch. Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
Hi Andreas, On 12/20/11 13:53, Andreas Müller wrote: On Tuesday, December 20, 2011 12:41:08 PM you wrote: Dear Tom Rini, In message CA+M6bXn_ZBqA8rosE4L4O+4Eu+grAhWgCZ=u=2Nomb6WcyL6- w...@mail.gmail.com you wrote: I guess you really, really must use i2c before relocation? =A0If possible, this should be avoided in the first place. Yes, board rev detection to know how to configure SDRAM. I don't consider this a valid reason (reading the SPD EEPROM would be such a reason). In almost all other cases it should be suffucient to configure the maximum number of memory banks and the maximum size of the memory banks and then use get_ram_size() to determine the actual amount of memory and to correctly initialize the memory controller. Note that I don't insist on any changes to existing code here. This is just a recommendation which you may (or may not) consider for any future ports / implementations. Dear Wolfgang Denk, I agree to your concerns but - as I understood Steve Sakoman - here the situation is slightly different: At elder overo boards TWL4030 RTC irq is connected to gpio112. Unfortunately this pin is also used for binary revision detection. Therefore we need to send 'shut-up' to TWL4030 via i2c to avoid reading wrong revision. In SPL this must be done *before* SDRAM (timing) is set up, because the type of SDRAM is revision dependent. What about forging some very not optimized default DRAM settings, that suit any assembled DRAM and then when you have I2C access, reconfigure it - is it possible? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/net/e1000_spi.c: Fix build warnings
Fix:
e1000_spi.c: In function 'spi_free_slave':
e1000_spi.c:115: warning: unused variable 'hw'
e1000_spi.c: In function 'do_e1000_spi':
e1000_spi.c:472: warning: 'checksum' may be used uninitialized in this function
e1000_spi.c:472: note: 'checksum' was declared here
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000_spi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000_spi.c b/drivers/net/e1000_spi.c
index 5491780..5f774f4 100644
--- a/drivers/net/e1000_spi.c
+++ b/drivers/net/e1000_spi.c
@@ -1,4 +1,5 @@
#include e1000.h
+#include linux/compiler.h
/*---
* SPI transfer
@@ -112,7 +113,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
void spi_free_slave(struct spi_slave *spi)
{
- struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ __maybe_unused struct e1000_hw *hw = e1000_hw_from_spi(spi);
E1000_DBG(hw-nic, EEPROM SPI access released\n);
}
@@ -469,7 +470,7 @@ static int do_e1000_spi_program(cmd_tbl_t *cmdtp, struct
e1000_hw *hw,
static int do_e1000_spi_checksum(cmd_tbl_t *cmdtp, struct e1000_hw *hw,
int argc, char * const argv[])
{
- uint16_t i, length, checksum, checksum_reg;
+ uint16_t i, length, checksum = 0, checksum_reg;
uint16_t *buffer;
boolean_t upd;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
On Tuesday, December 20, 2011 01:06:07 PM you wrote: Dear Andreas, In message 201112201253.46991.schnitzelt...@gmx.de you wrote: I agree to your concerns but - as I understood Steve Sakoman - here the situation is slightly different: I think you misunderstand. Yes I think too :-) At elder overo boards TWL4030 RTC irq is connected to gpio112. Unfortunately this pin is also used for binary revision detection. Therefore we need to send 'shut-up' to TWL4030 via i2c to avoid reading wrong revision. In SPL this must be done *before* SDRAM (timing) is set up, because the type of SDRAM is revision dependent. My suggestion was to check if memory initialization can not rather be done _without_ reading (and without otherwise knowing) the board type or revision. Usually this is possible, and I always prefer such auto-adjusting solutions over hard-wired approaches that break down when any of the expected inout data is not correct or not available. Dear Wolfgang, I don't know if I want to jump also into these changes now - especially since I am quite new here.. But for my intererst - since it seems more error tolerant: How is SDRAM timing set up without exactly knowing what type is connected? Is there a good example implementation in u-boot(-spl)? Best regards Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sata_sil Driver on a PowerPC
On Tuesday 20 December 2011 13:59:12 John M Cavallo wrote: Thanks, but it didn't work. The 3114 is a very different beast from the 3132. I meant CONFIG_SATA_SIL. Re-reading the original message, I realized that I had copied the configuration from another attempt (I really have to work on my proof reeding skills). I should have said that I was using the sata_sil.c driver which claims to support the 3132. I am using the configuration: #define CONFIG_CMD_SATA #define CONFIG_SATA_SIL 1 #define CONFIG_LIBATA 1 #define CONFIG_LBA481 #define CONFIG_SYS_SATA_MAX_DEVICE 2 If this doesn't work (I have never used it before), and nobody else has any ideas, then you need to debug this issue... Best regards, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sata_sil Driver on a PowerPC
On Monday, December 19, 2011 Stefan Roese s...@denx.de wrote Hi John, On Monday 19 December 2011 22:26:09 johnc wrote: I am using the 405EX Kilauea Evaluation Board from Applied Micro, and am trying to get a Silicon Image 3124 PCIe to SATA adaptor working on it. I have modified the Kilauea configuration to include the sata_sil driver with the following in the configuration file: #define CONFIG_CMD_SATA #define CONFIG_FSL_SATA 1 This is definitely wrong. FSL is for Freescale. So its a driver for Freescales SoC SATA controller. There is a driver for the SI3124 though. Try this in your config header: #define CONFIG_CMD_SATA #define CONFIG_SATA_SIL3114 #define CONFIG_SYS_SATA_MAX_DEVICE2 #define CONFIG_LIBATA #define CONFIG_LBA48 Not sure if it works though. I have never used this driver personally. Best regards, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de Stefan, Thanks, but it didn't work. The 3114 is a very different beast from the 3132. Re-reading the original message, I realized that I had copied the configuration from another attempt (I really have to work on my proof reeding skills). I should have said that I was using the sata_sil.c driver which claims to support the 3132. I am using the configuration: #define CONFIG_CMD_SATA #define CONFIG_SATA_SIL 1 #define CONFIG_LIBATA 1 #define CONFIG_LBA481 #define CONFIG_SYS_SATA_MAX_DEVICE 2 John. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset Status on MPC83xx
Thought so, i was looking at the wrong manual 837x, hence did not find the section Thanks S From: Wolfgang Denk w...@denx.de To: Sridhar Addagada sridha...@yahoo.com Cc: u-boot@lists.denx.de u-boot@lists.denx.de Sent: Tuesday, December 20, 2011 5:18 PM Subject: Re: [U-Boot] Reset Status on MPC83xx Dear Sridhar Addagada, In message 1324360794.59571.yahoomail...@web120203.mail.ne1.yahoo.com you wrote: In an effort to find the cause of reboot from linux userspace, which was always returning hardreset, i traced the reason for the reset status register being cleared is from file arch/powerpc/cpu/mpc83xx/cpu_init.c, /* RSR - Reset Status Register - clear all status (4.6.1.3) */ gd-reset_status __raw_readl(im-reset.rsr); __raw_writel(~(RSR_RES), im-reset.rsr); Can anyone throw some light why it is getting cleared and what is 4.6.1.3 (4.6.1.3) usually means the relevant section in the respective user's manual (MPC8349E PowerQUICC II Pro Integrated Host Processor Family Reference Manual, Rev. 1), here section 4.6.1.3 Reset Status Register (RSR) on page 4-37 ff. The Note also explains why it makes sense to clear the register (so you can get a sane state for only the next reset/reboot). 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 What can it profit a man to gain the whole world and to come to his property with a gastric ulcer, a blown prostate, and bifocals? -- John Steinbeck, _Cannery Row U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot jumps to some location
On 20/12/2011 12:59, siddharth baisane wrote: hi, Hi, I am new to u-boot and have few doubts. I am trying to run uboot on custom board. I am using jtag(XDS 510 USB) to debug board. I have am3517 processor from ti. I have MT29C4G48MAZAPAKQ-5 IT chip which contains nand flash and lpddr. While making hardware I have not connected chip select 0 to this chip so I am not able to boot code from nand. Forget it ? So I am loading x-loader on internal sram at 0x40208800 and its running and I am getting message x-loader hangs on terminal U-Boot does not need x-loader anymore. The SPL substitutes the x-loader. You can load u-boot-spl.bin at 0x4020. Then I am loading uboot on ddr at 0x80e8. U-Boot for am3517_crane is linked 0x8010, as I can see. You must load at this address. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/4] mx28: Let imx_get_mac_from_fuse be common for mx28
Let imx_get_mac_from_fuse function be a common function, so that other
mx28 boards can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v5:
- Allow the MAC vendor to be overriden
Changes since v4:
- No changes
Change since v3:
- Add a note about the first two MAC addresses being from Freescale vendor.
arch/arm/cpu/arm926ejs/mx28/mx28.c | 44
board/denx/m28evk/m28evk.c | 35
2 files changed, 44 insertions(+), 35 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index 088c019..a25814e 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -214,6 +214,50 @@ int cpu_eth_init(bd_t *bis)
}
#endif
+static void __set_mac_vendor(char *mac)
+{
+ mac[0] = 0x00;
+ mac[1] = 0x04; /* Use FSL vendor MAC address by default */
+}
+
+void set_mac_vendor(char *mac)
+ __attribute__((weak, alias(__set_mac_vendor)));
+
+#ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
+
+#defineMXS_OCOTP_MAX_TIMEOUT 100
+
+void imx_get_mac_from_fuse(char *mac)
+{
+ struct mx28_ocotp_regs *ocotp_regs =
+ (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+ uint32_t data;
+
+ memset(mac, 0, 6);
+
+ writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
+
+ if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+ MXS_OCOTP_MAX_TIMEOUT)) {
+ printf(MXS FEC: Can't get MAC from OCOTP\n);
+ return;
+ }
+
+ data = readl(ocotp_regs-hw_ocotp_cust0);
+
+ mac[2] = (data 24) 0xff;
+ mac[3] = (data 16) 0xff;
+ mac[4] = (data 8) 0xff;
+ mac[5] = data 0xff;
+ set_mac_vendor(mac);
+}
+#else
+void imx_get_mac_from_fuse(char *mac)
+{
+ memset(mac, 0, 6);
+}
+#endif
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index fcee046..005446a 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
return ret;
}
-#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
-
-#defineMXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(char *mac)
-{
- struct mx28_ocotp_regs *ocotp_regs =
- (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
- uint32_t data;
-
- memset(mac, 0, 6);
-
- writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
-
- if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
- MXS_OCOTP_MAX_TIMEOUT)) {
- printf(MXS FEC: Can't get MAC from OCOTP\n);
- return;
- }
-
- data = readl(ocotp_regs-hw_ocotp_cust0);
-
- mac[0] = 0x00;
- mac[1] = 0x04;
- mac[2] = (data 24) 0xff;
- mac[3] = (data 16) 0xff;
- mac[4] = (data 8) 0xff;
- mac[5] = data 0xff;
-}
-#else
-void imx_get_mac_from_fuse(char *mac)
-{
- memset(mac, 0, 6);
-}
-#endif
-
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/4] mx28: Allow to set MAC address for the two FECs
MX28 has two built-in FECs (Fast Ethernet Controller).
OCOTP register can be used to only store 4 bytes of MAC addresses.
In order to workaround this limitation, let the MAC address of FEC1 be
the FEC0 address plus one.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v5:
No changes. Newly introduced on this series
arch/arm/cpu/arm926ejs/mx28/mx28.c |8 ++--
drivers/net/fec_mxc.c | 16
drivers/net/fec_mxc.h |1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index a25814e..79b4001 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -227,7 +227,7 @@ void set_mac_vendor(char *mac)
#defineMXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(char *mac)
+void mx28_get_mac_from_fuse(int dev_id, char *mac)
{
struct mx28_ocotp_regs *ocotp_regs =
(struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
@@ -249,10 +249,14 @@ void imx_get_mac_from_fuse(char *mac)
mac[3] = (data 16) 0xff;
mac[4] = (data 8) 0xff;
mac[5] = data 0xff;
+ /* Assume that FEC1 MAC address is MAC0 + 1 */
+ if (dev_id == 1)
+ mac[5]+= 1;
+
set_mac_vendor(mac);
}
#else
-void imx_get_mac_from_fuse(char *mac)
+void mx28_get_mac_from_fuse(int dev_id, char *mac)
{
memset(mac, 0, 6);
}
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index b05a4c0..a6bf597 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -345,11 +345,20 @@ static void fec_rbd_clean(int last, struct fec_bd *pRbd)
writew(0, pRbd-data_length);
}
+#ifndef CONFIG_MX28
static int fec_get_hwaddr(struct eth_device *dev, unsigned char *mac)
{
imx_get_mac_from_fuse(mac);
return !is_valid_ether_addr(mac);
}
+#else
+static int mx28_fec_get_hwaddr(struct eth_device *dev, int dev_id,
+ unsigned char *mac)
+{
+ mx28_get_mac_from_fuse(dev_id, mac);
+ return !is_valid_ether_addr(mac);
+}
+#endif
static int fec_set_hwaddr(struct eth_device *dev)
{
@@ -812,10 +821,17 @@ static int fec_probe(bd_t *bd, int dev_id, int phy_id,
uint32_t base_addr)
eth_register(edev);
+#ifndef CONFIG_MX28
if (fec_get_hwaddr(edev, ethaddr) == 0) {
debug(got MAC address from fuse: %pM\n, ethaddr);
memcpy(edev-enetaddr, ethaddr, 6);
}
+#else
+ if (mx28_fec_get_hwaddr(edev, dev_id, ethaddr) == 0) {
+ debug(got MAC%d address from fuse: %pM\n, dev_id, ethaddr);
+ memcpy(edev-enetaddr, ethaddr, 6);
+ }
+#endif
return ret;
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 8b26645..e2cfe4a 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -33,6 +33,7 @@
#define __FEC_MXC_H
void imx_get_mac_from_fuse(unsigned char *mac);
+void mx28_get_mac_from_fuse(int dev_id, unsigned char *mac);
/**
* Layout description of the FEC
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/4] mx28: Let dram_init be common for mx28
Let dram_init function be a common function, so that other mx28 boards
can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v5:
- Change return value on dram_init()
Changes since v4:
- Call mx28_dram_init from m28evk.c
Changes since v3:
- Rename dram_init to mx28_dram_init
arch/arm/cpu/arm926ejs/mx28/mx28.c | 21 +
arch/arm/include/asm/arch-mx28/sys_proto.h |2 ++
board/denx/m28evk/m28evk.c | 18 +-
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index 79b4001..722efbf 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -262,6 +262,27 @@ void mx28_get_mac_from_fuse(int dev_id, char *mac)
}
#endif
+#defineHW_DIGCTRL_SCRATCH0 0x8001c280
+#defineHW_DIGCTRL_SCRATCH1 0x8001c290
+int mx28_dram_init(void)
+{
+ uint32_t sz[2];
+
+ sz[0] = readl(HW_DIGCTRL_SCRATCH0);
+ sz[1] = readl(HW_DIGCTRL_SCRATCH1);
+
+ if (sz[0] != sz[1]) {
+ printf(MX28:\n
+ Error, the RAM size in HW_DIGCTRL_SCRATCH0 and\n
+ HW_DIGCTRL_SCRATCH1 is not the same. Please\n
+ verify these two registers contain valid RAM size!\n);
+ hang();
+ }
+
+ gd-ram_size = sz[0];
+ return 0;
+}
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/arch/arm/include/asm/arch-mx28/sys_proto.h
b/arch/arm/include/asm/arch-mx28/sys_proto.h
index be1f7db..f101494 100644
--- a/arch/arm/include/asm/arch-mx28/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx28/sys_proto.h
@@ -35,4 +35,6 @@ void mx28_common_spl_init(const iomux_cfg_t *iomux_setup,
const unsigned int iomux_size);
#endif
+int mx28_dram_init(void);
+
#endif /* __MX28_H__ */
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index 005446a..53df476 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -70,25 +70,9 @@ int board_init(void)
return 0;
}
-#defineHW_DIGCTRL_SCRATCH0 0x8001c280
-#defineHW_DIGCTRL_SCRATCH1 0x8001c290
int dram_init(void)
{
- uint32_t sz[2];
-
- sz[0] = readl(HW_DIGCTRL_SCRATCH0);
- sz[1] = readl(HW_DIGCTRL_SCRATCH1);
-
- if (sz[0] != sz[1]) {
- printf(MX28:\n
- Error, the RAM size in HW_DIGCTRL_SCRATCH0 and\n
- HW_DIGCTRL_SCRATCH1 is not the same. Please\n
- verify these two registers contain valid RAM size!\n);
- hang();
- }
-
- gd-ram_size = sz[0];
- return 0;
+ return mx28_dram_init();
}
#ifdef CONFIG_CMD_MMC
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 4/4] mx28evk: Add initial support for MX28EVK board
Add initial support for Freescale MX28EVK board. Tested boot via SD card and by loading a kernel via TFTP through the FEC interface. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- - For correct operation of saving environment variables into the SD card, the following patch is needed: http://lists.denx.de/pipermail/u-boot/2011-November/111448.html Changes since v5: - Fix tab vs spaces on mx28evk.h - Change return value on dram_init() Changes since v4: - No changes Changes since v3: - Fix Copyright in mx28evk.h - Call mx28_dram_init from dram_init Changes since v2: - Generate the patch again due to error in applying unrelated changes Changes since v1: - Read the MAC from fuses - Use tabs instead of space in u-boot.bd - Use puts instead of print - Factor out mac reading function - Factor out ddr size calculation function - Use GENERATED_GBL_DATA_SIZE - Protect CONFIG_ENV_IS_IN_MMC MAINTAINERS |1 + board/freescale/mx28evk/Makefile | 49 ++ board/freescale/mx28evk/iomux.c | 138 + board/freescale/mx28evk/mx28evk.c | 169 +++ board/freescale/mx28evk/u-boot.bd | 14 +++ boards.cfg|1 + include/configs/mx28evk.h | 176 + 7 files changed, 548 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx28evk/Makefile create mode 100644 board/freescale/mx28evk/iomux.c create mode 100644 board/freescale/mx28evk/mx28evk.c create mode 100644 board/freescale/mx28evk/u-boot.bd create mode 100644 include/configs/mx28evk.h diff --git a/MAINTAINERS b/MAINTAINERS index a56ca10..72e1089 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -639,6 +639,7 @@ Kristoffer Ericson kristoffer.eric...@gmail.com Fabio Estevam fabio.este...@freescale.com mx25pdk i.MX25 + mx28evk i.MX28 mx31pdk i.MX31 mx53ard i.MX53 mx53smd i.MX53 diff --git a/board/freescale/mx28evk/Makefile b/board/freescale/mx28evk/Makefile new file mode 100644 index 000..7459107 --- /dev/null +++ b/board/freescale/mx28evk/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +ifndef CONFIG_SPL_BUILD +COBJS := mx28evk.o +else +COBJS := iomux.o +endif + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +all: $(ALL) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx28evk/iomux.c b/board/freescale/mx28evk/iomux.c new file mode 100644 index 000..904e3f3 --- /dev/null +++ b/board/freescale/mx28evk/iomux.c @@ -0,0 +1,138 @@ +/* + * Freescale MX28EVK IOMUX setup + * + * Copyright (C) 2011 Marek Vasut marek.va...@gmail.com + * on behalf of DENX Software Engineering GmbH + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include common.h +#include config.h +#include asm/io.h +#include asm/arch/iomux-mx28.h +#include asm/arch/imx-regs.h +#include asm/arch/sys_proto.h + +#defineMUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) +#defineMUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) +#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL) + +const iomux_cfg_t
Re: [U-Boot] [PATCH v6 1/4] mx28: Let imx_get_mac_from_fuse be common for mx28
Let imx_get_mac_from_fuse function be a common function, so that other
mx28 boards can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v5:
- Allow the MAC vendor to be overriden
Changes since v4:
- No changes
Change since v3:
- Add a note about the first two MAC addresses being from Freescale vendor.
arch/arm/cpu/arm926ejs/mx28/mx28.c | 44
board/denx/m28evk/m28evk.c |
35 2 files changed, 44 insertions(+), 35
deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c index 088c019..a25814e 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -214,6 +214,50 @@ int cpu_eth_init(bd_t *bis)
}
#endif
+static void __set_mac_vendor(char *mac)
+{
+ mac[0] = 0x00;
+ mac[1] = 0x04; /* Use FSL vendor MAC address by default */
+}
+
+void set_mac_vendor(char *mac)
+ __attribute__((weak, alias(__set_mac_vendor)));
+
+#ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
+
+#define MXS_OCOTP_MAX_TIMEOUT 100
+
+void imx_get_mac_from_fuse(char *mac)
+{
+ struct mx28_ocotp_regs *ocotp_regs =
+ (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+ uint32_t data;
+
+ memset(mac, 0, 6);
+
+ writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
+
+ if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+ MXS_OCOTP_MAX_TIMEOUT)) {
+ printf(MXS FEC: Can't get MAC from OCOTP\n);
+ return;
+ }
+
+ data = readl(ocotp_regs-hw_ocotp_cust0);
+
+ mac[2] = (data 24) 0xff;
+ mac[3] = (data 16) 0xff;
+ mac[4] = (data 8) 0xff;
+ mac[5] = data 0xff;
+ set_mac_vendor(mac);
+}
+#else
+void imx_get_mac_from_fuse(char *mac)
+{
+ memset(mac, 0, 6);
+}
+#endif
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index fcee046..005446a 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
return ret;
}
-#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
-
-#define MXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(char *mac)
-{
- struct mx28_ocotp_regs *ocotp_regs =
- (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
- uint32_t data;
-
- memset(mac, 0, 6);
-
- writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
-
- if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
- MXS_OCOTP_MAX_TIMEOUT)) {
- printf(MXS FEC: Can't get MAC from OCOTP\n);
- return;
- }
-
- data = readl(ocotp_regs-hw_ocotp_cust0);
-
- mac[0] = 0x00;
- mac[1] = 0x04;
- mac[2] = (data 24) 0xff;
- mac[3] = (data 16) 0xff;
- mac[4] = (data 8) 0xff;
- mac[5] = data 0xff;
-}
-#else
-void imx_get_mac_from_fuse(char *mac)
-{
- memset(mac, 0, 6);
-}
-#endif
-
#endif
It's good, but why not make it completely generic -- like mx28_adjust_mac() --
so the users can for example change the last bit of the mac depending on the
NIC
that's used (FEC0 or FEC1). I think I proposed that. It's only a matter of
adding a parameter (nic #) and renaming it :)
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
On Tue, Dec 20, 2011 at 4:20 AM, Igor Grinberg grinb...@compulab.co.ilwrote: What about forging some very not optimized default DRAM settings, that suit any assembled DRAM and then when you have I2C access, reconfigure it - is it possible? The board ID is used to determine some fairly fundamental things like how the address bits are multiplexed, bank size, number of banks, and timing. Perhaps it might be possible to determine some non-optimal settings that can work with the current set of POP memories used, and also a scheme to modify the above on the fly while executing from said ram, but then one would have to revisit this every time a new vendor/type of POP was used. That seems a lot more complex than the current method. I suppose we could just drop support for the old boards in u-boot. Those folks could continue to use the current x-load solution. Or perhaps someone will come up with a more clever idea! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/4] mx28: Allow to set MAC address for the two FECs
MX28 has two built-in FECs (Fast Ethernet Controller).
OCOTP register can be used to only store 4 bytes of MAC addresses.
In order to workaround this limitation, let the MAC address of FEC1 be
the FEC0 address plus one.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v5:
No changes. Newly introduced on this series
arch/arm/cpu/arm926ejs/mx28/mx28.c |8 ++--
drivers/net/fec_mxc.c | 16
drivers/net/fec_mxc.h |1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c index a25814e..79b4001 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -227,7 +227,7 @@ void set_mac_vendor(char *mac)
#define MXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(char *mac)
+void mx28_get_mac_from_fuse(int dev_id, char *mac)
{
struct mx28_ocotp_regs *ocotp_regs =
(struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
@@ -249,10 +249,14 @@ void imx_get_mac_from_fuse(char *mac)
mac[3] = (data 16) 0xff;
mac[4] = (data 8) 0xff;
mac[5] = data 0xff;
+ /* Assume that FEC1 MAC address is MAC0 + 1 */
+ if (dev_id == 1)
+ mac[5]+= 1;
No, please don't ... user might want to do this the other way around so just
give him the freedom (and you're missing space before +) :) You can move
exactly
this code to the default implementation of mx28_mac_adjust().
+
set_mac_vendor(mac);
}
#else
-void imx_get_mac_from_fuse(char *mac)
+void mx28_get_mac_from_fuse(int dev_id, char *mac)
{
memset(mac, 0, 6);
}
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index b05a4c0..a6bf597 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -345,11 +345,20 @@ static void fec_rbd_clean(int last, struct fec_bd
*pRbd) writew(0, pRbd-data_length);
}
+#ifndef CONFIG_MX28
static int fec_get_hwaddr(struct eth_device *dev, unsigned char *mac)
{
imx_get_mac_from_fuse(mac);
return !is_valid_ether_addr(mac);
}
+#else
+static int mx28_fec_get_hwaddr(struct eth_device *dev, int dev_id,
+ unsigned char *mac)
+{
+ mx28_get_mac_from_fuse(dev_id, mac);
+ return !is_valid_ether_addr(mac);
+}
+#endif
static int fec_set_hwaddr(struct eth_device *dev)
{
@@ -812,10 +821,17 @@ static int fec_probe(bd_t *bd, int dev_id, int
phy_id, uint32_t base_addr)
eth_register(edev);
+#ifndef CONFIG_MX28
if (fec_get_hwaddr(edev, ethaddr) == 0) {
debug(got MAC address from fuse: %pM\n, ethaddr);
memcpy(edev-enetaddr, ethaddr, 6);
}
+#else
+ if (mx28_fec_get_hwaddr(edev, dev_id, ethaddr) == 0) {
+ debug(got MAC%d address from fuse: %pM\n, dev_id, ethaddr);
+ memcpy(edev-enetaddr, ethaddr, 6);
+ }
+#endif
return ret;
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 8b26645..e2cfe4a 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -33,6 +33,7 @@
#define __FEC_MXC_H
void imx_get_mac_from_fuse(unsigned char *mac);
+void mx28_get_mac_from_fuse(int dev_id, unsigned char *mac);
/**
* Layout description of the FEC
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 3/4] mx28: Let dram_init be common for mx28
Let dram_init function be a common function, so that other mx28 boards
can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v5:
- Change return value on dram_init()
Changes since v4:
- Call mx28_dram_init from m28evk.c
Changes since v3:
- Rename dram_init to mx28_dram_init
arch/arm/cpu/arm926ejs/mx28/mx28.c | 21 +
arch/arm/include/asm/arch-mx28/sys_proto.h |2 ++
board/denx/m28evk/m28evk.c | 18 +-
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c index 79b4001..722efbf 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -262,6 +262,27 @@ void mx28_get_mac_from_fuse(int dev_id, char *mac)
}
#endif
+#define HW_DIGCTRL_SCRATCH0 0x8001c280
+#define HW_DIGCTRL_SCRATCH1 0x8001c290
+int mx28_dram_init(void)
+{
+ uint32_t sz[2];
+
+ sz[0] = readl(HW_DIGCTRL_SCRATCH0);
+ sz[1] = readl(HW_DIGCTRL_SCRATCH1);
+
+ if (sz[0] != sz[1]) {
+ printf(MX28:\n
+ Error, the RAM size in HW_DIGCTRL_SCRATCH0 and\n
+ HW_DIGCTRL_SCRATCH1 is not the same. Please\n
+ verify these two registers contain valid RAM size!\n);
+ hang();
+ }
+
+ gd-ram_size = sz[0];
+ return 0;
+}
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/arch/arm/include/asm/arch-mx28/sys_proto.h
b/arch/arm/include/asm/arch-mx28/sys_proto.h index be1f7db..f101494 100644
--- a/arch/arm/include/asm/arch-mx28/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx28/sys_proto.h
@@ -35,4 +35,6 @@ void mx28_common_spl_init(const iomux_cfg_t *iomux_setup,
const unsigned int iomux_size);
#endif
+int mx28_dram_init(void);
+
#endif /* __MX28_H__ */
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index 005446a..53df476 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -70,25 +70,9 @@ int board_init(void)
return 0;
}
-#define HW_DIGCTRL_SCRATCH0 0x8001c280
-#define HW_DIGCTRL_SCRATCH1 0x8001c290
int dram_init(void)
{
- uint32_t sz[2];
-
- sz[0] = readl(HW_DIGCTRL_SCRATCH0);
- sz[1] = readl(HW_DIGCTRL_SCRATCH1);
-
- if (sz[0] != sz[1]) {
- printf(MX28:\n
- Error, the RAM size in HW_DIGCTRL_SCRATCH0 and\n
- HW_DIGCTRL_SCRATCH1 is not the same. Please\n
- verify these two registers contain valid RAM size!\n);
- hang();
- }
-
- gd-ram_size = sz[0];
- return 0;
+ return mx28_dram_init();
}
#ifdef CONFIG_CMD_MMC
Acked-by: Marek Vasut marek.va...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/4] mx28evk: Add initial support for MX28EVK board
Add initial support for Freescale MX28EVK board. Tested boot via SD card and by loading a kernel via TFTP through the FEC interface. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- - For correct operation of saving environment variables into the SD card, the following patch is needed: http://lists.denx.de/pipermail/u-boot/2011-November/111448.html Changes since v5: - Fix tab vs spaces on mx28evk.h - Change return value on dram_init() Changes since v4: - No changes Changes since v3: - Fix Copyright in mx28evk.h - Call mx28_dram_init from dram_init Changes since v2: - Generate the patch again due to error in applying unrelated changes Changes since v1: - Read the MAC from fuses - Use tabs instead of space in u-boot.bd - Use puts instead of print - Factor out mac reading function - Factor out ddr size calculation function - Use GENERATED_GBL_DATA_SIZE - Protect CONFIG_ENV_IS_IN_MMC MAINTAINERS |1 + board/freescale/mx28evk/Makefile | 49 ++ board/freescale/mx28evk/iomux.c | 138 + board/freescale/mx28evk/mx28evk.c | 169 +++ board/freescale/mx28evk/u-boot.bd | 14 +++ boards.cfg|1 + include/configs/mx28evk.h | 176 + 7 files changed, 548 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx28evk/Makefile create mode 100644 board/freescale/mx28evk/iomux.c create mode 100644 board/freescale/mx28evk/mx28evk.c create mode 100644 board/freescale/mx28evk/u-boot.bd create mode 100644 include/configs/mx28evk.h diff --git a/MAINTAINERS b/MAINTAINERS index a56ca10..72e1089 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -639,6 +639,7 @@ Kristoffer Ericson kristoffer.eric...@gmail.com Fabio Estevam fabio.este...@freescale.com mx25pdk i.MX25 + mx28evk i.MX28 mx31pdk i.MX31 mx53ard i.MX53 mx53smd i.MX53 diff --git a/board/freescale/mx28evk/Makefile b/board/freescale/mx28evk/Makefile new file mode 100644 index 000..7459107 --- /dev/null +++ b/board/freescale/mx28evk/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +ifndef CONFIG_SPL_BUILD +COBJS:= mx28evk.o +else +COBJS:= iomux.o +endif + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB): $(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +all: $(ALL) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx28evk/iomux.c b/board/freescale/mx28evk/iomux.c new file mode 100644 index 000..904e3f3 --- /dev/null +++ b/board/freescale/mx28evk/iomux.c @@ -0,0 +1,138 @@ +/* + * Freescale MX28EVK IOMUX setup + * + * Copyright (C) 2011 Marek Vasut marek.va...@gmail.com + * on behalf of DENX Software Engineering GmbH + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include common.h +#include config.h +#include asm/io.h +#include asm/arch/iomux-mx28.h +#include asm/arch/imx-regs.h +#include asm/arch/sys_proto.h + +#define MUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) +#define MUX_CONFIG_ENET (MXS_PAD_3V3 |
[U-Boot] [PATCH] Makefile: fix distclean and *_config rules to be less noise
Signed-off-by: Lauri Hintsala lauri.hints...@bluegiga.com
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 05966f4..ba336ed 100644
--- a/Makefile
+++ b/Makefile
@@ -643,7 +643,7 @@ unconfig:
sinclude $(obj).boards.depend
$(obj).boards.depend: boards.cfg
- awk '(NF $$1 !~ /^#/) { print $$1 : $$1 _config; $$(MAKE) }' $
$@
+ @awk '(NF $$1 !~ /^#/) { print $$1 : $$1 _config; $$(MAKE) }'
$ $@
#
# Functions to generate common board directory names
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/4] mx28: Allow to set MAC address for the two FECs
On 20/12/2011 14:53, Fabio Estevam wrote:
MX28 has two built-in FECs (Fast Ethernet Controller).
OCOTP register can be used to only store 4 bytes of MAC addresses.
In order to workaround this limitation, let the MAC address of FEC1 be
the FEC0 address plus one.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Hi Fabio,
Changes since v5:
No changes. Newly introduced on this series
arch/arm/cpu/arm926ejs/mx28/mx28.c |8 ++--
drivers/net/fec_mxc.c | 16
drivers/net/fec_mxc.h |1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index a25814e..79b4001 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -227,7 +227,7 @@ void set_mac_vendor(char *mac)
#define MXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(char *mac)
+void mx28_get_mac_from_fuse(int dev_id, char *mac)
{
but imx_get_mac_from_fuse() is common to all IMX SOCs. Why do we need
another name only for MX28 ? I think it is better to adjust
imx_get_mac_from_fuse() to allow a second parameter (dev_id), that can
be ignored in other SOCs implementations.
struct mx28_ocotp_regs *ocotp_regs =
(struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
@@ -249,10 +249,14 @@ void imx_get_mac_from_fuse(char *mac)
mac[3] = (data 16) 0xff;
mac[4] = (data 8) 0xff;
mac[5] = data 0xff;
+ /* Assume that FEC1 MAC address is MAC0 + 1 */
+ if (dev_id == 1)
+ mac[5]+= 1;
+
set_mac_vendor(mac);
Should be not better that the additional mac is computed by the (weak)
board function ? Then it is responsibility of the board and his
maintainer to change (if needed) the MAC for the second interface.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] mx28: Let imx_get_mac_from_fuse be common for mx28
On 12/20/2011 03:55 PM, Marek Vasut wrote: Let imx_get_mac_from_fuse function be a common function, so that other mx28 boards can reuse it. [snip] +static void __set_mac_vendor(char *mac) [snip] It's good, but why not make it completely generic -- like mx28_adjust_mac() -- so the users can for example change the last bit of the mac depending on the NIC that's used (FEC0 or FEC1). I think I proposed that. It's only a matter of adding a parameter (nic #) and renaming it :) What is stored in MX28EVK CUST1 fuse? It seems to be CUST0 increased by one. So maybe we should read it from there for FEC1? It would be nice to have very generic fuse reading function that could be used to read a serial number or similar user data. I will work this out if you don't like to do it. I'm quite busy now so it might take a week or two. -- Veli-Pekka Peltola ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] mx28: Let imx_get_mac_from_fuse be common for mx28
On 12/20/2011 03:55 PM, Marek Vasut wrote: Let imx_get_mac_from_fuse function be a common function, so that other mx28 boards can reuse it. [snip] +static void __set_mac_vendor(char *mac) [snip] It's good, but why not make it completely generic -- like mx28_adjust_mac() -- so the users can for example change the last bit of the mac depending on the NIC that's used (FEC0 or FEC1). I think I proposed that. It's only a matter of adding a parameter (nic #) and renaming it :) What is stored in MX28EVK CUST1 fuse? It seems to be CUST0 increased by one. So maybe we should read it from there for FEC1? It would be nice to have very generic fuse reading function that could be used to read a serial number or similar user data. I will work this out if you don't like to do it. I'm quite busy now so it might take a week or two. The release'll be early xmas present from Wolfgang, so you have those two weeks no problem ;-) Please go ahead and do it. Thanks! M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28: remove omap specific config options
On 20/12/2011 13:00, Veli-Pekka Peltola wrote: Config options for OMAP are not used with i.MX28 so remove dead code. Signed-off-by: Veli-Pekka Peltola veli-pekka.pelt...@bluegiga.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/arm926ejs/mx28/start.S |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) Applied to u-boot-imx, next branch, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/esd/cpci750/mv_eth.c: Fix GCC 4.6 build warnings
Fix:
mv_eth.c: In function 'mv64360_eth_real_open':
mv_eth.c:425:6: warning: variable 'port_status' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'mv64360_eth_stop':
mv_eth.c:643:15: warning: variable 'port_num' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'mv64360_eth_xmit':
mv_eth.c:719:15: warning: variable 'port_num' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'mv64360_eth_receive':
mv_eth.c:804:15: warning: variable 'port_num' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'mv64360_eth_get_stats':
mv_eth.c:903:15: warning: variable 'port_num' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'mv64360_eth_update_stat':
mv_eth.c:931:24: warning: variable 'dummy' set but not used
[-Wunused-but-set-variable]
mv_eth.c:930:15: warning: variable 'port_num' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'mv64360_eth_print_stat':
mv_eth.c:1012:15: warning: variable 'port_num' set but not used
[-Wunused-but-set-variable]
mv_eth.c: In function 'eth_clear_mib_counters':
mv_eth.c:2069:15: warning: variable 'dummy' set but not used
[-Wunused-but-set-variable
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Reinhard Arlt reinhard.a...@esd.eu
---
board/esd/cpci750/mv_eth.c | 34 +++---
1 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/board/esd/cpci750/mv_eth.c b/board/esd/cpci750/mv_eth.c
index 781ad23..001c1ad 100644
--- a/board/esd/cpci750/mv_eth.c
+++ b/board/esd/cpci750/mv_eth.c
@@ -422,7 +422,7 @@ static int mv64360_eth_real_open (struct eth_device *dev)
ETH_PORT_INFO *ethernet_private;
struct mv64360_eth_priv *port_private;
unsigned int port_num;
- u32 port_status, phy_reg_data;
+ u32 phy_reg_data;
ethernet_private = (ETH_PORT_INFO *) dev-priv;
/* ronen - when we update the MAC env params we only update
dev-enetaddr
@@ -520,7 +520,7 @@ static int mv64360_eth_real_open (struct eth_device *dev)
*/
MV_REG_WRITE (MV64360_ETH_MAXIMUM_TRANSMIT_UNIT (port_num), 0);
- port_status = MV_REG_READ (MV64360_ETH_PORT_STATUS_REG (port_num));
+ MV_REG_READ (MV64360_ETH_PORT_STATUS_REG (port_num));
/* Check Link status on phy */
eth_port_read_smi_reg (port_num, 1, phy_reg_data);
@@ -638,15 +638,6 @@ static int mv64360_eth_free_rx_rings (struct eth_device
*dev)
int mv64360_eth_stop (struct eth_device *dev)
{
- ETH_PORT_INFO *ethernet_private;
- struct mv64360_eth_priv *port_private;
- unsigned int port_num;
-
- ethernet_private = (ETH_PORT_INFO *) dev-priv;
- port_private =
- (struct mv64360_eth_priv *) ethernet_private-port_private;
- port_num = port_private-port_num;
-
/* Disable all gigE address decoder */
MV_REG_WRITE (MV64360_ETH_BASE_ADDR_ENABLE_REG, 0x3f);
DP (printf (%s Ethernet stop called ... \n, __FUNCTION__));
@@ -716,7 +707,6 @@ int mv64360_eth_xmit (struct eth_device *dev, volatile void
*dataPtr,
{
ETH_PORT_INFO *ethernet_private;
struct mv64360_eth_priv *port_private;
- unsigned int port_num;
PKT_INFO pkt_info;
ETH_FUNC_RET_STATUS status;
struct net_device_stats *stats;
@@ -725,7 +715,6 @@ int mv64360_eth_xmit (struct eth_device *dev, volatile void
*dataPtr,
ethernet_private = (ETH_PORT_INFO *) dev-priv;
port_private =
(struct mv64360_eth_priv *) ethernet_private-port_private;
- port_num = port_private-port_num;
stats = port_private-stats;
@@ -801,7 +790,6 @@ int mv64360_eth_receive (struct eth_device *dev)
{
ETH_PORT_INFO *ethernet_private;
struct mv64360_eth_priv *port_private;
- unsigned int port_num;
PKT_INFO pkt_info;
struct net_device_stats *stats;
@@ -809,7 +797,6 @@ int mv64360_eth_receive (struct eth_device *dev)
ethernet_private = (ETH_PORT_INFO *) dev-priv;
port_private =
(struct mv64360_eth_priv *) ethernet_private-port_private;
- port_num = port_private-port_num;
stats = port_private-stats;
while ((eth_port_receive (ethernet_private, ETH_Q0, pkt_info) ==
@@ -900,12 +887,10 @@ static struct net_device_stats *mv64360_eth_get_stats
(struct eth_device *dev)
{
ETH_PORT_INFO *ethernet_private;
struct mv64360_eth_priv *port_private;
- unsigned int port_num;
ethernet_private = (ETH_PORT_INFO *) dev-priv;
port_private =
(struct mv64360_eth_priv *) ethernet_private-port_private;
- port_num = port_private-port_num;
mv64360_eth_update_stat (dev);
@@ -927,13 +912,10 @@ static void mv64360_eth_update_stat (struct eth_device
*dev)
ETH_PORT_INFO *ethernet_private;
struct mv64360_eth_priv *port_private;
struct net_device_stats *stats;
- unsigned int port_num;
-
Re: [U-Boot] Some thoughts on SPL
On Fri, Dec 16, 2011 at 10:20 AM, jonsm...@gmail.com jonsm...@gmail.com wrote: The CPU I'm working with, the LPC3130, is kind of an in-between CPU for SPL. Instead of a tightly constrained RAM of 16KB or so I have 96KB to work with. 96KB is enough room to support all of the various boot modes (uart, nand, spi, USB, etc) but not enough room for the full uboot command set. So I'm still stuck with the SPL model, but my constraints are much less. One example of a conflict with SPL is NAND support. With SPL you hard code in the NAND type. In my case I have enough room to do NAND type detection. So this has me modifying the #ifdefs in the makefiles to include the NAND detection code in my SPL loader. I'm wondering if SPL could be designed in a more generic manner. Another model would be to use SPL as the base layer for all u-boot builds. You would then start turning on features until full uboot capability was reached. An example of this would be NAND support, the default would be hard coded NAND for all u-boot builds, but turning on NAND detection would increase the size of the build and disable the hard coded support. Another default would be SPL chaining into the next image, turning on the u-boot UI would again make the code larger and disable auto-chaining. So, in chasing down another problem I was having (that turned out unrelated) I just made SPL use the full NAND stack. It wouldn't be difficult to add CONFIG_SPL_FULL_NAND_SUPPORT (and either keep the existing name for nand_spl_simple or rename to CONFIG_SPL_MIN_NAND_SUPPORT). I've even got the tree I did that hack in around on github if you want a reference. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
On Mon, Dec 19, 2011 at 6:23 AM, Wolfgang Denk w...@denx.de wrote: Hi everybody, I've just released v2011.12-rc2; please help testing. Please respond quickly if you find anything missing for the final release, I want to get this out on Friday at latest. I'm testing out the latest u-boot on my pandaboard Rev A1 (OMAP4430). A build of v2011.12-rc2 (using the cross-compiler on Ubuntu 10.10) works on the pandaboard, except for USB and ethernet. There is an outstanding pull request (http://lists.denx.de/pipermail/u-boot/2011-December/113883.html) that fixes this. Unfortunately, trying to build v2011.12-rc2 with the cross-compiler from Ubuntu 11.10 causes an ICE. I'm taking a look at it now to see if I can figure out the problem, but I thought I would point it out sooner rather than later. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 1/4] net: imx: Add multi-FEC support for imx_get_mac_from_fuse
Add multi-FEC support for imx_get_mac_from_fuse by passing dev_id as a
parameter.
This feature is important on mx28 SoC for example that has two FEC ports.
Cc: Ben Warren biggerbadder...@gmail.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Change since v6:
- No changes. Introduced on this series
arch/arm/cpu/arm1136/mx35/generic.c |2 +-
arch/arm/cpu/arm926ejs/mx25/generic.c|2 +-
arch/arm/cpu/arm926ejs/mx27/generic.c|2 +-
arch/arm/cpu/armv7/mx6/soc.c |2 +-
arch/arm/include/asm/arch-mx6/imx-regs.h |2 +-
board/denx/m28evk/m28evk.c |4 ++--
drivers/net/fec_mxc.c|9 +
drivers/net/fec_mxc.h|2 +-
8 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx35/generic.c
b/arch/arm/cpu/arm1136/mx35/generic.c
index ac4838f..d41613e 100644
--- a/arch/arm/cpu/arm1136/mx35/generic.c
+++ b/arch/arm/cpu/arm1136/mx35/generic.c
@@ -393,7 +393,7 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
/*
* The MX35 has no fuse for MAC, return a NULL MAC
*/
-void imx_get_mac_from_fuse(unsigned char *mac)
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
{
memset(mac, 0, 6);
}
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index c045a0b..9cadb7c 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -312,7 +312,7 @@ void mx25_fec_init_pins(void)
}
-void imx_get_mac_from_fuse(unsigned char *mac)
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
{
int i;
struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index 222a8e9..34c20e1 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -314,7 +314,7 @@ void mx27_fec_init_pins(void)
imx_gpio_mode(mode[i]);
}
-void imx_get_mac_from_fuse(unsigned char *mac)
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
{
int i;
struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index dff5e4e..5a6f9e2 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -63,7 +63,7 @@ int arch_cpu_init(void)
#endif
#if defined(CONFIG_FEC_MXC)
-void imx_get_mac_from_fuse(unsigned char *mac)
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
{
struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
struct fuse_bank *bank = iim-bank[4];
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 85d55b7..dfec6b0 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -167,7 +167,7 @@
#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
#include asm/types.h
-extern void imx_get_mac_from_fuse(unsigned char *mac);
+extern void imx_get_mac_from_fuse(int dev_id, unsigned char *mac);
/* System Reset Controller (SRC) */
struct src {
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index fcee046..a0fabc0 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -181,7 +181,7 @@ int board_eth_init(bd_t *bis)
#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
#defineMXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(char *mac)
+void imx_get_mac_from_fuse(int dev_id, char *mac)
{
struct mx28_ocotp_regs *ocotp_regs =
(struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
@@ -207,7 +207,7 @@ void imx_get_mac_from_fuse(char *mac)
mac[5] = data 0xff;
}
#else
-void imx_get_mac_from_fuse(char *mac)
+void imx_get_mac_from_fuse(int dev_id, char *mac)
{
memset(mac, 0, 6);
}
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index b05a4c0..1529a27 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -345,9 +345,10 @@ static void fec_rbd_clean(int last, struct fec_bd *pRbd)
writew(0, pRbd-data_length);
}
-static int fec_get_hwaddr(struct eth_device *dev, unsigned char *mac)
+static int fec_get_hwaddr(struct eth_device *dev, int dev_id,
+ unsigned char *mac)
{
- imx_get_mac_from_fuse(mac);
+ imx_get_mac_from_fuse(dev_id, mac);
return !is_valid_ether_addr(mac);
}
@@ -812,8 +813,8 @@ static int fec_probe(bd_t *bd, int dev_id, int phy_id,
uint32_t base_addr)
eth_register(edev);
- if (fec_get_hwaddr(edev, ethaddr) == 0) {
- debug(got MAC address from fuse: %pM\n, ethaddr);
+ if (fec_get_hwaddr(edev, dev_id, ethaddr) == 0) {
+ debug(got MAC%d address from fuse: %pM\n, dev_id, ethaddr);
memcpy(edev-enetaddr, ethaddr, 6);
}
diff --git a/drivers/net/fec_mxc.h
[U-Boot] [PATCH v7 2/4] mx28: Let imx_get_mac_from_fuse be common for mx28
Let imx_get_mac_from_fuse function be a common function, so that other
mx28 boards can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v6:
- Let mac[5] be set inside mx28_adjust_mac
Changes since v5:
- Allow the MAC vendor to be overriden
Changes since v4:
- No changes
Change since v3:
- Add a note about the first two MAC addresses being from Freescale vendor.
arch/arm/cpu/arm926ejs/mx28/mx28.c | 46
board/denx/m28evk/m28evk.c | 35 ---
2 files changed, 46 insertions(+), 35 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index 088c019..ee4e337 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -214,6 +214,52 @@ int cpu_eth_init(bd_t *bis)
}
#endif
+static void __mx28_adjust_mac(int dev_id, char *mac)
+{
+ mac[0] = 0x00;
+ mac[1] = 0x04; /* Use FSL vendor MAC address by default */
+
+ if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
+ mac[5] += 1;
+}
+
+void mx28_adjust_mac(int dev_id, char *mac)
+ __attribute__((weak, alias(__mx28_adjust_mac)));
+
+#ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
+
+#defineMXS_OCOTP_MAX_TIMEOUT 100
+void imx_get_mac_from_fuse(int dev_id, char *mac)
+{
+ struct mx28_ocotp_regs *ocotp_regs =
+ (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+ uint32_t data;
+
+ memset(mac, 0, 6);
+
+ writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
+
+ if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+ MXS_OCOTP_MAX_TIMEOUT)) {
+ printf(MXS FEC: Can't get MAC from OCOTP\n);
+ return;
+ }
+
+ data = readl(ocotp_regs-hw_ocotp_cust0);
+
+ mac[2] = (data 24) 0xff;
+ mac[3] = (data 16) 0xff;
+ mac[4] = (data 8) 0xff;
+ mac[5] = data 0xff;
+ mx28_adjust_mac(dev_id, mac);
+}
+#else
+void imx_get_mac_from_fuse(int dev_id, char *mac)
+{
+ memset(mac, 0, 6);
+}
+#endif
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index a0fabc0..005446a 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
return ret;
}
-#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
-
-#defineMXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- struct mx28_ocotp_regs *ocotp_regs =
- (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
- uint32_t data;
-
- memset(mac, 0, 6);
-
- writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
-
- if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
- MXS_OCOTP_MAX_TIMEOUT)) {
- printf(MXS FEC: Can't get MAC from OCOTP\n);
- return;
- }
-
- data = readl(ocotp_regs-hw_ocotp_cust0);
-
- mac[0] = 0x00;
- mac[1] = 0x04;
- mac[2] = (data 24) 0xff;
- mac[3] = (data 16) 0xff;
- mac[4] = (data 8) 0xff;
- mac[5] = data 0xff;
-}
-#else
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- memset(mac, 0, 6);
-}
-#endif
-
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 3/4] mx28: Let dram_init be common for mx28
Let dram_init function be a common function, so that other mx28 boards
can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Marek Vasut marek.va...@gmail.com
---
Changes since v6:
- Added Acked-by line
Changes since v5:
- Change return value on dram_init()
Changes since v4:
- Call mx28_dram_init from m28evk.c
Changes since v3:
- Rename dram_init to mx28_dram_init
arch/arm/cpu/arm926ejs/mx28/mx28.c | 21 +
arch/arm/include/asm/arch-mx28/sys_proto.h |2 ++
board/denx/m28evk/m28evk.c | 18 +-
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index ee4e337..c95e900 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -260,6 +260,27 @@ void imx_get_mac_from_fuse(int dev_id, char *mac)
}
#endif
+#defineHW_DIGCTRL_SCRATCH0 0x8001c280
+#defineHW_DIGCTRL_SCRATCH1 0x8001c290
+int mx28_dram_init(void)
+{
+ uint32_t sz[2];
+
+ sz[0] = readl(HW_DIGCTRL_SCRATCH0);
+ sz[1] = readl(HW_DIGCTRL_SCRATCH1);
+
+ if (sz[0] != sz[1]) {
+ printf(MX28:\n
+ Error, the RAM size in HW_DIGCTRL_SCRATCH0 and\n
+ HW_DIGCTRL_SCRATCH1 is not the same. Please\n
+ verify these two registers contain valid RAM size!\n);
+ hang();
+ }
+
+ gd-ram_size = sz[0];
+ return 0;
+}
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/arch/arm/include/asm/arch-mx28/sys_proto.h
b/arch/arm/include/asm/arch-mx28/sys_proto.h
index be1f7db..f101494 100644
--- a/arch/arm/include/asm/arch-mx28/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx28/sys_proto.h
@@ -35,4 +35,6 @@ void mx28_common_spl_init(const iomux_cfg_t *iomux_setup,
const unsigned int iomux_size);
#endif
+int mx28_dram_init(void);
+
#endif /* __MX28_H__ */
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index 005446a..53df476 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -70,25 +70,9 @@ int board_init(void)
return 0;
}
-#defineHW_DIGCTRL_SCRATCH0 0x8001c280
-#defineHW_DIGCTRL_SCRATCH1 0x8001c290
int dram_init(void)
{
- uint32_t sz[2];
-
- sz[0] = readl(HW_DIGCTRL_SCRATCH0);
- sz[1] = readl(HW_DIGCTRL_SCRATCH1);
-
- if (sz[0] != sz[1]) {
- printf(MX28:\n
- Error, the RAM size in HW_DIGCTRL_SCRATCH0 and\n
- HW_DIGCTRL_SCRATCH1 is not the same. Please\n
- verify these two registers contain valid RAM size!\n);
- hang();
- }
-
- gd-ram_size = sz[0];
- return 0;
+ return mx28_dram_init();
}
#ifdef CONFIG_CMD_MMC
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 4/4] mx28evk: Add initial support for MX28EVK board
Add initial support for Freescale MX28EVK board. Tested boot via SD card and by loading a kernel via TFTP through the FEC interface. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut marek.va...@gmail.com --- - For correct operation of saving environment variables into the SD card, the following patch is needed: http://lists.denx.de/pipermail/u-boot/2011-November/111448.html Changes since v6: - Added Acked-by line Changes since v5: - Fix tab vs spaces on mx28evk.h - Change return value on dram_init() Changes since v4: - No changes Changes since v3: - Fix Copyright in mx28evk.h - Call mx28_dram_init from dram_init Changes since v2: - Generate the patch again due to error in applying unrelated changes Changes since v1: - Read the MAC from fuses - Use tabs instead of space in u-boot.bd - Use puts instead of print - Factor out mac reading function - Factor out ddr size calculation function - Use GENERATED_GBL_DATA_SIZE - Protect CONFIG_ENV_IS_IN_MMC MAINTAINERS |1 + board/freescale/mx28evk/Makefile | 49 ++ board/freescale/mx28evk/iomux.c | 138 + board/freescale/mx28evk/mx28evk.c | 169 +++ board/freescale/mx28evk/u-boot.bd | 14 +++ boards.cfg|1 + include/configs/mx28evk.h | 176 + 7 files changed, 548 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx28evk/Makefile create mode 100644 board/freescale/mx28evk/iomux.c create mode 100644 board/freescale/mx28evk/mx28evk.c create mode 100644 board/freescale/mx28evk/u-boot.bd create mode 100644 include/configs/mx28evk.h diff --git a/MAINTAINERS b/MAINTAINERS index a56ca10..72e1089 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -639,6 +639,7 @@ Kristoffer Ericson kristoffer.eric...@gmail.com Fabio Estevam fabio.este...@freescale.com mx25pdk i.MX25 + mx28evk i.MX28 mx31pdk i.MX31 mx53ard i.MX53 mx53smd i.MX53 diff --git a/board/freescale/mx28evk/Makefile b/board/freescale/mx28evk/Makefile new file mode 100644 index 000..7459107 --- /dev/null +++ b/board/freescale/mx28evk/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +ifndef CONFIG_SPL_BUILD +COBJS := mx28evk.o +else +COBJS := iomux.o +endif + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +all: $(ALL) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx28evk/iomux.c b/board/freescale/mx28evk/iomux.c new file mode 100644 index 000..904e3f3 --- /dev/null +++ b/board/freescale/mx28evk/iomux.c @@ -0,0 +1,138 @@ +/* + * Freescale MX28EVK IOMUX setup + * + * Copyright (C) 2011 Marek Vasut marek.va...@gmail.com + * on behalf of DENX Software Engineering GmbH + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include common.h +#include config.h +#include asm/io.h +#include asm/arch/iomux-mx28.h +#include asm/arch/imx-regs.h +#include asm/arch/sys_proto.h + +#defineMUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) +#defineMUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP) +#define
[U-Boot] [PATCH] drivers/net/e1000.c: Fix GCC 4.6 build warnings
Fix:
e1000.c: In function 'e1000_read_mac_addr':
e1000.c:1149:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
e1000.c:1149:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/net/e1000.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 6b71bd9..54f6425 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -45,6 +45,7 @@ tested on both gig copper and gig fiber boards
*/
#include e1000.h
+#include asm/unaligned.h
#define TOUT_LOOP 10
@@ -1146,7 +1147,8 @@ e1000_read_mac_addr(struct eth_device *nic)
nic-enetaddr[5] ^= 1;
#ifdef CONFIG_E1000_FALLBACK_MAC
- if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
+ if (get_unaligned_be32(nic-enetaddr) == 0 ||
+ get_unaligned_be32(nic-enetaddr) == ~0) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
memcpy (nic-enetaddr, fb_mac, NODE_ADDRESS_SIZE);
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000.c: Fix GCC 4.6 build warnings
On Dec 20, 2011, at 10:49, Anatolij Gustschin wrote:
Fix:
e1000.c: In function 'e1000_read_mac_addr':
e1000.c:1149:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
e1000.c:1149:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
[...]
#ifdef CONFIG_E1000_FALLBACK_MAC
- if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
+ if (get_unaligned_be32(nic-enetaddr) == 0 ||
+ get_unaligned_be32(nic-enetaddr) == ~0) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
memcpy (nic-enetaddr, fb_mac, NODE_ADDRESS_SIZE);
No, if you are going to fix this code then make it use the right
function for the job: is_valid_ether_addr()
Furthermore, while the E1000 chipset does not generally work very
well without a proper SPI EEPROM image (if at all), I think it
would be better for the driver to load successfully and use the
macaddr from the U-Boot environment instead of some hardcoded
compile-time constant.
IE: That whole code block should be ripped out and instead just
tweak the valid MAC address check further down.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On 12/19/2011 05:59 PM, Remy Bohmer wrote: Hi Wolfgang, 2011/12/19 Wolfgang Grandegger w...@grandegger.com: On 12/19/2011 01:51 PM, Vincent Palatin wrote: On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger w...@grandegger.com wrote: I just realized that this patch breaks usb start on my mx53loco board: The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch. This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk. I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See: http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567 I would prefer a solution in line with the specification, but what is the reason why Linux takes 100 msec here? Is that just chosen randomly , or was there a good reason for it? If there is a good reason (which I assume) I would prefer to follow Linux here and go for the 100 msec. Can you please provide a patch? OK, should find time tomorrow. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000_spi.c: Fix build warnings
On Dec 20, 2011, at 07:29, Anatolij Gustschin wrote:
Fix:
e1000_spi.c: In function 'spi_free_slave':
e1000_spi.c:115: warning: unused variable 'hw'
e1000_spi.c: In function 'do_e1000_spi':
e1000_spi.c:472: warning: 'checksum' may be used uninitialized in this
function
e1000_spi.c:472: note: 'checksum' was declared here
Acked-by: Kyle Moffett kyle.d.moff...@boeing.com
This is great, thanks!
I actually thought that the checksum fix had already made it
into Wolfgang's tree, but I can't find it now that I'm looking
for it.
The really frustrating thing is that on my test system I have
seen the unused variable warning for a while now (although I
was not sure what to do about it), but despite the fact that
the checksum variable is very clearly improperly initialized
I don't get that warning out of my compiler.
Oh, right, I'm using GCC 4.4 right now and it needs 4.6+
Ironically enough, I have never had the checksum computation
produce an incorrect result, Linux always thinks the result is
correct. It must always get a zero in that register somehow.
Cheers,
Kyle Moffett
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000_spi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000_spi.c b/drivers/net/e1000_spi.c
index 5491780..5f774f4 100644
--- a/drivers/net/e1000_spi.c
+++ b/drivers/net/e1000_spi.c
@@ -1,4 +1,5 @@
#include e1000.h
+#include linux/compiler.h
/*---
* SPI transfer
@@ -112,7 +113,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
void spi_free_slave(struct spi_slave *spi)
{
- struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ __maybe_unused struct e1000_hw *hw = e1000_hw_from_spi(spi);
E1000_DBG(hw-nic, EEPROM SPI access released\n);
}
@@ -469,7 +470,7 @@ static int do_e1000_spi_program(cmd_tbl_t *cmdtp, struct
e1000_hw *hw,
static int do_e1000_spi_checksum(cmd_tbl_t *cmdtp, struct e1000_hw *hw,
int argc, char * const argv[])
{
- uint16_t i, length, checksum, checksum_reg;
+ uint16_t i, length, checksum = 0, checksum_reg;
uint16_t *buffer;
boolean_t upd;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 2/4] mx28: Let imx_get_mac_from_fuse be common for mx28
Let imx_get_mac_from_fuse function be a common function, so that other
mx28 boards can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v6:
- Let mac[5] be set inside mx28_adjust_mac
Changes since v5:
- Allow the MAC vendor to be overriden
Changes since v4:
- No changes
Change since v3:
- Add a note about the first two MAC addresses being from Freescale vendor.
arch/arm/cpu/arm926ejs/mx28/mx28.c | 46
board/denx/m28evk/m28evk.c |
35 --- 2 files changed, 46 insertions(+), 35
deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c index 088c019..ee4e337 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -214,6 +214,52 @@ int cpu_eth_init(bd_t *bis)
}
#endif
+static void __mx28_adjust_mac(int dev_id, char *mac)
unsigned char * ... see the header file in your previous patch ;-)
+{
+ mac[0] = 0x00;
+ mac[1] = 0x04; /* Use FSL vendor MAC address by default */
+
+ if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
+ mac[5] += 1;
+}
+
+void mx28_adjust_mac(int dev_id, char *mac)
+ __attribute__((weak, alias(__mx28_adjust_mac)));
+
+#ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
+
+#define MXS_OCOTP_MAX_TIMEOUT 100
+void imx_get_mac_from_fuse(int dev_id, char *mac)
DTTO
+{
+ struct mx28_ocotp_regs *ocotp_regs =
+ (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+ uint32_t data;
+
+ memset(mac, 0, 6);
+
+ writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
+
+ if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+ MXS_OCOTP_MAX_TIMEOUT)) {
+ printf(MXS FEC: Can't get MAC from OCOTP\n);
+ return;
+ }
+
+ data = readl(ocotp_regs-hw_ocotp_cust0);
+
+ mac[2] = (data 24) 0xff;
+ mac[3] = (data 16) 0xff;
+ mac[4] = (data 8) 0xff;
+ mac[5] = data 0xff;
+ mx28_adjust_mac(dev_id, mac);
+}
+#else
+void imx_get_mac_from_fuse(int dev_id, char *mac)
DTTO
+{
+ memset(mac, 0, 6);
+}
+#endif
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index a0fabc0..005446a 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
return ret;
}
-#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
-
-#define MXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- struct mx28_ocotp_regs *ocotp_regs =
- (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
- uint32_t data;
-
- memset(mac, 0, 6);
-
- writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
-
- if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
- MXS_OCOTP_MAX_TIMEOUT)) {
- printf(MXS FEC: Can't get MAC from OCOTP\n);
- return;
- }
-
- data = readl(ocotp_regs-hw_ocotp_cust0);
-
- mac[0] = 0x00;
- mac[1] = 0x04;
- mac[2] = (data 24) 0xff;
- mac[3] = (data 16) 0xff;
- mac[4] = (data 8) 0xff;
- mac[5] = data 0xff;
-}
-#else
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- memset(mac, 0, 6);
-}
-#endif
-
#endif
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sdhc_boot: Introduce CONFIG_FSL_FIXED_MMC_LOCATION option
Since commit 97039ab98 (env_mmc: Allow board code to override the environment
address)
mmc_get_env_addr is a weak-aliased function in common/env_mmc.c
The mmc_get_env_addr implementation that exists at
board/freescale/common/sdhc_boot.c is meant to be used only for PowerPC boards,
but currently it is being used for all platforms that have CONFIG_ENV_IS_IN_MMC
defined.
Introduce CONFIG_FSL_FIXED_MMC_LOCATION so that the boards that need to use
the mmc_get_env_addr version from board/freescale/common/sdhc_boot.c could
activate
this config option on their board file.
This fixes the retrieval of CONFIG_ENV_OFFSET on non-PowerPC boards.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/common/Makefile|2 +-
board/freescale/common/sdhc_boot.c |2 ++
include/configs/MPC8536DS.h|1 +
include/configs/P1010RDB.h |1 +
include/configs/P1_P2_RDB.h|1 +
include/configs/P2020COME.h|1 +
include/configs/P2020DS.h |1 +
include/configs/P2041RDB.h |1 +
include/configs/corenet_ds.h |1 +
include/configs/p1_p2_rdb_pc.h |1 +
10 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 9077aaf..5f8f7c6 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -39,7 +39,7 @@ COBJS-$(CONFIG_PQ_MDS_PIB)+= pq-mds-pib.o
COBJS-$(CONFIG_ID_EEPROM) += sys_eeprom.o
COBJS-$(CONFIG_FSL_SGMII_RISER)+= sgmii_riser.o
ifndef CONFIG_RAMBOOT_PBL
-COBJS-$(CONFIG_ENV_IS_IN_MMC) += sdhc_boot.o
+COBJS-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o
endif
COBJS-$(CONFIG_MPC8541CDS) += cds_pci_ft.o
diff --git a/board/freescale/common/sdhc_boot.c
b/board/freescale/common/sdhc_boot.c
index e432318..68c335b 100644
--- a/board/freescale/common/sdhc_boot.c
+++ b/board/freescale/common/sdhc_boot.c
@@ -32,6 +32,7 @@
#define ESDHC_BOOT_IMAGE_SIZE 0x48
#define ESDHC_BOOT_IMAGE_ADDR 0x50
+#ifdef CONFIG_FSL_FIXED_MMC_LOCATION
int mmc_get_env_addr(struct mmc *mmc, u32 *env_addr)
{
u8 *tmp_buf;
@@ -61,3 +62,4 @@ int mmc_get_env_addr(struct mmc *mmc, u32 *env_addr)
return 0;
}
+#endif
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 16db98f..4b5373c 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -659,6 +659,7 @@
#define CONFIG_ENV_SECT_SIZE 0x1
#elif defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE0x2000
#define CONFIG_SYS_MMC_ENV_DEV 0
#else
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index af4609f..0a22a5c 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -609,6 +609,7 @@ extern unsigned long get_sdram_size(void);
#if defined(CONFIG_SYS_RAMBOOT)
#if defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_SYS_MMC_ENV_DEV 0
#define CONFIG_ENV_SIZE0x2000
#elif defined(CONFIG_RAMBOOT_SPIFLASH)
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 00fa74d..29f016b 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -519,6 +519,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_ENV_OFFSET ((512 * 1024) +
CONFIG_SYS_NAND_BLOCK_SIZE)
#elif defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE0x2000
#define CONFIG_SYS_MMC_ENV_DEV 0
#elif defined(CONFIG_RAMBOOT_SPIFLASH)
diff --git a/include/configs/P2020COME.h b/include/configs/P2020COME.h
index cf20d2b..f3d1db0 100644
--- a/include/configs/P2020COME.h
+++ b/include/configs/P2020COME.h
@@ -350,6 +350,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
*/
#if defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC1
+ #define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_SYS_MMC_ENV_DEV 0
#elif defined(CONFIG_RAMBOOT_SPIFLASH)
diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h
index 2d9657a..2d9b916 100644
--- a/include/configs/P2020DS.h
+++ b/include/configs/P2020DS.h
@@ -596,6 +596,7 @@
*/
#if defined(CONFIG_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE0x2000
#define CONFIG_SYS_MMC_ENV_DEV 0
#elif defined(CONFIG_SPIFLASH)
diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index a48055e..3c04e89 100644
--- a/include/configs/P2041RDB.h
+++ b/include/configs/P2041RDB.h
@@ -92,6 +92,7 @@
#elif defined(CONFIG_SDCARD)
#define CONFIG_SYS_EXTRA_ENV_RELOC
#define CONFIG_ENV_IS_IN_MMC
+
Re: [U-Boot] [PATCH] drivers/net/e1000_spi.c: Fix build warnings
On Tue, 20 Dec 2011 10:19:51 -0600 Moffett, Kyle D kyle.d.moff...@boeing.com wrote: On Dec 20, 2011, at 07:29, Anatolij Gustschin wrote: Fix: e1000_spi.c: In function 'spi_free_slave': e1000_spi.c:115: warning: unused variable 'hw' e1000_spi.c: In function 'do_e1000_spi': e1000_spi.c:472: warning: 'checksum' may be used uninitialized in this function e1000_spi.c:472: note: 'checksum' was declared here Acked-by: Kyle Moffett kyle.d.moff...@boeing.com This is great, thanks! I actually thought that the checksum fix had already made it into Wolfgang's tree, but I can't find it now that I'm looking for it. There is a checksum fix in Wolfgang's tree, commit 7a341066 (e1000: fix bugs from recent commits). It is for drivers/net/e1000.c file, however. The really frustrating thing is that on my test system I have seen the unused variable warning for a while now (although I was not sure what to do about it), but despite the fact that the checksum variable is very clearly improperly initialized I don't get that warning out of my compiler. Oh, right, I'm using GCC 4.4 right now and it needs 4.6+ I've seen this warning with GCC 4.2.2 and GCC 4.6.1. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
On Tuesday 20 December 2011 06:09 PM, Andreas Müller wrote: On Tuesday, December 20, 2011 01:06:07 PM you wrote: Dear Andreas, In message201112201253.46991.schnitzelt...@gmx.de you wrote: I agree to your concerns but - as I understood Steve Sakoman - here the situation is slightly different: I think you misunderstand. Yes I think too :-) At elder overo boards TWL4030 RTC irq is connected to gpio112. Unfortunately this pin is also used for binary revision detection. Therefore we need to send 'shut-up' to TWL4030 via i2c to avoid reading wrong revision. In SPL this must be done *before* SDRAM (timing) is set up, because the type of SDRAM is revision dependent. My suggestion was to check if memory initialization can not rather be done _without_ reading (and without otherwise knowing) the board type or revision. Usually this is possible, and I always prefer such auto-adjusting solutions over hard-wired approaches that break down when any of the expected inout data is not correct or not available. Dear Wolfgang, I don't know if I want to jump also into these changes now - especially since I am quite new here.. But for my intererst - since it seems more error tolerant: How is SDRAM timing set up without exactly knowing what type is connected? Is there a good example implementation in u-boot(-spl)? Here is an example for automatic configuration with LPDDR2 memories in OMAP4. http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap-common/emif-common.c;h=62678ff5d30739ce6dc0a4fdb5ea398acc3d31ea;hb=HEAD Look at the function emif_get_device_details(). The automatic settings make use of timing values from JEDEC spec that is guaranteed to be safe for all devices, but not necessarily optimal(but for all LPDDR2 devices I have seen so far their timings are not different from the JEDEC defaults). In addition, we need to know density etc. which can be read from the LPDDR2 device itself. Something similar may be possible for LPDDR (I presume you are using LPDDR), but will be somewhat complex, to say the least. Please note that we have compiled out the above code from OMAP4 SPL due to space constraints! If something like 'int foo __attribute__ ((section(.data))) = 0;' is solving your problem that may be the easier solution at the moment. br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 2/4] mx28: Let imx_get_mac_from_fuse be common for mx28
Let imx_get_mac_from_fuse function be a common function, so that other
mx28 boards can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v7:
- Use unsigned char instead of char
Changes since v6:
- Let mac[5] be set inside mx28_adjust_mac
Changes since v5:
- Allow the MAC vendor to be overriden
Changes since v4:
- No changes
Change since v3:
- Add a note about the first two MAC addresses being from Freescale vendor.
arch/arm/cpu/arm926ejs/mx28/mx28.c | 46
board/denx/m28evk/m28evk.c | 35 ---
2 files changed, 46 insertions(+), 35 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index 088c019..ee4e337 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -214,6 +214,52 @@ int cpu_eth_init(bd_t *bis)
}
#endif
+static void __mx28_adjust_mac(int dev_id, unsigned char *mac)
+{
+ mac[0] = 0x00;
+ mac[1] = 0x04; /* Use FSL vendor MAC address by default */
+
+ if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
+ mac[5] += 1;
+}
+
+void mx28_adjust_mac(int dev_id, unsigned char *mac)
+ __attribute__((weak, alias(__mx28_adjust_mac)));
+
+#ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
+
+#defineMXS_OCOTP_MAX_TIMEOUT 100
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+{
+ struct mx28_ocotp_regs *ocotp_regs =
+ (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+ uint32_t data;
+
+ memset(mac, 0, 6);
+
+ writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
+
+ if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+ MXS_OCOTP_MAX_TIMEOUT)) {
+ printf(MXS FEC: Can't get MAC from OCOTP\n);
+ return;
+ }
+
+ data = readl(ocotp_regs-hw_ocotp_cust0);
+
+ mac[2] = (data 24) 0xff;
+ mac[3] = (data 16) 0xff;
+ mac[4] = (data 8) 0xff;
+ mac[5] = data 0xff;
+ mx28_adjust_mac(dev_id, mac);
+}
+#else
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+{
+ memset(mac, 0, 6);
+}
+#endif
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index a0fabc0..005446a 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
return ret;
}
-#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
-
-#defineMXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- struct mx28_ocotp_regs *ocotp_regs =
- (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
- uint32_t data;
-
- memset(mac, 0, 6);
-
- writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
-
- if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
- MXS_OCOTP_MAX_TIMEOUT)) {
- printf(MXS FEC: Can't get MAC from OCOTP\n);
- return;
- }
-
- data = readl(ocotp_regs-hw_ocotp_cust0);
-
- mac[0] = 0x00;
- mac[1] = 0x04;
- mac[2] = (data 24) 0xff;
- mac[3] = (data 16) 0xff;
- mac[4] = (data 8) 0xff;
- mac[5] = data 0xff;
-}
-#else
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- memset(mac, 0, 6);
-}
-#endif
-
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/4] mx28: Let imx_get_mac_from_fuse be common for mx28
Let imx_get_mac_from_fuse function be a common function, so that other
mx28 boards can reuse it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v7:
- Use unsigned char instead of char
Changes since v6:
- Let mac[5] be set inside mx28_adjust_mac
Changes since v5:
- Allow the MAC vendor to be overriden
Changes since v4:
- No changes
Change since v3:
- Add a note about the first two MAC addresses being from Freescale vendor.
arch/arm/cpu/arm926ejs/mx28/mx28.c | 46
board/denx/m28evk/m28evk.c |
35 --- 2 files changed, 46 insertions(+), 35
deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c index 088c019..ee4e337 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -214,6 +214,52 @@ int cpu_eth_init(bd_t *bis)
}
#endif
+static void __mx28_adjust_mac(int dev_id, unsigned char *mac)
+{
+ mac[0] = 0x00;
+ mac[1] = 0x04; /* Use FSL vendor MAC address by default */
+
+ if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
+ mac[5] += 1;
+}
+
+void mx28_adjust_mac(int dev_id, unsigned char *mac)
+ __attribute__((weak, alias(__mx28_adjust_mac)));
+
+#ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
+
+#define MXS_OCOTP_MAX_TIMEOUT 100
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+{
+ struct mx28_ocotp_regs *ocotp_regs =
+ (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+ uint32_t data;
+
+ memset(mac, 0, 6);
+
+ writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
+
+ if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+ MXS_OCOTP_MAX_TIMEOUT)) {
+ printf(MXS FEC: Can't get MAC from OCOTP\n);
+ return;
+ }
+
+ data = readl(ocotp_regs-hw_ocotp_cust0);
+
+ mac[2] = (data 24) 0xff;
+ mac[3] = (data 16) 0xff;
+ mac[4] = (data 8) 0xff;
+ mac[5] = data 0xff;
+ mx28_adjust_mac(dev_id, mac);
+}
+#else
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+{
+ memset(mac, 0, 6);
+}
+#endif
+
U_BOOT_CMD(
clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
display clocks,
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index a0fabc0..005446a 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
return ret;
}
-#ifdef CONFIG_M28_FEC_MAC_IN_OCOTP
-
-#define MXS_OCOTP_MAX_TIMEOUT 100
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- struct mx28_ocotp_regs *ocotp_regs =
- (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
- uint32_t data;
-
- memset(mac, 0, 6);
-
- writel(OCOTP_CTRL_RD_BANK_OPEN, ocotp_regs-hw_ocotp_ctrl_set);
-
- if (mx28_wait_mask_clr(ocotp_regs-hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
- MXS_OCOTP_MAX_TIMEOUT)) {
- printf(MXS FEC: Can't get MAC from OCOTP\n);
- return;
- }
-
- data = readl(ocotp_regs-hw_ocotp_cust0);
-
- mac[0] = 0x00;
- mac[1] = 0x04;
- mac[2] = (data 24) 0xff;
- mac[3] = (data 16) 0xff;
- mac[4] = (data 8) 0xff;
- mac[5] = data 0xff;
-}
-#else
-void imx_get_mac_from_fuse(int dev_id, char *mac)
-{
- memset(mac, 0, 6);
-}
-#endif
-
#endif
Acked-by: Marek Vasut marek.va...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000_spi.c: Fix build warnings
On Tuesday 20 December 2011 07:29:03 Anatolij Gustschin wrote: - struct e1000_hw *hw = e1000_hw_from_spi(spi); + __maybe_unused struct e1000_hw *hw = e1000_hw_from_spi(spi); E1000_DBG(hw-nic, EEPROM SPI access released\n); fix the E1000_DBG() macro to use debug() instead -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000.c: Fix GCC 4.6 build warnings
On Tuesday 20 December 2011 11:07:30 Moffett, Kyle D wrote:
On Dec 20, 2011, at 10:49, Anatolij Gustschin wrote:
#ifdef CONFIG_E1000_FALLBACK_MAC
- if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
+ if (get_unaligned_be32(nic-enetaddr) == 0 ||
+ get_unaligned_be32(nic-enetaddr) == ~0) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
memcpy (nic-enetaddr, fb_mac, NODE_ADDRESS_SIZE);
No, if you are going to fix this code then make it use the right
function for the job: is_valid_ether_addr()
+1
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra: Fix Harmony and Ventana builds
Sorry, folks. Please ignore u-boot-tegra/next for now. It's in transition. u-boot-tegra/master has some new patches (getting ready for a pull request) that changed the Seaboard Makefile but not the Harmony or Ventana ones. The fix-it patch I submitted should've had a line that said it applies against u-boot-tegra/master (which really should be 'next', I guess). The BUG= and TEST= lines are required for ChromeOS U-Boot submissions - I just got into the habit of always applying them to commit messages. I'll remove 'em, add some more info about where exactly this patch applies, and resubmit. Thanks for catching all this, Tom -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Monday, December 19, 2011 11:56 PM To: Stephen Warren Cc: Tom Warren; u-boot@lists.denx.de; s...@chromium.org; w...@denx.de; Tom Warren Subject: Re: [PATCH] arm: Tegra: Fix Harmony and Ventana builds Hi all, Le 20/12/2011 01:06, Stephen Warren a écrit : Tom Warren wrote at Monday, December 19, 2011 4:09 PM: Signed-off-by: Tom Warrentwar...@nvidia.com BUG=none TEST=built all 3 (Harmony, Seaboard and Ventana) and tested Seaboard Tom, I'm a little confused by this. The patch removes ../common/board.o from COBJS for Harmony and Ventana, but not from Seaboard, and at least in u-boot-tegra/ next, Seaboard still references that file. Also, applying this patch causes Harmony and Ventana to fail to build (link) due to undefined symbols typically provided by common/board.o. What branch is the patch targeted at, and what build problems is it solving? Plus, I would suggest making the commit message less cryptic; I can make no heads or tails of these BUG= and TEST= lines. Amicalement, -- Albert. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000.c: Fix GCC 4.6 build warnings
On Tue, 20 Dec 2011 10:07:30 -0600
Moffett, Kyle D kyle.d.moff...@boeing.com wrote:
On Dec 20, 2011, at 10:49, Anatolij Gustschin wrote:
Fix:
e1000.c: In function 'e1000_read_mac_addr':
e1000.c:1149:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
e1000.c:1149:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
[...]
#ifdef CONFIG_E1000_FALLBACK_MAC
- if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
+ if (get_unaligned_be32(nic-enetaddr) == 0 ||
+ get_unaligned_be32(nic-enetaddr) == ~0) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
memcpy (nic-enetaddr, fb_mac, NODE_ADDRESS_SIZE);
No, if you are going to fix this code then make it use the right
function for the job: is_valid_ether_addr()
You are right, I'll fix it using is_valid_ether_addr().
Furthermore, while the E1000 chipset does not generally work very
well without a proper SPI EEPROM image (if at all), I think it
would be better for the driver to load successfully and use the
macaddr from the U-Boot environment instead of some hardcoded
compile-time constant.
IE: That whole code block should be ripped out and instead just
tweak the valid MAC address check further down.
The config option is documented in README:
CONFIG_E1000_FALLBACK_MAC
default MAC for empty EEPROM after production.
I assume this block is only for a possibility to use the driver
until the eeprom is programmed with a valid mac address.
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] mmc: Implement central card-detection.
On Tuesday 20 December 2011 03:52:39 Thierry Reding wrote:
This series of patches implements central card-detection within the MMC
framework. Before this patch series, many boards actually did implement
the board_mmc_getcd() function, but it wasn't used except by one driver
(fsl_esdhc). Unfortunately, implementations interpreted the meaning of
the cd parameter differently, some taking it to signal card absence and
others using it to detect card presence. Furthermore, the signature of
the board_mmc_getcd() function was not at all consistent with other MMC
related functions.
as you've seen, GPIO pin detection is not novel or unique to any driver/SoC.
i'd suggest instead finding a way to move this into struct mmc. perhaps
something like:
include/mmc.h:
struct mmc {
...
#ifdef CONFIG_MMC_GPIO_CD
unsigned gpio_cd;
#endif
...
};
and then the default mmc_register() func can do:
#ifdef CONFIG_MMC_GPIO_CD
if (!mmc-getcd)
mmc-getcd = mmc_getcd_gpio;
#endif
and we can have the drivers/mmc/mmc.c:
#ifdef CONFIG_MMC_GPIO_CD
int mmc_getcd_gpio(struct mmc *mmc)
{
return !gpio_get_value(mmc-getcd);
}
#endif
then mmc drivers can extend their register function to take a GPIO number (if
they don't already). and then they get everything else for free.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] drivers/net/e1000.c: Fix GCC 4.6 build warnings
Fix:
e1000.c: In function 'e1000_read_mac_addr':
e1000.c:1149:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
e1000.c:1149:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kyle Moffett kyle.d.moff...@boeing.com
---
v2:
- use is_valid_ether_addr() for the check as suggested
by Kyle Moffett
drivers/net/e1000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 6b71bd9..e726f39 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1146,7 +1146,7 @@ e1000_read_mac_addr(struct eth_device *nic)
nic-enetaddr[5] ^= 1;
#ifdef CONFIG_E1000_FALLBACK_MAC
- if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
+ if (!is_valid_ether_addr(nic-enetaddr)) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
memcpy (nic-enetaddr, fb_mac, NODE_ADDRESS_SIZE);
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Enable access to FAT filesystem in an ISO9660 El-Torito volume
The included series of 3 patches fixes several bugs in the FAT code and the USB storage stack to make it possible to read from a FAT filesystem image embedded as an El-Torito boot image in an ISO9660 volume (IE: a CD or DVD). This has been tested on the eXMeritus HWW-1U-1A. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] fs/fat: Fix FAT detection to support non-DOS partition tables
The FAT filesystem code currently ends up requiring that the partition
table be a DOS MBR, as it checks for the DOS 0x55 0xAA signature on the
partition table (which may be Mac, EFI, ISO9660, etc) before actually
computing the partition offset.
This fixes support for accessing a FAT filesystem in an ISO9660 boot
volume (El-Torito format) by reordering the filesystem checks and
reading the 0x55 0xAA DOS boot signature and FAT/FAT32 magic number
from the first sector of the partition instead of from sector 0.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
fs/fat/fat.c | 123 -
1 files changed, 60 insertions(+), 63 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 9a29458..13bab8f 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -44,49 +44,36 @@ static void downcase (char *str)
}
static block_dev_desc_t *cur_dev = NULL;
-
-static unsigned long part_offset = 0;
-
-static int cur_part = 1;
-
-#define DOS_PART_TBL_OFFSET0x1be
-#define DOS_PART_MAGIC_OFFSET 0x1fe
+static unsigned int cur_part_nr = 1;
+static disk_partition_t cur_part_info = {
+ .start = 0,
+ .size = 0,
+ .blksz = 512,
+ .name = ,
+ .type = ,
+};
+
+#define DOS_BOOT_MAGIC_OFFSET 0x1fe
#define DOS_FS_TYPE_OFFSET 0x36
#define DOS_FS32_TYPE_OFFSET 0x52
-static int disk_read (__u32 startblock, __u32 getsize, __u8 * bufptr)
+static int disk_read(__u32 block, __u32 nr_blocks, void *buf)
{
- if (cur_dev == NULL)
+ if (!cur_dev || !cur_dev-block_read)
return -1;
- startblock += part_offset;
-
- if (cur_dev-block_read) {
- return cur_dev-block_read(cur_dev-dev, startblock, getsize,
- (unsigned long *) bufptr);
- }
- return -1;
+ return cur_dev-block_read(cur_dev-dev,
+ cur_part_info.start + block, nr_blocks, buf);
}
int fat_register_device (block_dev_desc_t * dev_desc, int part_no)
{
unsigned char buffer[dev_desc-blksz];
+ unsigned int found_partition = 0;
- if (!dev_desc-block_read)
- return -1;
+ /* First close any currently found FAT filesystem */
+ cur_dev = NULL;
- cur_dev = dev_desc;
- /* check if we have a MBR (on floppies we have only a PBR) */
- if (dev_desc-block_read(dev_desc-dev, 0, 1, (ulong *)buffer) != 1) {
- printf(** Can't read from device %d **\n,
- dev_desc-dev);
- return -1;
- }
- if (buffer[DOS_PART_MAGIC_OFFSET] != 0x55 ||
- buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) {
- /* no signature found */
- return -1;
- }
#if (defined(CONFIG_CMD_IDE) || \
defined(CONFIG_CMD_MG_DISK) || \
defined(CONFIG_CMD_SATA) || \
@@ -94,45 +81,55 @@ int fat_register_device (block_dev_desc_t * dev_desc, int
part_no)
defined(CONFIG_CMD_USB) || \
defined(CONFIG_MMC) || \
defined(CONFIG_SYSTEMACE) )
- {
- disk_partition_t info;
-
- /* First we assume there is a MBR */
- if (!get_partition_info(dev_desc, part_no, info)) {
- part_offset = info.start;
- cur_part = part_no;
- } else if ((strncmp((char *)buffer[DOS_FS_TYPE_OFFSET],
- FAT, 3) == 0) ||
- (strncmp((char *)buffer[DOS_FS32_TYPE_OFFSET],
- FAT32, 5) == 0)) {
- /* ok, we assume we are on a PBR only */
- cur_part = 1;
- part_offset = 0;
- } else {
+
+ /* Read the partition table, if present */
+ if (!get_partition_info(dev_desc, part_no, cur_part_info)) {
+ cur_dev = dev_desc;
+ cur_part_nr = part_no;
+ }
+#endif
+
+ /* Otherwise it might be a superfloppy (whole-disk FAT filesystem) */
+ if (!cur_dev) {
+ if (part_no != 1) {
printf(** Partition %d not valid on device %d **\n,
- part_no, dev_desc-dev);
+ part_no, dev_desc-dev);
return -1;
}
+
+ found_partition = 1;
+ cur_dev = dev_desc;
+ cur_part_nr = 1;
+ cur_part_info.start = 0;
+ cur_part_info.size = dev_desc-lba;
+ cur_part_info.blksz = dev_desc-blksz;
+ memset(cur_part_info.name, 0, sizeof(cur_part_info.name));
+ memset(cur_part_info.type, 0, sizeof(cur_part_info.type));
}
-#else
- if ((strncmp((char *)buffer[DOS_FS_TYPE_OFFSET], FAT, 3) == 0) ||
- (strncmp((char *)buffer[DOS_FS32_TYPE_OFFSET], FAT32, 5) == 0)) {
- /* ok, we assume we are on a PBR only */
-
[U-Boot] [PATCH 2/3] fs/fat: Improve error handling
The FAT filesystem fails silently in inexplicable ways when given a
filesystem with a block-size that does not match the device sector size.
In theory this is not an unsupportable combination but requires a major
rewrite of a lot of the filesystem. Until that occurs, the filesystem
should detect that scenario and display a helpful error message.
This scenario in particular occurred on a 512-byte blocksize FAT fs
stored in an El-Torito boot volume on a CD-ROM (2048-byte sector size).
Additionally, in many circumstances the -block_read method will not
return a negative number to indicate an error but instead return 0 to
indicate the number of blocks successfully read (IE: None).
The FAT filesystem should defensively check to ensure that it got all of
the sectors that it asked for when reading.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
fs/fat/fat.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 13bab8f..2136cd7 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -282,6 +282,8 @@ get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
{
__u32 idx = 0;
__u32 startsect;
+ __u32 nr_sect;
+ int ret;
if (clustnum 0) {
startsect = mydata-data_begin +
@@ -292,16 +294,19 @@ get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
debug(gc - clustnum: %d, startsect: %d\n, clustnum, startsect);
- if (disk_read(startsect, size / mydata-sect_size, buffer) 0) {
- debug(Error reading data\n);
+ nr_sect = size / mydata-sect_size;
+ ret = disk_read(startsect, nr_sect, buffer);
+ if (ret != nr_sect) {
+ debug(Error reading data (got %d)\n, ret);
return -1;
}
if (size % mydata-sect_size) {
__u8 tmpbuf[mydata-sect_size];
idx = size / mydata-sect_size;
- if (disk_read(startsect + idx, 1, tmpbuf) 0) {
- debug(Error reading data\n);
+ ret = disk_read(startsect + idx, 1, tmpbuf);
+ if (ret != 1) {
+ debug(Error reading data (got %d)\n, ret);
return -1;
}
buffer += idx * mydata-sect_size;
@@ -810,6 +815,11 @@ do_fat_read (const char *filename, void *buffer, unsigned
long maxsize,
mydata-sect_size = (bs.sector_size[1] 8) + bs.sector_size[0];
mydata-clust_size = bs.cluster_size;
+ if (mydata-sect_size != cur_part_info.blksz) {
+ printf(Error: FAT sector size mismatch (fs=%hu, dev=%lu)\n,
+ mydata-sect_size, cur_part_info.blksz);
+ return -1;
+ }
if (mydata-fatsize == 32) {
mydata-data_begin = mydata-rootdir_sect -
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] usb_storage: Fix EHCI out of buffer pointers with CD-ROM
When performing large bulk reads from a CD or DVD using the U-Boot
usb_storage driver, it generates requests of up to 20 blocks at a time.
With a standard 512-byte block size, that is 10240 bytes and within the
limit of U-Boot's EHCI driver (maximum 5 pages at 4k per page).
Unfortunately CD-ROM media has a 2048-byte blocksize, resulting in a
maximum transfer size of 40960 bytes, which does not fit.
Since the EHCI specification is impossibly obtuse and far beyond my
comprehension, I chose to dynamically compute the limit based on the
blocksize.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
common/usb_storage.c | 45 +
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index d9a2585..2720b8d 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -151,6 +151,7 @@ struct us_data {
unsigned intirqpipe;/* pipe for release_irq */
unsigned char irqmaxp;/* max packed for irq Pipe */
unsigned char irqinterval;/* Intervall for IRQ Pipe */
+ unsigned long max_xfer_blk; /* Max blocks per xfer */
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine */
trans_cmnd transport; /* transport routine */
@@ -1041,14 +1042,13 @@ static void usb_bin_fixup(struct usb_device_descriptor
descriptor,
}
#endif /* CONFIG_USB_BIN_FIXUP */
-#define USB_MAX_READ_BLK 20
-
unsigned long usb_stor_read(int device, unsigned long blknr,
unsigned long blkcnt, void *buffer)
{
unsigned long start, blks, buf_addr;
unsigned short smallblks;
struct usb_device *dev;
+ struct us_data *ss;
int retry, i;
ccb *srb = usb_ccb;
@@ -1066,13 +1066,14 @@ unsigned long usb_stor_read(int device, unsigned long
blknr,
if (dev-devnum == usb_dev_desc[device].target)
break;
}
+ ss = (struct us_data *)dev-privptr;
usb_disable_asynch(1); /* asynch transfer not allowed */
srb-lun = usb_dev_desc[device].lun;
buf_addr = (unsigned long)buffer;
start = blknr;
blks = blkcnt;
- if (usb_test_unit_ready(srb, (struct us_data *)dev-privptr)) {
+ if (usb_test_unit_ready(srb, ss)) {
printf(Device NOT ready\n Request Sense returned %02X %02X
%02X\n, srb-sense_buf[2], srb-sense_buf[12],
srb-sense_buf[13]);
@@ -1086,19 +1087,18 @@ unsigned long usb_stor_read(int device, unsigned long
blknr,
/* XXX need some comment here */
retry = 2;
srb-pdata = (unsigned char *)buf_addr;
- if (blks USB_MAX_READ_BLK)
- smallblks = USB_MAX_READ_BLK;
+ if (blks ss-max_xfer_blk)
+ smallblks = ss-max_xfer_blk;
else
smallblks = (unsigned short) blks;
retry_it:
- if (smallblks == USB_MAX_READ_BLK)
+ if (smallblks == ss-max_xfer_blk)
usb_show_progress();
srb-datalen = usb_dev_desc[device].blksz * smallblks;
srb-pdata = (unsigned char *)buf_addr;
- if (usb_read_10(srb, (struct us_data *)dev-privptr, start,
- smallblks)) {
+ if (usb_read_10(srb, ss, start, smallblks)) {
USB_STOR_PRINTF(Read ERROR\n);
- usb_request_sense(srb, (struct us_data *)dev-privptr);
+ usb_request_sense(srb, ss);
if (retry--)
goto retry_it;
blkcnt -= blks;
@@ -1113,19 +1113,18 @@ retry_it:
start, smallblks, buf_addr);
usb_disable_asynch(0); /* asynch transfer allowed */
- if (blkcnt = USB_MAX_READ_BLK)
+ if (blkcnt = ss-max_xfer_blk)
debug(\n);
return blkcnt;
}
-#define USB_MAX_WRITE_BLK 20
-
unsigned long usb_stor_write(int device, unsigned long blknr,
unsigned long blkcnt, const void *buffer)
{
unsigned long start, blks, buf_addr;
unsigned short smallblks;
struct usb_device *dev;
+ struct us_data *ss;
int retry, i;
ccb *srb = usb_ccb;
@@ -1143,6 +1142,7 @@ unsigned long usb_stor_write(int device, unsigned long
blknr,
if (dev-devnum == usb_dev_desc[device].target)
break;
}
+ ss = (struct us_data *)dev-privptr;
usb_disable_asynch(1); /* asynch transfer not allowed */
@@ -1150,7 +1150,7 @@ unsigned long usb_stor_write(int device, unsigned long
blknr,
buf_addr = (unsigned long)buffer;
start = blknr;
Re: [U-Boot] [PATCH v2] drivers/net/e1000.c: Fix GCC 4.6 build warnings
On Dec 20, 2011, at 12:36, Anatolij Gustschin wrote: Fix: e1000.c: In function 'e1000_read_mac_addr': e1000.c:1149:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] e1000.c:1149:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Kyle Moffett kyle.d.moff...@boeing.com Looks great, thanks! Acked-by: Kyle Moffett kyle.d.moff...@boeing.com Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/eltec/elppc/misc.c: Fix GCC 4.6 build warning
Fix: misc.c: In function 'misc_init_r': misc.c:119:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] Signed-off-by: Anatolij Gustschin ag...@denx.de --- board/eltec/elppc/misc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/eltec/elppc/misc.c b/board/eltec/elppc/misc.c index d476cd5..89f1b1d 100644 --- a/board/eltec/elppc/misc.c +++ b/board/eltec/elppc/misc.c @@ -116,7 +116,7 @@ int misc_init_r (void) eerev.etheraddr[5] = 0x4D; /* cache config word for ELPPC */ - *(int *) eerev.res[0] = 0; + memset(eerev.res[0], 0, 4); initSrom = 1; /* force dialog */ copyNv = 1; /* copy to nvram */ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] usb_storage: Fix EHCI out of buffer pointers with CD-ROM
On Tuesday 20 December 2011 12:41:14 Kyle Moffett wrote: + /* + * The U-Boot EHCI driver cannot handle more than 4096*5 bytes in a + * transfer without running itself out of qt_buffers. + */ + ss-max_xfer_blk = (4096*5)/dev_desc-blksz; spaces around those operators -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fs/fat: Fix FAT detection to support non-DOS partition tables
On Tuesday 20 December 2011 12:41:12 Kyle Moffett wrote:
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
+static disk_partition_t cur_part_info = {
+ .start = 0,
+ .size = 0,
+ .blksz = 512,
+ .name = ,
+ .type = ,
+};
there any way we could delay that initialization of blksz to runtime ? if
that wasn't there, cur_part_info would be in .bss instead of .data.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/eltec/elppc/misc.c: Fix GCC 4.6 build warning
On Tuesday 20 December 2011 12:51:09 Anatolij Gustschin wrote: - *(int *) eerev.res[0] = 0; + memset(eerev.res[0], 0, 4); foo[0] is the same thing as foo -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] cmd_fat: add FAT write command
On Monday 19 December 2011 22:48:06 Donggeun Kim wrote:
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
+ if (argc 5) {
+ printf(usage: fatwrite interface dev[:part]
+ addr filename bytes\n);
+ return 1;
return cmd_usage(cmdtp);
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fs/fat: Fix FAT detection to support non-DOS partition tables
On Dec 20, 2011, at 13:20, Mike Frysinger wrote:
On Tuesday 20 December 2011 12:41:12 Kyle Moffett wrote:
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
+static disk_partition_t cur_part_info = {
+.start = 0,
+.size = 0,
+.blksz = 512,
+.name = ,
+.type = ,
+};
there any way we could delay that initialization of blksz to runtime ? if
that wasn't there, cur_part_info would be in .bss instead of .data.
I redid this patch several times before I figured out what was going
on and I ended up with both paths fully initializing this struct, so
there's really no need for an initializer at all.
I'll remove it for the next round.
Thanks for the review!
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] usb_storage: Fix EHCI out of buffer pointers with CD-ROM
On Dec 20, 2011, at 13:20, Mike Frysinger wrote: On Tuesday 20 December 2011 12:41:14 Kyle Moffett wrote: +/* + * The U-Boot EHCI driver cannot handle more than 4096*5 bytes in a + * transfer without running itself out of qt_buffers. + */ +ss-max_xfer_blk = (4096*5)/dev_desc-blksz; spaces around those operators Fixed, thanks for the catch! Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] mmc: fsl_esdhc: Implement card-detect hook.
This card-detect hook probably doesn't work. Perhaps somebody with more
knowledge about the hardware can comment on this. I think that perhaps
even the complete code from esdhc_init() could go into the getcd()
function instead or mmc_getcd() needs to be called at some later time
after mmc_init(), which, however, would require many other drivers to
change.
In addition to implementing the hook, this patch also removes the call
to the board_mmc_getcd() function which is now called from the MMC
framework and is no longer required here.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/fsl_esdhc.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index f719afd..b46bf9f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -412,7 +412,6 @@ static int esdhc_init(struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
int timeout = 1000;
- int ret = 0;
/* Reset the entire host controller */
esdhc_write32(regs-sysctl, SYSCTL_RSTA);
@@ -439,24 +438,19 @@ static int esdhc_init(struct mmc *mmc)
/* Set timout to the maximum value */
esdhc_clrsetbits32(regs-sysctl, SYSCTL_TIMEOUT_MASK, 14 16);
- /* Check if there is a callback for detecting the card */
- ret = board_mmc_getcd(mmc);
- if (ret 0) {
- timeout = 1000;
- while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS)
- --timeout)
- udelay(1000);
+ return 0;
+}
- if (timeout = 0)
- ret = NO_CARD_ERR;
- } else {
- if (ret == 0)
- ret = NO_CARD_ERR;
- else
- ret = 0;
- }
+static int esdhc_getcd(struct mmc *mmc)
+{
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
+ int timeout = 1000;
+
+ while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS) --timeout)
+ udelay(1000);
- return ret;
+ return timeout 0;
}
static void esdhc_reset(struct fsl_esdhc *regs)
@@ -494,6 +488,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
mmc-send_cmd = esdhc_send_cmd;
mmc-set_ios = esdhc_set_ios;
mmc-init = esdhc_init;
+ mmc-getcd = esdhc_getcd;
voltage_caps = 0;
caps = regs-hostcapblt;
--
1.7.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] usb_storage: Fix EHCI out of buffer pointers with CD-ROM
On Tuesday 20 December 2011 13:24:25 Moffett, Kyle D wrote: On Dec 20, 2011, at 13:20, Mike Frysinger wrote: On Tuesday 20 December 2011 12:41:14 Kyle Moffett wrote: + /* + * The U-Boot EHCI driver cannot handle more than 4096*5 bytes in a + * transfer without running itself out of qt_buffers. + */ + ss-max_xfer_blk = (4096*5)/dev_desc-blksz; spaces around those operators Fixed, thanks for the catch! you're too cheery for this list. i fear you may not last long. hopefully you'll prove me wrong. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH I2C] fix: error ATMEL_FIO_BASE undeclared, if use I2C_Soft on AT91
* Since AT91 name schema was changed to ATMEL_BASE_xxx, I2C_SOFT on AT91 devices fails with 'error: ATMEL_FIO_BASE undeclared' * change ATMEL_PIO_BASE to ATMEL_BASE_PIOA will fix this Signed-off-by: Jens Scharsig e...@bus-elektronik.de --- include/i2c.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/i2c.h b/include/i2c.h index ee31034..1f35acf 100644 --- a/include/i2c.h +++ b/include/i2c.h @@ -78,7 +78,7 @@ # elif (defined(CONFIG_AT91RM9200) || \ defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ defined(CONFIG_AT91SAM9263)) !defined(CONFIG_AT91_LEGACY) -# define I2C_SOFT_DECLARATIONSat91_pio_t *pio = (at91_pio_t *) AT91_PIO_BASE; +# define I2C_SOFT_DECLARATIONSat91_pio_t *pio = (at91_pio_t *) ATMEL_BASE_PIOA; # else # define I2C_SOFT_DECLARATIONS # endif -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] about flashing the u-boot
On 12/19/2011 06:43 PM, Érico Porto wrote: Got usb-tap to work, but ONLY with code warrior - and for some reason can run it on ubuntu+unity but not on ubuntu+xfce, which loads everything except the action button in the flash programmer where you select what you will do: flash dump, erase, write... Please report this to supp...@freescale.com. Any open alternative to use usb tap Abatron BDI3000 is a popular choice. or someone know where is the command line tool that is used by the CW IDE? The command line backend is called CCS (not sure where in a typical installation you'd find it) -- but the flash programming logic is in CW itself, so if you want to do flash programming with CCS directly you'll need to script it yourself. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] mmc: Implement central card-detection.
* Mike Frysinger wrote:
On Tuesday 20 December 2011 03:52:39 Thierry Reding wrote:
This series of patches implements central card-detection within the MMC
framework. Before this patch series, many boards actually did implement
the board_mmc_getcd() function, but it wasn't used except by one driver
(fsl_esdhc). Unfortunately, implementations interpreted the meaning of
the cd parameter differently, some taking it to signal card absence and
others using it to detect card presence. Furthermore, the signature of
the board_mmc_getcd() function was not at all consistent with other MMC
related functions.
as you've seen, GPIO pin detection is not novel or unique to any driver/SoC.
i'd suggest instead finding a way to move this into struct mmc. perhaps
something like:
include/mmc.h:
struct mmc {
...
#ifdef CONFIG_MMC_GPIO_CD
unsigned gpio_cd;
#endif
...
};
and then the default mmc_register() func can do:
#ifdef CONFIG_MMC_GPIO_CD
if (!mmc-getcd)
mmc-getcd = mmc_getcd_gpio;
#endif
and we can have the drivers/mmc/mmc.c:
#ifdef CONFIG_MMC_GPIO_CD
int mmc_getcd_gpio(struct mmc *mmc)
{
return !gpio_get_value(mmc-getcd);
}
#endif
then mmc drivers can extend their register function to take a GPIO number (if
they don't already). and then they get everything else for free.
Yes, there is some potential for refactoring drivers, though only a very
limited number of boards actually implement card-detection. I guess something
like what you are proposing could be added on top of the series. That would
hard-code the fact that card-detect GPIOs are always low-active, though. Can
we live with that? If a board handles that differently they can always
override the behaviour by specifying their own board_mmc_getcd().
Thierry
pgpgY7c9w0hJ1.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Some thoughts on SPL
On 12/20/2011 09:38 AM, Tom Rini wrote: So, in chasing down another problem I was having (that turned out unrelated) I just made SPL use the full NAND stack. It wouldn't be difficult to add CONFIG_SPL_FULL_NAND_SUPPORT How about CONFIG_SPL_NAND_FULL? (and either keep the existing name for nand_spl_simple or rename to CONFIG_SPL_MIN_NAND_SUPPORT). Please keep it as CONFIG_SPL_NAND_SIMPLE. There will be other NAND SPL implementations besides simple and full once we migrate over the existing nand_spl users. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] arm: Tegra: Fix Harmony and Ventana builds in u-boot-tegra/master
Seaboard changes have removed the need for common/board.o in the Makefile. Propagate this change to the other Tegra2 builds. Signed-off-by: Tom Warren twar...@nvidia.com --- V2: Add more info to commit msg about use/source of change board/nvidia/harmony/Makefile |1 - board/nvidia/ventana/Makefile |3 +-- include/configs/ventana.h |3 +++ 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/board/nvidia/harmony/Makefile b/board/nvidia/harmony/Makefile index f6599de..b6efa1c 100644 --- a/board/nvidia/harmony/Makefile +++ b/board/nvidia/harmony/Makefile @@ -31,7 +31,6 @@ endif LIB= $(obj)lib$(BOARD).o COBJS := $(BOARD).o -COBJS += ../common/board.o SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/nvidia/ventana/Makefile b/board/nvidia/ventana/Makefile index 9e5a87f..b4ab79a 100644 --- a/board/nvidia/ventana/Makefile +++ b/board/nvidia/ventana/Makefile @@ -30,8 +30,7 @@ endif LIB= $(obj)lib$(BOARD).o -COBJS += ../seaboard/seaboard.o -COBJS += ../common/board.o +COBJS = ../seaboard/seaboard.o SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/include/configs/ventana.h b/include/configs/ventana.h index afd6ff6..acc9b43 100644 --- a/include/configs/ventana.h +++ b/include/configs/ventana.h @@ -52,4 +52,7 @@ #define CONFIG_EFI_PARTITION #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT + +/* Environment not stored */ +#define CONFIG_ENV_IS_NOWHERE #endif /* __CONFIG_H */ -- 1.7.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Some thoughts on SPL
On Tue, Dec 20, 2011 at 1:48 PM, Scott Wood scottw...@freescale.com wrote: On 12/20/2011 09:38 AM, Tom Rini wrote: So, in chasing down another problem I was having (that turned out unrelated) I just made SPL use the full NAND stack. It wouldn't be difficult to add CONFIG_SPL_FULL_NAND_SUPPORT How about CONFIG_SPL_NAND_FULL? (and either keep the existing name for nand_spl_simple or rename to CONFIG_SPL_MIN_NAND_SUPPORT). Please keep it as CONFIG_SPL_NAND_SIMPLE. There will be other NAND SPL implementations besides simple and full once we migrate over the existing nand_spl users. OK, I only opened up README.SPL which says CONFIG_SPL_NAND_SUPPORT and not documenting that existing CONFIG_SPL_NAND_SIMPLE, so, agreed. And I'll add CONFIG_SPL_NAND_SIMPLE to the README. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
Dear Andreas, In message 201112201339.39460.schnitzelt...@gmx.de you wrote: I don't know if I want to jump also into these changes now - especially since I am quite new here.. But for my intererst - since it seems more error tolerant: How is SDRAM timing set up without exactly knowing what type is connected? Is there a good example implementation in u-boot(-spl)? In most cases thare is not an arbitrary range of RAM types, but only a pretty small selection; even more often they differ only in size, not in timings. It depends on the set of possible configurations and capabilities of the meory controller how to proceed then. Typically you will start with very conservative settings, and from the sizes found you will know the correct configuration. As for examples: probably not much in SPL, but a number of PPC board use this. See for example board/tqc/tqm8xx/tqm8xx.c which probes several banks of memory in 8, 9, and 10 column mode and then adjusts timing, even taking into account that the CPU and bus clock (and thus the refresh timings) are variable on some of these boards (you can set the CPU clock through the cpuclk environment variable). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is no statute of limitations on stupidity. - Randomly produced by a computer program called Markov3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Dear Chris Lalancette, In message CABMb9GuQ+1d4y2xxRUcR8DKP=p_c894mhldpvacq3h95e-n...@mail.gmail.com you wrote: Unfortunately, trying to build v2011.12-rc2 with the cross-compiler from Ubuntu 11.10 causes an ICE. I'm taking a look at it now to see if I can figure out the problem, but I thought I would point it out sooner rather than later. Which sort of ICE is this? Is this by chance this one: internal compiler error: in decode_addr_const, at varasm.c:2632 ? 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 Why don't you have a Linux partition installed so you can be working in a programmer-friendly environment instead of a keep-gates'-bank- account-happy one? :-)-- Tom Christiansen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-staging
Hello Wolfgang, Please pull two fixes for inclusion in v2011.12 release. Thanks! The following changes since commit 901de79a3792c81aefcbf207a34049e63f21362b: Prepare v2011.12-rc2 (2011-12-19 12:12:54 +0100) are available in the git repository at: git://git.denx.de/u-boot-staging.git ag...@denx.de Heiko Schocher (1): common/cmd_pxe.c: Fix GCC 4.6 build warnings Sven Schnelle (1): AVR32: fix timer_init() function arch/avr32/cpu/interrupts.c |5 +++-- common/cmd_pxe.c|2 +- 2 files changed, 4 insertions(+), 3 deletions(-) Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-x86/next
Dear Graeme Russ, In message 4eeea032.8050...@gmail.com you wrote: Hi Wolfgang: The following changes since commit 7b725f8485bcdd0be3cda40e435b783882bf18ec: CHECKPATCH: ./board/esd/hh405/logo_320_240_8bpp.c (2011-12-18 00:14:46 +0100) are available in the git repository at: git://git.denx.de/u-boot-x86.git next Gabe Black (7): x86: Initial commit for running as a coreboot payload x86: Import code from coreboot's libpayload to parse the coreboot table x86: Clean up the x86 zimage code in preparation to extend it x86: Add support for booting Linux using the 32 bit boot protocol x86: Add infrastructure to extract an e820 table from the coreboot tables x86: Refactor the zboot innards so they can be reused with a vboot image x86: Add support for specifying an initrd with the zboot command arch/x86/cpu/coreboot/Makefile | 58 + arch/x86/cpu/coreboot/asm-offsets.c | 25 ++ arch/x86/cpu/coreboot/coreboot_car.S | 29 +++ arch/x86/cpu/coreboot/ipchecksum.c | 54 + arch/x86/cpu/coreboot/sdram.c| 75 ++ arch/x86/cpu/coreboot/sysinfo.c | 39 +++ arch/x86/cpu/coreboot/tables.c | 183 ++ arch/x86/include/asm/arch-coreboot/ipchecksum.h | 37 +++ arch/x86/include/asm/arch-coreboot/sysinfo.h | 63 + arch/x86/include/asm/arch-coreboot/tables.h | 241 +++ arch/x86/include/asm/zimage.h| 36 +-- arch/x86/lib/bootm.c | 21 ++- arch/x86/lib/zimage.c| 276 ++ board/chromebook-x86/coreboot/Makefile | 53 board/chromebook-x86/coreboot/coreboot.c | 87 +++ board/chromebook-x86/coreboot/coreboot_pci.c | 30 +++ board/chromebook-x86/coreboot/coreboot_start.S | 29 +++ board/chromebook-x86/coreboot/coreboot_start16.S | 46 boards.cfg |1 + include/configs/coreboot.h | 225 ++ include/serial.h |2 +- 21 files changed, 1482 insertions(+), 128 deletions(-) create mode 100644 arch/x86/cpu/coreboot/Makefile create mode 100644 arch/x86/cpu/coreboot/asm-offsets.c create mode 100644 arch/x86/cpu/coreboot/coreboot_car.S create mode 100644 arch/x86/cpu/coreboot/ipchecksum.c create mode 100644 arch/x86/cpu/coreboot/sdram.c create mode 100644 arch/x86/cpu/coreboot/sysinfo.c create mode 100644 arch/x86/cpu/coreboot/tables.c create mode 100644 arch/x86/include/asm/arch-coreboot/ipchecksum.h create mode 100644 arch/x86/include/asm/arch-coreboot/sysinfo.h create mode 100644 arch/x86/include/asm/arch-coreboot/tables.h create mode 100644 board/chromebook-x86/coreboot/Makefile create mode 100644 board/chromebook-x86/coreboot/coreboot.c create mode 100644 board/chromebook-x86/coreboot/coreboot_pci.c create mode 100644 board/chromebook-x86/coreboot/coreboot_start.S create mode 100644 board/chromebook-x86/coreboot/coreboot_start16.S create mode 100644 include/configs/coreboot.h Applied to next branch, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: Tegra: Fix Harmony and Ventana builds in u-boot-tegra/master
Tom Warren wrote at Tuesday, December 20, 2011 1:54 PM: Seaboard changes have removed the need for common/board.o in the Makefile. Propagate this change to the other Tegra2 builds. Signed-off-by: Tom Warren twar...@nvidia.com Acked-by: Stephen Warren swar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Dear Albert ARIBAUD, In message 4eef6c88.8090...@aribaud.net you wrote: Hi Wolfgang, The following changes since commit 901de79a3792c81aefcbf207a34049e63f21362b: Prepare v2011.12-rc2 (2011-12-19 12:12:54 +0100) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Anatolij Gustschin (3): Fix building for mx51evk board ARM: sbc35_a9g20: re-add MACH_TYPE_SBC35_A9G20 ARM: tny_a9260: re-add MACH_TYPE_TNY_A9G20 and MACH_TYPE_TNY_A9260 Chris Lalancette (1): omap4_panda: Initialize the USB phy David M�ller (ELSOFT AG) (1): add print_cpuinfo to s3c24x0 Heiko Schocher (1): arm, fdt: update ethernet mac address before booting Linux Ilya Yanok (1): arm926ejs: remove noop flush_dcache_all function Manfred Rudigier (1): davinci: Fixed wrong timebase clock frequency. Marek Vasut (2): M28: Fix tab indent in u-boot.bd PXA: Kill last remnants of set_GPIO_mode function arch/arm/cpu/arm920t/s3c24x0/Makefile|1 + arch/arm/cpu/arm920t/s3c24x0/cpu_info.c | 54 + arch/arm/cpu/arm926ejs/cache.c |5 -- arch/arm/cpu/arm926ejs/davinci/timer.c |2 +- arch/arm/include/asm/arch-omap4/clocks.h | 63 ++ arch/arm/lib/bootm.c |2 + board/calao/sbc35_a9g20/sbc35_a9g20.c|1 - board/calao/tny_a9260/tny_a9260.c|5 -- board/denx/m28evk/u-boot.bd |8 ++-- board/freescale/mx51evk/mx51evk.c|3 +- board/freescale/mx53loco/mx53loco.c |3 +- board/lubbock/lubbock.c |6 +++ board/ti/panda/panda.c | 59 drivers/mmc/pxa_mmc.c|5 -- include/configs/sbc35_a9g20.h|3 + include/configs/tny_a9260.h |4 ++ 16 files changed, 201 insertions(+), 23 deletions(-) create mode 100644 arch/arm/cpu/arm920t/s3c24x0/cpu_info.c Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mvgbe: remove setting of ethaddr within the driver
Dear Michael Walle, In message 1321570349-4224-1-git-send-email-mich...@walle.cc you wrote: A network driver should not touch the environment at all. This patch fixes this behaviour by removing the code for setting a default/randomized MAC address. Signed-off-by: Michael Walle mich...@walle.cc Acked-by: Mike Frysinger vap...@gentoo.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Cc: Mike Frysinger vap...@gentoo.org Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Valentin Longchamp valentin.longch...@keymile.com Cc: Eric Cooper e...@cmu.edu Cc: Jason Cooper u-b...@lakedaemon.net Cc: Siddarth Gore go...@marvell.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Simon Guinot simon.gui...@sequanux.org --- drivers/net/mvgbe.c | 23 --- 1 files changed, 0 insertions(+), 23 deletions(-) Applied to next branch, 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 Any sufficiently advanced technology is indistinguishable from a rigged demo. - Andy Finkel, computer guy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mvgbe: remove setting of ethaddr within the driver
Dear Michael Walle, In message 1321570349-4224-1-git-send-email-mich...@walle.cc you wrote: A network driver should not touch the environment at all. This patch fixes this behaviour by removing the code for setting a default/randomized MAC address. Signed-off-by: Michael Walle mich...@walle.cc Acked-by: Mike Frysinger vap...@gentoo.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Cc: Mike Frysinger vap...@gentoo.org Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Valentin Longchamp valentin.longch...@keymile.com Cc: Eric Cooper e...@cmu.edu Cc: Jason Cooper u-b...@lakedaemon.net Cc: Siddarth Gore go...@marvell.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Simon Guinot simon.gui...@sequanux.org --- drivers/net/mvgbe.c | 23 --- 1 files changed, 0 insertions(+), 23 deletions(-) Applied to next branch, 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 It is a good thing for an uneducated man to read books of quotations. - Sir Winston Churchill _My Early Life_ ch. 9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] next branch started
Dear Michael Walle, In message 201112182328.19108.mich...@walle.cc you wrote: Please feel free to send pull-requests for next, or to point me to patches that should go into next (or even into the upcoming release). http://patchwork.ozlabs.org/patch/126328/ http://patchwork.ozlabs.org/patch/122253/ Applied to next branch, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The trouble with doing something right the first time is that nobody appreciates how difficult it was.- Walt West ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Dear =?ISO-8859-1?Q?Andreas_Bie=DFmann?=, In message 4eef2c5f.8070...@gmail.com you wrote: Dear Wolfgang, On 19.12.2011 12:23, Wolfgang Denk wrote: Hi everybody, I've just released v2011.12-rc2; please help testing. Please respond quickly if you find anything missing for the final release, I want to get this out on Friday at latest. avr32 is still broken. Anatolij has taken the required patch cause Reinhard is not responding. Please merge this patch into final release. Anatolij can you please send a pull request for http://git.denx.de/?p=u-boot/u-boot-staging.git;a=commitdiff;h=c230649a1da6701b081105a43beef163ae5e2820 Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Another war ... must it always be so? How many comrades have we lost in this way? ... Obedience. Duty. Death, and more death ... -- Romulan Commander, Balance of Terror, stardate 1709.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] AVR32: fix timer_init() function
Dear Sven Schnelle, In message 1443988412-13421-1-git-send-email-sv...@stackframe.org you wrote: timer_init() now returns an int (the error code) instead of void. This makes compilation fail with: interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1 Signed-off-by: Sven Schnelle sv...@stackframe.org --- Changes for v3: - return -EINVAL regardless of the return value Changes for v2: - Coding style arch/avr32/cpu/interrupts.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks. [Cherry-picked Anatolij's commit.] 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 trouble with doing something right the first time is that nobody appreciates how difficult it was.- Walt West ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Dear Simon Glass, In message CAPnjgZ1gS7JcZ7SH=necsdq+n4wmv28yb1ji7d2lv3910i5...@mail.gmail.com you wrote: Hi Wolfgang, On Mon, Dec 19, 2011 at 3:23 AM, Wolfgang Denk w...@denx.de wrote: Hi everybody, I've just released v2011.12-rc2; please help testing. Please respond quickly if you find anything missing for the final release, I want to get this out on Friday at latest. Thanks. Just the tftpput fix from me. I can change it quickly f needed. http://patchwork.ozlabs.org/patch/132342/ Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You'll learn something about men and women -- the way they're supposed to be. Caring for each other, being happy with each other, being good to each other. That's what we call love. You'll like that a lot. -- Kirk, The Apple, stardate 3715.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: Fix arguments in tftpput command
Dear Simon Glass, In message 1324347043-29184-1-git-send-email-...@chromium.org you wrote: The switch to strict_strtoul() was not done correctly - this fixes the compile error when CONFIG_CMD_TFTPPUT is active. There appears to very little use of strict_strtoul() in commands, so it might be easier to switch to simple_strtoul(). If not, we should decide the best way to use strict_strtoul(). For now I have added a friendly message which will of course increase code size. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Check return value and print friendly message if incorrect common/cmd_net.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Here's a fish hangs in the net like a poor man's right in the law. 'Twill hardly come out. - Shakespeare, Pericles, Act II, Scene 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000_spi.c: Fix build warnings
Dear Anatolij Gustschin, In message 1324384143-10198-1-git-send-email-ag...@denx.de you wrote: Fix: e1000_spi.c: In function 'spi_free_slave': e1000_spi.c:115: warning: unused variable 'hw' e1000_spi.c: In function 'do_e1000_spi': e1000_spi.c:472: warning: 'checksum' may be used uninitialized in this function e1000_spi.c:472: note: 'checksum' was declared here Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Kyle Moffett kyle.d.moff...@boeing.com --- drivers/net/e1000_spi.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Compassion -- that's the one things no machine ever had. Maybe it's the one thing that keeps men ahead of them. -- McCoy, The Ultimate Computer, stardate 4731.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-staging
Dear Anatolij Gustschin, In message 20111220223552.2b63881f@wker you wrote: Hello Wolfgang, Please pull two fixes for inclusion in v2011.12 release. Thanks! The following changes since commit 901de79a3792c81aefcbf207a34049e63f21362b: Prepare v2011.12-rc2 (2011-12-19 12:12:54 +0100) are available in the git repository at: git://git.denx.de/u-boot-staging.git ag...@denx.de Heiko Schocher (1): common/cmd_pxe.c: Fix GCC 4.6 build warnings Sven Schnelle (1): AVR32: fix timer_init() function arch/avr32/cpu/interrupts.c |5 +++-- common/cmd_pxe.c|2 +- 2 files changed, 4 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de READ THIS BEFORE OPENING PACKAGE: According to Certain Suggested Ver- sions of the Grand Unified Theory, the Primary Particles Constituting this Product May Decay to Nothingness Within the Next Four Hundred Million Years. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: fix some issues in FAT write support code
Dear Anatolij Gustschin, In message 1323954734-26775-1-git-send-email-ag...@denx.de you wrote: Writing a file to the FAT partition didn't work while a test using a CF card. The test was done on mpc5200 based board (powerpc). There is a number of problems in FAT write code: Compiler warning: fat_write.c: In function 'file_fat_write': fat_write.c:326: warning: 'counter' may be used uninitialized in this function fat_write.c:326: note: 'counter' was declared here 'l_filename' string is not terminated, so a file name with garbage at the end is used as a file name as shown by debug code. Return value of set_contents() is not checked properly so actually a file won't be written at all (as checked using 'fatls' after a write attempt with 'fatwrite' command). do_fat_write() doesn't return the number of written bytes if no error happened. However the return value of this function is used to show the number of written bytes in do_fat_fswrite(). The patch adds some debug code and fixes above mentioned problems and also fixes a typo in error output. NOTE: after a successful write to the FAT partition (under U-Boot) the partition was checked under Linux using fsck. The partition needed fixing FATs: -bash-3.2# fsck -a /dev/sda1 fsck 1.39 (29-May-2006) dosfsck 2.11, 12 Mar 2005, FAT32, LFN FATs differ but appear to be intact. Using first FAT. Performing changes. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Donggeun Kim dg77@samsung.com Cc: Aaron Williams aaron.willi...@cavium.com --- fs/fat/fat_write.c | 19 ++- 1 files changed, 14 insertions(+), 5 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Emotions are alien to me. I'm a scientist. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/samsung/universal_c210/universal.c: Fix build warning
Dear Anatolij Gustschin, In message 1324304404-24044-1-git-send-email-ag...@denx.de you wrote: Fix: universal.c: In function 's5pc210_phy_control': universal.c:273:7: warning: 'ret' may be used uninitialized in this function [-Wuninitialized] Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- board/samsung/universal_c210/universal.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The shortest unit of time in the multiverse is the News York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: s3c_udc_otg: fix GCC 4.6 build warnings
Dear Anatolij Gustschin, In message 1324304435-24076-1-git-send-email-ag...@denx.de you wrote: Fix: In file included from s3c_udc_otg.c:216:0: s3c_udc_otg_xfer_dma.c: In function 'complete_tx': s3c_udc_otg_xfer_dma.c:280:33: warning: variable 'is_short' set but not used s3c_udc_otg_xfer_dma.c:280:6: warning: variable 'ep_tsr' set but not used s3c_udc_otg_xfer_dma.c: In function 's3c_udc_irq': s3c_udc_otg_xfer_dma.c:469:16: warning: variable 'flags' set but not used s3c_udc_otg_xfer_dma.c:468:18: warning: variable 'gintmsk' set but not used s3c_udc_otg_xfer_dma.c: In function 's3c_queue': s3c_udc_otg_xfer_dma.c:582:14: warning: variable 'gintsts' set but not used s3c_udc_otg_xfer_dma.c:581:16: warning: variable 'flags' set but not used s3c_udc_otg_xfer_dma.c: In function 's3c_ep0_read': s3c_udc_otg_xfer_dma.c:778:6: warning: variable 'ret' set but not used s3c_udc_otg_xfer_dma.c: In function 's3c_udc_set_halt': s3c_udc_otg_xfer_dma.c:1020:16: warning: variable 'flags' set but not used s3c_udc_otg_xfer_dma.c: In function 's3c_ep0_setup': s3c_udc_otg_xfer_dma.c:1258:13: warning: initialization from incompatible pointer type [enabled by default] s3c_udc_otg_xfer_dma.c:1239:16: warning: variable 'is_in' set but not used s3c_udc_otg_xfer_dma.c:1239:9: warning: variable 'bytes' set but not used s3c_udc_otg.c: In function 'usb_gadget_register_driver': s3c_udc_otg.c:292:16: warning: variable 'flags' set but not used s3c_udc_otg.c: In function 'usb_gadget_unregister_driver': s3c_udc_otg.c:338:16: warning: variable 'flags' set but not used s3c_udc_otg.c: In function 's3c_ep_enable': s3c_udc_otg.c:582:16: warning: variable 'flags' set but not used s3c_udc_otg.c: In function 's3c_ep_disable': s3c_udc_otg.c:646:16: warning: variable 'flags' set but not used s3c_udc_otg.c: In function 's3c_dequeue': s3c_udc_otg.c:704:16: warning: variable 'flags' set but not used Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Remy Bohmer li...@bohmer.net --- drivers/usb/gadget/s3c_udc_otg.c | 52 - drivers/usb/gadget/s3c_udc_otg_xfer_dma.c | 166 - include/usb/lin_gadget_compat.h |2 +- include/usb/s3c_udc.h | 20 ++-- 4 files changed, 125 insertions(+), 115 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It took him several minutes to understand any new idea put to him, and this is a very valuable trait in a leader, because anything any- one is still trying to explain to you after two minutes is probably important and anything they give up after a mere minute or so is al- most certainly something they shouldn't have been bothering you with in the first place. - Terry Pratchett, _Reaper Man_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
