Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear "Bedia, Vaibhav", In message you wrote: > > Is having a config option to specify the location of bss (like > CONFIG_SYS_BSS_ADDR) better/acceptable? No such option is necessary because it is up to the SPL linker script where it places the BSS. 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 Quote from the Boss... "I didn't say it was your fault. I said I was going to blame it on you." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support
Dear Albert ARIBAUD, In message <4d47ad9a.3060...@free.fr> you wrote: > > Wolfgang, do we: > > - wait for Prafulla's pull, or > > - just take Stefano's and move ahead with this release, and Prafulla > stacks the current changes onto his 'next' branch until the MW opens > again, or > > - something else yet? Let's please thake what we have so far and get some -rc1 out ASAP. When Prafulla's pull request comes, we can still decide if we pull this into mainline (I tend to do so if it's really a few days) or push into next. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I am a computer. I am dumber than any human and smarter than any ad- ministrator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Aneesh V, In message <4d4798e2.3050...@ti.com> you wrote: > > I had been working on creating an MMC SPL for OMAP4. OMAP boards > typically support booting from the FAT partition of a removable SD/MMC > card. So, we need to have FAT support in the SPL. But I am having some > difficulties in adding FAT support to SPL. > > BSS footprint of fat.c is very high. It has three buffers each of size > 64KB. To workaround this problem I have done something like below(The > way x-loader works around this problem today). > CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? Why would that be necessary? Just put the BSS segment in SDRAM, and everything is fine, isn't it? > Also, I was wondering why we need 3 such scratch buffers in this > implementation. I do not understand this code. But I was wondering if we > could work with just one 64K buffer? I have no idea. I am not familiar with that code either. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A day without sunshine is like night. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix min/max macros in include/common.h
Dear Aaron Williams, In message <201101311955.50902.aaron.willi...@caviumnetworks.com> you wrote: > There is a bug in the min and max macros in common.h which occurs if > Y is a larger type than X. For example, if Y is a 64-bit value and X > is a 32-bit value then Y will be truncated to 32-bits. This fix > matches what is done in the Linux kernel but without the additional > type checking present in the kernel version. Please stick to the rules. When resubmitting a patch you are supposed to mark it as a reposting, and to keep the message references in place so mails get threaded properly. Please make sure and read http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions 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 Always leave room to add an explanation if it doesn't work out. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] [NAND] Add support for 4GiB and larger NAND
Dear Aaron Williams, In message <201101311944.13761.aaron.willi...@caviumnetworks.com> you wrote: > I'm still fighting with my mail tool, hopefully this will work. You should use "git format-patch" to create and "git send-email" to submit the patch instead. Noter that such a comment as the line above should ot go into the commit message, but below the "---" line (which gets insertred by "git format-patch"). > -Aaron Ditto for this line. Please read the hints at http://www.denx.de/wiki/U-Boot/Patches Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have the simplest tastes. I am always satisfied with the best. -- Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
Dear Scott Wood, In message <20110131135548.50d65...@udp111988uds.am.freescale.net> you wrote: > > > [Btw: "final" is probably not a technically correct term for all the > > use cases I see below.] > > I meant final as compared to partial links, not anything to do with spl > versus tpl versus the main image. > > Do you have a better wording? Not really. ld documentation also talks about "final binary" or "final executable". Note that I'm not insisting on a change here. > > > LDFLAGS += $(PLATFORM_LDFLAGS) > > > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS) > > > > > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) > > > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) > > > > Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here? > > > > Are you sure that this change is correct for all affected boards? > > > > How has this change been tested? > > As I understand it, it has only been limited to PLATFORM_LDFLAGS since > the LDFLAGS_u-boot commit. Was that change intentional, and widely > tested? Can you please be more specific? I don't see where "the LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related code. The relevant hunk looks like this: @@ -204,9 +204,11 @@ endif AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) -LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) +LDFLAGS += $(PLATFORM_LDFLAGS) + +LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) ifneq ($(CONFIG_SYS_TEXT_BASE),) -LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE) +LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE) endif # Location of a usable BFD library, where we define "usable" as and this does not make any changes of PLATFORM_LDFLAGS into LDFLAGS or vice versa. 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 the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs!" - David E. Lundstrom, "A Few Good Men From Univac", MIT Press, 1987 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC 405EX hangs waiting for PCIE to reset
Hi David, On Friday 28 January 2011 14:57:06 David Thomas wrote: > We have a board with an AMCC PPC 405EX connected to two fpga's with PCIE > interfaces. > > On some boards, on power up, the u-boot code hangs in the while loop in > the following code waiting for PCIE1 to come out of reset. PCIE0 comes > out of reset successfully. > > The PHYSTA for PCIE1 always reads back with the value 0x3000, > indicating the the interface is in the P2 state and that the PLL has not > locked. > > If a timeout is added and U-boot is allowed to proceed, a machine check > is eventually taken and the processor reboots. During the reboot, u-boot > runs through the same code but this time both PCIE interfaces > successfully come out of reset and the board comes up normally. > > Any suggestions about what might be happening here? Did you try setting the "pcidelay" environment variable. This will delay initializing the PCI(e) interfaces for n milliseconds. Try setting it to 3000 (3 seconds) to see if this helps. Please note that you need to set CONFIG_PCI_BOOTDELAY in your board config header to enable this "feature". Cheers, 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] [PATCH] BLOCK: Fixup iMX51 ATA driver
On 11/29/2010 03:18 PM, Marek Vasut wrote: > Signed-off-by: Marek Vasut Hi Marek, in my regression tests to check if all IMX boards are compiled clean I found the following warnings (efikamx): mxc_ata.c:90: warning: 'pio_t0' defined but not used mxc_ata.c:93: warning: 'pio_t2_16' defined but not used mxc_ata.c:94: warning: 'pio_t2i' defined but not used As I have already merged your patch into u-boot-imx (and Albert has already merged it in u-boot-arm), I will post a patch on top of it to remove them. Anyway, have you expected that these three variables are not used at all ? Could I remove them ? Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Le 01/02/2011 08:04, Albert ARIBAUD a écrit : > I'd like to make sure I understand the issue. Do these three BSS > variables occupy space in the U-Boot binary? If they do, then *that* > must be fixed rather than allocating a fixed address for them. In ARM > achitectures, the linker file makes sure the BSS is at the end of the > image and is not loadable, so the ELF to bin conversion just skips them. > Maybe the linker file you're using here does not do this? Answering myself: after reading Vaibhav's answer, I should amend my question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in whatever memory it lands in. In that case, there's indeed no fix except putting the buffers in DRAM. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Le 01/02/2011 06:23, Aneesh V a écrit : > Dear Wolfgang, > > I had been working on creating an MMC SPL for OMAP4. OMAP boards > typically support booting from the FAT partition of a removable SD/MMC > card. So, we need to have FAT support in the SPL. But I am having some > difficulties in adding FAT support to SPL. > > BSS footprint of fat.c is very high. It has three buffers each of size > 64KB. To workaround this problem I have done something like below(The > way x-loader works around this problem today). > CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? > > Also, I was wondering why we need 3 such scratch buffers in this > implementation. I do not understand this code. But I was wondering if we > could work with just one 64K buffer? > > --- > +#ifdef CONFIG_PRELOADER > +__u8 *get_vfatname_block = (__u8 *)CONFIG_SYS_SPL_FAT_BUFFER_BASE; > +#else >__attribute__ ((__aligned__ (__alignof__ (dir_entry >__u8 get_vfatname_block[MAX_CLUSTSIZE]; > +#endif > > . > . > . > > +#ifdef CONFIG_PRELOADER > +__u8 *get_dentfromdir_block = (__u8 *)CONFIG_SYS_SPL_FAT_BUFFER_BASE + > + MAX_CLUSTSIZE; > +#else >__attribute__ ((__aligned__ (__alignof__ (dir_entry >__u8 get_dentfromdir_block[MAX_CLUSTSIZE]; > +#endif > + I'd like to make sure I understand the issue. Do these three BSS variables occupy space in the U-Boot binary? If they do, then *that* must be fixed rather than allocating a fixed address for them. In ARM achitectures, the linker file makes sure the BSS is at the end of the image and is not loadable, so the ELF to bin conversion just skips them. Maybe the linker file you're using here does not do this? > Best regards, > Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support
(actually Cc:ing Wolfgang, sorry) Le 01/02/2011 07:52, Albert ARIBAUD a écrit : >> Hi Albert, >> I am sorry being on business trip and very busy schedule, >> I just have pantheon patch-series to be pulled in and few more stuff related >> to fixes. But I don't think I will be able to do it within day or two. >> >> Regards.. >> Prafulla . . . > > Understood. > > Wolfgang, do we: > > - wait for Prafulla's pull, or > > - just take Stefano's and move ahead with this release, and Prafulla > stacks the current changes onto his 'next' branch until the MW opens > again, or > > - something else yet? > > Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Hi Aneesh, On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote: > Dear Wolfgang, > > I had been working on creating an MMC SPL for OMAP4. OMAP boards > typically support booting from the FAT partition of a removable > SD/MMC card. So, we need to have FAT support in the SPL. But I am > having some difficulties in adding FAT support to SPL. > > BSS footprint of fat.c is very high. It has three buffers each of > size 64KB. To workaround this problem I have done something like > below(The way x-loader works around this problem today). > CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? > [...] I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss. Is having a config option to specify the location of bss (like CONFIG_SYS_BSS_ADDR) better/acceptable? Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support
Le 01/02/2011 07:14, Prafulla Wadaskar a écrit : > > >> -Original Message- >> From: Albert ARIBAUD [mailto:albert.arib...@free.fr] >> Sent: Monday, January 31, 2011 4:06 AM >> To: Stefano Babic >> Cc: Marek Vasut; u-boot@lists.denx.de; m...@genesi-usa.com; Prafulla >> Wadaskar >> Subject: Re: [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support >> >> Le 31/01/2011 11:20, Stefano Babic a écrit : >>> On 01/31/2011 11:00 AM, Marek Vasut wrote: On Wednesday 19 January 2011 15:40:37 Marek Vasut wrote: > Supported: > MMC > IDE > PMIC > SPI flash > LEDs > > I can boot the kernel supplied by freescale/genesi with this from >> MMC card > and/or PATA disk. > > Signed-off-by: Marek Vasut > --- > v4: Fixed coding style as proposed by Wolfgang (multiline comments, > #defines) ping ! >>> >>> pong ! >>> >>> I have put your patches into the u-boot-imx, next branch. I have not >>> seen any further comment to your patches and they will be part of the >>> next pull-request. >>> >>> Generally, I wait until my last pull-request goes to mainline before >>> sending a new one. I thought this is also better for Albert (in CC), >> but >>> I could send pull request more often. Albert, what do you mean ? >> Should >>> be acceptable for you to receive more pull-request without waiting for >>> merging into ML ? >> >> I'm still waiting for Prafulla's pull request at this point (Cc:). If >> the new commits in imx/master are fixes or were submitted (as V1) before >> the merge window close, then I can still accept them. > > Hi Albert, > I am sorry being on business trip and very busy schedule, > I just have pantheon patch-series to be pulled in and few more stuff related > to fixes. But I don't think I will be able to do it within day or two. > > Regards.. > Prafulla . . . Understood. Wolfgang, do we: - wait for Prafulla's pull, or - just take Stefano's and move ahead with this release, and Prafulla stacks the current changes onto his 'next' branch until the MW opens again, or - something else yet? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, January 31, 2011 4:06 AM > To: Stefano Babic > Cc: Marek Vasut; u-boot@lists.denx.de; m...@genesi-usa.com; Prafulla > Wadaskar > Subject: Re: [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support > > Le 31/01/2011 11:20, Stefano Babic a écrit : > > On 01/31/2011 11:00 AM, Marek Vasut wrote: > >> On Wednesday 19 January 2011 15:40:37 Marek Vasut wrote: > >>> Supported: > >>> MMC > >>> IDE > >>> PMIC > >>> SPI flash > >>> LEDs > >>> > >>> I can boot the kernel supplied by freescale/genesi with this from > MMC card > >>> and/or PATA disk. > >>> > >>> Signed-off-by: Marek Vasut > >>> --- > >>> v4: Fixed coding style as proposed by Wolfgang (multiline comments, > >>> #defines) > >> > >> ping ! > > > > pong ! > > > > I have put your patches into the u-boot-imx, next branch. I have not > > seen any further comment to your patches and they will be part of the > > next pull-request. > > > > Generally, I wait until my last pull-request goes to mainline before > > sending a new one. I thought this is also better for Albert (in CC), > but > > I could send pull request more often. Albert, what do you mean ? > Should > > be acceptable for you to receive more pull-request without waiting for > > merging into ML ? > > I'm still waiting for Prafulla's pull request at this point (Cc:). If > the new commits in imx/master are fixes or were submitted (as V1) before > the merge window close, then I can still accept them. Hi Albert, I am sorry being on business trip and very busy schedule, I just have pantheon patch-series to be pulled in and few more stuff related to fixes. But I don't think I will be able to do it within day or two. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v2] powerpc/8xxx: Refactor fsl_ddr_get_spd into common code from board
Move fsl_ddr_get_spd into common mpc8xxx/ddr/main.c as most boards
pretty much do the same thing. The only variations are in how many
controllers or DIMMs per controller exist. To make this work we
standardize on the names of the SPD_EEPROM_ADDRESS defines based on the
use case of the board.
We allow boards to override get_spd to either do board specific fixups
to the SPD data or deal with any unique behavior of how the SPD eeproms
are wired up.
Signed-off-by: Kumar Gala
---
* Fix error check in fsl_ddr_get_spd related to # of DDR controllers
arch/powerpc/cpu/mpc8xxx/ddr/main.c | 63 +--
board/freescale/corenet_ds/ddr.c| 27 ---
board/freescale/mpc8536ds/ddr.c | 21 ---
board/freescale/mpc8540ads/ddr.c| 22
board/freescale/mpc8541cds/ddr.c| 21 ---
board/freescale/mpc8544ds/ddr.c | 22
board/freescale/mpc8548cds/ddr.c| 22
board/freescale/mpc8555cds/ddr.c| 21 ---
board/freescale/mpc8560ads/ddr.c| 22
board/freescale/mpc8568mds/ddr.c| 22
board/freescale/mpc8569mds/ddr.c| 22
board/freescale/mpc8572ds/ddr.c | 23 -
board/freescale/mpc8610hpcd/ddr.c | 21 ---
board/freescale/mpc8641hpcn/ddr.c | 30
board/freescale/p1022ds/ddr.c | 18 --
board/freescale/p2020ds/ddr.c | 19 --
board/sbc8548/ddr.c | 22
board/sbc8560/ddr.c | 22
board/sbc8641d/ddr.c| 30
board/socrates/ddr.c| 22
board/stx/stxgp3/ddr.c | 22
board/stx/stxssa/ddr.c | 21 ---
board/xes/xpedite517x/ddr.c | 25 +-
board/xes/xpedite520x/ddr.c | 17 +-
board/xes/xpedite537x/ddr.c | 17 +-
board/xes/xpedite550x/ddr.c | 15 +
include/configs/MPC8569MDS.h|3 +-
include/configs/MPC8610HPCD.h |2 +-
include/configs/P1022DS.h |2 +-
include/configs/P2020DS.h |2 +-
include/configs/xpedite550x.h |2 +-
31 files changed, 69 insertions(+), 551 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index bb96d66..4129d3c 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -13,6 +13,7 @@
*/
#include
+#include
#include
#include "ddr.h"
@@ -26,9 +27,65 @@ extern void fsl_ddr_set_lawbar(
extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
unsigned int ctrl_num);
-/* Board-specific functions defined in each board's ddr.c */
-extern void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
- unsigned int ctrl_num);
+#if defined(SPD_EEPROM_ADDRESS) || \
+defined(SPD_EEPROM_ADDRESS1) || defined(SPD_EEPROM_ADDRESS2) || \
+defined(SPD_EEPROM_ADDRESS3) || defined(SPD_EEPROM_ADDRESS4)
+#if (CONFIG_NUM_DDR_CONTROLLERS == 1) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS,
+};
+#endif
+#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS1, /* controller 1 */
+ [1][0] = SPD_EEPROM_ADDRESS2, /* controller 2 */
+};
+#endif
+#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS1, /* controller 1 */
+ [0][1] = SPD_EEPROM_ADDRESS2, /* controller 1 */
+ [1][0] = SPD_EEPROM_ADDRESS3, /* controller 2 */
+ [1][1] = SPD_EEPROM_ADDRESS4, /* controller 2 */
+};
+#endif
+
+static void __get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
+{
+ int ret = i2c_read(i2c_address, 0, 1, (uchar *)spd,
+ sizeof(generic_spd_eeprom_t));
+
+ if (ret) {
+ debug("DDR: failed to read SPD from address %u\n", i2c_address);
+ memset(spd, 0, sizeof(generic_spd_eeprom_t));
+ }
+}
+
+__attribute__((weak, alias("__get_spd")))
+void get_spd(generic_spd_eeprom_t *spd, u8 i2c_address);
+
+void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
+ unsigned int ctrl_num)
+{
+ unsigned int i;
+ unsigned int i2c_address = 0;
+
+ if (ctrl_num >= CONFIG_NUM_DDR_CONTROLLERS) {
+ printf("%s unexpected ctrl_num = %u\n", __FUNCTION__, ctrl_num);
+ return;
+ }
+
+ for (i = 0; i < CONFIG_DIMM_SLOTS_PER_CTLR; i++) {
+ i2c_address = spd_i2c_addr[ctrl_num][i];
+
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
I've published some related cleanup patches and push those patches into u-boot-85xx.git 'dev' branch. You should be able to: * drop board_lmb_reserve() * remove config.mk and CONFIG_SYS_LDSCRIPT in config.h * remove fsl_ddr_get_mem_data_rate(), fsl_ddr_get_spd() [need to rename SPD_EEPROM_ADDRESS1 to SPD_EEPROM_ADDRESS] * just set P1021 related defines rather than touch immap_qe.h - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BSS footprint of FAT very high - SPL issues
Dear Wolfgang, I had been working on creating an MMC SPL for OMAP4. OMAP boards typically support booting from the FAT partition of a removable SD/MMC card. So, we need to have FAT support in the SPL. But I am having some difficulties in adding FAT support to SPL. BSS footprint of fat.c is very high. It has three buffers each of size 64KB. To workaround this problem I have done something like below(The way x-loader works around this problem today). CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? Also, I was wondering why we need 3 such scratch buffers in this implementation. I do not understand this code. But I was wondering if we could work with just one 64K buffer? --- +#ifdef CONFIG_PRELOADER +__u8 *get_vfatname_block = (__u8 *)CONFIG_SYS_SPL_FAT_BUFFER_BASE; +#else __attribute__ ((__aligned__ (__alignof__ (dir_entry __u8 get_vfatname_block[MAX_CLUSTSIZE]; +#endif . . . +#ifdef CONFIG_PRELOADER +__u8 *get_dentfromdir_block = (__u8 *)CONFIG_SYS_SPL_FAT_BUFFER_BASE + + MAX_CLUSTSIZE; +#else __attribute__ ((__aligned__ (__alignof__ (dir_entry __u8 get_dentfromdir_block[MAX_CLUSTSIZE]; +#endif + Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Cleanup some QE related defines
Move some processor specific QE defines into config_mpc85xx.h and use
QE_MURAM_SIZE to cleanup some ifdef mess in the QE immap struct.
Also fixed up some comment style issues in immap_qe.h
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/config_mpc85xx.h |6 ++
arch/powerpc/include/asm/immap_qe.h | 98 +
2 files changed, 37 insertions(+), 67 deletions(-)
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index bef88ce..4e7c179 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -67,11 +67,17 @@
#define CONFIG_MAX_CPUS1
#define CONFIG_SYS_FSL_NUM_LAWS10
#define CONFIG_SYS_FSL_SEC_COMPAT 2
+#define QE_MURAM_SIZE 0x1UL
+#define MAX_QE_RISC2
+#define QE_NUM_OF_SNUM 28
#elif defined(CONFIG_MPC8569)
#define CONFIG_MAX_CPUS1
#define CONFIG_SYS_FSL_NUM_LAWS10
#define CONFIG_SYS_FSL_SEC_COMPAT 2
+#define QE_MURAM_SIZE 0x2UL
+#define MAX_QE_RISC4
+#define QE_NUM_OF_SNUM 46
#elif defined(CONFIG_MPC8572)
#define CONFIG_MAX_CPUS2
diff --git a/arch/powerpc/include/asm/immap_qe.h
b/arch/powerpc/include/asm/immap_qe.h
index 531cfc8..9be9dca 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -3,7 +3,7 @@
* The Internal Memory Map for devices with QE on them. This
* is the superset of all QE devices (8360, etc.).
*
- * Copyright (c) 2006-2009 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006-2009, 2011 Freescale Semiconductor, Inc.
* Author: Shlomi Gridih
*
* This program is free software; you can redistribute it and/or modify it
@@ -15,8 +15,19 @@
#ifndef __IMMAP_QE_H__
#define __IMMAP_QE_H__
-/* QE I-RAM
-*/
+#ifdef CONFIG_MPC83xx
+#if defined(CONFIG_MPC8360)
+#define QE_MURAM_SIZE 0xc000UL
+#define MAX_QE_RISC2
+#define QE_NUM_OF_SNUM 28
+#elif defined(CONFIG_MPC832x)
+#define QE_MURAM_SIZE 0x4000UL
+#define MAX_QE_RISC1
+#define QE_NUM_OF_SNUM 28
+#endif
+#endif
+
+/* QE I-RAM */
typedef struct qe_iram {
u32 iadd; /* I-RAM Address Register */
u32 idata; /* I-RAM Data Register*/
@@ -25,8 +36,7 @@ typedef struct qe_iram {
u8 res1[0x70];
} __attribute__ ((packed)) qe_iram_t;
-/* QE Interrupt Controller
-*/
+/* QE Interrupt Controller */
typedef struct qe_ic {
u32 qicr;
u32 qivec;
@@ -49,8 +59,7 @@ typedef struct qe_ic {
u8 res3[0x1C];
} __attribute__ ((packed)) qe_ic_t;
-/* Communications Processor
-*/
+/* Communications Processor */
typedef struct cp_qe {
u32 cecr; /* QE command register */
u32 ceccr; /* QE controller configuration register */
@@ -87,8 +96,7 @@ typedef struct cp_qe {
u8 res13[0x280];
} __attribute__ ((packed)) cp_qe_t;
-/* QE Multiplexer
-*/
+/* QE Multiplexer */
typedef struct qe_mux {
u32 cmxgcr; /* CMX general clock route register*/
u32 cmxsi1cr_l; /* CMX SI1 clock route low register*/
@@ -102,8 +110,7 @@ typedef struct qe_mux {
u8 res0[0x1C];
} __attribute__ ((packed)) qe_mux_t;
-/* QE Timers
-*/
+/* QE Timers */
typedef struct qe_timers {
u8 gtcfr1; /* Timer 1 2 global configuration register */
u8 res0[0x3];
@@ -133,8 +140,7 @@ typedef struct qe_timers {
u8 res2[0x46];
} __attribute__ ((packed)) qe_timers_t;
-/* BRG
-*/
+/* BRG */
typedef struct qe_brg {
u32 brgc1; /* BRG1 configuration register */
u32 brgc2; /* BRG2 configuration register */
@@ -155,8 +161,7 @@ typedef struct qe_brg {
u8 res0[0x40];
} __attribute__ ((packed)) qe_brg_t;
-/* SPI
-*/
+/* SPI */
typedef struct spi {
u8 res0[0x20];
u32 spmode; /* SPI mode register */
@@ -174,8 +179,7 @@ typedef struct spi {
u8 res7[0x8];
} __attribute__ ((packed)) spi_t;
-/* SI
-*/
+/* SI */
typedef struct si1 {
u16 siamr1; /* SI1 TDMA mode register */
u16 sibmr1; /* SI1 TDMB mode register */
@@ -222,16 +226,14 @@ typedef struct si1 {
u8 res9[0xBB];
} __attribute__ ((packed)) si1_t;
-/* SI Routing Tables
-*/
+/* SI Routing Tables */
typedef struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
} __attribute__ ((packed)) sir_t;
-/* USB Controller.
-*/
+/* USB Controller. */
typedef struct usb_ctlr {
u8 usb_usmod;
u8 usb_usadr;
@@ -253,8 +255,7 @@ typedef struct usb_ctlr {
u8 res6[0x22];
} __attribute__ ((packed)) usb_t;
-/* MCC
-*/
+/* MCC */
typedef struct mcc {
u32 mcce; /* MCC event
[U-Boot] [PATCH 2/2] powerpc/8xxx: Refactor fsl_ddr_get_spd into common code from board
Move fsl_ddr_get_spd into common mpc8xxx/ddr/main.c as most boards
pretty much do the same thing. The only variations are in how many
controllers or DIMMs per controller exist. To make this work we
standardize on the names of the SPD_EEPROM_ADDRESS defines based on the
use case of the board.
We allow boards to override get_spd to either do board specific fixups
to the SPD data or deal with any unique behavior of how the SPD eeproms
are wired up.
Signed-off-by: Kumar Gala
---
arch/powerpc/cpu/mpc8xxx/ddr/main.c | 63 +--
board/freescale/corenet_ds/ddr.c| 27 ---
board/freescale/mpc8536ds/ddr.c | 21 ---
board/freescale/mpc8540ads/ddr.c| 22
board/freescale/mpc8541cds/ddr.c| 21 ---
board/freescale/mpc8544ds/ddr.c | 22
board/freescale/mpc8548cds/ddr.c| 22
board/freescale/mpc8555cds/ddr.c| 21 ---
board/freescale/mpc8560ads/ddr.c| 22
board/freescale/mpc8568mds/ddr.c| 22
board/freescale/mpc8569mds/ddr.c| 22
board/freescale/mpc8572ds/ddr.c | 23 -
board/freescale/mpc8610hpcd/ddr.c | 21 ---
board/freescale/mpc8641hpcn/ddr.c | 30
board/freescale/p1022ds/ddr.c | 18 --
board/freescale/p2020ds/ddr.c | 19 --
board/sbc8548/ddr.c | 22
board/sbc8560/ddr.c | 22
board/sbc8641d/ddr.c| 30
board/socrates/ddr.c| 22
board/stx/stxgp3/ddr.c | 22
board/stx/stxssa/ddr.c | 21 ---
board/xes/xpedite517x/ddr.c | 25 +-
board/xes/xpedite520x/ddr.c | 17 +-
board/xes/xpedite537x/ddr.c | 17 +-
board/xes/xpedite550x/ddr.c | 15 +
include/configs/MPC8569MDS.h|3 +-
include/configs/MPC8610HPCD.h |2 +-
include/configs/P1022DS.h |2 +-
include/configs/P2020DS.h |2 +-
include/configs/xpedite550x.h |2 +-
31 files changed, 69 insertions(+), 551 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index bb96d66..ee290f5 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -13,6 +13,7 @@
*/
#include
+#include
#include
#include "ddr.h"
@@ -26,9 +27,65 @@ extern void fsl_ddr_set_lawbar(
extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
unsigned int ctrl_num);
-/* Board-specific functions defined in each board's ddr.c */
-extern void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
- unsigned int ctrl_num);
+#if defined(SPD_EEPROM_ADDRESS) || \
+defined(SPD_EEPROM_ADDRESS1) || defined(SPD_EEPROM_ADDRESS2) || \
+defined(SPD_EEPROM_ADDRESS3) || defined(SPD_EEPROM_ADDRESS4)
+#if (CONFIG_NUM_DDR_CONTROLLERS == 1) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS,
+};
+#endif
+#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS1, /* controller 1 */
+ [1][0] = SPD_EEPROM_ADDRESS2, /* controller 2 */
+};
+#endif
+#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS1, /* controller 1 */
+ [0][1] = SPD_EEPROM_ADDRESS2, /* controller 1 */
+ [1][0] = SPD_EEPROM_ADDRESS3, /* controller 2 */
+ [1][1] = SPD_EEPROM_ADDRESS4, /* controller 2 */
+};
+#endif
+
+static void __get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
+{
+ int ret = i2c_read(i2c_address, 0, 1, (uchar *)spd,
+ sizeof(generic_spd_eeprom_t));
+
+ if (ret) {
+ debug("DDR: failed to read SPD from address %u\n", i2c_address);
+ memset(spd, 0, sizeof(generic_spd_eeprom_t));
+ }
+}
+
+__attribute__((weak, alias("__get_spd")))
+void get_spd(generic_spd_eeprom_t *spd, u8 i2c_address);
+
+void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
+ unsigned int ctrl_num)
+{
+ unsigned int i;
+ unsigned int i2c_address = 0;
+
+ if (ctrl_num) {
+ printf("%s unexpected ctrl_num = %u\n", __FUNCTION__, ctrl_num);
+ return;
+ }
+
+ for (i = 0; i < CONFIG_DIMM_SLOTS_PER_CTLR; i++) {
+ i2c_address = spd_i2c_addr[ctrl_num][i];
+ get_spd(&(ctrl_dimms_spd[i]), i2c_address);
+ }
+}
+#else
+void fsl_ddr_get_spd(generic_spd_
[U-Boot] [PATCH 1/2] powerpc/8xxx: Replace fsl_ddr_get_mem_data_rate with get_ddr_freq()
Every 85xx board implements fsl_ddr_get_mem_data_rate via get_ddr_freq()
and every 86xx board uses get_bus_freq(). If implement get_ddr_freq()
as a static inline to call get_bus_freq() we can remove
fsl_ddr_get_mem_data_rate altogether and just call get_ddr_freq()
directly.
Signed-off-by: Kumar Gala
---
arch/powerpc/cpu/mpc8xxx/ddr/util.c |6 ++
board/freescale/corenet_ds/ddr.c|5 -
board/freescale/mpc8536ds/ddr.c |5 -
board/freescale/mpc8540ads/ddr.c|8
board/freescale/mpc8541cds/ddr.c|5 -
board/freescale/mpc8544ds/ddr.c |5 -
board/freescale/mpc8548cds/ddr.c|5 -
board/freescale/mpc8555cds/ddr.c|5 -
board/freescale/mpc8560ads/ddr.c|8
board/freescale/mpc8568mds/ddr.c|6 --
board/freescale/mpc8569mds/ddr.c|6 --
board/freescale/mpc8572ds/ddr.c |5 -
board/freescale/mpc8610hpcd/ddr.c |5 -
board/freescale/mpc8641hpcn/ddr.c |7 +--
board/freescale/p1022ds/ddr.c |5 -
board/freescale/p2020ds/ddr.c |5 -
board/sbc8548/ddr.c |5 -
board/sbc8560/ddr.c |8
board/sbc8641d/ddr.c|5 -
board/socrates/ddr.c|5 -
board/stx/stxgp3/ddr.c |8
board/stx/stxssa/ddr.c |8
board/xes/xpedite517x/ddr.c |7 +--
board/xes/xpedite520x/ddr.c |5 -
board/xes/xpedite537x/ddr.c |5 -
board/xes/xpedite550x/ddr.c |5 -
include/common.h|4
27 files changed, 8 insertions(+), 148 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
index 1e2d921..815c5e3 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
@@ -11,8 +11,6 @@
#include "ddr.h"
-unsigned int fsl_ddr_get_mem_data_rate(void);
-
/*
* Round mclk_ps to nearest 10 ps in memory controller code.
*
@@ -24,7 +22,7 @@ unsigned int get_memory_clk_period_ps(void)
{
unsigned int mclk_ps;
- mclk_ps = 2ULL / fsl_ddr_get_mem_data_rate();
+ mclk_ps = 2ULL / get_ddr_freq(0);
/* round to nearest 10 ps */
return 10 * ((mclk_ps + 5) / 10);
}
@@ -40,7 +38,7 @@ unsigned int picos_to_mclk(unsigned int picos)
if (!picos)
return 0;
- clks = fsl_ddr_get_mem_data_rate() * (unsigned long long) picos;
+ clks = get_ddr_freq(0) * (unsigned long long) picos;
clks_temp = clks;
clks = clks / ULL_2e12;
if (clks_temp % ULL_2e12) {
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index fb53946..252c738 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -118,11 +118,6 @@ static void get_spd(ddr3_spd_eeprom_t *spd, unsigned char
i2c_address)
}
}
-unsigned int fsl_ddr_get_mem_data_rate(void)
-{
- return get_ddr_freq(0);
-}
-
void fsl_ddr_get_spd(ddr3_spd_eeprom_t *ctrl_dimms_spd,
unsigned int ctrl_num)
{
diff --git a/board/freescale/mpc8536ds/ddr.c b/board/freescale/mpc8536ds/ddr.c
index 2bad787..565e213 100644
--- a/board/freescale/mpc8536ds/ddr.c
+++ b/board/freescale/mpc8536ds/ddr.c
@@ -17,11 +17,6 @@ static void get_spd(ddr2_spd_eeprom_t *spd, unsigned char
i2c_address)
i2c_read(i2c_address, 0, 1, (uchar *)spd, sizeof(ddr2_spd_eeprom_t));
}
-unsigned int fsl_ddr_get_mem_data_rate(void)
-{
- return get_ddr_freq(0);
-}
-
void fsl_ddr_get_spd(ddr2_spd_eeprom_t *ctrl_dimms_spd,
unsigned int ctrl_num)
{
diff --git a/board/freescale/mpc8540ads/ddr.c b/board/freescale/mpc8540ads/ddr.c
index 93d1100..64a3ee1 100644
--- a/board/freescale/mpc8540ads/ddr.c
+++ b/board/freescale/mpc8540ads/ddr.c
@@ -18,14 +18,6 @@ get_spd(ddr1_spd_eeprom_t *spd, unsigned char i2c_address)
i2c_read(i2c_address, 0, 1, (uchar *)spd, sizeof(ddr1_spd_eeprom_t));
}
-
-unsigned int
-fsl_ddr_get_mem_data_rate(void)
-{
- return get_ddr_freq(0);
-}
-
-
void
fsl_ddr_get_spd(ddr1_spd_eeprom_t *ctrl_dimms_spd,
unsigned int ctrl_num)
diff --git a/board/freescale/mpc8541cds/ddr.c b/board/freescale/mpc8541cds/ddr.c
index c84a6cb..ce08af1 100644
--- a/board/freescale/mpc8541cds/ddr.c
+++ b/board/freescale/mpc8541cds/ddr.c
@@ -18,11 +18,6 @@ get_spd(ddr1_spd_eeprom_t *spd, unsigned char i2c_address)
i2c_read(i2c_address, 0, 1, (uchar *)spd, sizeof(ddr1_spd_eeprom_t));
}
-unsigned int fsl_ddr_get_mem_data_rate(void)
-{
- return get_ddr_freq(0);
-}
-
void fsl_ddr_get_spd(ddr1_spd_eeprom_t *ctrl_dimms_spd,
unsigned int ctrl_num)
{
diff --git a/board/freescale/mpc8544ds/ddr.c b/board/freescale/mpc8544ds/ddr.c
index b8330eb..87f0a22 100644
--- a/board/freescale/mpc8544ds/d
[U-Boot] [PATCH v2] powerpc/85xx: Remove config.mk for nand linker script
Move the include of mpc85xx/u-boot-nand.lds to utilize CONFIG_SYS_LDSCRIPT rather than having an explicit config.mk Signed-off-by: Kumar Gala --- * Use $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds so we should work in O= * Move CONFIG_SYS_LDSCRIPT for NAND to !CONFIG_NAND_SPL case board/freescale/mpc8536ds/config.mk | 30 -- board/freescale/mpc8569mds/config.mk | 30 -- board/freescale/mpc8572ds/config.mk | 30 -- board/freescale/p1_p2_rdb/config.mk | 31 --- include/configs/MPC8536DS.h |1 + include/configs/MPC8569MDS.h |1 + include/configs/MPC8572DS.h |1 + include/configs/P1_P2_RDB.h |1 + 8 files changed, 4 insertions(+), 121 deletions(-) delete mode 100644 board/freescale/mpc8536ds/config.mk delete mode 100644 board/freescale/mpc8569mds/config.mk delete mode 100644 board/freescale/mpc8572ds/config.mk delete mode 100644 board/freescale/p1_p2_rdb/config.mk diff --git a/board/freescale/mpc8536ds/config.mk b/board/freescale/mpc8536ds/config.mk deleted file mode 100644 index 228d8c0..000 --- a/board/freescale/mpc8536ds/config.mk +++ /dev/null @@ -1,30 +0,0 @@ -# -# Copyright 2008, 2011 Freescale Semiconductor. -# -# 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 -# - -# -# mpc8536ds board -# -ifndef NAND_SPL -ifeq ($(CONFIG_NAND), y) -LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds -endif -endif diff --git a/board/freescale/mpc8569mds/config.mk b/board/freescale/mpc8569mds/config.mk deleted file mode 100644 index 54b2eb1..000 --- a/board/freescale/mpc8569mds/config.mk +++ /dev/null @@ -1,30 +0,0 @@ -# -# Copyright (C) 2009 Freescale Semiconductor, Inc. -# -# 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 -# - -# -# mpc8569mds board -# -ifndef NAND_SPL -ifeq ($(CONFIG_NAND), y) -LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds -endif -endif diff --git a/board/freescale/mpc8572ds/config.mk b/board/freescale/mpc8572ds/config.mk deleted file mode 100644 index 9fd30f9..000 --- a/board/freescale/mpc8572ds/config.mk +++ /dev/null @@ -1,30 +0,0 @@ -# -# Copyright 2007-2008,2010-2011 Freescale Semiconductor, Inc. -# -# 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 -# - -# -# mpc8572ds board -# -ifndef NAND_SPL -ifeq ($(CONFIG_NAND), y) -LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds -endif -endif diff --git a/board/freescale/p1_p2_rdb/config.mk b/board/freescale/p1_p2_rdb/config.mk deleted file mode 100644 index 0769804..000 --- a/board/freescale/p1_p2_rdb/config.mk +++ /dev/null @@ -1,31 +0,0 @@ -# -# Copyright 2009, 2011 Freescale Semiconductor, Inc. -# -# See file CREDITS for list of people who contributed to this -# project. -# -# This
Re: [U-Boot] [PATCH] powerpc/85xx: Add some defines for P2040, P3041, P5010, P5020
On Jan 25, 2011, at 12:47 PM, Kumar Gala wrote: > Specify the number of DDR controllers, number of frame managers, number > of 1g and 10g ports. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/include/asm/config_mpc85xx.h | 15 +++ > 1 files changed, 15 insertions(+), 0 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Extend ethernet device tree stashing parameters for "fsl, etsec2"
On Jan 25, 2011, at 3:22 AM, Kumar Gala wrote: > From: Pankaj Chauhan > > In a manner similar to passing ethernet stashing parameters into device > tree for "gianfar", extend the support to the "fsl,etsec2" as well. > > Signed-off-by: Pankaj Chauhan > Signed-off-by: Sandeep Gopalpet > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/fdt.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: Declare fsl_ddr_set_memctl_regs in
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > Remove declerations of fsl_ddr_set_memctl_regs in board files with and > place it into a common header. > > Based on patch from Poonam Aggrwal. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/include/asm/fsl_ddr_sdram.h |2 ++ > board/freescale/corenet_ds/ddr.c |3 --- > board/freescale/p1_p2_rdb/ddr.c |3 --- > 3 files changed, 2 insertions(+), 6 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/85xx: Remove DATARATE_*_MHZ defines in static ddr init
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > Rather than having #defines DATARATE_*_MHZ, lets just match what we do on > the SPD code and convert the DDR frequency into MHZ and just compare > with a constant. > > Based on patch from Poonam Aggrwal. > > Signed-off-by: Kumar Gala > --- > board/freescale/corenet_ds/ddr.c | 14 -- > board/freescale/corenet_ds/p4080ds_ddr.c | 24 +--- > board/freescale/p1_p2_rdb/ddr.c | 25 +++-- > 3 files changed, 28 insertions(+), 35 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] poewrpc/85xx: Enable ECC on MPC8572DS
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > From: York Sun > > Using hwconfig to turn on/off ECC, without re-compiling. > > Signed-off-by: York Sun > Signed-off-by: Kumar Gala > --- > include/configs/MPC8572DS.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] powerpc/mpc85xx: implement workaround for errata DDR111 and DDR134
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > From: York Sun > > Workaround for the following errata: > DDR111 - MCKE signal may not function correctly at assertion of HRESET > DDR134 - The automatic CAS-to-Preamble feature of the DDR controller can > calibrate to incorrect values > > These two workarounds must be implemented together because they touch > common registers. > > Signed-off-by: York Sun > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/cmd_errata.c |4 + > arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 107 - > arch/powerpc/include/asm/config_mpc85xx.h |1 + > arch/powerpc/include/asm/fsl_ddr_sdram.h |5 ++ > 4 files changed, 116 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] powerpc/85xx: Rename MPC8572 DDR erratum to DDR115
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > From: York Sun > > Use unique erratum number instead of platform number. > Enable command that reports errata on MPC8572DS. > > Signed-off-by: York Sun > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/cmd_errata.c |4 +++- > arch/powerpc/cpu/mpc85xx/ddr-gen3.c |2 +- > arch/powerpc/include/asm/config_mpc85xx.h |1 + > 3 files changed, 5 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] powerpc/85xx: Remove unnecessary polling loop from DDR init
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > From: York Sun > > This polling loop is not required normally, unless specifically stated in > workaround. > > Signed-off-by: York Sun > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/ddr-gen3.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] powerpc/85xx: Enable Errata command on MPC8572DS
On Jan 26, 2011, at 12:22 AM, Kumar Gala wrote: > From: York Sun > > Also removed duplicate CONFIG_CMD_IRQ define. > > Signed-off-by: York Sun > Signed-off-by: Kumar Gala > --- > include/configs/MPC8572DS.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] fsl_esdhc: Add the workaround for erratum ESDHC-A001 (enable on P2020)
On Jan 29, 2011, at 5:20 PM, Kumar Gala wrote: > Data timeout counter (SYSCTL[DTOCV]) is not reliable for values of 4, 8, > and 12. Program one more than the desired value: 4 -> 5, 8 -> 9, 12 -> 13. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++ > arch/powerpc/include/asm/config_mpc85xx.h |2 ++ > drivers/mmc/fsl_esdhc.c |5 + > 3 files changed, 10 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/85xx: Enable ESDHC111 Erratum on P2010/P2020 SoCs
On Jan 29, 2011, at 5:20 PM, Kumar Gala wrote: > Signed-off-by: Kumar Gala > --- > arch/powerpc/include/asm/config_mpc85xx.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] powerpc/p1021: add more P1021 defines.
On Jan 31, 2011, at 5:36 PM, Timur Tabi wrote:
> On Mon, Jan 31, 2011 at 3:08 PM, Kumar Gala wrote:
>
>>> @@ -588,6 +588,9 @@ typedef struct qe_immap {
>>> #elif defined(CONFIG_MPC8569)
>>> u8 muram[0x2]; /* 0x1_ - 0x3_ Multi-user RAM */
>>> u8 res17[0x1]; /* 0x3_ - 0x4_ */
>>> +#elif defined(CONFIG_P1021)
>>> + u8 muram[0x06000]; /* 0x1_ - 0x1_6000 Multi-user RAM */
>>> + u8 res17[0x1a000]; /* 0x1_6000 - 0x3_ */
>>> #else
>>> u8 muram[0xC000]; /* 0x11 - 0x11C000 Multi-user RAM */
>>> u8 res17[0x24000]; /* 0x11C000 - 0x14 */
>>
>> Can we reduce this mess with using QE_MURAM_SIZE?
>>
>>u8 muram[QE_MURAM_SIZE];
>>u8 res17[0x - QE_MURAM_SIZE];
>
> I don't think we need res17, because nothing references it. That will
> simplify it even more.
Looks like qe_immap isn't embedded anywhere so should be ok (was concerned if
the struct is expected to be a given size.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Remove config.mk for nand linker script
On Jan 31, 2011, at 4:52 PM, Scott Wood wrote: > On Mon, 31 Jan 2011 16:37:44 -0600 > Kumar Gala wrote: > >> * fix where we define this, it should !CONFIG_NAND_SPL, read the old >> config.mk incorrectly. > > I don't think that will make a difference -- CONFIG_NAND_SPL is never > set when symbols are extracted into autoconf.mk, and > CONFIG_SYS_LDSCRIPT is not used when building the SPL. it seems to work out ok. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] Fix min/max macros in include/common.h
There is a bug in the min and max macros in common.h which occurs if
Y is a larger type than X. For example, if Y is a 64-bit value and X
is a 32-bit value then Y will be truncated to 32-bits. This fix
matches what is done in the Linux kernel but without the additional
type checking present in the kernel version.
Signed-off-by: Aaron Williams
include/common.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/common.h b/include/common.h
index d8c912d..cf5c076 100644
--- a/include/common.h
+++ b/include/common.h
@@ -180,11 +180,13 @@ typedef void (interrupt_handler_t)(void *);
* General Purpose Utilities
*/
#define min(X, Y) \
- ({ typeof (X) __x = (X), __y = (Y); \
+ ({ typeof (X) __x = (X);\
+ typeof (Y) __y = (Y); \
(__x < __y) ? __x : __y; })
#define max(X, Y) \
- ({ typeof (X) __x = (X), __y = (Y); \
+ ({ typeof (X) __x = (X);\
+ typeof (Y) __y = (Y); \
(__x > __y) ? __x : __y; })
#define MIN(x, y) min(x, y)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] [NAND] Add support for 4GiB and larger NAND
I'm still fighting with my mail tool, hopefully this will work.
This patch adds support for NAND flash 4GiB and larger. The changes in
the data structure match those found in the Linux kernel. Most of the
changes involve changing u32s to u64s.
-Aaron
Signed-off-by: Aaron Williams
common/cmd_mtdparts.c | 64 +++---
include/jffs2/load_kernel.h |6 ++--
3 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 5481c88..26d24b0 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -21,6 +21,11 @@
* $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
* Copyright 2002 SYSGO Real-Time Solutions GmbH
*
+ * (C) Copyright 2011
+ * Aaron Williams, Cavium Networks, Inc.
+ *
+ * Added support for partitions and flash greater than or equal to 4GiB.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -174,7 +179,7 @@ static int device_del(struct mtd_device *dev);
* @param retptr output pointer to next char after parse completes (output)
* @return resulting unsigned int
*/
-static unsigned long memsize_parse (const char *const ptr, const char
**retptr)
+static u64 memsize_parse (const char *const ptr, const char **retptr)
{
unsigned long ret = simple_strtoul(ptr, (char **)retptr, 0);
@@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const
ptr, const char **retptr)
* @param buf output buffer
* @param size size to be converted to string
*/
-static void memsize_format(char *buf, u32 size)
+static void memsize_format(char *buf, u64 size)
{
#define SIZE_GB ((u32)1024*1024*1024)
#define SIZE_MB ((u32)1024*1024)
#define SIZE_KB ((u32)1024)
if ((size % SIZE_GB) == 0)
- sprintf(buf, "%ug", size/SIZE_GB);
+ sprintf(buf, "%llug", size/SIZE_GB);
else if ((size % SIZE_MB) == 0)
- sprintf(buf, "%um", size/SIZE_MB);
+ sprintf(buf, "%llum", size/SIZE_MB);
else if (size % SIZE_KB == 0)
- sprintf(buf, "%uk", size/SIZE_KB);
+ sprintf(buf, "%lluk", size/SIZE_KB);
else
- sprintf(buf, "%u", size);
+ sprintf(buf, "%llu", size);
}
/**
@@ -325,7 +330,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
{
struct mtd_info *mtd = NULL;
int i, j;
- ulong start;
+ u64 start;
if (get_mtd_info(id->type, id->num, &mtd))
return 1;
@@ -337,7 +342,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
* Only one eraseregion (NAND, OneNAND or uniform NOR),
* checking for alignment is easy here
*/
- if ((unsigned long)part->offset % mtd->erasesize) {
+ if ((u64)part->offset % mtd->erasesize) {
printf("%s%d: partition (%s) start offset"
"alignment incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
@@ -412,7 +417,7 @@ static int part_validate(struct mtdids *id, struct
part_info *part)
part->size = id->size - part->offset;
if (part->offset > id->size) {
- printf("%s: offset %08x beyond flash size %08x\n",
+ printf("%s: offset %08llx beyond flash size %08llx\n",
id->mtd_id, part->offset, id->size);
return 1;
}
@@ -595,8 +600,8 @@ static int part_add(struct mtd_device *dev, struct
part_info *part)
static int part_parse(const char *const partdef, const char **ret, struct
part_info **retpart)
{
struct part_info *part;
- unsigned long size;
- unsigned long offset;
+ u64 size;
+ u64 offset;
const char *name;
int name_len;
unsigned int mask_flags;
@@ -615,7 +620,7 @@ static int part_parse(const char *const partdef, const
char **ret, struct part_i
} else {
size = memsize_parse(p, &p);
if (size < MIN_PART_SIZE) {
- printf("partition size too small (%lx)\n", size);
+ printf("partition size too small (%llx)\n", size);
return 1;
}
}
@@ -687,14 +692,14 @@ static int part_parse(const char *const partdef, const
char **ret, struct part_i
part->auto_name = 0;
} else {
/* auto generated name in form of size@offset */
- sprintf(part->name, "0x%08lx@0x%08lx", size, offset);
+ sprintf(part->name, "0x%08llx@0x%08llx", size, offset);
part->auto_name = 1;
}
part->name[name_len - 1] = '\0';
INIT_LIST_HEAD(&part->link);
- debug("+ partition: name %-22s size 0x%08x offset 0x%08x mask flags
%d\n",
+ debug("+ partit
[U-Boot] [PATCH 1/1] Add support for 4GiB and larger NAND
___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
On Mon, 2011-01-31 at 15:28 -0600, Kumar Gala wrote: > On Jan 31, 2011, at 2:50 PM, Haiying Wang wrote: > > > On Mon, 2011-01-31 at 21:11 +0100, Wolfgang Denk wrote: > >>> > >>> +#ifdef CONFIG_P1021 > >>> + ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); > >>> + > >>> + /* QE9 and QE12 need to be set for enabling QE MII managment signals */ > >>> + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE9); > >>> + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE12); > >>> +#endif > >> ... > >> > >> Can we please avoid having board specific code in common files? > > I wish I could, but only P1021 has such pin mux problems. > > > >> If this is really necessary, it shoud be a feature-specific #define, > >> not a board specific one. > > I don't know whether this *feature* will show up on other SoC. But if > > you insist, I can use CONFIG_QE_PIN_MUX. > > > > Thanks. > > > > Haiying > > I think pin muxing is a board level decision so it seems like board code is > the right place for it. > If it is a one time setting, there should be no problem to put it into board code. But these pin settings need to be done before any usage of phy read/write (accessing MDIO/MDC), and need to be released after the usage of phy, thus the devices connected to eLBC like NAND flash/BCSR can be accessed. If we use board code to set/release the pin, we don't know when the phy access and nand flash access will happen. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Trying again submitting the patch.
Adds support for NAND flash chips that are 4GiB and larger.
Signed-off-by: Aaron Williams
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 5481c88..26d24b0 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -21,6 +21,11 @@
* $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
* Copyright 2002 SYSGO Real-Time Solutions GmbH
*
+ * (C) Copyright 2011
+ * Aaron Williams, Cavium Networks, Inc.
+ *
+ * Added support for partitions and flash greater than or equal to 4GiB.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -174,7 +179,7 @@ static int device_del(struct mtd_device *dev);
* @param retptr output pointer to next char after parse completes (output)
* @return resulting unsigned int
*/
-static unsigned long memsize_parse (const char *const ptr, const char **retptr)
+static u64 memsize_parse (const char *const ptr, const char **retptr)
{
unsigned long ret = simple_strtoul(ptr, (char **)retptr, 0);
@@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const ptr, const char **retptr)
* @param buf output buffer
* @param size size to be converted to string
*/
-static void memsize_format(char *buf, u32 size)
+static void memsize_format(char *buf, u64 size)
{
#define SIZE_GB ((u32)1024*1024*1024)
#define SIZE_MB ((u32)1024*1024)
#define SIZE_KB ((u32)1024)
if ((size % SIZE_GB) == 0)
- sprintf(buf, "%ug", size/SIZE_GB);
+ sprintf(buf, "%llug", size/SIZE_GB);
else if ((size % SIZE_MB) == 0)
- sprintf(buf, "%um", size/SIZE_MB);
+ sprintf(buf, "%llum", size/SIZE_MB);
else if (size % SIZE_KB == 0)
- sprintf(buf, "%uk", size/SIZE_KB);
+ sprintf(buf, "%lluk", size/SIZE_KB);
else
- sprintf(buf, "%u", size);
+ sprintf(buf, "%llu", size);
}
/**
@@ -325,7 +330,7 @@ static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
{
struct mtd_info *mtd = NULL;
int i, j;
- ulong start;
+ u64 start;
if (get_mtd_info(id->type, id->num, &mtd))
return 1;
@@ -337,7 +342,7 @@ static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
* Only one eraseregion (NAND, OneNAND or uniform NOR),
* checking for alignment is easy here
*/
- if ((unsigned long)part->offset % mtd->erasesize) {
+ if ((u64)part->offset % mtd->erasesize) {
printf("%s%d: partition (%s) start offset"
"alignment incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
@@ -412,7 +417,7 @@ static int part_validate(struct mtdids *id, struct part_info *part)
part->size = id->size - part->offset;
if (part->offset > id->size) {
- printf("%s: offset %08x beyond flash size %08x\n",
+ printf("%s: offset %08llx beyond flash size %08llx\n",
id->mtd_id, part->offset, id->size);
return 1;
}
@@ -595,8 +600,8 @@ static int part_add(struct mtd_device *dev, struct part_info *part)
static int part_parse(const char *const partdef, const char **ret, struct part_info **retpart)
{
struct part_info *part;
- unsigned long size;
- unsigned long offset;
+ u64 size;
+ u64 offset;
const char *name;
int name_len;
unsigned int mask_flags;
@@ -615,7 +620,7 @@ static int part_parse(const char *const partdef, const char **ret, struct part_i
} else {
size = memsize_parse(p, &p);
if (size < MIN_PART_SIZE) {
- printf("partition size too small (%lx)\n", size);
+ printf("partition size too small (%llx)\n", size);
return 1;
}
}
@@ -687,14 +692,14 @@ static int part_parse(const char *const partdef, const char **ret, struct part_i
part->auto_name = 0;
} else {
/* auto generated name in form of size@offset */
- sprintf(part->name, "0x%08lx@0x%08lx", size, offset);
+ sprintf(part->name, "0x%08llx@0x%08llx", size, offset);
part->auto_name = 1;
}
part->name[name_len - 1] = '\0';
INIT_LIST_HEAD(&part->link);
- debug("+ partition: name %-22s size 0x%08x offset 0x%08x mask flags %d\n",
+ debug("+ partition: name %-22s size 0x%08llx offset 0x%08llx mask flags %d\n",
part->name, part->size,
part->offset, part->mask_flags);
@@ -710,7 +715,7 @@ static int part_parse(const char *const partdef, const char **ret, struct part_i
* @param size a pointer to the size of the mtd device (output)
* @return 0 if device is valid, 1 otherwise
*/
-int mtd_device_validate(u8 type, u8 num, u32 *size)
+int mtd_device_validate(u8 type, u8 num, u64 *size)
{
struct mtd_info *mtd = NULL;
@@ -842,7 +847,7 @@ static int device_parse(const char *const mtd_dev, const char **ret, struct mtd_
LIST_HEAD(tmp_list);
struct list_head *entry, *n;
u16 num_parts;
- u32 offset;
+ u64 offset;
int err = 1;
debug("===device_parse===\n");
@@ -1077,15 +1082,16 @@ int mtd_id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 *dev_num)
* @param buflen buffer size
* @return 0 on success, 1 otherwise
*/
-static int generate_mtdparts(char *buf, u32 buflen)
+static int gene
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
Hi Remy, Still waiting on some boards to try, unfortunately. I expect it will happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get to the bottom of it I will split the patches as requested. I have not seen reports from other users of U-Boot. Also working on USB host Ethernet. Regards, Simon On Mon, Jan 31, 2011 at 11:54 AM, Remy Bohmer wrote: > Hi, > > 2011/1/31 Remy Bohmer : > > Hi Simon, > > > > 2010/12/16 Simon Glass : > >> Hi Remy, > >> Thanks for the feedback. I will update the patch with your changes. > >> Unfortunately I don't have a lot of hardware to try, hence the list > post. I > >> will be doing some more testing in January so will come back to it then. > In > > > > Have you made any progress about this yet? > > FYI: I have stored this patch in my u-boot-usb testing branch after > rebasing to the current mainline. > > Kind regards, > > Remy > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] powerpc/p1021: add more P1021 defines.
On Mon, Jan 31, 2011 at 3:08 PM, Kumar Gala wrote:
>> @@ -588,6 +588,9 @@ typedef struct qe_immap {
>> #elif defined(CONFIG_MPC8569)
>> u8 muram[0x2]; /* 0x1_ - 0x3_ Multi-user RAM */
>> u8 res17[0x1]; /* 0x3_ - 0x4_ */
>> +#elif defined(CONFIG_P1021)
>> + u8 muram[0x06000]; /* 0x1_ - 0x1_6000 Multi-user RAM */
>> + u8 res17[0x1a000]; /* 0x1_6000 - 0x3_ */
>> #else
>> u8 muram[0xC000]; /* 0x11 - 0x11C000 Multi-user RAM */
>> u8 res17[0x24000]; /* 0x11C000 - 0x14 */
>
> Can we reduce this mess with using QE_MURAM_SIZE?
>
> u8 muram[QE_MURAM_SIZE];
> u8 res17[0x - QE_MURAM_SIZE];
I don't think we need res17, because nothing references it. That will
simplify it even more.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB
On Thu, 27 Jan 2011 17:43:10 -0800
Aaron Williams wrote:
> I have included my preliminary patch which seems to be working.
> It has not been extensively tested yet. All of the changes were basically
> making the sizes and offsets u64 instead of u32. When looking at the Linux
> kernel code it looks like they also use u64. I was mistaken and our NAND
> flash chip is 4GiB in size so I can't test with any larger chips.
>
> -Aaron
Patch is whitespace-mangled and does not apply.
Also needs sign-off and propper commit message. See
http://www.denx.de/wiki/U-Boot/Patches
and also the Developer's Certificate of Origin in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD
> @@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const
> ptr, const char **retptr)
> * @param buf output buffer
> * @param size size to be converted to string
> */
> -static void memsize_format(char *buf, u32 size)
> +static void memsize_format(char *buf, u64 size)
> {
> #define SIZE_GB ((u32)1024*1024*1024)
> #define SIZE_MB ((u32)1024*1024)
> #define SIZE_KB ((u32)1024)
>
> if ((size % SIZE_GB) == 0)
> - sprintf(buf, "%ug", size/SIZE_GB);
> + sprintf(buf, "%llug", size/SIZE_GB);
> else if ((size % SIZE_MB) == 0)
> - sprintf(buf, "%um", size/SIZE_MB);
> + sprintf(buf, "%llum", size/SIZE_MB);
> else if (size % SIZE_KB == 0)
> - sprintf(buf, "%uk", size/SIZE_KB);
> + sprintf(buf, "%lluk", size/SIZE_KB);
> else
> - sprintf(buf, "%u", size);
> + sprintf(buf, "%llu", size);
> }
>
Need to make sure there are no boards with MTD enabled but not
CONFIG_SYS_64BIT_VSPRINTF.
-Scot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB
This patch seems to be working fine in my setup. Any comments?
-Aaron
On Thursday, January 27, 2011 05:43:10 pm Aaron Williams wrote:
> I have included my preliminary patch which seems to be working.
> It has not been extensively tested yet. All of the changes were basically
> making the sizes and offsets u64 instead of u32. When looking at the Linux
> kernel code it looks like they also use u64. I was mistaken and our NAND
> flash chip is 4GiB in size so I can't test with any larger chips.
>
> -Aaron
>
> diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
> index 5481c88..26d24b0 100644
> --- a/common/cmd_mtdparts.c
> +++ b/common/cmd_mtdparts.c
> @@ -21,6 +21,11 @@
> * $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
> * Copyright 2002 SYSGO Real-Time Solutions GmbH
> *
> + * (C) Copyright 2011
> + * Aaron Williams, Cavium Networks, Inc.
> + *
> + * Added support for partitions and flash greater than or equal to 4GiB.
> + *
> * See file CREDITS for list of people who contributed to this
> * project.
> *
> @@ -174,7 +179,7 @@ static int device_del(struct mtd_device *dev);
> * @param retptr output pointer to next char after parse completes
> (output) * @return resulting unsigned int
> */
> -static unsigned long memsize_parse (const char *const ptr, const char
> **retptr) +static u64 memsize_parse (const char *const ptr, const char
> **retptr) {
> unsigned long ret = simple_strtoul(ptr, (char **)retptr, 0);
>
> @@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const
> ptr, const char **retptr) * @param buf output buffer
> * @param size size to be converted to string
> */
> -static void memsize_format(char *buf, u32 size)
> +static void memsize_format(char *buf, u64 size)
> {
> #define SIZE_GB ((u32)1024*1024*1024)
> #define SIZE_MB ((u32)1024*1024)
> #define SIZE_KB ((u32)1024)
>
> if ((size % SIZE_GB) == 0)
> - sprintf(buf, "%ug", size/SIZE_GB);
> + sprintf(buf, "%llug", size/SIZE_GB);
> else if ((size % SIZE_MB) == 0)
> - sprintf(buf, "%um", size/SIZE_MB);
> + sprintf(buf, "%llum", size/SIZE_MB);
> else if (size % SIZE_KB == 0)
> - sprintf(buf, "%uk", size/SIZE_KB);
> + sprintf(buf, "%lluk", size/SIZE_KB);
> else
> - sprintf(buf, "%u", size);
> + sprintf(buf, "%llu", size);
> }
>
> /**
> @@ -325,7 +330,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part) {
> struct mtd_info *mtd = NULL;
> int i, j;
> - ulong start;
> + u64 start;
>
> if (get_mtd_info(id->type, id->num, &mtd))
> return 1;
> @@ -337,7 +342,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part) * Only one eraseregion (NAND, OneNAND or uniform
> NOR), * checking for alignment is easy here
> */
> - if ((unsigned long)part->offset % mtd->erasesize) {
> + if ((u64)part->offset % mtd->erasesize) {
> printf("%s%d: partition (%s) start offset"
>"alignment incorrect\n",
>MTD_DEV_TYPE(id->type), id->num,
> part->name); @@ -412,7 +417,7 @@ static int part_validate(struct mtdids
> *id, struct part_info *part) part->size = id->size - part->offset;
>
> if (part->offset > id->size) {
> - printf("%s: offset %08x beyond flash size %08x\n",
> + printf("%s: offset %08llx beyond flash size %08llx\n",
> id->mtd_id, part->offset, id->size);
> return 1;
> }
> @@ -595,8 +600,8 @@ static int part_add(struct mtd_device *dev, struct
> part_info *part) static int part_parse(const char *const partdef, const
> char **ret, struct part_info **retpart) {
> struct part_info *part;
> - unsigned long size;
> - unsigned long offset;
> + u64 size;
> + u64 offset;
> const char *name;
> int name_len;
> unsigned int mask_flags;
> @@ -615,7 +620,7 @@ static int part_parse(const char *const partdef, const
> char **ret, struct part_i } else {
> size = memsize_parse(p, &p);
> if (size < MIN_PART_SIZE) {
> - printf("partition size too small (%lx)\n", size);
> + printf("partition size too small (%llx)\n", size);
> return 1;
> }
> }
> @@ -687,14 +692,14 @@ static int part_parse(const char *const partdef,
> const char **ret, struct part_i part->auto_name = 0;
> } else {
> /* auto generated name in form of size@offset */
> - sprintf(part->name, "0x%08lx@0x%08lx", size, offset);
> + sprintf(part->name, "0x%08llx@0x%08llx", size, offset);
> part->auto_name = 1;
> }
>
>
Re: [U-Boot] [PATCH 1/1] fix min/max macros in common.h
Any comments on this? This bug caused me a lot of troube.
-Aaron
On Tuesday, January 25, 2011 02:30:55 pm Aaron Williams wrote:
> In some of my work with the Cavium Octeon 64-bit processor I ran into a
> problem with the min and max macros provided in common.h. The problem
> occurs if x is 32-bit and y is 64-bit. In this case, y will always be
> truncated to 32-bits. This patch fixes this problem.
>
> -Aaron
>
> diff --git a/include/common.h b/include/common.h
> index d8c912d..cf5c076 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -180,11 +180,13 @@ typedef void (interrupt_handler_t)(void *);
> * General Purpose Utilities
> */
> #define min(X, Y) \
> - ({ typeof (X) __x = (X), __y = (Y); \
> + ({ typeof (X) __x = (X);\
> + typeof (Y) __y = (Y); \
> (__x < __y) ? __x : __y; })
>
> #define max(X, Y) \
> - ({ typeof (X) __x = (X), __y = (Y); \
> + ({ typeof (X) __x = (X);\
> + typeof (Y) __y = (Y); \
> (__x > __y) ? __x : __y; })
>
> #define MIN(x, y) min(x, y)
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
On Mon, 31 Jan 2011 23:40:41 +0100 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110131160713.0b78c...@udp111988uds.am.freescale.net> you wrote: > > > > Do you want the README changes to be a separate patch from the > > board/makefile changes? > > Did you not just explain that this would make no sense? I don't think so, though it makes sense to me that it should go with the makefile changes. But I'm trying to figure out precisely what you want done with this patchset, rather than what makes sense to me. I'll take that as a "squash it in with the board and makefile changes". -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Remove config.mk for nand linker script
On Mon, 31 Jan 2011 16:37:44 -0600 Kumar Gala wrote: > * fix where we define this, it should !CONFIG_NAND_SPL, read the old > config.mk incorrectly. I don't think that will make a difference -- CONFIG_NAND_SPL is never set when symbols are extracted into autoconf.mk, and CONFIG_SYS_LDSCRIPT is not used when building the SPL. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Dear Scott Wood, In message <20110131160713.0b78c...@udp111988uds.am.freescale.net> you wrote: > > Do you want the README changes to be a separate patch from the > board/makefile changes? Did you not just explain that this would make no sense? 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 Wright Bothers weren't the first to fly. They were just the first not to crash. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Remove config.mk for nand linker script
On Jan 31, 2011, at 4:15 PM, Kumar Gala wrote: > Move the include of mpc85xx/u-boot-nand.lds to utilize > CONFIG_SYS_LDSCRIPT rather than having an explicit config.mk > > Signed-off-by: Kumar Gala > --- > board/freescale/mpc8536ds/config.mk | 30 -- > board/freescale/mpc8569mds/config.mk | 30 -- > board/freescale/mpc8572ds/config.mk | 30 -- > board/freescale/p1_p2_rdb/config.mk | 31 --- > include/configs/MPC8536DS.h |1 + > include/configs/MPC8569MDS.h |1 + > include/configs/MPC8572DS.h |1 + > include/configs/P1_P2_RDB.h |1 + > 8 files changed, 4 insertions(+), 121 deletions(-) > delete mode 100644 board/freescale/mpc8536ds/config.mk > delete mode 100644 board/freescale/mpc8569mds/config.mk > delete mode 100644 board/freescale/mpc8572ds/config.mk > delete mode 100644 board/freescale/p1_p2_rdb/config.mk broken in two different ways, will fix both of them: * use of $(TOPDIR)/$(CPUDIR) * fix where we define this, it should !CONFIG_NAND_SPL, read the old config.mk incorrectly. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull u-boot-mpc85xx.git
Dear Kumar Gala, In message you wrote: > A bug fix, and I felt that Alex had published code well ahead of merge > window close that this was reasonable to go in (and new board so isn't > going to break anything). > > The following changes since commit 8aba9dceebb14144e07d19593111ee3a999c37fc: > > Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS (2011-01-25 > 22:22:30 +0100) > > are available in the git repository at: > git://git.denx.de/u-boot-mpc85xx master > > Alex Dubov (1): > mpq101: initial support for Mercury Computer Systems MPQ101 board > > York Sun (1): > p1022ds: fix pixis_reset altbank > > MAINTAINERS |4 + > board/mercury/mpq101/Makefile | 53 ++ > board/mercury/mpq101/law.c | 52 + > board/mercury/mpq101/mpq101.c | 129 + > board/mercury/mpq101/tlb.c | 82 > board/mercury/mpq101/u-boot.lds | 132 + > boards.cfg |1 + > include/configs/P1022DS.h |2 +- > include/configs/mpq101.h| 394 > +++ > 9 files changed, 848 insertions(+), 1 deletions(-) > create mode 100644 board/mercury/mpq101/Makefile > create mode 100644 board/mercury/mpq101/law.c > create mode 100644 board/mercury/mpq101/mpq101.c > create mode 100644 board/mercury/mpq101/tlb.c > create mode 100644 board/mercury/mpq101/u-boot.lds > create mode 100644 include/configs/mpq101.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The 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] Pull request: u-boot-i2c
Dear Heiko Schocher, In message <4d4112b1.70...@denx.de> you wrote: > Hello Wolfgang, > > please pull from u-boot-i2c.git. This should go in actual release, > as it is a bugfix. > > The following changes since commit 8aba9dceebb14144e07d19593111ee3a999c37fc: > > Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS (2011-01-25 > 22:22:30 +0100) > > are available in the git repository at: > git://git.denx.de/u-boot-i2c.git master > > Ryan Mallon (1): > Fix at91 includes in soft_i2c driver > > drivers/i2c/soft_i2c.c |4 +--- > 1 files changed, 1 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 "Ada is PL/I trying to be Smalltalk. - Codoso diBlini ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
Dear Kumar Gala,
In message you wrote:
>
> >>> +LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds
> >>> +endif
> >>> +endif
> >>> +endif
> >>
> >> Why is this config.mk needed? Can you not do all this in the board
> >> config file instead?
> > Do you mean the board header file or arch/powerpc/config.mk? I did not
> see any LDSCRIPT defined in Freescale board header file.
>
> I think something like:
>
> diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h
> index e6b60cf..f2d6cdb 100644
> --- a/include/configs/MPC8572DS.h
> +++ b/include/configs/MPC8572DS.h
> @@ -37,6 +37,7 @@
> #define CONFIG_NAND_U_BOOT
> #define CONFIG_RAMBOOT_NAND
> #ifdef CONFIG_NAND_SPL
> +#define CONFIG_SYS_LDSCRIPT "arch/powerpc/cpu/mpc85xx/u-boot-nand.lds"
This will eventually break with out of tree builds.
Rather use
#define CONFIG_SYS_LDSCRIPT $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds
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 a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Remove config.mk for nand linker script
Move the include of mpc85xx/u-boot-nand.lds to utilize CONFIG_SYS_LDSCRIPT rather than having an explicit config.mk Signed-off-by: Kumar Gala --- board/freescale/mpc8536ds/config.mk | 30 -- board/freescale/mpc8569mds/config.mk | 30 -- board/freescale/mpc8572ds/config.mk | 30 -- board/freescale/p1_p2_rdb/config.mk | 31 --- include/configs/MPC8536DS.h |1 + include/configs/MPC8569MDS.h |1 + include/configs/MPC8572DS.h |1 + include/configs/P1_P2_RDB.h |1 + 8 files changed, 4 insertions(+), 121 deletions(-) delete mode 100644 board/freescale/mpc8536ds/config.mk delete mode 100644 board/freescale/mpc8569mds/config.mk delete mode 100644 board/freescale/mpc8572ds/config.mk delete mode 100644 board/freescale/p1_p2_rdb/config.mk diff --git a/board/freescale/mpc8536ds/config.mk b/board/freescale/mpc8536ds/config.mk deleted file mode 100644 index 228d8c0..000 --- a/board/freescale/mpc8536ds/config.mk +++ /dev/null @@ -1,30 +0,0 @@ -# -# Copyright 2008, 2011 Freescale Semiconductor. -# -# 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 -# - -# -# mpc8536ds board -# -ifndef NAND_SPL -ifeq ($(CONFIG_NAND), y) -LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds -endif -endif diff --git a/board/freescale/mpc8569mds/config.mk b/board/freescale/mpc8569mds/config.mk deleted file mode 100644 index 54b2eb1..000 --- a/board/freescale/mpc8569mds/config.mk +++ /dev/null @@ -1,30 +0,0 @@ -# -# Copyright (C) 2009 Freescale Semiconductor, Inc. -# -# 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 -# - -# -# mpc8569mds board -# -ifndef NAND_SPL -ifeq ($(CONFIG_NAND), y) -LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds -endif -endif diff --git a/board/freescale/mpc8572ds/config.mk b/board/freescale/mpc8572ds/config.mk deleted file mode 100644 index 9fd30f9..000 --- a/board/freescale/mpc8572ds/config.mk +++ /dev/null @@ -1,30 +0,0 @@ -# -# Copyright 2007-2008,2010-2011 Freescale Semiconductor, Inc. -# -# 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 -# - -# -# mpc8572ds board -# -ifndef NAND_SPL -ifeq ($(CONFIG_NAND), y) -LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds -endif -endif diff --git a/board/freescale/p1_p2_rdb/config.mk b/board/freescale/p1_p2_rdb/config.mk deleted file mode 100644 index 0769804..000 --- a/board/freescale/p1_p2_rdb/config.mk +++ /dev/null @@ -1,31 +0,0 @@ -# -# Copyright 2009, 2011 Freescale Semiconductor, Inc. -# -# 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 -# pu
[U-Boot] [PATCH v2] powerpc: Move cpu specific lmb reserve to arch_lmb_reserve
We've been utilizing board_lmb_reserve to reserve the boot page for MP
systems. We can just move this into arch_lmb_reserve for 85xx & 86xx
systems rather than duplicating in each board port.
Signed-off-by: Kumar Gala
---
* Fix compiler warning for not including in bootm.c
arch/powerpc/lib/bootm.c |5 +
board/freescale/corenet_ds/corenet_ds.c | 11 +--
board/freescale/mpc8572ds/mpc8572ds.c | 11 +--
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 11 +--
board/freescale/p1022ds/p1022ds.c | 10 +-
board/freescale/p1_p2_rdb/p1_p2_rdb.c |9 -
board/freescale/p2020ds/p2020ds.c | 10 +-
board/sbc8641d/sbc8641d.c |9 -
board/xes/xpedite517x/xpedite517x.c |9 -
board/xes/xpedite537x/xpedite537x.c |9 -
board/xes/xpedite550x/xpedite550x.c |9 -
11 files changed, 10 insertions(+), 93 deletions(-)
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 116d81b..c7f3d08 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_OF_LIBFDT)
#include
@@ -166,6 +167,10 @@ void arch_lmb_reserve(struct lmb *lmb)
sp -= 4096;
lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + get_effective_memsize() -
sp));
+#ifdef CONFIG_MP
+ cpu_mp_lmb_reserve(lmb);
+#endif
+
return ;
}
diff --git a/board/freescale/corenet_ds/corenet_ds.c
b/board/freescale/corenet_ds/corenet_ds.c
index 232dc72..3db93c3 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009-2010 Freescale Semiconductor, Inc.
+ * Copyright 2009-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -39,8 +39,6 @@ extern void pci_of_setup(void *blob, bd_t *bd);
DECLARE_GLOBAL_DATA_PTR;
-void cpu_mp_lmb_reserve(struct lmb *lmb);
-
int checkboard (void)
{
u8 sw;
@@ -186,13 +184,6 @@ int misc_init_r(void)
return 0;
}
-#ifdef CONFIG_MP
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
-
void ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c
b/board/freescale/mpc8572ds/mpc8572ds.c
index 4b2ef4e..f444805 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007-2010 Freescale Semiconductor, Inc.
+ * Copyright 2007-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -259,12 +259,3 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
}
#endif
-
-#ifdef CONFIG_MP
-extern void cpu_mp_lmb_reserve(struct lmb *lmb);
-
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index 166ff0c..cd2ce4b 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2006, 2007, 2010 Freescale Semiconductor.
+ * Copyright 2006, 2007, 2010-2011 Freescale Semiconductor.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -261,12 +261,3 @@ void board_reset(void)
while (1)
;
}
-
-#ifdef CONFIG_MP
-extern void cpu_mp_lmb_reserve(struct lmb *lmb);
-
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/p1022ds/p1022ds.c
b/board/freescale/p1022ds/p1022ds.c
index 0ea0bdf..62beafa 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2010 Freescale Semiconductor, Inc.
+ * Copyright 2010-2011 Freescale Semiconductor, Inc.
* Authors: Srikanth Srinivasan
* Timur Tabi
*
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -302,10 +301,3 @@ void ft_board_setup(void *blob, bd_t *bd)
ft_codec_setup(blob, "wlf,wm8776");
}
#endif
-
-#ifdef CONFIG_MP
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
index 0780942..806d90e 100644
--- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
+++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
@@ -229,12 +229,3 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_memory(blob, (u64)base, (u64)size);
}
#endif
-
-#ifdef CONFIG_MP
-extern void cpu_mp_lmb_reserve(struct lmb *lmb);
-
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/p2020ds/p2020ds.c
b/board/freescale/p2020ds/p2020ds.c
i
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
Dear Haiying Wang,
In message <1296509955.2049.543.camel@haiying-laptop> you wrote:
>
> > Why is this config.mk needed? Can you not do all this in the board
> > config file instead?
> Do you mean the board header file or arch/powerpc/config.mk? I did not see
> any LDSCRIPT defined in Freescale board header file.
I mean the board config header file, include/configs/.h
> > > diff --git a/board/freescale/p1021mds/ddr.c
> > > b/board/freescale/p1021mds/ddr.c
> > > new file mode 100644
> > > index 000..594a4a8
> > > --- /dev/null
> > > +++ b/board/freescale/p1021mds/ddr.c
> >
> > It seems there are a number of functions here which ar actually shared
> > with other files, for example board/freescale/p1022ds/ddr.c.
> Every boards has its board specific ddr parameters which are defined the its
> own board ddr.c. The common code for ddr has been defined in
> arch/powerpc/cpu/mpc8xxx/ddr/.
Well, but there is tons of common code. For example, all of
board/freescale/corenet_ds/ddr.c
board/freescale/mpc8536ds/ddr.c
board/freescale/mpc8540ads/ddr.c
board/freescale/mpc8541cds/ddr.c
board/freescale/mpc8544ds/ddr.c
board/freescale/mpc8548cds/ddr.c
board/freescale/mpc8555cds/ddr.c
board/freescale/mpc8560ads/ddr.c
board/freescale/mpc8568mds/ddr.c
board/freescale/mpc8569mds/ddr.c
board/freescale/mpc8572ds/ddr.c
board/freescale/mpc8610hpcd/ddr.c
board/freescale/mpc8641hpcn/ddr.c
board/freescale/p1021mds/ddr.c
board/freescale/p1022ds/ddr.c
board/freescale/p2020ds/ddr.c
share the same function
unsigned int fsl_ddr_get_mem_data_rate(void)
{
return get_ddr_freq(0);
}
And
board/freescale/p1021mds/ddr.c
board/freescale/p1022ds/ddr.c
share (except for the comment) the same
void fsl_ddr_get_spd(ddr3_spd_eeprom_t *ctrl_dimms_spd, unsigned int
ctrl_num)
while
board/freescale/corenet_ds/ddr.c
board/freescale/mpc8569mds/ddr.c
use another variant, but again both boards the same one.
> If you go to see each ddr.c, you can find there is
> fsl_ddr_board_options() which defines the different values for each
> board. Also fsl_ddr_get_spd() is also highly dependent on board, like
> ddr type(ddr2 or ddr3), i2c spd eeprom address, ddr controller# etc.
Actually this is not quite true. See examples above.
> > > +void board_lmb_reserve(struct lmb *lmb)
> > > +{
> > > + cpu_mp_lmb_reserve(lmb);
> > > +}
> >
> > How many board/freescale//.c file share this same code?
> There are some, but I don't know whether there will be difference coming in
> later.
Then we can use a common implementation for all where it fits, and
use board specific code only where needed.
> > > diff --git a/board/freescale/p1021mds/tlb.c
> > > b/board/freescale/p1021mds/tlb.c
> > > new file mode 100644
> > > index 000..30af6dd
> > > --- /dev/null
> > > +++ b/board/freescale/p1021mds/tlb.c
> >
> > How much of this is actually different from - say -
> > board/freescale/p1022ds/tlb.c ?
> The tlb.c is also a highly board dependent file. Different boards have
> different supported peripherals. If you look at p1021 and p1022's tlb.c
> files, you can see p1022ds has 3 PCIE, P1021 has 2, P1022ds has NOR flash,
> P1021MDS only has NAND flash... etc
Yes, there are differences. But it seems there is more common code
than differing one?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A penny saved is a penny to squander.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
On Mon, 31 Jan 2011 22:34:34 +0100
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110131151506.700dd...@udp111988uds.am.freescale.net> you wrote:
> >
> > > For example, why must we add the Makefile changes in the first step,
> > > when all the code it references is still missing? Should this not be
> > > the last step?
> >
> > If you make it the last step, then the board will exist but not be
> > buildable in the previous step (unless you combine them, but you said
> > that's not what you're asking for). How is that better? And is this
> > really worth bickering about?
>
> Yes, this is better, and this is how we always do it: add the featurs,
> but not enable them unless we have all together, then add the needed
> #defines and make rules to actually use the code.
Those two "this"es don't match.
The latter is what we did do. We added TPL, but it wasn't enabled
until a board actually turns on CONFIG_HAS_TPL.
The former, what I was asking above if it was what you meant, would be
to have the board be added, enabling CONFIG_HAS_TPL because that's the
only way this board can be built, with a commit that is broken until
the subsequent commit adding TPL to the toplevel makefile is added. Or
to have the toplevel makefile changes squashed into the board patch.
It's not as if this is a make rule pointing at a specific file (with no
$(BOARDDIR)) that is absent.
> > Because it's not specific to 85xx or p1021mds. The generic
> > infrastructure for TPL consists of the makefile changes and
> > documentation. It seems useful to me to separate that for review, but
>
> A dead / broken make rule and dead documentation is what the generic
> infrastructure for TPL consists of?
What is broken about it?
Yes, the makefile change and documentation are what the generic
infrastructure for TPL consists of. Yes, it's inactive until a board
enables the feature ("when we have all together"), at which point the
board is required to provide tpl/board/$(BOARDDIR)/Makefile. Code
which is not board-specific is pulled from nand_spl and main U-Boot via
this board-specific makefile.
BTW, CONFIG_HAS_TPL is actually used in the toplevel makefile changes.
> > if you want it squashed into a board-specific patch instead, fine.
> > Just tell us what you want to see.
>
> I already did, but here we go:
No, you made some vague statements of general principle, of which your
interpretation apparently differs from mine. I was hoping for
specifics about this patch set.
> First, please do not add make rules before you have code they apply
> to.
So squash the makefile changes into the board patch?
Which seems to be how nand_spl got added a while back (patch title
"Add support for AMCC Sequoia PPC440EPx eval board"). Maybe the
makefile construct you recently objected to (possibly-empty variable
rule target) would have been more visible if it had been separated out. :-)
What about the division between the mpc85xx portion and the p1021mds
portion?
> After doing this, there is this rudimentary patch to the README.
> From a strictly technical point of view it should be split nto two
> parts: the first one (documenting the existing NAND_SPL variables) is
> independent of the TPL stuff and could be handles separately. The
> second part should be mergeed into the patch that first uses these
> variables. Note that I do not insist on splitting the README changes.
> It's OK with me to keep this together.
Yes, the NAND_SPL bits were lumped in there for convenience, and to
demonstrate the correspondence.
Do you want the README changes to be a separate patch from the
board/makefile changes?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
On Jan 31, 2011, at 3:39 PM, Haiying Wang wrote: > On Mon, 2011-01-31 at 21:03 +0100, Wolfgang Denk wrote: >> Dear haiying.w...@freescale.com, >>> diff --git a/board/freescale/p1021mds/config.mk >>> b/board/freescale/p1021mds/config.mk >>> new file mode 100644 >>> index 000..3888f61 >>> --- /dev/null >>> +++ b/board/freescale/p1021mds/config.mk >> ... >>> +ifndef NAND_SPL >>> +ifndef IN_TPL >>> +ifeq ($(CONFIG_NAND), y) >>> +LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds >>> +endif >>> +endif >>> +endif >> >> Why is this config.mk needed? Can you not do all this in the board >> config file instead? > Do you mean the board header file or arch/powerpc/config.mk? I did not see > any LDSCRIPT defined in Freescale board header file. I think something like: diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index e6b60cf..f2d6cdb 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -37,6 +37,7 @@ #define CONFIG_NAND_U_BOOT #define CONFIG_RAMBOOT_NAND #ifdef CONFIG_NAND_SPL +#define CONFIG_SYS_LDSCRIPT "arch/powerpc/cpu/mpc85xx/u-boot-nand.lds" #define CONFIG_SYS_TEXT_BASE_SPL 0xfff0 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE_SPL /* start of mon - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: Move cpu specific lmb reserve to arch_lmb_reserve
We've been utilizing board_lmb_reserve to reserve the boot page for MP
systems. We can just move this into arch_lmb_reserve for 85xx & 86xx
systems rather than duplicating in each board port.
Signed-off-by: Kumar Gala
---
arch/powerpc/lib/bootm.c |4
board/freescale/corenet_ds/corenet_ds.c | 11 +--
board/freescale/mpc8572ds/mpc8572ds.c | 11 +--
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 11 +--
board/freescale/p1022ds/p1022ds.c | 10 +-
board/freescale/p1_p2_rdb/p1_p2_rdb.c |9 -
board/freescale/p2020ds/p2020ds.c | 10 +-
board/sbc8641d/sbc8641d.c |9 -
board/xes/xpedite517x/xpedite517x.c |9 -
board/xes/xpedite537x/xpedite537x.c |9 -
board/xes/xpedite550x/xpedite550x.c |9 -
11 files changed, 9 insertions(+), 93 deletions(-)
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 116d81b..6472b83 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -166,6 +166,10 @@ void arch_lmb_reserve(struct lmb *lmb)
sp -= 4096;
lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + get_effective_memsize() -
sp));
+#ifdef CONFIG_MP
+ cpu_mp_lmb_reserve(lmb);
+#endif
+
return ;
}
diff --git a/board/freescale/corenet_ds/corenet_ds.c
b/board/freescale/corenet_ds/corenet_ds.c
index 232dc72..3db93c3 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009-2010 Freescale Semiconductor, Inc.
+ * Copyright 2009-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -39,8 +39,6 @@ extern void pci_of_setup(void *blob, bd_t *bd);
DECLARE_GLOBAL_DATA_PTR;
-void cpu_mp_lmb_reserve(struct lmb *lmb);
-
int checkboard (void)
{
u8 sw;
@@ -186,13 +184,6 @@ int misc_init_r(void)
return 0;
}
-#ifdef CONFIG_MP
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
-
void ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c
b/board/freescale/mpc8572ds/mpc8572ds.c
index 4b2ef4e..f444805 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007-2010 Freescale Semiconductor, Inc.
+ * Copyright 2007-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -259,12 +259,3 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
}
#endif
-
-#ifdef CONFIG_MP
-extern void cpu_mp_lmb_reserve(struct lmb *lmb);
-
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index 166ff0c..cd2ce4b 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2006, 2007, 2010 Freescale Semiconductor.
+ * Copyright 2006, 2007, 2010-2011 Freescale Semiconductor.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -261,12 +261,3 @@ void board_reset(void)
while (1)
;
}
-
-#ifdef CONFIG_MP
-extern void cpu_mp_lmb_reserve(struct lmb *lmb);
-
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/p1022ds/p1022ds.c
b/board/freescale/p1022ds/p1022ds.c
index 0ea0bdf..62beafa 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2010 Freescale Semiconductor, Inc.
+ * Copyright 2010-2011 Freescale Semiconductor, Inc.
* Authors: Srikanth Srinivasan
* Timur Tabi
*
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -302,10 +301,3 @@ void ft_board_setup(void *blob, bd_t *bd)
ft_codec_setup(blob, "wlf,wm8776");
}
#endif
-
-#ifdef CONFIG_MP
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
index 0780942..806d90e 100644
--- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
+++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
@@ -229,12 +229,3 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_memory(blob, (u64)base, (u64)size);
}
#endif
-
-#ifdef CONFIG_MP
-extern void cpu_mp_lmb_reserve(struct lmb *lmb);
-
-void board_lmb_reserve(struct lmb *lmb)
-{
- cpu_mp_lmb_reserve(lmb);
-}
-#endif
diff --git a/board/freescale/p2020ds/p2020ds.c
b/board/freescale/p2020ds/p2020ds.c
index 8546aa9..58c56e7 100644
--- a/board/freescale/p2020ds/p2020ds.c
+++ b/board/freescale/p2020ds/p2020ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007-2010 Freescale
Re: [U-Boot] Pull request: u-boot-video/master
Dear Anatolij Gustschin, In message <20110127003229.4a6f09ac@wker> you wrote: > Dear Wolfgang, > > The following changes since commit 8aba9dceebb14144e07d19593111ee3a999c37fc: > > Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS (2011-01-25 > 22:22:30 +0100) > > are available in the git repository at: > ssh://gu-vi...@git.denx.de/u-boot-video.git master > > Liu Ying (1): > lcd: align fb writing address for horizontal display offset > > common/lcd.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 It is much easier to suggest solutions when you know nothing ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
> It seems there are a number of functions here which ar actually shared
> with other files, for example board/freescale/p1022ds/ddr.c.
>
> I wonder if it is not possible to use more common code here - especially
> given the fact that we already have a nice collection of such files:
>
> board/freescale/corenet_ds/ddr.c
> board/freescale/mpc8536ds/ddr.c
> board/freescale/mpc8540ads/ddr.c
> board/freescale/mpc8541cds/ddr.c
> board/freescale/mpc8544ds/ddr.c
> board/freescale/mpc8548cds/ddr.c
> board/freescale/mpc8555cds/ddr.c
> board/freescale/mpc8560ads/ddr.c
> board/freescale/mpc8568mds/ddr.c
> board/freescale/mpc8569mds/ddr.c
> board/freescale/mpc8572ds/ddr.c
> board/freescale/mpc8610hpcd/ddr.c
> board/freescale/mpc8641hpcn/ddr.c
> board/freescale/p1022ds/ddr.c
> board/freescale/p1_p2_rdb/ddr.c
> board/freescale/p2020ds/ddr.c
We've already done that, the code in these files is board specific
params/tuning of DDR params.
>
>> diff --git a/board/freescale/p1021mds/p1021mds.c
>> b/board/freescale/p1021mds/p1021mds.c
>> new file mode 100644
>> index 000..c7a7e57
>> --- /dev/null
>> +++ b/board/freescale/p1021mds/p1021mds.c
> ...
>> +extern void cpu_mp_lmb_reserve(struct lmb *lmb);
We have this in already.
Will cleanup the other guys
> Please move prototypes to header file.
>
>> +void board_lmb_reserve(struct lmb *lmb)
>> +{
>> +cpu_mp_lmb_reserve(lmb);
>> +}
>
> How many board/freescale//.c file share this same code?
All of our multicore parts do this, we could move this into other places like
arch_lmb_reserve().
>> diff --git a/board/freescale/p1021mds/tlb.c b/board/freescale/p1021mds/tlb.c
>> new file mode 100644
>> index 000..30af6dd
>> --- /dev/null
>> +++ b/board/freescale/p1021mds/tlb.c
>
> How much of this is actually different from - say -
> board/freescale/p1022ds/tlb.c ?
Its mostly board specific.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
On Mon, 2011-01-31 at 21:03 +0100, Wolfgang Denk wrote:
> Dear haiying.w...@freescale.com,
> > diff --git a/board/freescale/p1021mds/config.mk
> > b/board/freescale/p1021mds/config.mk
> > new file mode 100644
> > index 000..3888f61
> > --- /dev/null
> > +++ b/board/freescale/p1021mds/config.mk
> ...
> > +ifndef NAND_SPL
> > +ifndef IN_TPL
> > +ifeq ($(CONFIG_NAND), y)
> > +LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds
> > +endif
> > +endif
> > +endif
>
> Why is this config.mk needed? Can you not do all this in the board
> config file instead?
Do you mean the board header file or arch/powerpc/config.mk? I did not see any
LDSCRIPT defined in Freescale board header file.
> > diff --git a/board/freescale/p1021mds/ddr.c b/board/freescale/p1021mds/ddr.c
> > new file mode 100644
> > index 000..594a4a8
> > --- /dev/null
> > +++ b/board/freescale/p1021mds/ddr.c
>
> It seems there are a number of functions here which ar actually shared
> with other files, for example board/freescale/p1022ds/ddr.c.
Every boards has its board specific ddr parameters which are defined the its
own board ddr.c. The common code for ddr has been defined in
arch/powerpc/cpu/mpc8xxx/ddr/.
> I wonder if it is not possible to use more common code here - especially
> given the fact that we already have a nice collection of such files:
>
> board/freescale/corenet_ds/ddr.c
> board/freescale/mpc8536ds/ddr.c
> board/freescale/mpc8540ads/ddr.c
> board/freescale/mpc8541cds/ddr.c
> board/freescale/mpc8544ds/ddr.c
> board/freescale/mpc8548cds/ddr.c
> board/freescale/mpc8555cds/ddr.c
> board/freescale/mpc8560ads/ddr.c
> board/freescale/mpc8568mds/ddr.c
> board/freescale/mpc8569mds/ddr.c
> board/freescale/mpc8572ds/ddr.c
> board/freescale/mpc8610hpcd/ddr.c
> board/freescale/mpc8641hpcn/ddr.c
> board/freescale/p1022ds/ddr.c
> board/freescale/p1_p2_rdb/ddr.c
> board/freescale/p2020ds/ddr.c
If you go to see each ddr.c, you can find there is
fsl_ddr_board_options() which defines the different values for each
board. Also fsl_ddr_get_spd() is also highly dependent on board, like
ddr type(ddr2 or ddr3), i2c spd eeprom address, ddr controller# etc.
Only fsl_ddr_get_mem_data_rate()might be moved to common code.
> > +void board_lmb_reserve(struct lmb *lmb)
> > +{
> > + cpu_mp_lmb_reserve(lmb);
> > +}
>
> How many board/freescale//.c file share this same code?
There are some, but I don't know whether there will be difference coming in
later.
>
> > diff --git a/board/freescale/p1021mds/tlb.c b/board/freescale/p1021mds/tlb.c
> > new file mode 100644
> > index 000..30af6dd
> > --- /dev/null
> > +++ b/board/freescale/p1021mds/tlb.c
>
> How much of this is actually different from - say -
> board/freescale/p1022ds/tlb.c ?
The tlb.c is also a highly board dependent file. Different boards have
different supported peripherals. If you look at p1021 and p1022's tlb.c files,
you can see p1022ds has 3 PCIE, P1021 has 2, P1022ds has NOR flash, P1021MDS
only has NAND flash... etc.
Haiying
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
Dear Haiying Wang, In message <1296507737.2049.518.camel@haiying-laptop> you wrote: > On Mon, 2011-01-31 at 21:08 +0100, Wolfgang Denk wrote: > > Dear haiying.w...@freescale.com, > > > > In message <1296499317-26616-6-git-send-email-haiying.w...@freescale.com> > > you wrote: > > > From: Haiying Wang > > > > > > For some board which doesn't have NOR flash and the QE's firmware(ucode) > > > is > > > saved in its NAND flash, we don't want call qe_init in cpu_init_r, but > > > will > > > call it later after nand is initialized. > > > > Is there a pressing reason to do this so early for other boards? Can > > not all boards initialize this later? > > > My understanding is that QE is a cpu feature, so it is called early in > cpu_init_r. As Kumar recommended before, I can move qe_init from > cpu_init_r to misc_init_r for every 85xx boards with qe support. Is it > acceptable to you? Yes, if this way we can avoid to do the same thing at different points in the initialization sequence. 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 Save yourself! Reboot in 5 seconds! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Dear Scott Wood, In message <20110131151506.700dd...@udp111988uds.am.freescale.net> you wrote: > > > For example, why must we add the Makefile changes in the first step, > > when all the code it references is still missing? Should this not be > > the last step? > > If you make it the last step, then the board will exist but not be > buildable in the previous step (unless you combine them, but you said > that's not what you're asking for). How is that better? And is this > really worth bickering about? Yes, this is better, and this is how we always do it: add the featurs, but not enable them unless we have all together, then add the needed #defines and make rules to actually use the code. > Please just say, clearly and specifically, what you want the patchset > to look like... > > > And what is the benefit of adding documentation to the README here? > > To me it makes more sense to add this when CONFIG_HAS_TPL and > > CONFIG_IN_TPL get used first. > > Because it's not specific to 85xx or p1021mds. The generic > infrastructure for TPL consists of the makefile changes and > documentation. It seems useful to me to separate that for review, but A dead / broken make rule and dead documentation is what the generic infrastructure for TPL consists of? > if you want it squashed into a board-specific patch instead, fine. > Just tell us what you want to see. I already did, but here we go: First, please do not add make rules before you have code they apply to. After doing this, there is this rudimentary patch to the README. >From a strictly technical point of view it should be split nto two parts: the first one (documenting the existing NAND_SPL variables) is independent of the TPL stuff and could be handles separately. The second part should be mergeed into the patch that first uses these variables. Note that I do not insist on splitting the README changes. It's OK with me to keep this together. 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 6/6] p1021mds: add QE and UEC support
On Jan 31, 2011, at 2:50 PM, Haiying Wang wrote: > On Mon, 2011-01-31 at 21:11 +0100, Wolfgang Denk wrote: >>> >>> +#ifdef CONFIG_P1021 >>> + ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); >>> + >>> + /* QE9 and QE12 need to be set for enabling QE MII managment signals */ >>> + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE9); >>> + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE12); >>> +#endif >> ... >> >> Can we please avoid having board specific code in common files? > I wish I could, but only P1021 has such pin mux problems. > >> If this is really necessary, it shoud be a feature-specific #define, >> not a board specific one. > I don't know whether this *feature* will show up on other SoC. But if > you insist, I can use CONFIG_QE_PIN_MUX. > > Thanks. > > Haiying I think pin muxing is a board level decision so it seems like board code is the right place for it. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
On Mon, 31 Jan 2011 21:50:57 +0100 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110131143141.2959d...@udp111988uds.am.freescale.net> you wrote: > > > > I'm confused. You say "of course not all together", but the first one > > you say to include with the second, and the second you say to include > > with the third. > > I did not say this. "WHy not add the tpl target when you actually add the tpl code?" "Then this is where that file belongs to." > > Has your aversion to "dead" code grown so strong it can't exist even in > > a transitory state between members of a patchset, even when necessary > > to avoid mixing users of a facility with the facility itself in the > > same patch? I think that would do significant harm to reviewability. > > Calm down, and re-read what I wrote. I am calm, albeit confused and a bit frustrated. I did re-read it and I'm still not sure exactly what you want. > For example, why must we add the Makefile changes in the first step, > when all the code it references is still missing? Should this not be > the last step? If you make it the last step, then the board will exist but not be buildable in the previous step (unless you combine them, but you said that's not what you're asking for). How is that better? And is this really worth bickering about? Please just say, clearly and specifically, what you want the patchset to look like... > And what is the benefit of adding documentation to the README here? > To me it makes more sense to add this when CONFIG_HAS_TPL and > CONFIG_IN_TPL get used first. Because it's not specific to 85xx or p1021mds. The generic infrastructure for TPL consists of the makefile changes and documentation. It seems useful to me to separate that for review, but if you want it squashed into a board-specific patch instead, fine. Just tell us what you want to see. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] powerpc/p1021: add more P1021 defines.
On Jan 31, 2011, at 12:41 PM,
wrote:
> From: Haiying Wang
>
> Signed-off-by: Haiying Wang
> ---
> arch/powerpc/include/asm/immap_85xx.h |6 ++
> arch/powerpc/include/asm/immap_qe.h |9 +++--
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/immap_85xx.h
> b/arch/powerpc/include/asm/immap_85xx.h
> index 6bd83ba..77e3629 100644
> --- a/arch/powerpc/include/asm/immap_85xx.h
> +++ b/arch/powerpc/include/asm/immap_85xx.h
> @@ -1948,6 +1948,12 @@ typedef struct ccsr_gur {
> u8 res10b[76];
> par_io_t qe_par_io[7];
> u8 res10c[1600];
> +#elif defined(CONFIG_P1021)
> + u8 res10b1[12];
> + u32 iovselsr;
> + u8 res10b2[60];
> + par_io_t qe_par_io[3];
> + u8 res10c[1496];
> #else
> u8 res10b[1868];
> #endif
> diff --git a/arch/powerpc/include/asm/immap_qe.h
> b/arch/powerpc/include/asm/immap_qe.h
> index 531cfc8..0fffba2 100644
> --- a/arch/powerpc/include/asm/immap_qe.h
> +++ b/arch/powerpc/include/asm/immap_qe.h
> @@ -3,7 +3,7 @@
> * The Internal Memory Map for devices with QE on them. This
> * is the superset of all QE devices (8360, etc.).
> *
> - * Copyright (c) 2006-2009 Freescale Semiconductor, Inc.
> + * Copyright (c) 2006-2011 Freescale Semiconductor, Inc.
> * Author: Shlomi Gridih
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -588,6 +588,9 @@ typedef struct qe_immap {
> #elif defined(CONFIG_MPC8569)
> u8 muram[0x2]; /* 0x1_ - 0x3_ Multi-user RAM */
> u8 res17[0x1]; /* 0x3_ - 0x4_ */
> +#elif defined(CONFIG_P1021)
> + u8 muram[0x06000]; /* 0x1_ - 0x1_6000 Multi-user RAM */
> + u8 res17[0x1a000]; /* 0x1_6000 - 0x3_ */
> #else
> u8 muram[0xC000]; /* 0x11 - 0x11C000 Multi-user RAM */
> u8 res17[0x24000]; /* 0x11C000 - 0x14 */
Can we reduce this mess with using QE_MURAM_SIZE?
u8 muram[QE_MURAM_SIZE];
u8 res17[0x - QE_MURAM_SIZE];
> @@ -601,13 +604,15 @@ extern qe_map_t *qe_immr;
> #define QE_MURAM_SIZE 0x1UL
> #elif defined(CONFIG_MPC8569)
> #define QE_MURAM_SIZE 0x2UL
> +#elif defined(CONFIG_P1021)
> +#define QE_MURAM_SIZE 0x6000UL
> #elif defined(CONFIG_MPC8360)
> #define QE_MURAM_SIZE 0xc000UL
> #elif defined(CONFIG_MPC832x)
> #define QE_MURAM_SIZE 0x4000UL
> #endif
>
> -#if defined(CONFIG_MPC8323)
> +#if defined(CONFIG_MPC8323) || defined(CONFIG_P1021)
> #define MAX_QE_RISC 1
> #define QE_NUM_OF_SNUM28
> #elif defined(CONFIG_MPC8569)
We can move some of these into include/config_mpc85xx.h
> --
> 1.7.3.1.50.g1e633
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
On Mon, 2011-01-31 at 21:08 +0100, Wolfgang Denk wrote: > Dear haiying.w...@freescale.com, > > In message <1296499317-26616-6-git-send-email-haiying.w...@freescale.com> you > wrote: > > From: Haiying Wang > > > > For some board which doesn't have NOR flash and the QE's firmware(ucode) is > > saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will > > call it later after nand is initialized. > > Is there a pressing reason to do this so early for other boards? Can > not all boards initialize this later? > My understanding is that QE is a cpu feature, so it is called early in cpu_init_r. As Kumar recommended before, I can move qe_init from cpu_init_r to misc_init_r for every 85xx boards with qe support. Is it acceptable to you? Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] help for u-bbot on altera ep2s60-sdr board
Hi all, where could I find informations about to configure u-boot for altera ep2s60-sdr board? I saw that there is a board gr_ep2s60 but I suppose it is for altera ep2s60- ddr. Any suggestion will be appreciated. Regards -- Ing. Fabio Giovagnini Aurion s.r.l. P.I e C.F. 00885711200 skype: aurion.giovagnini Tel. +39.051.594.78.24 Fax. +39.051.082.14.49 Cell. +39.335.83.50.919 www.aurion-tech.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Dear Kumar Gala, In message you wrote: > ... > I'm in agreement with Scott on this. I believe we've taken this a bit > too far about "dead code". It should be reasonable in a patch series to > have code that will be used in a subsequent patch. Yes, but you should not enable it or add it to Makefiles before it's even there. 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 go slow, be gentle. It's no one-way street -- you know how you feel and that's all. It's how the girl feels too. Don't press. If the girl feels anything for you at all, you'll know. -- Kirk, "Charlie X", stardate 1535.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Dear Scott Wood, In message <20110131143141.2959d...@udp111988uds.am.freescale.net> you wrote: > > I'm confused. You say "of course not all together", but the first one > you say to include with the second, and the second you say to include > with the third. I did not say this. > If you're suggesting keeping them mostly separate, but just moving some > bits into the subsequent patch, that makes no sense to me. They > logically belong where they are -- e.g. Come on. Read what I wrote. > Has your aversion to "dead" code grown so strong it can't exist even in > a transitory state between members of a patchset, even when necessary > to avoid mixing users of a facility with the facility itself in the > same patch? I think that would do significant harm to reviewability. Calm down, and re-read what I wrote. For example, why must we add the Makefile changes in the first step, when all the code it references is still missing? Should this not be the last step? And what is the benefit of adding documentation to the README here? To me it makes more sense to add this when CONFIG_HAS_TPL and CONFIG_IN_TPL get used first. 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 Plans break down. You cannot plan the future. Only presumptuous fools plan. The wise man _steers_.- Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
On Mon, 2011-01-31 at 21:11 +0100, Wolfgang Denk wrote: > > > > +#ifdef CONFIG_P1021 > > + ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); > > + > > + /* QE9 and QE12 need to be set for enabling QE MII managment signals */ > > + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE9); > > + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE12); > > +#endif > ... > > Can we please avoid having board specific code in common files? I wish I could, but only P1021 has such pin mux problems. > If this is really necessary, it shoud be a feature-specific #define, > not a board specific one. I don't know whether this *feature* will show up on other SoC. But if you insist, I can use CONFIG_QE_PIN_MUX. Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
On Jan 31, 2011, at 2:31 PM, Scott Wood wrote: > On Mon, 31 Jan 2011 21:22:04 +0100 > Wolfgang Denk wrote: > >> Dear Scott Wood, >> >> In message <20110131141332.5a4a2...@udp111988uds.am.freescale.net> you wrote: >>> I think these patches are incorrectly split. >>> >>> I think the intent was to split the arch-neutral stuff from the 85xx >>> stuff from the board stuff -- you'd rather they be all bunched together? >> >> No, of course not all together. >> This patch adds stuff to the Makefile, which would result in errors if used, as the referenced directories don't exist yet. >>> >>> Lots of patches add features, disabled by default, that require CPU or >>> board code to provide things, that would cause errors if the feature >>> were enabled on a board otherwise. >> >> But here nothing is disabled. It's added to the top level Makefile. >> It's dead code if unused, and causes errors if used. WHy not add the >> tpl target when you actually add the tpl code? >> >>> I don't think it's even possible to add an empty directory with git. >> >> True. Butt that would not fix anythign, it would still not work. >> [PATCH 2/6] powerpc/85xx: add TPL support This patch creates unused files, like arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds >>> >>> It gets used in later in the patchset, when a board with tpl is added. >> >> Then this is where that file belongs to. > > I'm confused. You say "of course not all together", but the first one > you say to include with the second, and the second you say to include > with the third. > > If you're suggesting keeping them mostly separate, but just moving some > bits into the subsequent patch, that makes no sense to me. They > logically belong where they are -- e.g. > arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds is part of 85xx TPL support, it > is not p1021mds-specific. And every bit of the first two patches is > technically dead until a board is added that uses it. > > Has your aversion to "dead" code grown so strong it can't exist even in > a transitory state between members of a patchset, even when necessary > to avoid mixing users of a facility with the facility itself in the > same patch? I think that would do significant harm to reviewability. > > -Scott I'm in agreement with Scott on this. I believe we've taken this a bit too far about "dead code". It should be reasonable in a patch series to have code that will be used in a subsequent patch. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
On Mon, 31 Jan 2011 21:22:04 +0100 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110131141332.5a4a2...@udp111988uds.am.freescale.net> you wrote: > > > > > I think these patches are incorrectly split. > > > > I think the intent was to split the arch-neutral stuff from the 85xx > > stuff from the board stuff -- you'd rather they be all bunched together? > > No, of course not all together. > > > > This patch adds stuff to the Makefile, which would result in > > > errors if used, as the referenced directories don't exist yet. > > > > Lots of patches add features, disabled by default, that require CPU or > > board code to provide things, that would cause errors if the feature > > were enabled on a board otherwise. > > But here nothing is disabled. It's added to the top level Makefile. > It's dead code if unused, and causes errors if used. WHy not add the > tpl target when you actually add the tpl code? > > > I don't think it's even possible to add an empty directory with git. > > True. Butt that would not fix anythign, it would still not work. > > > > [PATCH 2/6] powerpc/85xx: add TPL support > > > > > > This patch creates unused files, like > > > arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds > > > > It gets used in later in the patchset, when a board with tpl is added. > > Then this is where that file belongs to. I'm confused. You say "of course not all together", but the first one you say to include with the second, and the second you say to include with the third. If you're suggesting keeping them mostly separate, but just moving some bits into the subsequent patch, that makes no sense to me. They logically belong where they are -- e.g. arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds is part of 85xx TPL support, it is not p1021mds-specific. And every bit of the first two patches is technically dead until a board is added that uses it. Has your aversion to "dead" code grown so strong it can't exist even in a transitory state between members of a patchset, even when necessary to avoid mixing users of a facility with the facility itself in the same patch? I think that would do significant harm to reviewability. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
Dear Haiying Wang, In message <1296504850.2049.434.camel@haiying-laptop> you wrote: > > > If you introduce a new LDFLAGS_FINAL instead, then why do we have to > > keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of > > the U-Boot image? > LDFLAGS_FINAL does not provide the whole set of linker options to U-Boot > image, so it does not replace the LDFLAGS_u-boot, in patch: I have problems to understan the intentions behind all these many different linker flag settings, nd this while we are discussing it. In two weeks from now I will understand none of this any more. Either this can be made simpler. If you are sure this is not possible, then we need some detailed documentation of all this, at least in the README, but eventually as a separate doc/README.* > > > LDFLAGS += $(PLATFORM_LDFLAGS) > > > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS) > > > > > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) > > > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) > > > > Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here? > Yes. it LDFLAGS_FINAL here includes "-Bstatic $(PLATFORM_LDFLAGS)". No. Pleasse see 5 lines above: it is "-Bstatic $(LDFLAGS)". > > Are you sure that this change is correct for all affected boards? > Can not 100% sure because I can not test all the affected boards. Yes, you can. Run MAKEALL for all ppc boards and compare the System.map and u-boot.map files before and after your change. This is still no guarantee to cover 100% of the potential issues, but as close as we can get with reasonable effort. > > How has this change been tested? > I only can test powerpc by MAKEALL. > > > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) > > > $(LDFLAGS_FINAL) > > > > Arghhh... Here you introduce yet another setting, LDFLAGS_spl ? > This is an intentional name change. LDFLAGS_spl is used here as > LDFLAGS_u-boot, but for nand spl linkage. Actually it is not a new FLAGS, > just add *_spl* here so that it can be differed from the LDFlAGS in toplevel > config.mk. > > > This is not mentioned in the commit message. And why do we need it? > > Isn't LDFLAGS_FINAL enough? > As said, it is not a new flag, just a name change. Anyway. It was not mentioned in the commit message, and not explained anywhere else. We _really_ need to thoroughly document all this stuff or soon nobody will understand nothing of this anymore. > > Will I soon see patches to also add LDFLAGS_tpl? > Yes, in patch 3/6. :-( 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 cannot propel yourself forward by patting yourself on the back. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
On Mon, 31 Jan 2011 21:18:35 +0100 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110131140801.33609...@udp111988uds.am.freescale.net> you wrote: > > > > > Please rather omit the setting instead of using fillers that are of no > > > practical value. > > > > Well, they do make it easier for a user to quickly see what the names > > are that U-Boot expects for such commonly used things, rather than > > having to scan the manual. > > I doubt both the "quicly see" part (in such a long list of settings) > and the "rather than having to scan the manual" part. I've found it convenient, along with the more meaningful error messages if I forget to replace one of them. YMMV. > > > > + "ramdiskfile=your.ramdisk.u-boot\0" > > > > \ > > > > > > Ditto. [BTW: why "ramdisk.u-boot"? U-Boot does not use ramdisks. > > > The ramdisk is only used for some OS, so that should probably be > > > "...ramdisk.linux" instead?] > > > > We often use the ".u-boot" suffix on ramdisks that have been wrapped > > with a uImage header. > > That would be a "uRamdisk" then (similar to uImage). Is anyone actually calling it that? What if I have multiple ramdisk images that I want to call different names? FWIW, for non-Linux OS images we sometimes use .uImage as a suffix. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Dear Scott Wood, In message <20110131141332.5a4a2...@udp111988uds.am.freescale.net> you wrote: > > > I think these patches are incorrectly split. > > I think the intent was to split the arch-neutral stuff from the 85xx > stuff from the board stuff -- you'd rather they be all bunched together? No, of course not all together. > > This patch adds stuff to the Makefile, which would result in > > errors if used, as the referenced directories don't exist yet. > > Lots of patches add features, disabled by default, that require CPU or > board code to provide things, that would cause errors if the feature > were enabled on a board otherwise. But here nothing is disabled. It's added to the top level Makefile. It's dead code if unused, and causes errors if used. WHy not add the tpl target when you actually add the tpl code? > I don't think it's even possible to add an empty directory with git. True. Butt that would not fix anythign, it would still not work. > > [PATCH 2/6] powerpc/85xx: add TPL support > > > > This patch creates unused files, like > > arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds > > It gets used in later in the patchset, when a board with tpl is added. Then this is where that file belongs to. 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 Eureka! -- Archimedes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
Dear Scott Wood, In message <20110131140801.33609...@udp111988uds.am.freescale.net> you wrote: > > > Please rather omit the setting instead of using fillers that are of no > > practical value. > > Well, they do make it easier for a user to quickly see what the names > are that U-Boot expects for such commonly used things, rather than > having to scan the manual. I doubt both the "quicly see" part (in such a long list of settings) and the "rather than having to scan the manual" part. > > > + "ramdiskfile=your.ramdisk.u-boot\0" \ > > > > Ditto. [BTW: why "ramdisk.u-boot"? U-Boot does not use ramdisks. > > The ramdisk is only used for some OS, so that should probably be > > "...ramdisk.linux" instead?] > > We often use the ".u-boot" suffix on ramdisks that have been wrapped > with a uImage header. That would be a "uRamdisk" then (similar to uImage). 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 usually takes more than three weeks to prepare a good impromptu speech. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Mon, 2011-01-31 at 20:33 +0100, Wolfgang Denk wrote: > If I understand the intention of the LDFLAGS_u-boot setting > corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting. No, I don't want to add a LDFLAGS_nand_spl for nand_spl only, I need LDFLAGS_FINAL to be passed to nand spl, tpl, and final uboot images. > If you introduce a new LDFLAGS_FINAL instead, then why do we have to > keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of > the U-Boot image? LDFLAGS_FINAL does not provide the whole set of linker options to U-Boot image, so it does not replace the LDFLAGS_u-boot, in patch: -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) > [Btw: "final" is probably not a technically correct term for all the > use cases I see below.] did not think of any better term. > ... > > diff --git a/config.mk b/config.mk > > index 5147c35..caa6221 100644 > > --- a/config.mk > > +++ b/config.mk > > @@ -205,8 +205,9 @@ endif > > AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) > > > > LDFLAGS += $(PLATFORM_LDFLAGS) > > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS) > > > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) > > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) > > Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here? Yes. it LDFLAGS_FINAL here includes "-Bstatic $(PLATFORM_LDFLAGS)". > Are you sure that this change is correct for all affected boards? Can not 100% sure because I can not test all the affected boards. > How has this change been tested? I only can test powerpc by MAKEALL. > > > -LDFLAGS= -Bstatic -T $(nandobj)u-boot.lds -Ttext > > $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS) > > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) > > $(LDFLAGS_FINAL) > > > Arghhh... Here you introduce yet another setting, LDFLAGS_spl ? This is an intentional name change. LDFLAGS_spl is used here as LDFLAGS_u-boot, but for nand spl linkage. Actually it is not a new FLAGS, just add *_spl* here so that it can be differed from the LDFlAGS in toplevel config.mk. > This is not mentioned in the commit message. And why do we need it? > Isn't LDFLAGS_FINAL enough? As said, it is not a new flag, just a name change. > > Will I soon see patches to also add LDFLAGS_tpl? Yes, in patch 3/6. > > This is becoming a mess. We need to find a simple, clean way to solve > this. I'm on the verge of reverting the LDFLAGS_u-boot commit. We just want to make sure gc-sections works for all the uboot images. :) Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
On Mon, 31 Jan 2011 20:39:51 +0100 Wolfgang Denk wrote: > Dear haiying.w...@freescale.com, > > In message <1296499317-26616-1-git-send-email-haiying.w...@freescale.com> you > wrote: > > This patchset adds support for TPL(Tertiary Program Loader) and P1021MDS > > board. > > It is a rework of patchset at > > http://lists.denx.de/pipermail/u-boot/2010-December/082881.html, > > addresses the comments from the list and is based on the top of the tree. > > It needs to be applied after patch > > http://lists.denx.de/pipermail/u-boot/2011-January/086346.html and patch > > http://lists.denx.de/pipermail/u-boot/2011-January/086524.html > > I think these patches are incorrectly split. I think the intent was to split the arch-neutral stuff from the 85xx stuff from the board stuff -- you'd rather they be all bunched together? > [PATCH 1/6] Introduce the Tertiary Program loader > > This patch adds stuff to the Makefile, which would result in > errors if used, as the referenced directories don't exist yet. Lots of patches add features, disabled by default, that require CPU or board code to provide things, that would cause errors if the feature were enabled on a board otherwise. I don't think it's even possible to add an empty directory with git. > [PATCH 2/6] powerpc/85xx: add TPL support > > This patch creates unused files, like > arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds It gets used in later in the patchset, when a board with tpl is added. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
Dear haiying.w...@freescale.com,
In message <1296499317-26616-7-git-send-email-haiying.w...@freescale.com> you
wrote:
> From: Haiying Wang
>
> P1021 has some QE pins which need to be set in pmuxcr register before using QE
> functions. In this patch, pin QE0 and QE3 are set for UCC1 and UCC5 in Eth
> mode.
> QE9 and QE12 are set for MII management. QE12 needs to be released after MII
> access because QE12 pin is muxed with LBCTL signal.
>
> P1021MDS has to load the microcode from NAND flash, this patch defines
> misc_init_r() for loading ucode and initializing qe.
...
> diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
> index 282ab23..04d7987 100644
> --- a/drivers/qe/uec.c
> +++ b/drivers/qe/uec.c
...
> +#ifdef CONFIG_P1021
> +#define BCSR11_ENET_MICRST 0x20
> +#endif
>
> /* Default UTBIPAR SMI address */
> #ifndef CONFIG_UTBIPAR_INIT_TBIPA
> @@ -588,9 +591,25 @@ static void phy_change(struct eth_device *dev)
> {
> uec_private_t *uec = (uec_private_t *)dev->priv;
>
> +#ifdef CONFIG_P1021
> + ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> +
> + /* QE9 and QE12 need to be set for enabling QE MII managment signals */
> + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE9);
> + setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE12);
> +#endif
...
Can we please avoid having board specific code in common files?
If this is really necessary, it shoud be a feature-specific #define,
not a board specific one.
> @@ -425,6 +469,8 @@
> #define CONFIG_PCI_PNP /* do pci plug-and-play */
> #endif
>
> +#define CONFIG_E1000
In which way is this change related to this 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
It is better to marry than to burn.
- Bible ``I Corinthians'' ch. 7, v. 9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
Dear haiying.w...@freescale.com, In message <1296499317-26616-6-git-send-email-haiying.w...@freescale.com> you wrote: > From: Haiying Wang > > For some board which doesn't have NOR flash and the QE's firmware(ucode) is > saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will > call it later after nand is initialized. Is there a pressing reason to do this so early for other boards? Can not all boards initialize this later? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "I didn't know it was impossible when I did it." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
On Mon, 31 Jan 2011 21:03:17 +0100 Wolfgang Denk wrote: > > +/* > > + * Environment Configuration > > + */ > > +#define CONFIG_HOSTNAMEp1021mds > > +#define CONFIG_ROOTPATH/nfsroot > > +#define CONFIG_BOOTFILEyour.uImage > > Please rather omit the setting instead of using fillers that are of no > practical value. Well, they do make it easier for a user to quickly see what the names are that U-Boot expects for such commonly used things, rather than having to scan the manual. > > +#define CONFIG_LOADADDR100 /*default location for tftp and > > bootm*/ > > + > > +#define CONFIG_BOOTDELAY 10 /* -1 disables auto-boot */ > > +#undef CONFIG_BOOTARGS /* the boot command will set bootargs*/ > > + > > +#defineCONFIG_EXTRA_ENV_SETTINGS > > \ > > + "netdev=eth0\0" \ > > + "consoledev=ttyS0\0"\ > > + "ramdiskaddr=200\0" \ > > + "ramdiskfile=your.ramdisk.u-boot\0" \ > > Ditto. [BTW: why "ramdisk.u-boot"? U-Boot does not use ramdisks. > The ramdisk is only used for some OS, so that should probably be > "...ramdisk.linux" instead?] We often use the ".u-boot" suffix on ramdisks that have been wrapped with a uImage header. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] powerpc/p1021: add more P1021 defines.
Dear haiying.w...@freescale.com,
In message <1296499317-26616-5-git-send-email-haiying.w...@freescale.com> you
wrote:
> From: Haiying Wang
>
> Signed-off-by: Haiying Wang
> ---
> arch/powerpc/include/asm/immap_85xx.h |6 ++
> arch/powerpc/include/asm/immap_qe.h |9 +++--
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/immap_85xx.h
> b/arch/powerpc/include/asm/immap_85xx.h
> index 6bd83ba..77e3629 100644
> --- a/arch/powerpc/include/asm/immap_85xx.h
> +++ b/arch/powerpc/include/asm/immap_85xx.h
> @@ -1948,6 +1948,12 @@ typedef struct ccsr_gur {
> u8 res10b[76];
> par_io_t qe_par_io[7];
> u8 res10c[1600];
> +#elif defined(CONFIG_P1021)
> + u8 res10b1[12];
> + u32 iovselsr;
> + u8 res10b2[60];
> + par_io_t qe_par_io[3];
> + u8 res10c[1496];
> #else
res10b1? Two levels of insertions already. Isn't it time to renumber
the reserved fields?
> @@ -601,13 +604,15 @@ extern qe_map_t *qe_immr;
> #define QE_MURAM_SIZE0x1UL
> #elif defined(CONFIG_MPC8569)
> #define QE_MURAM_SIZE0x2UL
> +#elif defined(CONFIG_P1021)
> +#define QE_MURAM_SIZE 0x6000UL
> #elif defined(CONFIG_MPC8360)
> #define QE_MURAM_SIZE0xc000UL
> #elif defined(CONFIG_MPC832x)
> #define QE_MURAM_SIZE0x4000UL
> #endif
Can you please keep the "if defined(..)" list sorted? Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If you want strict real-time behavior, run in the real time schedu-
ling class. But there are no seatbelts or airbags; main(){for(;;);}
can hard hang your system. -- Bart Smaalders
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
Dear haiying.w...@freescale.com,
In message <1296499317-26616-4-git-send-email-haiying.w...@freescale.com> you
wrote:
> From: Haiying Wang
>
> Support P1021MDS board to boot from NAND flash (No NOR flash on this
> board). And because P1021 only has 256K L2 SRAM, which can not used for final
> uboot image, this patch also enables the TPL BOOT on P1021MDS so that DDR can
> be initialized in L2 SRAM through SPD code. So there are three stage uboot
> images:
> * nand_spl, pad from 4KB size to 16KB, load tpl_boot from offset 16KB in NAND.
> * tpl_boot, 112KB size. The env variables are copied to offset 128KB
> in L2 SRAM, so that ddr spd code can get the interleaving mode setting in
> env.
> It loads final uboot image from offset 128KB in NAND.
> * final uboot image, size is variable depends on the functions enabled.
> diff --git a/board/freescale/p1021mds/config.mk
> b/board/freescale/p1021mds/config.mk
> new file mode 100644
> index 000..3888f61
> --- /dev/null
> +++ b/board/freescale/p1021mds/config.mk
...
> +ifndef NAND_SPL
> +ifndef IN_TPL
> +ifeq ($(CONFIG_NAND), y)
> +LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds
> +endif
> +endif
> +endif
Why is this config.mk needed? Can you not do all this in the board
config file instead?
> diff --git a/board/freescale/p1021mds/ddr.c b/board/freescale/p1021mds/ddr.c
> new file mode 100644
> index 000..594a4a8
> --- /dev/null
> +++ b/board/freescale/p1021mds/ddr.c
It seems there are a number of functions here which ar actually shared
with other files, for example board/freescale/p1022ds/ddr.c.
I wonder if it is not possible to use more common code here - especially
given the fact that we already have a nice collection of such files:
board/freescale/corenet_ds/ddr.c
board/freescale/mpc8536ds/ddr.c
board/freescale/mpc8540ads/ddr.c
board/freescale/mpc8541cds/ddr.c
board/freescale/mpc8544ds/ddr.c
board/freescale/mpc8548cds/ddr.c
board/freescale/mpc8555cds/ddr.c
board/freescale/mpc8560ads/ddr.c
board/freescale/mpc8568mds/ddr.c
board/freescale/mpc8569mds/ddr.c
board/freescale/mpc8572ds/ddr.c
board/freescale/mpc8610hpcd/ddr.c
board/freescale/mpc8641hpcn/ddr.c
board/freescale/p1022ds/ddr.c
board/freescale/p1_p2_rdb/ddr.c
board/freescale/p2020ds/ddr.c
> diff --git a/board/freescale/p1021mds/p1021mds.c
> b/board/freescale/p1021mds/p1021mds.c
> new file mode 100644
> index 000..c7a7e57
> --- /dev/null
> +++ b/board/freescale/p1021mds/p1021mds.c
...
> +extern void cpu_mp_lmb_reserve(struct lmb *lmb);
Please move prototypes to header file.
> +void board_lmb_reserve(struct lmb *lmb)
> +{
> + cpu_mp_lmb_reserve(lmb);
> +}
How many board/freescale//.c file share this same code?
> diff --git a/board/freescale/p1021mds/tlb.c b/board/freescale/p1021mds/tlb.c
> new file mode 100644
> index 000..30af6dd
> --- /dev/null
> +++ b/board/freescale/p1021mds/tlb.c
How much of this is actually different from - say -
board/freescale/p1022ds/tlb.c ?
...
> +/*
> + * Environment Configuration
> + */
> +#define CONFIG_HOSTNAME p1021mds
> +#define CONFIG_ROOTPATH /nfsroot
> +#define CONFIG_BOOTFILE your.uImage
Please rather omit the setting instead of using fillers that are of no
practical value.
> +#define CONFIG_LOADADDR 100 /*default location for tftp and
> bootm*/
> +
> +#define CONFIG_BOOTDELAY 10 /* -1 disables auto-boot */
> +#undef CONFIG_BOOTARGS /* the boot command will set bootargs*/
> +
> +#define CONFIG_EXTRA_ENV_SETTINGS
> \
> + "netdev=eth0\0" \
> + "consoledev=ttyS0\0"\
> + "ramdiskaddr=200\0" \
> + "ramdiskfile=your.ramdisk.u-boot\0" \
Ditto. [BTW: why "ramdisk.u-boot"? U-Boot does not use ramdisks.
The ramdisk is only used for some OS, so that should probably be
"...ramdisk.linux" instead?]
> + "fdtaddr=c0\0" \
> + "fdtfile=your.fdt.dtb\0"\
Ditto. [Are "fdt" and "dtb" not redundant?]
> diff --git a/tpl/board/freescale/p1021mds/tpl_boot.c
> b/tpl/board/freescale/p1021mds/tpl_boot.c
> new file mode 100644
> index 000..386d76c
> --- /dev/null
> +++ b/tpl/board/freescale/p1021mds/tpl_boot.c
...
> +extern void nand_load(unsigned int offs, int uboot_size, uchar *dst);
> +extern phys_size_t init_ddr_dram(void);
Please move prototypes to header files.
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 bug is indisting
[U-Boot] [PATCH] mvgbe: enable the reception of packets with an odd number of preamble nibbles
With the current hardware initialisation of the driver all packets with an odd number of preamble nibbles are dropped. Some switches seem to send all packets with such an preamble. According to the functional specifications of the marvell 88F6180, 6190, 6192 and 6281 the reception of such packets can be enabled by setting bit 22 in register PSC1. Signed-off-by: Klaus Flittner --- drivers/net/mvgbe.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c index c701f43..f1081a2 100644 --- a/drivers/net/mvgbe.c +++ b/drivers/net/mvgbe.c @@ -446,6 +446,9 @@ static int mvgbe_init(struct eth_device *dev) MVGBE_REG_WR(regs->psc0, MVGBE_MAX_RX_PACKET_9700BYTE | (MVGBE_REG_RD(regs->psc0) & MRU_MASK)); + /* Receive packets with odd number of preamble nibbles */ + MVGBE_REG_BITS_SET(regs->psc1, 1 << 22); + /* Enable port initially */ MVGBE_REG_BITS_SET(regs->psc0, MVGBE_SERIAL_PORT_EN); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Mon, 31 Jan 2011 20:33:09 +0100 Wolfgang Denk wrote: > Dear haiying.w...@freescale.com, > > In message <1296498767-26408-1-git-send-email-haiying.w...@freescale.com> you > wrote: > > From: Haiying Wang > > > > commit 8aba9dceebb14144e07d19593111ee3a999c37fc > > Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS > > > > breaks the usage of --gc-section to build nand_spl. We still need linker > > option > > --gc-section for every uboot image, not only the main one. LDFLAGS_FINAL > > passes > > the --gc-sections to each uboot image. > > If I understand the intention of the LDFLAGS_u-boot setting > corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting. > > If you introduce a new LDFLAGS_FINAL instead, then why do we have to > keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of > the U-Boot image? > > [Btw: "final" is probably not a technically correct term for all the > use cases I see below.] I meant final as compared to partial links, not anything to do with spl versus tpl versus the main image. Do you have a better wording? > > diff --git a/config.mk b/config.mk > > index 5147c35..caa6221 100644 > > --- a/config.mk > > +++ b/config.mk > > @@ -205,8 +205,9 @@ endif > > AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) > > > > LDFLAGS += $(PLATFORM_LDFLAGS) > > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS) > > > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) > > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) > > Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here? > > Are you sure that this change is correct for all affected boards? > > How has this change been tested? As I understand it, it has only been limited to PLATFORM_LDFLAGS since the LDFLAGS_u-boot commit. Was that change intentional, and widely tested? > > -LDFLAGS= -Bstatic -T $(nandobj)u-boot.lds -Ttext > > $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS) > > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) > > $(LDFLAGS_FINAL) > > > Arghhh... Here you introduce yet another setting, LDFLAGS_spl ? > > This is not mentioned in the commit message. And why do we need it? > Isn't LDFLAGS_FINAL enough? No, it's not enough. The whole point is to separate options which should apply to all final (non-partial) links, versus options which are specific to a particular image. This is the point where we add in the options that are specific to the spl image. With :=, we could preserve the LDFLAGS name, but it seemed better to avoid muddying up what LDFLAGS means, if it's now supposed to mean options that are used in partial linking -- and it makes things look more consistent with what's done in the main image. Or we could not use a variable for this and stick it on the ld command line, but is that really an improvement? > Will I soon see patches to also add LDFLAGS_tpl? Of course. :-) > This is becoming a mess. We need to find a simple, clean way to solve > this. I'm on the verge of reverting the LDFLAGS_u-boot commit. What's the alternative solution, when we have some options that need to be set during partial link, others which cannot be set during partial link but must be set during final link, and a couple more (text address and linker script) which are specific to the individual image? I think introducing the additional variables makes things less messy, because it means each variable has a specific, unambiguous purpose. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
Hi, 2011/1/31 Remy Bohmer : > Hi Simon, > > 2010/12/16 Simon Glass : >> Hi Remy, >> Thanks for the feedback. I will update the patch with your changes. >> Unfortunately I don't have a lot of hardware to try, hence the list post. I >> will be doing some more testing in January so will come back to it then. In > > Have you made any progress about this yet? FYI: I have stored this patch in my u-boot-usb testing branch after rebasing to the current mainline. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Dear haiying.w...@freescale.com, In message <1296499317-26616-1-git-send-email-haiying.w...@freescale.com> you wrote: > This patchset adds support for TPL(Tertiary Program Loader) and P1021MDS > board. > It is a rework of patchset at > http://lists.denx.de/pipermail/u-boot/2010-December/082881.html, > addresses the comments from the list and is based on the top of the tree. > It needs to be applied after patch > http://lists.denx.de/pipermail/u-boot/2011-January/086346.html and patch > http://lists.denx.de/pipermail/u-boot/2011-January/086524.html I think these patches are incorrectly split. [PATCH 1/6] Introduce the Tertiary Program loader This patch adds stuff to the Makefile, which would result in errors if used, as the referenced directories don't exist yet. [PATCH 2/6] powerpc/85xx: add TPL support This patch creates unused files, like arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds This makes no sense to me. 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 Misquotation is, in fact, the pride and privilege of the learned. A widely-read man never quotes accurately, for the rather obvious reason that he has read too widely. - Hesketh Pearson _Common Misquotations_ introduction ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
Dear haiying.w...@freescale.com, In message <1296498767-26408-1-git-send-email-haiying.w...@freescale.com> you wrote: > From: Haiying Wang > > commit 8aba9dceebb14144e07d19593111ee3a999c37fc > Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS > > breaks the usage of --gc-section to build nand_spl. We still need linker > option > --gc-section for every uboot image, not only the main one. LDFLAGS_FINAL > passes > the --gc-sections to each uboot image. If I understand the intention of the LDFLAGS_u-boot setting corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting. If you introduce a new LDFLAGS_FINAL instead, then why do we have to keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of the U-Boot image? [Btw: "final" is probably not a technically correct term for all the use cases I see below.] ... > diff --git a/config.mk b/config.mk > index 5147c35..caa6221 100644 > --- a/config.mk > +++ b/config.mk > @@ -205,8 +205,9 @@ endif > AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) > > LDFLAGS += $(PLATFORM_LDFLAGS) > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS) > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here? Are you sure that this change is correct for all affected boards? How has this change been tested? > -LDFLAGS = -Bstatic -T $(nandobj)u-boot.lds -Ttext > $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS) > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) > $(LDFLAGS_FINAL) Arghhh... Here you introduce yet another setting, LDFLAGS_spl ? This is not mentioned in the commit message. And why do we need it? Isn't LDFLAGS_FINAL enough? Will I soon see patches to also add LDFLAGS_tpl? This is becoming a mess. We need to find a simple, clean way to solve this. I'm on the verge of reverting the LDFLAGS_u-boot 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 Contrary to popular belief, thinking does not cause brain damage. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand commands missing wtchdog reset
On Mon, 31 Jan 2011 13:16:59 -0600 Scott Wood wrote: > On Mon, 31 Jan 2011 09:05:55 +0100 > Jaap de Jong wrote: > > > Hi all, > > On my board (at91sam9263ek) I have enabled the watchdog. > > It will reset the processor after about 16 seconds. > > It looks like it is working but if I'm writing a large file into nand it > > seems that the watchdog is not reset and finally my processor resets. > > I've patched it, but I'm not sure if it is the right way to do it this > > way... > > So far we've been putting the watchdog resets in higher-level > functions. It looks like the block-skipping versions have them, but > the non-block-skipping versions don't (and the former will call the > latter if it doesn't see any bad blocks). > > So I think this should go in nand_read() and nand_write(). If things > hang up inside the low-level wait that should trigger the watchdog. Oh, and all patches require a sign-off, and the text above the patch should be what is intended to go in the git changelog, with any additional comments/greetings/etc below a "---" line. See http://www.denx.de/wiki/U-Boot/Patches and also the Developer's Certificate of Origin in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] update/fix AcTux1 board
Am 01/31/2011 08:01 PM, schrieb Scott Wood: >> >> I got out everything except the LDSCRIPT definition. However, I can't >> find a way to specify a board-specific linker script (which I need due >> to the embedded environment) without using config.mk in the board >> directory, since the platform sets up a non-board default in >> arch/arm/config.mk. >> >> How about a >> #define CONFIG_BOARD_LDSCRIPT >> that is picked up by autoconf.mk and used in the Makefiles if set? > PowerPC uses CONFIG_SYS_LDSCRIPT for this. Thanks, found it - I had only searched non-architecture Makefiles. I can copy that mechanism to ARM. cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
Hi Simon, 2010/12/16 Simon Glass : > Hi Remy, > Thanks for the feedback. I will update the patch with your changes. > Unfortunately I don't have a lot of hardware to try, hence the list post. I > will be doing some more testing in January so will come back to it then. In Have you made any progress about this yet? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT PROBLEM] RAM loading RAMdisk addresses
Dear "GRACE, ERWAN (ERWAN)** CTR **", In message you wrote: > > My name is Erwan Grâce, I'm French. Here's my issue : I had loaded the Fl > ash memory of an electronic card with 2 RAMdisk which are supposed to be th > e same. However, when I checked the messages displayed on a screen at boot > time, I observed that there were some differences between the 2 RAMdisk : Please restrict your line length to some 70 characters or so. Thanks. > As you can notice, the 2 RAMdisk seem to be different but I don't know why. The are obviously different, as they have different sizes. We cannot answer the "why" as we have zero information about what you did on that system, or why you even think they should be the same. These are two different files. 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 "Intelligence without character is a dangerous thing." - G. Steinem ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query: Which u-boot version supports PPC476FP?
Dear prakash bedge, In message you wrote: > > Could anyone tell which version of u-boot supports PPC476FP processor? The only ones I am aware of are the out-of-tree ports which you can find on LSI's web site. No patches have been submitted for mainline inclusion yet. 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 Q: Why do mountain climbers rope themselves together? A: To prevent the sensible ones from going home. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand commands missing wtchdog reset
On Mon, 31 Jan 2011 09:05:55 +0100 Jaap de Jong wrote: > Hi all, > On my board (at91sam9263ek) I have enabled the watchdog. > It will reset the processor after about 16 seconds. > It looks like it is working but if I'm writing a large file into nand it > seems that the watchdog is not reset and finally my processor resets. > I've patched it, but I'm not sure if it is the right way to do it this > way... So far we've been putting the watchdog resets in higher-level functions. It looks like the block-skipping versions have them, but the non-block-skipping versions don't (and the former will call the latter if it doesn't see any bad blocks). So I think this should go in nand_read() and nand_write(). If things hang up inside the low-level wait that should trigger the watchdog. > diff -urN a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > --- a/drivers/mtd/nand/nand_base.c2010-12-22 20:22:14.0 +0100 > +++ b/drivers/mtd/nand/nand_base.c2011-01-31 08:45:07.818135600 +0100 > @@ -447,6 +447,7 @@ > if (chip->dev_ready) > if (chip->dev_ready(mtd)) > break; > +WATCHDOG_RESET (); > } > } > > @@ -730,6 +731,7 @@ > if (this->read_byte(mtd) & NAND_STATUS_READY) > break; > } > +WATCHDOG_RESET (); > } > #ifdef PPCHAMELON_NAND_TIMER_HACK > reset_timer(); > This patch is whitespace-mangled. Try using git send-email. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] update/fix AcTux1 board
On Sat, 29 Jan 2011 16:57:07 +0100 Michael Schwingen wrote: > Am 01/25/2011 09:44 PM, schrieb Wolfgang Denk: > > > >> diff --git a/board/actux1/config.mk b/board/actux1/config.mk > >> index 88634f7..a370337 100644 > >> --- a/board/actux1/config.mk > >> +++ b/board/actux1/config.mk > >> @@ -1,6 +1,3 @@ > >> -CONFIG_SYS_TEXT_BASE = 0x00e0 > >> - > >> -# include NPE ethernet driver > >> -BOARDLIBS = arch/arm/cpu/ixp/npe/libnpe.o > >> - > >> LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds > >> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections > >> +PLATFORM_LDFLAGS += --gc-sections > > Can we please get rid of this file completely? > > > I got out everything except the LDSCRIPT definition. However, I can't > find a way to specify a board-specific linker script (which I need due > to the embedded environment) without using config.mk in the board > directory, since the platform sets up a non-board default in > arch/arm/config.mk. > > How about a > #define CONFIG_BOARD_LDSCRIPT > that is picked up by autoconf.mk and used in the Makefiles if set? PowerPC uses CONFIG_SYS_LDSCRIPT for this. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] Introduce the Tertiary Program loader
From: Haiying Wang
TPL is introduced to enable a loader stub that boots out of some type of RAM,
after being loaded by an SPL or similar platform-specific mechanism.
One example of using this tpl loader is to initialize the ddr through spd code
in case the L2 SRAM size is not big enough to hold the final uboot image and
the nand spl code needs to be limitated to 4K byte, then tpl code will load the
final uboot image after ddr is initialized.
Signed-off-by: Haiying Wang
---
Makefile | 15 ++-
README | 27 +++
2 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0d1ea5d..ae5db69 100644
--- a/Makefile
+++ b/Makefile
@@ -402,8 +402,19 @@ $(obj)u-boot.lds: $(LDSCRIPT)
nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
+tpl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C tpl/board/$(BOARDDIR) all
+
+NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin
+NAND_SPL_OBJS-$(CONFIG_HAS_TPL) += $(obj)tpl/u-boot-tpl.bin
+NAND_SPL_OBJS-y += $(obj)u-boot.bin
+
+ifeq ($(CONFIG_HAS_TPL),y)
+$(obj)u-boot-nand.bin: nand_spl tpl $(obj)u-boot.bin
+else
$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin
- cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin >
$(obj)u-boot-nand.bin
+endif
+ cat $(NAND_SPL_OBJS-y) > $(obj)u-boot-nand.bin
onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
$(MAKE) -C onenand_ipl/board/$(BOARDDIR) all
@@ -1221,6 +1232,7 @@ clean:
@rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
+ @rm -f $(obj)tpl/{u-boot-tpl,u-boot-tpl.map}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@@ -1245,6 +1257,7 @@ clobber: clean
@rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l
-print | xargs rm -f
+ @[ ! -d $(obj)tpl ] || find $(obj)tpl -name "*" -type l -print | xargs
rm -f
ifeq ($(OBJTREE),$(SRCTREE))
mrproper \
diff --git a/README b/README
index 755d17c..447fff0 100644
--- a/README
+++ b/README
@@ -2124,6 +2124,33 @@ FIT uImage format:
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
+- NAND Boot Support
+ CONFIG_NAND_U_BOOT
+
+ Builds a U-Boot image that boots from NAND, prefixed by a small
+ loader stub (secondary program loader -- SPL) that loads the
+ rest of U-Boot into RAM. This symbol will be set in all build
+ phases.
+
+ CONFIG_NAND_SPL
+
+ This is set by the build system when compiling code to go into
+ the SPL. It is not set when building the code that the SPL
+ loads.
+
+- TPL Boot Support
+ CONFIG_HAS_TPL
+
+ Builds a U-Boot image that contains a loader stub (tertiary
+ program loader -- TPL) that boots out of some type of RAM,
+ after being loaded by an SPL or similar platform-specific
+ mechanism. This symbol will be set in all build phases.
+
+ CONFIG_IN_TPL
+
+ This is set by the build system when compiling code to go into
+ the TPL. It is not set when building the code that the TPL
+ loads, or when building the SPL.
Modem Support:
--
--
1.7.3.1.50.g1e633
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
From: Haiying Wang
P1021 has some QE pins which need to be set in pmuxcr register before using QE
functions. In this patch, pin QE0 and QE3 are set for UCC1 and UCC5 in Eth mode.
QE9 and QE12 are set for MII management. QE12 needs to be released after MII
access because QE12 pin is muxed with LBCTL signal.
P1021MDS has to load the microcode from NAND flash, this patch defines
misc_init_r() for loading ucode and initializing qe.
Signed-off-by: Haiying Wang
---
arch/powerpc/cpu/mpc85xx/speed.c |4 ++
arch/powerpc/include/asm/immap_85xx.h | 13 +
board/freescale/p1021mds/p1021mds.c | 83 +
drivers/qe/uec.c | 40 +++-
include/configs/P1021MDS.h| 47 ++
5 files changed, 186 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index f2aa8d0..ae94ee8 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -165,10 +165,14 @@ void get_sys_info (sys_info_t * sysInfo)
#endif
#ifdef CONFIG_QE
+#ifdef CONFIG_P1021
+ sysInfo->freqQE = sysInfo->freqSystemBus;
+#else
qe_ratio = ((gur->porpllsr) & MPC85xx_PORPLLSR_QE_RATIO)
>> MPC85xx_PORPLLSR_QE_RATIO_SHIFT;
sysInfo->freqQE = qe_ratio * CONFIG_SYS_CLK_FREQ;
#endif
+#endif
#if defined(CONFIG_FSL_LBC)
#if defined(CONFIG_SYS_LBC_LCRR)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 77e3629..9b7de6b 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1909,6 +1909,19 @@ typedef struct ccsr_gur {
#define MPC85xx_PMUXCR_SD_DATA 0x8000
#define MPC85xx_PMUXCR_SDHC_CD 0x4000
#define MPC85xx_PMUXCR_SDHC_WP 0x2000
+#define MPC85xx_PMUXCR_QE0 0x8000
+#define MPC85xx_PMUXCR_QE1 0x4000
+#define MPC85xx_PMUXCR_QE2 0x2000
+#define MPC85xx_PMUXCR_QE3 0x1000
+#define MPC85xx_PMUXCR_QE4 0x0800
+#define MPC85xx_PMUXCR_QE5 0x0400
+#define MPC85xx_PMUXCR_QE6 0x0200
+#define MPC85xx_PMUXCR_QE7 0x0100
+#define MPC85xx_PMUXCR_QE8 0x0080
+#define MPC85xx_PMUXCR_QE9 0x0040
+#define MPC85xx_PMUXCR_QE100x0020
+#define MPC85xx_PMUXCR_QE110x0010
+#define MPC85xx_PMUXCR_QE120x0008
u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
u8 res6[8];
u32 devdisr;/* Device disable control */
diff --git a/board/freescale/p1021mds/p1021mds.c
b/board/freescale/p1021mds/p1021mds.c
index c7a7e57..e1ee1cf 100644
--- a/board/freescale/p1021mds/p1021mds.c
+++ b/board/freescale/p1021mds/p1021mds.c
@@ -37,6 +37,54 @@
#include
#include
+#ifdef CONFIG_QE
+#ifdef CONFIG_SYS_QE_FW_IN_NAND
+#include
+#include
+#endif
+extern void qe_init(uint qe_base);
+extern void qe_reset(void);
+#endif
+
+#ifdef CONFIG_QE
+const qe_iop_conf_t qe_iop_conf_tab[] = {
+ /* QE_MUX_MDC */
+ {1, 19, 1, 0, 1}, /* QE_MUX_MDC*/
+ /* QE_MUX_MDIO */
+ {1, 20, 3, 0, 1}, /* QE_MUX_MDIO */
+
+ /* UCC_1_MII */
+ {0, 23, 2, 0, 2}, /* CLK12 */
+ {0, 24, 2, 0, 1}, /* CLK9 */
+ {0, 7, 1, 0, 2}, /* ENET1_TXD0_SER1_TXD0 */
+ {0, 9, 1, 0, 2}, /* ENET1_TXD1_SER1_TXD1 */
+ {0, 11, 1, 0, 2}, /* ENET1_TXD2_SER1_TXD2 */
+ {0, 12, 1, 0, 2}, /* ENET1_TXD3_SER1_TXD3 */
+ {0, 6, 2, 0, 2}, /* ENET1_RXD0_SER1_RXD0 */
+ {0, 10, 2, 0, 2}, /* ENET1_RXD1_SER1_RXD1 */
+ {0, 14, 2, 0, 2}, /* ENET1_RXD2_SER1_RXD2 */
+ {0, 15, 2, 0, 2}, /* ENET1_RXD3_SER1_RXD3 */
+ {0, 5, 1, 0, 2}, /* ENET1_TX_EN_SER1_RTS_B*/
+ {0, 13, 1, 0, 2}, /* ENET1_TX_ER */
+ {0, 4, 2, 0, 2}, /* ENET1_RX_DV_SER1_CTS_B*/
+ {0, 8, 2, 0, 2}, /* ENET1_RX_ER_SER1_CD_B*/
+ {0, 17, 2, 0, 2}, /* ENET1_CRS*/
+ {0, 16, 2, 0, 2}, /* ENET1_COL*/
+
+ /* UCC_5_RMII */
+ {1, 11, 2, 0, 1}, /* CLK13 */
+ {1, 7, 1, 0, 2}, /* ENET5_TXD0_SER5_TXD0 */
+ {1, 10, 1, 0, 2}, /* ENET5_TXD1_SER5_TXD1 */
+ {1, 6, 2, 0, 2}, /* ENET5_RXD0_SER5_RXD0 */
+ {1, 9, 2, 0, 2}, /* ENET5_RXD1_SER5_RXD1 */
+ {1, 5, 1, 0, 2}, /* ENET5_TX_EN_SER5_RTS_B*/
+ {1, 4, 2, 0, 2}, /* ENET5_RX_DV_SER5_CTS_B*/
+ {1, 8, 2, 0, 2}, /* ENET5_RX_ER_SER5_CD_B*/
+
+ {0, 0, 0, 0, QE_IOP_TAB_END} /* END of table */
+};
+#endif
+
int board_early_init_f(void)
{
@@ -100,6 +148,14 @@ int board_eth_init(bd_t *bis)
tsec_eth_init(bis, tsec_info, num);
+#if defined(CONFIG_UEC_ETH)
+ /* QE0 and QE3 need to be exposed for UCC1 and UCC5 Eth mode */
+ setbits_be32(&gur->pmu
[U-Boot] [PATCH 3/6] P1021: add P1021MDS board support
From: Haiying Wang Support P1021MDS board to boot from NAND flash (No NOR flash on this board). And because P1021 only has 256K L2 SRAM, which can not used for final uboot image, this patch also enables the TPL BOOT on P1021MDS so that DDR can be initialized in L2 SRAM through SPD code. So there are three stage uboot images: * nand_spl, pad from 4KB size to 16KB, load tpl_boot from offset 16KB in NAND. * tpl_boot, 112KB size. The env variables are copied to offset 128KB in L2 SRAM, so that ddr spd code can get the interleaving mode setting in env. It loads final uboot image from offset 128KB in NAND. * final uboot image, size is variable depends on the functions enabled. Signed-off-by: Haiying Wang Signed-off-by: Mohit Kumar Signed-off-by: Yu Liu Signed-off-by: Kai Jiang --- MAINTAINERS |4 + board/freescale/p1021mds/Makefile | 52 +++ board/freescale/p1021mds/config.mk| 31 ++ board/freescale/p1021mds/ddr.c| 107 + board/freescale/p1021mds/law.c| 34 ++ board/freescale/p1021mds/p1021mds.c | 133 ++ board/freescale/p1021mds/tlb.c| 102 + boards.cfg|1 + include/configs/P1021MDS.h| 535 + nand_spl/board/freescale/p1021mds/Makefile| 134 ++ nand_spl/board/freescale/p1021mds/nand_boot.c | 69 nand_spl/nand_boot_fsl_elbc.c |6 +- tpl/board/freescale/p1021mds/Makefile | 257 tpl/board/freescale/p1021mds/tpl_boot.c | 79 14 files changed, 1543 insertions(+), 1 deletions(-) create mode 100644 board/freescale/p1021mds/Makefile create mode 100644 board/freescale/p1021mds/config.mk create mode 100644 board/freescale/p1021mds/ddr.c create mode 100644 board/freescale/p1021mds/law.c create mode 100644 board/freescale/p1021mds/p1021mds.c create mode 100644 board/freescale/p1021mds/tlb.c create mode 100644 include/configs/P1021MDS.h create mode 100644 nand_spl/board/freescale/p1021mds/Makefile create mode 100644 nand_spl/board/freescale/p1021mds/nand_boot.c create mode 100644 tpl/board/freescale/p1021mds/Makefile create mode 100644 tpl/board/freescale/p1021mds/tpl_boot.c diff --git a/MAINTAINERS b/MAINTAINERS index edd1c5c..da1b2a3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17,6 +17,10 @@ # Board CPU # # +Haiying Wang + + P1021MDSP1021 + Poonam Aggrwal P2020RDBP2020 diff --git a/board/freescale/p1021mds/Makefile b/board/freescale/p1021mds/Makefile new file mode 100644 index 000..50d4743 --- /dev/null +++ b/board/freescale/p1021mds/Makefile @@ -0,0 +1,52 @@ +# +# Copyright (C) 2010-2011 Freescale Semiconductor, Inc. +# +# 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 + +COBJS-y+= $(BOARD).o +COBJS-y+= law.o +COBJS-y+= tlb.o +COBJS-y+= ddr.o + +SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS-y)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) $(SOBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/p1021mds/config.mk b/board/freescale/p1021mds/config.mk new file mode 100644 index 000..3888f61 --- /dev/null +++ b/board/freescale/p1021mds/config.mk @@ -0,0 +1,31 @@ +# +# Copyright (C) 2010 - 2011 Freescale Semiconductor, Inc. +# +# 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 Foundat
[U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
This patchset adds support for TPL(Tertiary Program Loader) and P1021MDS board. It is a rework of patchset at http://lists.denx.de/pipermail/u-boot/2010-December/082881.html, addresses the comments from the list and is based on the top of the tree. It needs to be applied after patch http://lists.denx.de/pipermail/u-boot/2011-January/086346.html and patch http://lists.denx.de/pipermail/u-boot/2011-January/086524.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
From: Haiying Wang For some board which doesn't have NOR flash and the QE's firmware(ucode) is saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will call it later after nand is initialized. Signed-off-by: Haiying Wang --- arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 8ece970..fcf9e7b 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -384,7 +384,7 @@ int cpu_init_r(void) enable_cpc(); -#ifdef CONFIG_QE +#if defined(CONFIG_QE) && !defined(CONFIG_SYS_QE_FW_IN_NAND) uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */ qe_init(qe_base); qe_reset(); -- 1.7.3.1.50.g1e633 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
