Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Stefan and Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: > This patch allows to override the libgcc Makefile inclusion from the toplevel > Makefile by the arch config.mk files. This is in preparation for the ARM > architecture to move away from including libgcc functions and only using > self-contained U-Boot functions as done in Linux. > > Currently all the ARM boards that use NAND are broken due to the addition of > 64 Bit device size support. In the past we have seen similar problems with > different tool chains due to EABI and FPU for example. > > With this patch and this one: "ARM: Don't include libgcc anymore" we move away > from all these problems on ARM since we don't include any functions from > libgcc anymore. You know, I'm a big fan of these two patches and like to see them in mainline asap ;) I applied them locally. Now, I'm preparing a patch to enable CONFIG_SYS_64BIT_VSPRINTF for all OMAP3 boards to get rid of these annoying "warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!". While without CONFIG_SYS_64BIT_VSPRINTF everything compiles fine with both libgcc patches applied, enabling CONFIG_SYS_64BIT_VSPRINTF still results in lib_generic/libgeneric.a(vsprintf.o): In function `put_dec': lib_generic/vsprintf.c:242: undefined reference to `__umoddi3' lib_generic/vsprintf.c:242: undefined reference to `__udivdi3' Any idea why this still happens *with* libgcc patches? Any idea how to fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too? Many thanks and best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Hi Dirk, On Sunday 12 July 2009 09:54:12 Dirk Behme wrote: > While without CONFIG_SYS_64BIT_VSPRINTF everything compiles fine with > both libgcc patches applied, enabling CONFIG_SYS_64BIT_VSPRINTF still > results in > > lib_generic/libgeneric.a(vsprintf.o): In function `put_dec': > > lib_generic/vsprintf.c:242: undefined reference to `__umoddi3' > > > lib_generic/vsprintf.c:242: undefined reference to `__udivdi3' > > Any idea why this still happens *with* libgcc patches? Any idea how to > fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too? I have to admit that I'm not sure why this is the case. But I suggest that you take a look at Simon's patch sent to the list a few days ago: [PATCH 5/8]: Use do_div from div64.h for vsprintf This should fix this issue. Let me know if this helps. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Stefan Roese wrote: > Hi Dirk, > > On Sunday 12 July 2009 09:54:12 Dirk Behme wrote: >> While without CONFIG_SYS_64BIT_VSPRINTF everything compiles fine with >> both libgcc patches applied, enabling CONFIG_SYS_64BIT_VSPRINTF still >> results in >> >> lib_generic/libgeneric.a(vsprintf.o): In function `put_dec': >> >> lib_generic/vsprintf.c:242: undefined reference to `__umoddi3' >> >> >> lib_generic/vsprintf.c:242: undefined reference to `__udivdi3' >> >> Any idea why this still happens *with* libgcc patches? Any idea how to >> fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too? > > I have to admit that I'm not sure why this is the case. But I suggest that > you > take a look at Simon's patch sent to the list a few days ago: > > [PATCH 5/8]: Use do_div from div64.h for vsprintf > > This should fix this issue. > > Let me know if this helps. Yes, thanks! For the archives: With http://lists.denx.de/pipermail/u-boot/2009-July/055599.html http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=07a6acbe20357ebc2af36ac32e7029828d895a62 http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e2a7f3af809f828878fe I'm now able to enable CONFIG_SYS_64BIT_VSPRINTF for all OMAP3 boards and compile it without (tool chain related) warnings. OMAP3 CONFIG_SYS_64BIT_VSPRINTF patch will be sent, soon. Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations. Signed-off-by: Dirk Behme --- This patch is against recent mainline "MAINTAINERS: fix sorting, remove duplicates." 3672cd5c3b53d219d33345eebad4e25ad5bf6d52. Compile tested with ./MAKEALL ARM_CORTEX_A8 and boot tested on Beagle board. To be able to compile it independent of tool chain (libgcc) the following patches were applied for this: http://lists.denx.de/pipermail/u-boot/2009-July/055599.html http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=07a6acbe20357ebc2af36ac32e7029828d895a62 http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e2a7f3af809f828878fe include/configs/omap3_beagle.h |1 + include/configs/omap3_evm.h |1 + include/configs/omap3_overo.h |1 + include/configs/omap3_pandora.h |1 + include/configs/omap3_zoom1.h |1 + include/configs/omap3_zoom2.h |1 + 6 files changed, 6 insertions(+) Index: omap3_patches/include/configs/omap3_zoom2.h === --- omap3_patches.orig/include/configs/omap3_zoom2.h +++ omap3_patches/include/configs/omap3_zoom2.h @@ -150,6 +150,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_zoom1.h === --- omap3_patches.orig/include/configs/omap3_zoom1.h +++ omap3_patches/include/configs/omap3_zoom1.h @@ -129,6 +129,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_evm.h === --- omap3_patches.orig/include/configs/omap3_evm.h +++ omap3_patches/include/configs/omap3_evm.h @@ -130,6 +130,7 @@ /* * Board NAND Info. */ +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_pandora.h === --- omap3_patches.orig/include/configs/omap3_pandora.h +++ omap3_patches/include/configs/omap3_pandora.h @@ -122,6 +122,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_beagle.h === --- omap3_patches.orig/include/configs/omap3_beagle.h +++ omap3_patches/include/configs/omap3_beagle.h @@ -133,6 +133,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_overo.h === --- omap3_patches.orig/include/configs/omap3_overo.h +++ omap3_patches/include/configs/omap3_overo.h @@ -119,6 +119,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Stefan Roese, In message <200907121002.46516...@denx.de> you wrote: > > > Any idea why this still happens *with* libgcc patches? Any idea how to > > fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too? > > I have to admit that I'm not sure why this is the case. But I suggest that > you > take a look at Simon's patch sent to the list a few days ago: > > [PATCH 5/8]: Use do_div from div64.h for vsprintf > > This should fix this issue. It will hush up the current errors, but that's actually a bad thing here - the errors are an indication that Jean-Christophe's patch might not be working as it is supposed 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 "What the scientists have in their briefcases is terrifying." - Nikita Khrushchev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] macb: get mac address from environment
This fix macb driver broken by commit 56b555a644f3cbb1b3929cb52b61d3ce483885f5 >>> what exactly broke ? drivers that are ported to NET_MULTI should *not* >>> be getting the mac from the environment. and from what i can see, the >>> macb driver is properly supporting the NET_MULTI setup. >>> >>> looks to me like the existing code is correct and your new proposed code >>> is not >> Hmm. Since pointed commit Ethernet just stopped to work, at least on my >> board similar to SAM9260EK. Maybe someone else can confirm it? >> >> Moreover, since that patch, when ethaddr is not set in the environment, >> and I set it from command line, I get this while trying to ping: >> >> U-Boot> ping 192.168.2.1 >> macb0: link up, 100Mbps full-duplex (lpa: 0x45e1) >> *** ERROR: `ethaddr' not set >> macb0: link up, 100Mbps full-duplex (lpa: 0x45e1) >> ping failed; host 192.168.2.1 is not alive > > do you have CONFIG_NET_MULTI defined ? if not, your board needs to switch > over to it. > -mike I use configuration for at91sam9260ek board already present in U-Boot and CONFIG_NET_MULTI is defined there. Andrzej ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
On 12:29 Sun 12 Jul , Wolfgang Denk wrote: > Dear Stefan Roese, > > In message <200907121002.46516...@denx.de> you wrote: > > > > > Any idea why this still happens *with* libgcc patches? Any idea how to > > > fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too? > > > > I have to admit that I'm not sure why this is the case. But I suggest that > > you > > take a look at Simon's patch sent to the list a few days ago: > > > > [PATCH 5/8]: Use do_div from div64.h for vsprintf > > > > This should fix this issue. > > It will hush up the current errors, but that's actually a bad thing > here - the errors are an indication that Jean-Christophe's patch > might not be working as it is supposed to. They do fix what they are suppose to , fix FPU and EABI problem which was re-introduce by the 64 bit mtd support here the problem is different you try to div64 which is not supported on arm you do need to do_div please apply this patch so I'll be able to send a pull request with the arm specific part and other patch be go in vacancy for one week this night Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: > be go in vacancy for one week this night This does mean that we will have no more ARM patches merged until merge window closes, right? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubi: help message correction
> In message you wrote: >> Fix incorrect information about size units. >> >> Signed-off-by: Andrzej Wolski >> --- >> diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c >> index bbca389..d1653b1 100644 >> --- a/common/cmd_ubi.c >> +++ b/common/cmd_ubi.c >> @@ -608,6 +608,6 @@ U_BOOT_CMD(ubi, 6, 1, do_ubi, >> " - Remove volume\n" >> "[Legends]\n" >> " volume: charater name\n" >> -" size: KiB, MiB, GiB, and bytes\n" >> +" size: hex value\n" >> " type: s[tatic] or d[ynamic] (default=dynamic)" >> ); > > This is IMHO not a helpful help message. > > First, it is reduncant, as all input in U-Boot is in hex format. So > why repeat that information. And "size: value" - what does that tell > me? Would it not be good to mention the unit? Is it in KiB, MiB, GiB, > bytes, blocks, or whatever? This is size in bytes. Original message was probably based on Linux mtd-utils where size in KiB, MiB, etc. can be specified. This is not true in U-Boot where all input is in hex, so this message have to be corrected. If you think "hex value" is not helpful, can you suggest something better? Maybe just remove size entry? Regards, Andrzej Wolski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
On 14:13 Sun 12 Jul , Dirk Behme wrote: > Dear Jean-Christophe, > > Jean-Christophe PLAGNIOL-VILLARD wrote: > >be go in vacancy for one week this night > > This does mean that we will have no more ARM patches merged until > merge window closes, right? one tonight one next sunday Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support
> + */ > +#undef CONFIG_CMD_FLASH > +#define CONFIG_SYS_NO_FLASH /* Declare no flash (NOR/SPI) */ please move this 2 > + > +#include > +#define CONFIG_CMD_AUTOSCRIPT > +#define CONFIG_CMD_DHCP > +#define CONFIG_CMD_ENV > +#define CONFIG_CMD_FAT > +#define CONFIG_CMD_NAND > +#define CONFIG_CMD_PING > +#define CONFIG_CMD_USB here > + Otherwise fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On 22:42 Fri 10 Jul , Mike Frysinger wrote: > On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote: > > Peter Tyser wrote: > > >> Before verifying MIPS builds, I'd like to make sure that why you take > > >> lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any > > >> discussion on #IRC, is there any chance we could share the summary or > > >> decision to follow? > > > > > > There was no discussion, /lib/$(ARCH) just made more sense to me and it > > > was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). > > > > > > Using $(ARCH)/lib wouldn't clean up the top-level directory structure > > > much and would open a can of worms that I'm not prepared to deal with at > > > this time. For example, if there was an architecture specific > > > > Oops, I wanted to say "arch/$(ARCH)/lib/", not $(ARCH)/lib/, sorry. > > i thought that originally, but i dont care much either way. having > arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though. > > i dont understand needing a lib/ subdir under arch/$(ARCH)/ though. > > > > While we're talking about it, I'd always thought it would be nice to > > > split out all the cmd_* files from common/ into their own command/ > > > directory similar to u-boot-v2. > > > > Ack. The directory structure in u-boot-v2 looks nice, at least, to me, > > anyway. I prefer the arch/$(ARCH)/lib so will could also move the cpu stuff there too for the command dir why not Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
On 10:28 Sun 12 Jul , Dirk Behme wrote: > With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update > MTD infrastructure to support 64bit device size" > CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output > and to remove annoying warning > > warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! > > Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations. > > Signed-off-by: Dirk Behme > > --- > you mush have all board maintainer ack otherwise fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use
On 17:10 Sat 11 Jul , Kyungmin Park wrote: > Use the common OneNAND linker script. > > Signed-off-by: Kyungmin Park > --- > diff --git a/onenand_ipl/board/apollon/u-boot.onenand.lds > b/onenand_ipl/u-boot-onenand.lds > similarity index 100% > rename from onenand_ipl/board/apollon/u-boot.onenand.lds > rename to onenand_ipl/u-boot-onenand.lds this is arch specific please move it to lib_arm/ Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
Jean-Christophe PLAGNIOL-VILLARD wrote: > On 10:28 Sun 12 Jul , Dirk Behme wrote: >> With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update >> MTD infrastructure to support 64bit device size" >> CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output >> and to remove annoying warning >> >> warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! >> >> Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations. >> >> Signed-off-by: Dirk Behme >> >> --- >> > you mush have all board maintainer ack From technical point of view: What do you think what might be wrong with this change that any maintainer would reject it? Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Apollon board use common OneNAND IPL linker
On 17:11 Sat 11 Jul , Kyungmin Park wrote: > Use common OneNAND IPL linker script. > > Signed-off-by: Kyungmin Park please number the patch to known the apply order Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v12] Marvell MV88F6281GTW_GE Board support
> + */ > +#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ > +#define CONFIG_INITRD_TAG1 /* enable INITRD tag */ > +#define CONFIG_SETUP_MEMORY_TAGS 1 /* enable memory tag */ > + > +#define CONFIG_SYS_PROMPT "Marvell>> "/* Command Prompt */ > +#define CONFIG_SYS_CBSIZE 1024/* Console I/O Buff Size */ > +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE \ > + +sizeof(CONFIG_SYS_PROMPT) + 16)/* Print Buff */ > +/* > + * Commands configuration > + */ > +#undef CONFIG_CMD_FLASH > +#define CONFIG_SYS_NO_FLASH /* Declare no flash (NOR/SPI) */ please move this 2 define > + > +#include > +#define CONFIG_CMD_AUTOSCRIPT > +#define CONFIG_CMD_DHCP > +#define CONFIG_CMD_ENV > +#define CONFIG_CMD_FAT > +#define CONFIG_CMD_PING > +#define CONFIG_CMD_SF > +#define CONFIG_CMD_USB here > + > +/* > + * Flash configuration > + */ otherwise fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DHCP regression on 2009-06
On Fri, Jul 10, 2009 at 10:18 PM, Robin Getz wrote:
> On Fri 10 Jul 2009 12:27, Robin Getz pondered:
> > http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=3c172c4fdbbb5
> > 858fae38478d6399be4a16be3fc
> >
> > causes a regression on my network's DHCP server.
> > The part of the diff that causes the problem:
> >
> > #if defined(CONFIG_CMD_DHCP)
> >
> > case DHCP:
> > - /* Start with a clean slate... */
> > BootpTry = 0;
> > - NetOurIP = 0;
> > - NetServerIP = getenv_IPaddr ("serverip");
> > DhcpRequest(); /* Basically same as BOOTP */
> > break;
> >
> > Since we are leaving the "NetOurIP" to whatever it was... The test at:
> > NetReceive():
> >
> > case PROT_IP:
> > [snip]
> > tmp = NetReadIP(&ip->ip_dst);
> > if (NetOurIP && tmp != NetOurIP && tmp != 0x) {
> > return;
> > }
> >
> > Will return - (we leave the 'NetOurIP' set to the old value, the offered
> > address (what is in tmp) is not our's and tmp is not 0x).
> >
> > You never process the DHCP_OFFER...
> >
>
Did you try to remove the CONFIG_IPADDR from the board's config file?
In this case the NetOurIP will get 0. That should solve the problem.
Best regards,
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Could you regenerate it with the following option
git format-patch -M -B -C
> > + /* Configure GPIOs to output */
> > + writel(~(GPIO23 | GPIO17 | GPIO12 | GPIO11 | GPIO10 | GPIO8 |
> > GPIO2),
> > + &gpio6_base->oe);
> > + writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
> > + GPIO13 | GPIO12), &gpio5_base->oe);
> > + writel(~(GPIO22 | GPIO13), &gpio1_base->oe);
> > +
> > + /* Set GPIOs */
> > + writel(GPIO23 | GPIO17 | GPIO10 | GPIO8 | GPIO2,
> > + &gpio6_base->setdataout);
> > + writel(GPIO31 | GPIO29 | GPIO28 | GPIO22 | GPIO21 | GPIO13 | GPIO12,
> > + &gpio5_base->setdataout);
> > + writel(GPIO22 | GPIO13,
> > + &gpio1_base->setdataout);
> Aie... what are these gpios and why do they need to be set high?
>
> normally you might want to do setdataout followed by oe?
btw we have a gpio API now please use it
> > +
> > + dieid_num_r();
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Routine: set_muxconf_regs
> > + * Description: Setting up the configuration Mux registers specific to the
> > + * hardware. Many pins need to be moved from protect to primary
> > + * mode.
> > + */
> > +void set_muxconf_regs(void)
> > +{
> > + MUX_KBOC();
> > +}
> > diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h
please create you own vendor dirent
> > new file mode 100644
> > index 000..41c3b9e
> > --- /dev/null
> > +++ b/board/omap3/kboc/kboc.h
> > @@ -0,0 +1,382 @@
> > +/*
> > + * (C) Copyright 2009
> > + * KwikByte
> > + *
> > + * Author :
> > + * Christian Owens
> > + *
> > + * Derived from the following:
> > + *
> > + * (C) Copyright 2008
> > + * Dirk Behme
> > + *
> > + * 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
> > + */
> > +#ifndef _KBOC_H_
> > +#define _KBOC_H_
> > +
> > +const omap3_sysinfo sysinfo = {
> > + DDR_STACKED,
> > + "OMAP3 KBOC board",
> > +#if defined(CONFIG_ENV_IS_IN_ONENAND)
> > + "OneNAND",
> > +#else
> > + "NAND",
> > +#endif
>
> err... CONFIG_ENV_IS_IN_NAND is defined as 1 in config header.. means
> never support onenand?
> > +};
> > +
> > +/*
> > + * IEN - Input Enable
> > + * IDIS - Input Disable
> > + * PTD - Pull type Down
> > + * PTU - Pull type Up
> > + * DIS - Pull type selection is inactive
> > + * EN - Pull type selection is active
> > + * M0 - Mode 0
> > + * The commented string gives the final mux configuration for that pin
> > + */
> > +#define MUX_KBOC() \
> > + /*SDRC*/\
> > + MUX_VAL(CP(SDRC_D0), (IEN | PTD | DIS | M0)) /*SDRC_D0*/\
> > + MUX_VAL(CP(SDRC_D1), (IEN | PTD | DIS | M0)) /*SDRC_D1*/\
> > + MUX_VAL(CP(SDRC_D2), (IEN | PTD | DIS | M0)) /*SDRC_D2*/\
> > + MUX_VAL(CP(SDRC_D3), (IEN | PTD | DIS | M0)) /*SDRC_D3*/\
> > + MUX_VAL(CP(SDRC_D4), (IEN | PTD | DIS | M0)) /*SDRC_D4*/\
> > + MUX_VAL(CP(SDRC_D5), (IEN | PTD | DIS | M0)) /*SDRC_D5*/\
> > + MUX_VAL(CP(SDRC_D6), (IEN | PTD | DIS | M0)) /*SDRC_D6*/\
> > + MUX_VAL(CP(SDRC_D7), (IEN | PTD | DIS | M0)) /*SDRC_D7*/\
> > + MUX_VAL(CP(SDRC_D8), (IEN | PTD | DIS | M0)) /*SDRC_D8*/\
> > + MUX_VAL(CP(SDRC_D9), (IEN | PTD | DIS | M0)) /*SDRC_D9*/\
> > + MUX_VAL(CP(SDRC_D10), (IEN | PTD | DIS | M0)) /*SDRC_D10*/\
> > + MUX_VAL(CP(SDRC_D11), (IEN | PTD | DIS | M0)) /*SDRC_D11*/\
> > + MUX_VAL(CP(SDRC_D12), (IEN | PTD | DIS | M0)) /*SDRC_D12*/\
> > + MUX_VAL(CP(SDRC_D13), (IEN | PTD | DIS | M0)) /*SDRC_D13*/\
> > + MUX_VAL(CP(D2D_FRINT), (IEN | PTD | EN | M0))
> > /*d2d_frint*/\
> > + MUX_VAL(CP(D2D_DMAREQ0), (IEN | PTD | DIS | M0)) /*d2d_dmareq0*/\
> > + MUX_VAL(CP(D2D_DMAREQ1), (IEN | PTD | DIS | M0)) /*d2d_dmareq1*/\
> > + MUX_VAL(CP(D2D_DMAREQ2), (IEN | PTD | DIS | M0)) /*d2d_dmareq2*/\
> > + MUX_VAL(CP(D2D_DMAREQ3), (IEN | PTD | DIS | M0)) /*d2d_dmareq3*/\
> > + MUX_VAL(CP(D2D_N3GTRST), (IEN | PTD | DIS | M0)) /*d2d_n3gtrst*/\
> > + MUX_VAL(CP(D2D_N3GTDI), (IEN | PTD | DIS | M0)) /*d2d_n3gtdi*/\
>
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: >>> diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h > please create you own vendor dirent NACK. We use board/omap3//.h syntax. So this is fine. Everything else would make it inconsistent. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 08:13 AM: >>> _sread*/\ >>> + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) /*d2d_mbusflag*/\ >>> + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) /*d2d_sbusflag*/\ >>> + MUX_VAL(CP(SDRC_CKE0),(IDIS | PTU | EN | M0)) >>> /*sdrc_cke0*/\ >>> + MUX_VAL(CP(SDRC_CKE1),(IDIS | PTU | EN | M0)) >>> /*sdrc_cke1*/ >>> >> one more reason why the mux needs a big change in mux handling :( I >> think we will end up with 1/2 a dozen crazy and code repetition for >> each board... Arrggghhh... >> > NM: yes, it's really not easy to follow here > do you plan to do it soon? > Been a little tied up recent days with "work load" hoping things to ease down.. will try to send out a mux cleanup rev next weekend.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Nishanth Menon wrote: > Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 08:13 AM: _sread*/\ + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) /*d2d_mbusflag*/\ + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) /*d2d_sbusflag*/\ + MUX_VAL(CP(SDRC_CKE0),(IDIS | PTU | EN | M0)) /*sdrc_cke0*/\ + MUX_VAL(CP(SDRC_CKE1),(IDIS | PTU | EN | M0)) /*sdrc_cke1*/ >>> one more reason why the mux needs a big change in mux handling :( I >>> think we will end up with 1/2 a dozen crazy and code repetition for >>> each board... Arrggghhh... >>> >> NM: yes, it's really not easy to follow here >> do you plan to do it soon? >> > Been a little tied up recent days with "work load" hoping things to ease > down.. will try to send out a mux cleanup rev next weekend.. Btw, I like the way we do pin mux in U-Boot at the moment (*). Or better: I can't imagine a way how to do it even better without introducing other disadvantages. But I will enjoy to have a look to your changes ;) Maybe you can give us already an idea of how you like to change it? (*) What I like: Having everything in one file for each board. With this, you can get a complete overview of board's pin mux with looking only in one file. And you can see immediately for each pin what is configured and how. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <20090712120655.ga21...@game.jcrosoft.org> you wrote:
>
> > It will hush up the current errors, but that's actually a bad thing
> > here - the errors are an indication that Jean-Christophe's patch
> > might not be working as it is supposed to.
> They do fix what they are suppose to , fix FPU and EABI problem which was
> re-introduce by the 64 bit mtd support
> here the problem is different you try to div64 which is not supported on arm
> you do need to do_div
What do you mean - not supported by ARM? Of course ARM supports 64
bit division.
Compiling this little test code:
long long div(long long x, long long y)
{
return x / y;
}
will result in a call to __aeabi_ldivmod using an EABI compliant
version of GCC, resp. to __divdi3 using an older compiler. So GCC
knows how to handle this, and it provides adequate functions to do
it.
> please apply this patch so I'll be able to send a pull request with the arm
> specific part and other patch be go in vacancy for one week this night
I really hesitate to do that. It seems that not using the compiler
provided library is not such a clever thing to do. The compile writes
probably know better what a specific version of GCC needs that
anybody else.
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 more complex the mind, the greater the need for the simplicity of
play.
-- Kirk, "Shore Leave", stardate 3025.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712125148.gc21...@game.jcrosoft.org> you wrote: > > + */ > > +#undef CONFIG_CMD_FLASH > > +#define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */ > please move this 2 > > + > > +#include > > +#define CONFIG_CMD_AUTOSCRIPT > > +#define CONFIG_CMD_DHCP > > +#define CONFIG_CMD_ENV > > +#define CONFIG_CMD_FAT > > +#define CONFIG_CMD_NAND > > +#define CONFIG_CMD_PING > > +#define CONFIG_CMD_USB > here Why? 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 "Unibus timeout fatal trap program lost sorry" - An error message printed by DEC's RSTS operating system for the PDP-11 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712125617.ga7...@game.jcrosoft.org> you wrote: > On 10:28 Sun 12 Jul , Dirk Behme wrote: > > With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update > > MTD infrastructure to support 64bit device size" > > CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output > > and to remove annoying warning > > > > warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct > > output! > > > > Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations. > > > > Signed-off-by: Dirk Behme > > > > --- > > > you mush have all board maintainer ack Please do not put things on their head. This is not how the mailing list works. The good old way in Netiquette is "No News is Good News." When I post a patch, I don't expect that all the subscribers on the list that agree with the patch will send an ACK - I expect that those who see problems with it will raise their voice. Same here. If none of the board maintatiners sends a NAK after a reasonable time (3...4 days or so, max 1 week), the we can assume that the patch is OK and should be applied. 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 morsel of genuine history is a thing so rare as to be always valuable. - Thomas Jefferson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DHCP regression on 2009-06
Dear Michael Zaidman, In message <660c0f820907120614i2b33d8a1g9ac46c103e548...@mail.gmail.com> you wrote: > > Did you try to remove the CONFIG_IPADDR from the board's config file? > In this case the NetOurIP will get 0. That should solve the problem. Setting or not setting CONFIG_IPADDR only changes the default environment, and it should have zero impact whether "ipaddr" is set in the U-Boot environment or not. If this should not be the case, then there is indeed a bug (but the not defining CONFIG_IPADDR will not fix it 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 Star Trek Lives! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712131357.ge7...@game.jcrosoft.org> you wrote: > > > > diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h > please create you own vendor dirent This is only needed if the company is expected to release any significant number of boards. 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 ...though his invention worked superbly -- his theory was a crock of sewage from beginning to end. - Vernor Vinge, "The Peace War" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Dear Dirk Behme, In message <4a59e6b3.1070...@googlemail.com> you wrote: > > Jean-Christophe PLAGNIOL-VILLARD wrote: > >>> diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h > > please create you own vendor dirent > > NACK. We use board/omap3//.h syntax. So this is fine. > Everything else would make it inconsistent. I'm not sure what you mean by "we" here. The rus is that a vendor directory shall be used when a company supports any significaant number (say, more than 2...3) of boards. So when for example company FOO who already have other boards in board/foo/* releases their first OMAP3 board, it will naturally go into board/foo/ 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 Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP MUX handling improvement (was: Add support for the KwikByte KBOC OMAP35xx board)
Dirk Behme said the following on 07/12/2009 09:31 AM: > Nishanth Menon wrote: >> Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 >> 08:13 AM: > _sread*/\ > + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) > /*d2d_mbusflag*/\ > + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) > /*d2d_sbusflag*/\ > + MUX_VAL(CP(SDRC_CKE0),(IDIS | PTU | EN | M0)) > /*sdrc_cke0*/\ > + MUX_VAL(CP(SDRC_CKE1),(IDIS | PTU | EN | M0)) > /*sdrc_cke1*/ > one more reason why the mux needs a big change in mux handling :( I think we will end up with 1/2 a dozen crazy and code repetition for each board... Arrggghhh... >>> NM: yes, it's really not easy to follow here >>> do you plan to do it soon? >>> >> Been a little tied up recent days with "work load" hoping things to ease >> down.. will try to send out a mux cleanup rev next weekend.. > > Btw, I like the way we do pin mux in U-Boot at the moment (*). Or > better: I can't imagine a way how to do it even better without > introducing other disadvantages. But I will enjoy to have a look to > your changes ;) Maybe you can give us already an idea of how you like > to change it? > > (*) What I like: > > Having everything in one file for each board. With this, you can get a > complete overview of board's pin mux with looking only in one file. > And you can see immediately for each pin what is configured and how. Here are few quick things i like and dont like about the mux handling Pros: * Simple interface - just a #define Cons: * Repetition for every single board for common stuff such as Sdrc dat regs etc.. * Boards tend to enable *every* mux even if u-boot uses or not. Proposal stage 1: * move common mux out to a mux.h, where board files can use the defaults if they like -> i recollect having send such a patch out some time back.. but I never got the time to follow up on it. Proposal stage 2: * kick out mux settings from each board, which does not belong there -> e.g. if the board does not do camera at u-boot level ->move that out to kernel. This is just my 2 cents.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090712120655.ga21...@game.jcrosoft.org> you wrote:
>>> It will hush up the current errors, but that's actually a bad thing
>>> here - the errors are an indication that Jean-Christophe's patch
>>> might not be working as it is supposed to.
>> They do fix what they are suppose to , fix FPU and EABI problem which was
>> re-introduce by the 64 bit mtd support
>> here the problem is different you try to div64 which is not supported on arm
>> you do need to do_div
>
> What do you mean - not supported by ARM? Of course ARM supports 64
> bit division.
>
> Compiling this little test code:
>
> long long div(long long x, long long y)
> {
> return x / y;
> }
>
> will result in a call to __aeabi_ldivmod using an EABI compliant
> version of GCC, resp. to __divdi3 using an older compiler. So GCC
> knows how to handle this, and it provides adequate functions to do
> it.
>
>> please apply this patch so I'll be able to send a pull request with the arm
>> specific part and other patch be go in vacancy for one week this night
>
> I really hesitate to do that. It seems that not using the compiler
> provided library is not such a clever thing to do. The compile writes
> probably know better what a specific version of GCC needs that
> anybody else.
Yes, you are basically right. But ;)
But, as Jean-Christophe mentioned above, it's a pain with the various
ARM tool chains floating around. Some are older, some are newer, some
are configured for EABI, some not, some are configured for software
floating point, some for hardware floating point, etc., etc.
While I as developer might be able to find a recent tool chain with a
libgcc compatible with U-Boot, I think we should avoid this pain for
our users. Users which like to "just compile U-Boot" and then we tell
them "well, your tool chain you seem to be happy with doesn't link
U-Boot, for U-Boot you have to install an other one" I think wouldn't
make them happy.
Regarding not using the compilers library and if this clever: No, it
isn't clever, you are right again. The compiler's library version is
most probably better optimized. But, we are dealing with a boot loader
here. So for the topic we discuss here, I think avoiding some pain for
us ("my tool chain doesn't compile U-Boot, help!" mails at this list)
and our users (see above) is the stronger argument than some
optimization/performance issues in some (seldom?) used math functions.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Dear Wolfgang, Wolfgang Denk wrote: > Dear Dirk Behme, > > In message <4a59e6b3.1070...@googlemail.com> you wrote: >> Jean-Christophe PLAGNIOL-VILLARD wrote: > diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h >>> please create you own vendor dirent >> NACK. We use board/omap3//.h syntax. So this is fine. >> Everything else would make it inconsistent. > > I'm not sure what you mean by "we" here. Most probably the maintainers of all existing board/omap3/* and board/davinci/* boards ;) > The rus is that a vendor > directory shall be used when a company supports any significaant > number (say, more than 2...3) of boards. So when for example company > FOO who already have other boards in board/foo/* releases their first > OMAP3 board, it will naturally go into board/foo/ Yes, ok, fine. I understood Jean-Christophe that he wants board/omap3/ and this is what I doesn't like. At least not for the first board of a company. If they, later, add some additional (OMAP3) boards, moving then to board/omap3///, board/omap3/// etc would be fine, though. But please don't make the currently used schema inconsistent just for one (the first) board (not knowing if there ever will be an additional one). Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support
On 16:37 Sun 12 Jul , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090712125148.gc21...@game.jcrosoft.org> you wrote: > > > + */ > > > +#undef CONFIG_CMD_FLASH > > > +#define CONFIG_SYS_NO_FLASH /* Declare no flash (NOR/SPI) */ > > please move this 2 > > > + > > > +#include > > > +#define CONFIG_CMD_AUTOSCRIPT > > > +#define CONFIG_CMD_DHCP > > > +#define CONFIG_CMD_ENV > > > +#define CONFIG_CMD_FAT > > > +#define CONFIG_CMD_NAND > > > +#define CONFIG_CMD_PING > > > +#define CONFIG_CMD_USB > > here > > Why? how this suppose to work? you undef the CMD_FLASH et redefine it from the default? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
On 15:35 Sun 12 Jul , Dirk Behme wrote: > Dear Jean-Christophe, > > Jean-Christophe PLAGNIOL-VILLARD wrote: > > >>>diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h > >please create you own vendor dirent > > NACK. We use board/omap3//.h syntax. So this is fine. > Everything else would make it inconsistent. have more board in omap3 NACK omap3 is not a vendor it's a TI soc I've said it multiple time No new board will be allow to go in omap3 ditto for davinci Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
On 16:41 Sun 12 Jul , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090712125617.ga7...@game.jcrosoft.org> you wrote: > > On 10:28 Sun 12 Jul , Dirk Behme wrote: > > > With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update > > > MTD infrastructure to support 64bit device size" > > > CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output > > > and to remove annoying warning > > > > > > warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct > > > output! > > > > > > Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations. > > > > > > Signed-off-by: Dirk Behme > > > > > > --- > > > > > you mush have all board maintainer ack > > Please do not put things on their head. This is not how the mailing > list works. The good old way in Netiquette is "No News is Good News." > When I post a patch, I don't expect that all the subscribers on the > list that agree with the patch will send an ACK - I expect that those > who see problems with it will raise their voice. > > Same here. > > If none of the board maintatiners sends a NAK after a reasonable time > (3...4 days or so, max 1 week), the we can assume that the patch is > OK and should be applied. you ask us multiple time when we touch a board config we do need the board maintainer ack I've 10's of patch that you have nack because I never receive the board maintainer and they still wait to have board Maintainer ack. So please give only one rules Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP MUX handling improvement
Nishanth Menon wrote: > Dirk Behme said the following on 07/12/2009 09:31 AM: >> Nishanth Menon wrote: >>> Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 >>> 08:13 AM: >> _sread*/\ >> + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) >> /*d2d_mbusflag*/\ >> + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) >> /*d2d_sbusflag*/\ >> + MUX_VAL(CP(SDRC_CKE0),(IDIS | PTU | EN | M0)) >> /*sdrc_cke0*/\ >> + MUX_VAL(CP(SDRC_CKE1),(IDIS | PTU | EN | M0)) >> /*sdrc_cke1*/ >> > one more reason why the mux needs a big change in mux handling :( I > think we will end up with 1/2 a dozen crazy and code repetition for > each board... Arrggghhh... > NM: yes, it's really not easy to follow here do you plan to do it soon? >>> Been a little tied up recent days with "work load" hoping things to ease >>> down.. will try to send out a mux cleanup rev next weekend.. >> Btw, I like the way we do pin mux in U-Boot at the moment (*). Or >> better: I can't imagine a way how to do it even better without >> introducing other disadvantages. But I will enjoy to have a look to >> your changes ;) Maybe you can give us already an idea of how you like >> to change it? >> >> (*) What I like: >> >> Having everything in one file for each board. With this, you can get a >> complete overview of board's pin mux with looking only in one file. >> And you can see immediately for each pin what is configured and how. > Here are few quick things i like and dont like about the mux handling > Pros: > * Simple interface - just a #define > Cons: > * Repetition for every single board for common stuff such as Sdrc dat > regs etc.. This isn't a con for me. Having this in each board directory, you know that it is exactly right for this board and that you don't (accidentally) use some other (generic) code from somewhere else that you never checked. And you have it in one, easy maintainable file. You don't have to search for pin mux in x files scattered around in the source tree, with chance that you miss one if you want to check the pin mux for your board. > * Boards tend to enable *every* mux even if u-boot uses or not. This is a very big pro for me. Again, with this, you can be sure that the pin mux, which you have in one place, is done right for exactly this board. And you don't have to rely on broken kernel pin mux of anything else. With this, you can be sure that your board boots fine without burning something due to wrong pin mux. Even if you don't use all interfaces. > Proposal stage 1: > * move common mux out to a mux.h, where board files can use the defaults > if they like Con: Configuration scattered around in several files, see above. > -> i recollect having send such a patch out some time > back.. but I never got the time to follow up on it. > > Proposal stage 2: > * kick out mux settings from each board, which does not belong there -> > e.g. if the board does not do camera at u-boot level ->move that out to > kernel. Then you first have to fix totally broken kernel pin mux before we can do this ;) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 15:35 Sun 12 Jul , Dirk Behme wrote: >> Dear Jean-Christophe, >> >> Jean-Christophe PLAGNIOL-VILLARD wrote: >> > diff --git a/board/omap3/kboc/kboc.h b/board/omap3/kboc/kboc.h >>> please create you own vendor dirent >> NACK. We use board/omap3//.h syntax. So this is fine. >> Everything else would make it inconsistent. > have more board in omap3 NACK > omap3 is not a vendor it's a TI soc Please feel free to send a patch to change directory layout as you like and then we can discuss about it. > I've said it multiple time > > No new board will be allow to go in omap3 ditto for davinci Giving such a statement might sound like "no more (TI?) ARM boards will be allowed to be added" which I think doesn't really help. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
On 09:15 Thu 09 Jul , Stefan Roese wrote: > Hi Prafulla, > > On Wednesday 08 July 2009 19:48:19 Prafulla Wadaskar wrote: > > > MAINTAINERS |1 + > > > MAKEALL |1 + > > > Makefile |3 + > > > board/keymile/suen3/Makefile | 51 + > > > board/keymile/suen3/config.mk | 25 > > > board/keymile/suen3/sdramregs.txt | 28 + > > > > This file will be of no use until we have proposed bin_dep.sh and doimage > > utility in place. > > Even without doimage and/or bin_dep.sh in place, I think it makes perfect > sense to include this SDRAM init file in the board directory. Mainly because > of two reasons: > > a) Keep bootloader related files in one place (SDRAM init is crucial for >correct operation) > > b) Keep those files under revision control > > And I don't think that anything really speaks against having this file in > this > place for now. > > But anyway, we should try to get at least your bin_dep.sh infrastructure > accepter. Or at least restart the discussion about it (and probably about > doimage as well). I do not think we need this bin_dep.sh at all we can simply add a new target u-boot.kwd which will do somthing like this $(obj)u-boot.kwd: $(obj)u-boot.bin $(do_image) $(obj)u-boot.kwd $(obj)u-boot.bin $(obj)board/$(BOARDDIR)/sdramregs.txt Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Dirk,
In message <4a59f95a.6060...@googlemail.com> you wrote:
>
> > I really hesitate to do that. It seems that not using the compiler
> > provided library is not such a clever thing to do. The compile writes
> > probably know better what a specific version of GCC needs that
> > anybody else.
>
> Yes, you are basically right. But ;)
>
> But, as Jean-Christophe mentioned above, it's a pain with the various
> ARM tool chains floating around. Some are older, some are newer, some
> are configured for EABI, some not, some are configured for software
> floating point, some for hardware floating point, etc., etc.
Right. And each of these is supposed to come with it's own version of
libgcc, configured exactly for the requirements of this specific
version and configuration of GCC.
And it turns out that the majority of architectures works just fine
with such a setup, just using libgcc for functions required for and
provided by the compiler.
If the compiler provided functions cannot be used, this is IMO an
indication of a broken toolchain, which should either be fixed (if
it's under some form of maintenance) or abandoned (because you will
have the same problems again in other situations outside of U-Boot).
> While I as developer might be able to find a recent tool chain with a
> libgcc compatible with U-Boot, I think we should avoid this pain for
> our users. Users which like to "just compile U-Boot" and then we tell
> them "well, your tool chain you seem to be happy with doesn't link
> U-Boot, for U-Boot you have to install an other one" I think wouldn't
> make them happy.
>From the technical point of view it is only reasonable to point out
that these users have a broken toolchain, and that they should take
the first opportunity to fix or replace it.
Of course it it nice if we can also provide a workaround for them, so
they can update at a point in time that is convenient to them. But the
implementation of such a workaround should be clean, and eventually be
used only for systems that really need it.
In no case we should make the use of such a workaround for broken
setups the rule which has to be used by all systems (and eventually
all architectures, even those that never had such problems in the
first place).
This is why I really hesitate to apply these patches - they make the
workaround for a few broken systems the rule, instead of making clear
that this is an exception needed only by some (broken) systems.
> Regarding not using the compilers library and if this clever: No, it
> isn't clever, you are right again. The compiler's library version is
> most probably better optimized. But, we are dealing with a boot loader
This is in no way a question of optimization. If we provide
replacements for the libgcc functions, _we_ will have to maintain
these and make sure they work correctly with all versions of GCC that
exist in the multiverse and with all of their possible and impossible
configurations. That's a lot of work we put on ouw own back for - for
what?
> here. So for the topic we discuss here, I think avoiding some pain for
> us ("my tool chain doesn't compile U-Boot, help!" mails at this list)
> and our users (see above) is the stronger argument than some
> optimization/performance issues in some (seldom?) used math functions.
I think that answering a few mails, pointing out known problems with
broken tool chains requires by far less amount of effort than adding
this code. Heck, discussing and testing of this patch took already
way more of my time than replying to all related messages in the last
3 years together...
I think the patch needs to be changed such that it needs to be
specifically enabled for broken tool chains, and that by default all
systems behave the same, i. e. assume a working tool chain and use
libgcc.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Why waste negative entropy on comments, when you could use the same
entropy to create bugs instead?"- Steve Elias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 3/3] arm: Added support for jadecpu board based on Jade SoC
On 08:43 Thu 09 Jul , Matthias Weisser wrote:
> Hello Jean-Christophe
>
> >> +int board_init(void)
> >> +{
> >> + /* arch number of Versatile Board */
> >> + gd->bd->bi_arch_number = 0 /*MACH_TYPE_GSJADECPU*/;
> > nack
>
> How to get a arch number? As I don't use Linux on that board
> I don't think I need one. What is the right way to handle
> such a situation? Dont't set bi_arch_number at all?
you have no plan to support linux?
if not, just do not add it and disable linux boot support
btw please put a comment in the config about it
>
> >> +#define CCNT_BASE 0xfff42000
> > please move define to proper header
> >> +#define CDEBUG1 0xec
> >> +
> >> +#define DDR2C_BASE0xf300
> >> +#define DRIC 0x00
> >> +#define DRIC1 0x02
> >> +#define DRIC2 0x04
> >> +#define DRCA 0x06
> >> +#define DRCM 0x08
> >> +#define DRCST10x0a
> >> +#define DRCST20x0c
> >> +#define DRCR 0x0e
> >> +#define DRCF 0x20
> >> +#define DRASR 0x30
> >> +#define DRIMS 0x50
> >> +#define DROS 0x60
> >> +#define DRIBSLI 0x62
> >> +#define DRIBSODT1 0x64
> >> +#define DRIBSOCD 0x66
> >> +#define DRIBSOCD2 0x68
> >> +#define DROABA0x70
> >> +#define DROBV 0x80
> >> +#define DROBS 0x84
> >> +#define DROBSR1 0x86
> >> +#define DROBSR2 0x88
> >> +#define DROBSR3 0x8a
> >> +#define DROBSR4 0x8c
> >> +#define DRIMR10x90
> >> +#define DRIMR20x92
> >> +#define DRIMR30x94
> >> +#define DRIMR40x96
> >> +#define DROISR1 0x98
> >> +#define DROISR2 0x9a
> > what is this define?
>
> I will check this and move the needed ones to jade.h
>
> >> +
> >> + .macro wait, count
> >> + mov r4, #\count
> >> +3:
> >> + subsr4, r4, #0x1
> >> + bne 3b
> >> +
> >> + .endm
> > please use include/asm-arm/macro.h
>
> I don't have this file here. Is it currently included in the
> master branch of u-boot?
yes
>
> >> +/*
> >> + * Reset CPU by writing SWRSTREQ to CRSR-register
> >> + */
> >> +.globl reset_cpu
> >> +reset_cpu:
> >> + ldr r0, =0xfffe7000 /* CRG Base address */
> >> + ldr r2, =0x0002 /* SWRSTREQ */
> >> + str r2, [r0, #0x0c]
> >> +
> >> +_loop_forever:
> >> + b _loop_forever
> > is it board or soc specific reset?
>
> Reset is soc specific. I will move it to reset.c in the soc dir.
> Right?
yes please
>
> > this ram init is board or soc specific?
>
> RAM init is board specific as the soc could use other RAM
> configurations on other boards. So I think it should stay here.
>
> >> +#define CONFIG_SYS_HZ 1000
> >> +#define CONFIG_JADE_IOCLK (4150)
> >> +#define CONFIG_SYS_TIMERBASE 0xfffe
> > I guess it's soc specific so please move it to proper header
>
> For the timer base, yes.
>
> >> +#define VIDEO_KBD_INIT_FCT0
> >> +#define VIDEO_TSTC_FCTserial_tstc
> >> +#define VIDEO_GETC_FCTserial_getc
> > ??
> > why?
>
> Well, copy + paste from other board. Even if video is stdout/stdin
> serial port is used for input. Better way would be...?
please use device_t in this case
and set via preboot the correct stdout/stderr
you can also consider to add iomux support so you can use both at the sametime
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Dear Dirk Behme, In message <4a59fbda.70...@googlemail.com> you wrote: > > I understood Jean-Christophe that he wants > > board/omap3/ > > and this is what I doesn't like. At least not for the first board of a > company. If they, later, add some additional (OMAP3) boards, moving > then to board/omap3///, Agred - board/omap3/ is not acceptable, not for the first board, nor for any number of boards. If a vendor directory is used, then ist must go as board/ Otherwise we will have the same "" directories all over the place for all processors supported by a vendor - and for some active board vendors that can be a _lot_. 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 first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712151534.gf7...@game.jcrosoft.org> you wrote: > > > > > +#undef CONFIG_CMD_FLASH > > > > +#define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */ > > > please move this 2 > > > > + > > > > +#include > > > > +#define CONFIG_CMD_AUTOSCRIPT > > > > +#define CONFIG_CMD_DHCP > > > > +#define CONFIG_CMD_ENV > > > > +#define CONFIG_CMD_FAT > > > > +#define CONFIG_CMD_NAND > > > > +#define CONFIG_CMD_PING > > > > +#define CONFIG_CMD_USB > > > here > > > > Why? > how this suppose to work? > you undef the CMD_FLASH et redefine it from the default? Good. It would be nice if you added such an explanation to your comment, so people understand why you are making such requests. Otherwise they might assume you just had to make any comment. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is enough for the need of everyone in this world, but not for the greed of everyone. - Mahatma Gandhi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support
On 17:54 Sun 12 Jul , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090712151534.gf7...@game.jcrosoft.org> you wrote: > > > > > > > +#undef CONFIG_CMD_FLASH > > > > > +#define CONFIG_SYS_NO_FLASH /* Declare no flash (NOR/SPI) */ > > > > please move this 2 > > > > > + > > > > > +#include > > > > > +#define CONFIG_CMD_AUTOSCRIPT > > > > > +#define CONFIG_CMD_DHCP > > > > > +#define CONFIG_CMD_ENV > > > > > +#define CONFIG_CMD_FAT > > > > > +#define CONFIG_CMD_NAND > > > > > +#define CONFIG_CMD_PING > > > > > +#define CONFIG_CMD_USB > > > > here > > > > > > Why? > > how this suppose to work? > > you undef the CMD_FLASH et redefine it from the default? > > Good. It would be nice if you added such an explanation to your > comment, so people understand why you are making such requests. > Otherwise they might assume you just had to make any comment. ok it was too obvious for me Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Dirk,
>
> In message <4a59f95a.6060...@googlemail.com> you wrote:
>>> I really hesitate to do that. It seems that not using the compiler
>>> provided library is not such a clever thing to do. The compile writes
>>> probably know better what a specific version of GCC needs that
>>> anybody else.
>> Yes, you are basically right. But ;)
>>
>> But, as Jean-Christophe mentioned above, it's a pain with the various
>> ARM tool chains floating around. Some are older, some are newer, some
>> are configured for EABI, some not, some are configured for software
>> floating point, some for hardware floating point, etc., etc.
>
> Right. And each of these is supposed to come with it's own version of
> libgcc, configured exactly for the requirements of this specific
> version and configuration of GCC.
>
> And it turns out that the majority of architectures works just fine
> with such a setup, just using libgcc for functions required for and
> provided by the compiler.
>
> If the compiler provided functions cannot be used, this is IMO an
> indication of a broken toolchain, which should either be fixed (if
> it's under some form of maintenance) or abandoned (because you will
> have the same problems again in other situations outside of U-Boot).
>
>> While I as developer might be able to find a recent tool chain with a
>> libgcc compatible with U-Boot, I think we should avoid this pain for
>> our users. Users which like to "just compile U-Boot" and then we tell
>> them "well, your tool chain you seem to be happy with doesn't link
>> U-Boot, for U-Boot you have to install an other one" I think wouldn't
>> make them happy.
>
>>From the technical point of view it is only reasonable to point out
> that these users have a broken toolchain, and that they should take
> the first opportunity to fix or replace it.
>
> Of course it it nice if we can also provide a workaround for them, so
> they can update at a point in time that is convenient to them. But the
> implementation of such a workaround should be clean, and eventually be
> used only for systems that really need it.
>
> In no case we should make the use of such a workaround for broken
> setups the rule which has to be used by all systems (and eventually
> all architectures, even those that never had such problems in the
> first place).
Ah, I understand, most probably we are not aligned about what we talk,
sorry. Yes, I know, there was some discussion about the Makefiles and
that there are some requests to change them. Unfortunately, I'm no
Makefile expert.
So I'm only talking about ARM systems/architecture. If the Makefiles
discussed previously touch other systems/architectures, too, then this
is not what I'm talking about.
> This is why I really hesitate to apply these patches - they make the
> workaround for a few broken systems the rule, instead of making clear
> that this is an exception needed only by some (broken) systems.
For me the broken systems are in a first step ARM tool chains. Nothing
more. Not sure if we can limit it to a sub-group of ARM systems,
though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC?
>> Regarding not using the compilers library and if this clever: No, it
>> isn't clever, you are right again. The compiler's library version is
>> most probably better optimized. But, we are dealing with a boot loader
>
> This is in no way a question of optimization. If we provide
> replacements for the libgcc functions, _we_ will have to maintain
> these and make sure they work correctly with all versions of GCC that
> exist in the multiverse and with all of their possible and impossible
> configurations.
It was my understanding that Jean-Christophe copied this code from
kernel? Like we do with some other systems, e.g. MTD? So it's
maintained by kernel developers? Sorry if I missed something here.
> That's a lot of work we put on ouw own back for - for
> what?
>
>> here. So for the topic we discuss here, I think avoiding some pain for
>> us ("my tool chain doesn't compile U-Boot, help!" mails at this list)
>> and our users (see above) is the stronger argument than some
>> optimization/performance issues in some (seldom?) used math functions.
>
> I think that answering a few mails, pointing out known problems with
> broken tool chains requires by far less amount of effort than adding
> this code. Heck, discussing and testing of this patch took already
> way more of my time than replying to all related messages in the last
> 3 years together...
>
>
> I think the patch needs to be changed such that it needs to be
> specifically enabled for broken tool chains, and that by default all
> systems behave the same, i. e. assume a working tool chain and use
> libgcc.
Yes. I talk about "broken tool chains == ARM tool chains". Nothing
more. If the Makefile changes in the patches we talk about do some
more,
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
On 17:50 Sun 12 Jul , Wolfgang Denk wrote: > Dear Dirk, > > In message <4a59f95a.6060...@googlemail.com> you wrote: > > > > > I really hesitate to do that. It seems that not using the compiler > > > provided library is not such a clever thing to do. The compile writes > > > probably know better what a specific version of GCC needs that > > > anybody else. > > > > Yes, you are basically right. But ;) > > > > But, as Jean-Christophe mentioned above, it's a pain with the various > > ARM tool chains floating around. Some are older, some are newer, some > > are configured for EABI, some not, some are configured for software > > floating point, some for hardware floating point, etc., etc. > > Right. And each of these is supposed to come with it's own version of > libgcc, configured exactly for the requirements of this specific > version and configuration of GCC. the problem is that it's not really possible on arm because you will need a toolchain for u-boot and an other for the userland and in somecase an other for the kernel We can not trust at all the libgcc provide by the toolchains we have see this kind of problem thousand of times on the kernel and of course in U-Boot and it's not the only arch to have this kind of problem the mips have too. I can give 10's of toolchains which are correctly configured but never acheive to build u-boot or the kernel just because of the libgcc. Btw it will not be a huge work for U-Boot at all as we do this job in the kernel anyway Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Dirk Behme, In message <4a5a0b5b.2010...@googlemail.com> you wrote: > > > Of course it it nice if we can also provide a workaround for them, so > > they can update at a point in time that is convenient to them. But the > > implementation of such a workaround should be clean, and eventually be > > used only for systems that really need it. > > > > In no case we should make the use of such a workaround for broken > > setups the rule which has to be used by all systems (and eventually > > all architectures, even those that never had such problems in the > > first place). > > Ah, I understand, most probably we are not aligned about what we talk, > sorry. Yes, I know, there was some discussion about the Makefiles and > that there are some requests to change them. Unfortunately, I'm no > Makefile expert. > > So I'm only talking about ARM systems/architecture. If the Makefiles > discussed previously touch other systems/architectures, too, then this > is not what I'm talking about. Note that this is not a question of ARM versus other architectures. On ARM the use of libgcc should be the default like on all other architectures - only if needed it should be possible to switch on a don't-use-libgcc mode, but this should then be independent of architecture, either. > > This is why I really hesitate to apply these patches - they make the > > workaround for a few broken systems the rule, instead of making clear > > that this is an exception needed only by some (broken) systems. > > For me the broken systems are in a first step ARM tool chains. Nothing > more. Not sure if we can limit it to a sub-group of ARM systems, > though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC? That would be a board specific thing, which is inappropriate, as it does not depend on a specific board. The selection could be done by passing some argument or environment variables to "make", though. > > This is in no way a question of optimization. If we provide > > replacements for the libgcc functions, _we_ will have to maintain > > these and make sure they work correctly with all versions of GCC that > > exist in the multiverse and with all of their possible and impossible > > configurations. > > It was my understanding that Jean-Christophe copied this code from > kernel? Like we do with some other systems, e.g. MTD? So it's > maintained by kernel developers? Sorry if I missed something here. Even if it's maintained in Linux, we still have to follow any changes there, and port these to U-Boot, and analyse each new problem popping up by future uses of C statements that cause GCC to generate libgcc calls - that may or may not be covered by the kernel provided code. No matter where we get the code from, an ongoing effort will be needed to maintain this. > Yes. I talk about "broken tool chains == ARM tool chains". Nothing This is where I disagree. Why should we automatically assume that there are no sane ARM toolchains? We should always assume to have a usable toolchain first, and only fall back on the workaround if it's really necessary - no matter if it's ARM or anything else. Binding this to ARM is IMHO inherently wrong. 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 That said, there may be good reasons for what you did beyond obsequi- ous sycophantic parody. Perhaps you might be so kind as to elucidate. -- Tom Christiansen in <5ldjbm$jt...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712161700.gd21...@game.jcrosoft.org> you wrote: > > > Right. And each of these is supposed to come with it's own version of > > libgcc, configured exactly for the requirements of this specific > > version and configuration of GCC. > the problem is that it's not really possible on arm > because you will need a toolchain for u-boot and an other for the userland > and in somecase an other for the kernel You mean it is impossible to build a tool chain for ARM that can be used to build U-Boot, Linux, and user space code? I can't believe that ARM support in GCC is that seriously broken. > We can not trust at all the libgcc provide by the toolchains we have see this > kind of problem thousand of times on the kernel and of course in U-Boot > and it's not the only arch to have this kind of problem the mips have too. What do you mean? Are there examples where the libgcc provided functions are incorrect? But then - isn't the Linux kernel code drived from the very same set of sources? The only problems that I have seen in the past is that for example libgcc code assumes hardware FP support (ironically even on processors that never had a FPU) while U-Boot uses "-msoft-float". In that case it would be sufficient if the GCC builders provided a version of libgcc configured for soft-float. Are you aware of problems that have a different nature, i. e. where the libgcc provided source code is actually incorrect for some system? > I can give 10's of toolchains which are correctly configured but never acheive > to build u-boot or the kernel just because of the libgcc. The questionhere is probably how you define "correctly". If these tool chains are supposed to be used for U-Boot and kenrel development, then they are probably at least not complete. > Btw it will not be a huge work for U-Boot at all as we do this job in the > kernel anyway You still have to keep both in sync. And as I mantioned before: I do not oppose the change itself. I agree that it is useful and actually a very good idea to support users who really need this. The only things I oppose are (1) making this the default (or even mandatory) for all tool chains and (2) making it architecture-dependent. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the beginning, there was nothing, which exploded. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712152355.gh7...@game.jcrosoft.org> you wrote: > > > If none of the board maintatiners sends a NAK after a reasonable time > > (3...4 days or so, max 1 week), the we can assume that the patch is > > OK and should be applied. > you ask us multiple time when we touch a board config we do need the board > maintainer ack > I've 10's of patch that you have nack because I never receive the board > maintainer and they still wait to have board Maintainer ack. You are right. It's difficult to write don rules that cover all cases - which is one reason why I try to avoid writing down them in the first place. To me it seems reasonable to ask for maintainer feedback when changes affect a small number of boards - in such a case there is danger, that problems might remain unnoticed if the maintainers are not aware of the patch (which might sail under a subject that does not trigger their awareness), as nobody else is affected. If a patch affects a large number of boards in exactly the same way, such explicit triggering is less needed - it is very likely that a few of these boards will be tested in any way, so any problems will be noticed even if no extra notification of board maintainers takes place. To trigger a maintainer it should be sufficient to send him an e-mail (i. e. put him on cc: on the posting). If he does not apply in a reasonable time, we assume his implicit ACK. Sorry that I cannot provide a strict rule with clear decision criteria; if in doubt, use common sense. 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 An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Wolfgang, Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090712161700.gd21...@game.jcrosoft.org> you wrote: >>> Right. And each of these is supposed to come with it's own version of >>> libgcc, configured exactly for the requirements of this specific >>> version and configuration of GCC. >> the problem is that it's not really possible on arm >> because you will need a toolchain for u-boot and an other for the userland >> and in somecase an other for the kernel > > You mean it is impossible to build a tool chain for ARM that can be > used to build U-Boot, Linux, and user space code? I can't believe > that ARM support in GCC is that seriously broken. > >> We can not trust at all the libgcc provide by the toolchains we have see this >> kind of problem thousand of times on the kernel and of course in U-Boot >> and it's not the only arch to have this kind of problem the mips have too. > > What do you mean? Are there examples where the libgcc provided > functions are incorrect? But then - isn't the Linux kernel code > drived from the very same set of sources? > > The only problems that I have seen in the past is that for example > libgcc code assumes hardware FP support (ironically even on > processors that never had a FPU) while U-Boot uses "-msoft-float". In > that case it would be sufficient if the GCC builders provided a > version of libgcc configured for soft-float. > > Are you aware of problems that have a different nature, i. e. where > the libgcc provided source code is actually incorrect for some > system? > >> I can give 10's of toolchains which are correctly configured but never >> acheive >> to build u-boot or the kernel just because of the libgcc. > > The questionhere is probably how you define "correctly". If these tool > chains are supposed to be used for U-Boot and kenrel development, then > they are probably at least not complete. > >> Btw it will not be a huge work for U-Boot at all as we do this job in the >> kernel anyway > > You still have to keep both in sync. > > And as I mantioned before: I do not oppose the change itself. I agree > that it is useful and actually a very good idea to support users who > really need this. The only things I oppose are (1) making this the > default (or even mandatory) for all tool chains and (2) making it > architecture-dependent. So to do in in positive logic, what do you propose how to enable it? In the other mail you mentioned "The selection could be done by passing some argument or environment variables to "make""? Maybe you could give some (Makefile?) (pseudo?) code that Jean-Christophe gets an idea how to do this correctly? Sorry if this was given already in the Makefile discussion and I missed it. Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
On 20:17 Sun 12 Jul , Wolfgang Denk wrote: > Dear Dirk Behme, > > In message <4a5a0b5b.2010...@googlemail.com> you wrote: > > > > > Of course it it nice if we can also provide a workaround for them, so > > > they can update at a point in time that is convenient to them. But the > > > implementation of such a workaround should be clean, and eventually be > > > used only for systems that really need it. > > > > > > In no case we should make the use of such a workaround for broken > > > setups the rule which has to be used by all systems (and eventually > > > all architectures, even those that never had such problems in the > > > first place). > > > > Ah, I understand, most probably we are not aligned about what we talk, > > sorry. Yes, I know, there was some discussion about the Makefiles and > > that there are some requests to change them. Unfortunately, I'm no > > Makefile expert. > > > > So I'm only talking about ARM systems/architecture. If the Makefiles > > discussed previously touch other systems/architectures, too, then this > > is not what I'm talking about. > > Note that this is not a question of ARM versus other architectures. > On ARM the use of libgcc should be the default like on all other > architectures - only if needed it should be possible to switch on a > don't-use-libgcc mode, but this should then be independent of > architecture, either. which is the case no arch are force to switch the current patch just allow to switch to this mode. > > > > This is why I really hesitate to apply these patches - they make the > > > workaround for a few broken systems the rule, instead of making clear > > > that this is an exception needed only by some (broken) systems. > > > > For me the broken systems are in a first step ARM tool chains. Nothing > > more. Not sure if we can limit it to a sub-group of ARM systems, > > though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC? > > That would be a board specific thing, which is inappropriate, as it > does not depend on a specific board. The selection could be done by > passing some argument or environment variables to "make", though. > > > > This is in no way a question of optimization. If we provide > > > replacements for the libgcc functions, _we_ will have to maintain > > > these and make sure they work correctly with all versions of GCC that > > > exist in the multiverse and with all of their possible and impossible > > > configurations. > > > > It was my understanding that Jean-Christophe copied this code from > > kernel? Like we do with some other systems, e.g. MTD? So it's > > maintained by kernel developers? Sorry if I missed something here. > > Even if it's maintained in Linux, we still have to follow any changes > there, and port these to U-Boot, and analyse each new problem popping > up by future uses of C statements that cause GCC to generate libgcc > calls - that may or may not be covered by the kernel provided code. > > No matter where we get the code from, an ongoing effort will be > needed to maintain this. > > > Yes. I talk about "broken tool chains == ARM tool chains". Nothing > > This is where I disagree. Why should we automatically assume that > there are no sane ARM toolchains? unfortunately most of the arm toolchains are not sane for every point of view as you can not build U-Boot, kernel and userland with the same optimized toolchain most of the time. Maybe oneday we can assume that we could use any arm toolchain to build the 3, but for now I can assure it's not the case. On other it maybe not the case but as example on mips we have similar issue to workaround to be able to build U-Boot & Kernel Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Dirk, In message <4a5a3439.9000...@googlemail.com> you wrote: > > > And as I mantioned before: I do not oppose the change itself. I agree > > that it is useful and actually a very good idea to support users who > > really need this. The only things I oppose are (1) making this the > > default (or even mandatory) for all tool chains and (2) making it > > architecture-dependent. > > So to do in in positive logic, what do you propose how to enable it? > In the other mail you mentioned "The selection could be done by > passing some argument or environment variables to "make""? Right. > Maybe you could give some (Makefile?) (pseudo?) code that > Jean-Christophe gets an idea how to do this correctly? Sorry if this > was given already in the Makefile discussion and I missed it. No example was given yet. If someone puts enough effort into it, a clean implementation would probably provide a "spec string" with a "%G" definition to the CFLAGS and thus to the cross compiler's command-line options to override the GCC-provided definition of 'libgcc' with a new (U-Boot provided) one (see gcc.info, Node: Spec Files, Section 3.15 Specifying subprocesses and the switches to pass to them). A simpler implementation could use the '-B_prefix_' command-line option to select a different run-time support library. The feature itself could for example be triggered by using something like $ make USE_PRIVATE_LIBGCC=yes or $ USE_PRIVATE_LIBGCC=yes $ export USE_PRIVATE_LIBGCC $ make or similar. 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 Philosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712192216.ga1...@game.jcrosoft.org> you wrote: > > > Note that this is not a question of ARM versus other architectures. > > On ARM the use of libgcc should be the default like on all other > > architectures - only if needed it should be possible to switch on a > > don't-use-libgcc mode, but this should then be independent of > > architecture, either. > which is the case no arch are force to switch the current patch just allow > to switch to this mode. My understanding was that the current patch (1) makes not using lingcc the default for ARM, and (2) makes it the default for ARM for all too chains. Please show me how to activate the feature from the command line, as I seem to have missed this option (and the documentation for it). > > This is where I disagree. Why should we automatically assume that > > there are no sane ARM toolchains? > unfortunately most of the arm toolchains are not sane for every point of view > as you can not build U-Boot, kernel and userland with the same optimized > toolchain most of the time. But ARM is just one out of many different architectures, and there are eventually (sufficently) sane ARM tool chains available, too. This is the default case, and shall remain it. For broken tool chains (ARM or other) the feature can be activated (when running make). 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 Blast medicine anyway! We've learned to tie into every organ in the human body but one. The brain! The brain is what life is all about. -- McCoy, "The Menagerie", stardate 3012.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
On 20:37 Sun 12 Jul , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090712152355.gh7...@game.jcrosoft.org> you wrote: > > > > > If none of the board maintatiners sends a NAK after a reasonable time > > > (3...4 days or so, max 1 week), the we can assume that the patch is > > > OK and should be applied. > > you ask us multiple time when we touch a board config we do need the board > > maintainer ack > > I've 10's of patch that you have nack because I never receive the board > > maintainer and they still wait to have board Maintainer ack. > > You are right. It's difficult to write don rules that cover all cases > - which is one reason why I try to avoid writing down them in the > first place. > > To me it seems reasonable to ask for maintainer feedback when changes > affect a small number of boards - in such a case there is danger, > that problems might remain unnoticed if the maintainers are not aware > of the patch (which might sail under a subject that does not trigger > their awareness), as nobody else is affected. > > If a patch affects a large number of boards in exactly the same way, > such explicit triggering is less needed - it is very likely that a > few of these boards will be tested in any way, so any problems will > be noticed even if no extra notification of board maintainers takes > place. > > To trigger a maintainer it should be sufficient to send him an e-mail > (i. e. put him on cc: on the posting). If he does not apply in a > reasonable time, we assume his implicit ACK. > > > Sorry that I cannot provide a strict rule with clear decision > criteria; if in doubt, use common sense. Thanks. when increase the u-boot size IMHO we do need to have the board maintainer ack because we do not known if it will break or not the board If it's global or arch specifc we all take care the responsability to this ofcourse we will try to contact the board maintainers and yes not all of them will ack the patch but we will do our best. As example we the errno.h cleanup. Furehermore here all the boards maintainer are active on the ML so it's make sense to ask them there ack. But I'd like that we put a rules if the developer that post a patch do his best to have the board maintainer ack but not succed on it. The decission to ack it anyway will come to the Custiodians & you at the end. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DHCP regression on 2009-06
On Sun 12 Jul 2009 09:14, Michael Zaidman pondered:
>
> On Fri, Jul 10, 2009 at 10:18 PM, Robin Getz
wrote:
>
>
> On Fri 10 Jul 2009 12:27, Robin Getz pondered:
> > >
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=3c172c4fdbbb5858fae38478d6399be4a16be3fc
> >
> > causes a regression on my network's DHCP server.
> > The part of the diff that causes the problem:
> >
> > #if defined(CONFIG_CMD_DHCP)
> >
> > case DHCP:
> > - /* Start with a clean slate... */
> > BootpTry = 0;
> > - NetOurIP = 0;
> > - NetServerIP = getenv_IPaddr ("serverip");
> > DhcpRequest(); /* Basically same as BOOTP */
> > break;
> >
> > Since we are leaving the "NetOurIP" to whatever it was... The test at:
> > NetReceive():
> >
> > case PROT_IP:
> > [snip]
> > tmp = NetReadIP(&ip->ip_dst);
> > if (NetOurIP && tmp != NetOurIP && tmp != 0x) {
> > return;
> > }
> >
> > Will return - (we leave the 'NetOurIP' set to the old value, the offered
> > address (what is in tmp) is not our's and tmp is not 0x).
> >
> > You never process the DHCP_OFFER...
> >
>
> Did you try to remove the CONFIG_IPADDR from the board's config file?
> In this case the NetOurIP will get 0. That should solve the problem.
No it does not - the problem occurs if you do dhcp, save, and then move to a
different subnet, and a dhcp again (which is when I found it - recently moved
offices, and needed new IP addresses for all my development systems)
As Wolfgang stated: the initial state (what CONFIG_IPADDR controls) doesn't
change the issue that the bug exists - it just controls when the bug
appears - sooner or later - but it is still there
Rather than call BootpCheckPkt() as I suggested - Ben could just check the
value of packetHandler... (if it is DhcpHandler, don't return)...
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
On 21:35 Sun 12 Jul , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090712192216.ga1...@game.jcrosoft.org> you wrote: > > > > > Note that this is not a question of ARM versus other architectures. > > > On ARM the use of libgcc should be the default like on all other > > > architectures - only if needed it should be possible to switch on a > > > don't-use-libgcc mode, but this should then be independent of > > > architecture, either. > > which is the case no arch are force to switch the current patch just allow > > to switch to this mode. > > My understanding was that the current patch (1) makes not using > lingcc the default for ARM, and (2) makes it the default for ARM for > all too chains. the current patch do 2 thinks PATCH 1 allow to switch or not (by default use the toolchains libgcc) PATCH 2 for ARM only switch and do not use the libgcc anymore > > Please show me how to activate the feature from the command line, as > I seem to have missed this option (and the documentation for it). > > > > This is where I disagree. Why should we automatically assume that > > > there are no sane ARM toolchains? > > unfortunately most of the arm toolchains are not sane for every point of > > view > > as you can not build U-Boot, kernel and userland with the same optimized > > toolchain most of the time. > > But ARM is just one out of many different architectures, and there > are eventually (sufficently) sane ARM tool chains available, too. > This is the default case, and shall remain it. > > For broken tool chains (ARM or other) the feature can be activated > (when running make). Currently on arm you have more unsane toolchains than sane so I'll prefer to avoid the dual config as it will be safer I've test recently gcc-4.4.0 and it's the same you still have the problem you build some of the board but not all of them here is my status I've test to MAKEALL arm with the following toolchains on the current U-Boot ARM tree and different arch for the kernel I'll avoid the gcc-3.x.x U-Boot Kernel (without libgcc) Kernel (with libgcc) gcc-4.1.1 FailFailFail gcc-4.1.2 FailOK Fail gcc-4.2.1 FailOK Fail gcc-4.2.4 FailOK Fail gcc-4.3.2 FailOK Fail gcc-4.4.0 Failnot tested not tested Fail = mean one or more board fail to build evenif for the kernel there are reported ok by the autobuild kernel tool OK = all build (do not count the board report broken for the kernel by the autobuild kernel tool) Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v5] KB9202: Add NAND support
On 15:51 Wed 24 Jun , Scott Wood wrote: > On Wed, Jun 24, 2009 at 05:23:05PM +0200, Matthias Kaehlcke wrote: > > Add NAND support for the KwikByte KB9202 > > > > Signed-off-by: Matthias Kaehlcke > > > > --- > > > > El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit: > > > > > I get conflicts in kb9202.h. Is this against an arch tree, or does it > > > need to be respun? > > > > The previous patches were against v2009-03, as i had problems > > building the current git head for the kb9202 when i started working on > > the patch. Did you apply the first patch of this series when you got > > the conflict? This patch is based on the current HEAD. > > No - if it depends on other patches that go through an arch tree, then this > patch should go through that tree as well. > > Acked-by: Scott Wood Scott I've not follow this patch but for the arm part it's looks fine so I'll let you handle Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712193430.gb1...@game.jcrosoft.org> you wrote: > > when increase the u-boot size IMHO we do need to have the board maintainer > ack because we do not known if it will break or not the board It's not practical to wait for all BM's to ACK such a patch - you could reject it right away as well. > Furehermore here all the boards maintainer are active on the ML so it's make > sense to ask them there ack. Do you really want to see - say - 200 ACK messages here? It's not practical. > But I'd like that we put a rules if the developer that post a patch do his > best to have the board maintainer ack but not succed on it. The decission to > ack it anyway will come to the Custiodians & you at the end. If you have a proposal for rules that will actually work in such cases, please feel free to post them here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "You can have my Unix system when you pry it from my cold, dead fingers."- Cal Keegan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090712195107.gc1...@game.jcrosoft.org> you wrote: > > > > > On ARM the use of libgcc should be the default like on all other > > > > architectures - only if needed it should be possible to switch on a > > > > don't-use-libgcc mode, but this should then be independent of > > > > architecture, either. > > > which is the case no arch are force to switch the current patch just allow > > > to switch to this mode. > > > > My understanding was that the current patch (1) makes not using > > lingcc the default for ARM, and (2) makes it the default for ARM for > > all too chains. > the current patch do 2 thinks > PATCH 1 allow to switch or not (by default use the toolchains libgcc) The switch will be based on a configuration setting, i. e. you can change it only by changing the source code. You cannot for example compile the very same source code (without any changes to U-Boot source files) one time with and one time without using libgcc. > PATCH 2 for ARM only switch and do not use the libgcc anymore So it makes it not only the default, but actually the only supported setting (assuming you do not change the source code). Thanks for explaining the implementation to me. > > > unfortunately most of the arm toolchains are not sane for every point of > > > view > > > as you can not build U-Boot, kernel and userland with the same optimized > > > toolchain most of the time. > > > > But ARM is just one out of many different architectures, and there > > are eventually (sufficently) sane ARM tool chains available, too. > > This is the default case, and shall remain it. > > > > For broken tool chains (ARM or other) the feature can be activated > > (when running make). > Currently on arm you have more unsane toolchains than sane Maybe. This does not change any of my arguments. I have made up my mind. I hereby reject patches 1 and 2 in their current form. To have the patches accepted for imainline, use of libgcc should be the common default setting for all architectures, and switching of the use of libgcc should be possible for any board and any architec- ture without having to change any file in the U-Boot source tree. 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 No question is too silly to ask. Of course, some questions are too silly to to answer... - L. Wall & R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM Pull Request
Hi Wolfgang, please pull The following changes since commit 59869ca72df8bc4e4ffa9dd17cb6673bbe010272: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-video are available in the git repository at: git://git.denx.de/u-boot-arm.git master Daniel Mack (2): pxa: add clock for system bus 2 arbiter pxa: fix CKEN_B register bits Grazvydas Ignotas (4): OMAP3 pandora: pin mux cleanup OMAP3 pandora: setup pin mux for pins used on rev3 boards OMAP3 pandora: setup pulls for various GPIOs OMAP3 pandora: Fix CKE1 MUX setting to allow self-refresh Jean-Christophe PLAGNIOL-VILLARD (2): versatile: specify the board type on the prompt versatile: update config and merge to cfi flash driver Prafulla Wadaskar (2): nand: Add Marvell Kirkwood NAND driver arm: Kirkwood: bugfix: UART1 bar correction Sedji Gaouaou (2): at91: Introduction of at91sam9g45 SOC. at91: Introduction of at91sam9g10 SOC. MAINTAINERS |4 + MAKEALL | 38 +- Makefile| 41 ++- board/armltd/versatile/Makefile |2 +- board/armltd/versatile/flash.c | 514 --- board/atmel/at91sam9261ek/at91sam9261ek.c | 36 ++ board/atmel/at91sam9m10g45ek/Makefile | 55 +++ board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 334 +++ board/atmel/at91sam9m10g45ek/config.mk |1 + board/atmel/at91sam9m10g45ek/led.c | 41 ++ board/omap3/pandora/pandora.h | 86 ++--- cpu/arm926ejs/at91/Makefile |3 + cpu/arm926ejs/at91/at91sam9m10g45_devices.c | 175 cpu/arm926ejs/at91/clock.c | 12 +- doc/README.at91 | 22 +- drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/kirkwood_nand.c| 82 drivers/net/macb.c |6 +- include/asm-arm/arch-at91/at91_pmc.h|1 + include/asm-arm/arch-at91/at91sam9_matrix.h |2 + include/asm-arm/arch-at91/at91sam9g45.h | 139 ++ include/asm-arm/arch-at91/at91sam9g45_matrix.h | 153 +++ include/asm-arm/arch-at91/clk.h |5 + include/asm-arm/arch-at91/hardware.h|8 +- include/asm-arm/arch-at91/memory-map.h |1 + include/asm-arm/arch-kirkwood/kirkwood.h|2 +- include/asm-arm/arch-pxa/pxa-regs.h | 13 +- include/configs/at91sam9261ek.h | 13 +- include/configs/at91sam9m10g45ek.h | 225 ++ include/configs/versatile.h | 77 +++- 30 files changed, 1474 insertions(+), 618 deletions(-) delete mode 100644 board/armltd/versatile/flash.c create mode 100644 board/atmel/at91sam9m10g45ek/Makefile create mode 100644 board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c create mode 100644 board/atmel/at91sam9m10g45ek/config.mk create mode 100644 board/atmel/at91sam9m10g45ek/led.c create mode 100644 cpu/arm926ejs/at91/at91sam9m10g45_devices.c create mode 100644 drivers/mtd/nand/kirkwood_nand.c create mode 100644 include/asm-arm/arch-at91/at91sam9g45.h create mode 100644 include/asm-arm/arch-at91/at91sam9g45_matrix.h create mode 100644 include/configs/at91sam9m10g45ek.h Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Request pull: u-boot-sh
Dear Wolfgang.
Please pull u-boot-sh master branch.
Best regards,
Nobuhiro
The following changes since commit 3672cd5c3b53d219d33345eebad4e25ad5bf6d52:
Wolfgang Denk (1):
MAINTAINERS: fix sorting, remove duplicates.
are available in the git repository at:
git://git.denx.de/u-boot-sh.git master
Jean-Christophe PLAGNIOL-VILLARD (6):
sh7785lcr: fix out of tree build
sh: make the linker scripts more generic
sh: unify linker script
sh: introduce clock framework
sh3/sh4: fix CONFIG_SYS_HZ to 1000
sh3/sh4: rename config option TMU_CLK_DIVIDER to CONFIG_SYS_TMU_CLK_DIV
Nobuhiro Iwamatsu (3):
sh: Revised the build with newest compiler
sh: Add support ESPT-GIGA borad
sh: Update pci config for Renesas r7780mp board
MAKEALL |1 +
Makefile| 15 +-
board/espt/Makefile | 50
board/espt/config.mk|9 +
board/espt/espt.c | 50
board/espt/lowlevel_init.S | 334 +++
board/ms7720se/u-boot.lds | 108
board/ms7722se/u-boot.lds | 105 ---
board/ms7750se/u-boot.lds | 105 ---
board/renesas/MigoR/u-boot.lds | 105 ---
board/renesas/ap325rxa/u-boot.lds | 105 ---
board/renesas/r2dplus/u-boot.lds| 105 ---
board/renesas/r7780mp/u-boot.lds| 105 ---
board/renesas/sh7763rdp/u-boot.lds | 105 ---
board/renesas/sh7785lcr/Makefile|2 +-
board/renesas/sh7785lcr/lowlevel_init.S | 58 ++--
board/renesas/sh7785lcr/u-boot_29bit| 96 ---
board/renesas/sh7785lcr/u-boot_32bit| 96 ---
{board/renesas/rsk7203 => cpu/sh2}/u-boot.lds | 10 +-
{board/mpr2 => cpu/sh3}/u-boot.lds | 13 +-
{board/renesas/sh7785lcr => cpu/sh4}/u-boot.lds | 15 +-
include/asm-sh/clk.h| 35 +++
include/asm-sh/macro.h |2 +-
include/configs/MigoR.h |4 +-
include/configs/ap325rxa.h |4 +-
include/configs/espt.h | 126 +
include/configs/mpr2.h |4 +-
include/configs/ms7720se.h |4 +-
include/configs/ms7722se.h |4 +-
include/configs/ms7750se.h |4 +-
include/configs/r2dplus.h |4 +-
include/configs/r7780mp.h |7 +-
include/configs/sh7763rdp.h |4 +-
include/configs/sh7785lcr.h |4 +-
lib_sh/time.c | 55 +++--
sh_config.mk|3 +
36 files changed, 720 insertions(+), 1136 deletions(-)
create mode 100644 board/espt/Makefile
create mode 100644 board/espt/config.mk
create mode 100644 board/espt/espt.c
create mode 100644 board/espt/lowlevel_init.S
delete mode 100644 board/ms7720se/u-boot.lds
delete mode 100644 board/ms7722se/u-boot.lds
delete mode 100644 board/ms7750se/u-boot.lds
delete mode 100644 board/renesas/MigoR/u-boot.lds
delete mode 100644 board/renesas/ap325rxa/u-boot.lds
delete mode 100644 board/renesas/r2dplus/u-boot.lds
delete mode 100644 board/renesas/r7780mp/u-boot.lds
delete mode 100644 board/renesas/sh7763rdp/u-boot.lds
delete mode 100644 board/renesas/sh7785lcr/u-boot_29bit
delete mode 100644 board/renesas/sh7785lcr/u-boot_32bit
rename {board/renesas/rsk7203 => cpu/sh2}/u-boot.lds (89%)
rename {board/mpr2 => cpu/sh3}/u-boot.lds (87%)
rename {board/renesas/sh7785lcr => cpu/sh4}/u-boot.lds (90%)
create mode 100644 include/asm-sh/clk.h
create mode 100644 include/configs/espt.h
--
Nobuhiro Iwamatsu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use
Hi, On Sun, Jul 12, 2009 at 9:58 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:10 Sat 11 Jul , Kyungmin Park wrote: >> Use the common OneNAND linker script. >> >> Signed-off-by: Kyungmin Park >> --- >> diff --git a/onenand_ipl/board/apollon/u-boot.onenand.lds >> b/onenand_ipl/u-boot-onenand.lds >> similarity index 100% >> rename from onenand_ipl/board/apollon/u-boot.onenand.lds >> rename to onenand_ipl/u-boot-onenand.lds > this is arch specific > please move it to lib_arm/ Basically I agree your opinion, however do see the other arch OneNAND usage? I mean I can't see the other arch patches. I think until other arch uses it, I want to place it at onenand_ipl directory. How do you think? Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support
> -Original Message- > From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] > Sent: Sunday, July 12, 2009 9:37 PM > To: Wolfgang Denk > Cc: Prafulla Wadaskar; Manas Saksena; Ronen Shitrit; Nicolas > Pitre; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan > Sarnaik; Lennert Buijtenhek > Subject: Re: [U-Boot] [PATCH v6 2/2] Marvell Sheevaplug Board support > > On 17:54 Sun 12 Jul , Wolfgang Denk wrote: > > Dear Jean-Christophe PLAGNIOL-VILLARD, > > > > In message <20090712151534.gf7...@game.jcrosoft.org> you wrote: > > > > > > > > > +#undef CONFIG_CMD_FLASH Dear Jean I can define this line below > > > > > > +#define CONFIG_SYS_NO_FLASH/* But I can't define this line below since CONFIG_CMD_IMLS is defined in config_cmd_default.h under ifndef condition, then I will have to undef it again. Pls suggest?? Secondly, I think config_cmd_default.h need be tuned for its better usability. FLASH/FPGA/NET/SETGETDCR/IMLS are board specific, should be removed. I know the impact will be to update all other configs which are using it. Thirdly, On some of Embedded systems, where memory footprint is a very critical issue, we need to bring down u-boot binary size as small as possible. With this reference using config_cmd_default.h will be problematic. For this I think- we should add one more configuration like CONFIG_SMALL_IMAGE to generate smallest image u-boot binary. This is my requirement for some of board. What do you think to make it generic ? In brief, I am not enjoying using this file :-( I prefer it should be more generic. I wish NOT to use this file, shall I ? Regards.. Prafulla . . > Declare no flash (NOR/SPI) */ > > > > > please move this 2 > > > > > > + > > > > > > +#include #define > CONFIG_CMD_AUTOSCRIPT > > > > > > +#define CONFIG_CMD_DHCP #define CONFIG_CMD_ENV #define > > > > > > +CONFIG_CMD_FAT #define CONFIG_CMD_NAND #define > > > > > > +CONFIG_CMD_PING #define CONFIG_CMD_USB > > > > > here > > > > > > > > Why? > > > how this suppose to work? > > > you undef the CMD_FLASH et redefine it from the default? > > > > Good. It would be nice if you added such an explanation to your > > comment, so people understand why you are making such requests. > > Otherwise they might assume you just had to make any comment. > ok it was too obvious for me > > Best Regards, > J. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
