Re: [U-Boot] [PATCH 01/13] davinci_emac: move arch-independent defines to separate header
Hi Ilya,
On 11/28/11 18:37, Ilya Yanok wrote:
> DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs
> also. This patch moves common defines from arch-davinci/emac_defs.h to
> drivers/net/davinci_emac.h
>
> DaVinci specific PHY drivers hacked to include the new header. We might
> want to switch to phylib in future.
>
> Signed-off-by: Ilya Yanok
> ---
> arch/arm/cpu/arm926ejs/davinci/dp83848.c |1 +
> arch/arm/cpu/arm926ejs/davinci/et1011c.c |1 +
> arch/arm/cpu/arm926ejs/davinci/ksz8873.c |1 +
> arch/arm/cpu/arm926ejs/davinci/lxt972.c |1 +
> arch/arm/include/asm/arch-davinci/emac_defs.h | 289 ---
> drivers/net/davinci_emac.c|1 +
> drivers/net/davinci_emac.h| 314
> +
> 7 files changed, 319 insertions(+), 289 deletions(-)
> create mode 100644 drivers/net/davinci_emac.h
>
> diff --git a/arch/arm/cpu/arm926ejs/davinci/dp83848.c
> b/arch/arm/cpu/arm926ejs/davinci/dp83848.c
> index c71c685..d435e4b 100644
> --- a/arch/arm/cpu/arm926ejs/davinci/dp83848.c
> +++ b/arch/arm/cpu/arm926ejs/davinci/dp83848.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include "../../../../../drivers/net/davinci_emac.h"
Doesn't this look terrible?
I'd suggest, to split the davinci_emac.h to driver private part
(if there is) and to public part.
Then put the public part into the include/ directory - just as,
for example, dm9000 does.
Other then that, the patch indeed good and very useful.
Thanks.
[...]
> diff --git a/arch/arm/cpu/arm926ejs/davinci/ksz8873.c
> b/arch/arm/cpu/arm926ejs/davinci/ksz8873.c
> index 634eda0..3546e7f 100644
> --- a/arch/arm/cpu/arm926ejs/davinci/ksz8873.c
> +++ b/arch/arm/cpu/arm926ejs/davinci/ksz8873.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include "../../../../../drivers/net/davinci_emac.h"
grrr..
>
> int ksz8873_is_phy_connected(int phy_addr)
> {
> diff --git a/arch/arm/cpu/arm926ejs/davinci/lxt972.c
> b/arch/arm/cpu/arm926ejs/davinci/lxt972.c
> index 733d413..cce1fe4 100644
> --- a/arch/arm/cpu/arm926ejs/davinci/lxt972.c
> +++ b/arch/arm/cpu/arm926ejs/davinci/lxt972.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include "../../../../../drivers/net/davinci_emac.h"
grrr..
[...]
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 36c33af..43c4373 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include "davinci_emac.h"
then here, it will be both:
#include
#include "davinci_emac.h"
[...]
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/15] arm, davinci: Add SPL support for DA850 SoCs
Hello Christian, Christian Riesch wrote: > Hi Tom, > > On Tue, Nov 29, 2011 at 7:27 PM, Tom Rini wrote: >> On Fri, Nov 25, 2011 at 5:37 AM, Christian Riesch >> wrote: >>> This code adds an SPL for booting from SPI flash on DA850 SoCs. >>> >>> Signed-off-by: Christian Riesch >>> Cc: Heiko Schocher >>> Cc: Sandeep Paulraj >> Parts of this remind me of omap-common/spl.c so I think longer term we >> need to figure out if we can make everyone live with a few more common >> SPL files and functions. > > I stole some ideas from omap-common/spl.c and yes, there are similarities :-) > >> Aside, what are the size limitations you're >> dealing with here? Thanks! > > Size limitation of the SPL? I am using the AM1808 which has 128kB > internal SRAM, i think it is the same for all DA8xx SoCs. If we are using the "nor boot method" in "Legacy NOR Boot" mode on the am1808 we must take care, that we can copy only 16kB from NOR to the internal SRAM! (But I think, we don't need to take care of this mode, as we can use when booting from NOR the "direct NOR Boot" mode, where code is exectuted directly from NOR. This mode is used on the enbw_cmc board) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] davinci_emac: move arch-independent defines to separate header
On 11/29/11 20:57, Tom Rini wrote: > On Mon, Nov 28, 2011 at 9:37 AM, Ilya Yanok wrote: >> DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs >> also. This patch moves common defines from arch-davinci/emac_defs.h to >> drivers/net/davinci_emac.h >> >> DaVinci specific PHY drivers hacked to include the new header. We might >> want to switch to phylib in future. >> >> Signed-off-by: Ilya Yanok > > I missed the 0/13 email but, patches 1 to 10 will be queued up into > u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything > about 12 (but it's delegated to someone else) and I've commented on > 13. This should at least reduce the repost burden, thanks for all > your patience here! Good to hear, you are a co-custodian for u-boot-ti, I really like it, but... You should let patches hang a little on the list... This version was published just 1.5 days ago... You should let people look into this, otherwise, you can find yourself reapplying new versions or applying fixes to what could have been fixed... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] arm, davinci: add am1808 based enbw_cmc board
Hello Tom, Tom Rini wrote: > On Tue, Nov 29, 2011 at 5:33 AM, Heiko Schocher wrote: >> repost from: >> [U-Boot] [PATCH v3 0/3] arm, davinci: add am1808 based enbw_cmc board >> http://lists.denx.de/pipermail/u-boot/2011-November/111427.html >> >> changes for v4: >> - change gp0[15] output state to high >> - change gp6[10] output state to high >> add comments from Igor Grinberg: >> - removed clean, distclean targets from Makefile >> - sorted includes >> - aligned table >> - use misc functions from board/davinci/common moved for this >>board/davinci/common/misc.c to arch/arm/cpu/arm926ejs/davinci/misc.c >>in a seperate patch >> - use da8xx_configure_lpsc_items() >> add comments from Wolfgang Denk: >> - return instead continue, if gpio_request fails. >> >> Following patches are needed for this patchset >> - patchset from Christian Riesch: >> [U-Boot] [PATCH v3 00/15] Add an SPL to boot the da850evm from SPI >> http://lists.denx.de/pipermail/u-boot/2011-November/82.html >> >> - [U-Boot,1/2] arm, arm926ejs: always do cpu critical inits >> patchwork.ozlabs.org/patch/124787/ > > I've taken this one. Thanks! > >> - [U-Boot] arm, fdt: update ethernet mac address before booting Linux >> http://patchwork.ozlabs.org/patch/114736/ > > I've delegated this to Albert. Ok, thanks! > The rest of the series (will be) queued to u-boot-ti, thanks for your > patience. Yep, checked this. The enbw_cmc board build and works fine with u-boot-ti.git A "./MAKEALL -a arm --soc davinci" show me this errors: Configuring for davinci_schmoogie board... schmoogie.c: In function 'board_init': schmoogie.c:37:27: error: 'MACH_TYPE_SCHMOOGIE' undeclared (first use in this function) schmoogie.c:37:27: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [schmoogie.o] Fehler 1 make: *** [board/davinci/schmoogie/libschmoogie.o] Fehler 2 arm-linux-gnueabi-size: './u-boot': No such file Configuring for davinci_sffsdr board... textdata bss dec hex filename 1877786216 54620 248614 3cb26 ./u-boot Configuring for davinci_sonata board... sonata.c: In function 'board_init': sonata.c:38:27: error: 'MACH_TYPE_SONATA' undeclared (first use in this function) sonata.c:38:27: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [sonata.o] Fehler 1 make: *** [board/davinci/sonata/libsonata.o] Fehler 2 arm-linux-gnueabi-size: './u-boot': No such file Fixes for this from Christian Riesch for MACH_TYPE_SCHMOOGIE http://www.mail-archive.com/u-boot@lists.denx.de/msg69998.html for MACH_TYPE_SONATA http://www.mail-archive.com/u-boot@lists.denx.de/msg69997.html I could not find this patches in patchwork, nor are they applied in u-boot-arm.git ... Ah, they are in mainline u-boot.git ... Ok, they are not lost! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] linkage.h: move from blackfin to common includes
Add linkage.h support from blackfin to common include, which is a reduced version from Linux. Signed-off-by: Macpaul Lin --- arch/blackfin/include/asm/linkage.h | 74 --- include/linux/linkage.h | 72 ++ 2 files changed, 72 insertions(+), 74 deletions(-) delete mode 100644 arch/blackfin/include/asm/linkage.h create mode 100644 include/linux/linkage.h diff --git a/arch/blackfin/include/asm/linkage.h b/arch/blackfin/include/asm/linkage.h deleted file mode 100644 index fbb497c..000 --- a/arch/blackfin/include/asm/linkage.h +++ /dev/null @@ -1,74 +0,0 @@ -/* - * U-boot - linkage.h - * - * Copyright (c) 2005-2007 Analog Devices Inc. - * - * See file CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, - * MA 02110-1301 USA - */ - -#ifndef _LINUX_LINKAGE_H -#define _LINUX_LINKAGE_H - -#include - -#ifdef __cplusplus -#define CPP_ASMLINKAGE extern "C" -#else -#define CPP_ASMLINKAGE -#endif - -#define asmlinkage CPP_ASMLINKAGE - -#define SYMBOL_NAME_STR(X) #X -#define SYMBOL_NAME(X) X -#ifdef __STDC__ -#define SYMBOL_NAME_LABEL(X) X##: -#else -#define SYMBOL_NAME_LABEL(X) X: -#endif - -#define __ALIGN .align 4 -#define __ALIGN_STR".align 4" - -#ifdef __ASSEMBLY__ - -#define ALIGN __ALIGN -#define ALIGN_STR __ALIGN_STR - -#define LENTRY(name) \ - ALIGN; \ - SYMBOL_NAME_LABEL(name) - -#define ENTRY(name) \ - .globl SYMBOL_NAME(name); \ - LENTRY(name) -#endif - -#ifndef END -#define END(name) \ - .size name, .-name -#endif - -#ifndef ENDPROC -#define ENDPROC(name) \ - .type name, @function; \ - END(name) -#endif - -#endif diff --git a/include/linux/linkage.h b/include/linux/linkage.h new file mode 100644 index 000..1081dad --- /dev/null +++ b/include/linux/linkage.h @@ -0,0 +1,72 @@ +/* + * U-boot - linkage.h + * + * Copyright (c) 2005-2007 Analog Devices Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#ifndef _LINUX_LINKAGE_H +#define _LINUX_LINKAGE_H + +#include +#include + +#ifdef __cplusplus +#define CPP_ASMLINKAGE extern "C" +#else +#define CPP_ASMLINKAGE +#endif + +#define asmlinkage CPP_ASMLINKAGE + +#define SYMBOL_NAME_STR(X) #X +#define SYMBOL_NAME(X) X +#ifdef __STDC__ +#define SYMBOL_NAME_LABEL(X) X##: +#else +#define SYMBOL_NAME_LABEL(X) X: +#endif + +#ifdef __ASSEMBLY__ + +#define ALIGN __ALIGN +#define ALIGN_STR __ALIGN_STR + +#define LENTRY(name) \ + ALIGN; \ + SYMBOL_NAME_LABEL(name) + +#define ENTRY(name) \ + .globl SYMBOL_NAME(name); \ + LENTRY(name) +#endif + +#ifndef END +#define END(name) \ + .size name, .-name +#endif + +#ifndef ENDPROC +#define ENDPROC(name) \ + .type name, @function; \ + END(name) +#endif + +#endif -- 1.7.3.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] blackfin: fix linkage support due to header movement
Fix include path of linkage.h due to header file movement. Signed-off-by: Macpaul Lin --- arch/blackfin/cpu/cache.S |2 +- arch/blackfin/include/asm/blackfin_local.h |2 +- arch/blackfin/include/asm/cache.h |2 +- arch/blackfin/lib/__kgdb.S |2 +- arch/blackfin/lib/outs.S |2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/blackfin/cpu/cache.S b/arch/blackfin/cpu/cache.S index 6ed655a..1e468ee 100644 --- a/arch/blackfin/cpu/cache.S +++ b/arch/blackfin/cpu/cache.S @@ -8,9 +8,9 @@ * Licensed under the GPL-2 or later. */ -#include #include #include +#include .text /* Since all L1 caches work the same way, we use the same method for flushing diff --git a/arch/blackfin/include/asm/blackfin_local.h b/arch/blackfin/include/asm/blackfin_local.h index 71207b6..9d27f31 100644 --- a/arch/blackfin/include/asm/blackfin_local.h +++ b/arch/blackfin/include/asm/blackfin_local.h @@ -48,8 +48,8 @@ #define L1_CACHE_SHIFT 5 #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) -#include #include +#include #ifndef __ASSEMBLY__ # ifdef SHARED_RESOURCES diff --git a/arch/blackfin/include/asm/cache.h b/arch/blackfin/include/asm/cache.h index 482e4b5..568885a 100644 --- a/arch/blackfin/include/asm/cache.h +++ b/arch/blackfin/include/asm/cache.h @@ -7,7 +7,7 @@ #ifndef __ARCH_BLACKFIN_CACHE_H #define __ARCH_BLACKFIN_CACHE_H -#include/* for asmlinkage */ +#include /* for asmlinkage */ /* * Bytes per L1 cache line diff --git a/arch/blackfin/lib/__kgdb.S b/arch/blackfin/lib/__kgdb.S index cba4179..4ccde8f 100644 --- a/arch/blackfin/lib/__kgdb.S +++ b/arch/blackfin/lib/__kgdb.S @@ -1,5 +1,5 @@ -#include +#include /* save stack context for non-local goto * int kgdb_setjmp(long *buf) diff --git a/arch/blackfin/lib/outs.S b/arch/blackfin/lib/outs.S index 253d4c3..39d5332 100644 --- a/arch/blackfin/lib/outs.S +++ b/arch/blackfin/lib/outs.S @@ -8,7 +8,7 @@ * Licensed under the GPL-2. */ -#include +#include .align 2 -- 1.7.3.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] blackfin: add architecture part support of linkage.h
add architecture part support of linkage.h Signed-off-by: Macpaul Lin --- arch/blackfin/include/asm/linkage.h | 31 +++ 1 files changed, 31 insertions(+), 0 deletions(-) create mode 100644 arch/blackfin/include/asm/linkage.h diff --git a/arch/blackfin/include/asm/linkage.h b/arch/blackfin/include/asm/linkage.h new file mode 100644 index 000..9d6edd9 --- /dev/null +++ b/arch/blackfin/include/asm/linkage.h @@ -0,0 +1,31 @@ +/* + * U-boot - linkage.h + * + * Copyright (c) 2005-2007 Analog Devices Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#ifndef __ASM_LINKAGE_H +#define __ASM_LINKAGE_H + +#define __ALIGN .align 4 +#define __ALIGN_STR".align 4" + +#endif -- 1.7.3.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/15] arm, davinci: Add SPL support for DA850 SoCs
Hi Tom, On Tue, Nov 29, 2011 at 7:27 PM, Tom Rini wrote: > On Fri, Nov 25, 2011 at 5:37 AM, Christian Riesch > wrote: >> This code adds an SPL for booting from SPI flash on DA850 SoCs. >> >> Signed-off-by: Christian Riesch >> Cc: Heiko Schocher >> Cc: Sandeep Paulraj > > Parts of this remind me of omap-common/spl.c so I think longer term we > need to figure out if we can make everyone live with a few more common > SPL files and functions. I stole some ideas from omap-common/spl.c and yes, there are similarities :-) > Aside, what are the size limitations you're > dealing with here? Thanks! Size limitation of the SPL? I am using the AM1808 which has 128kB internal SRAM, i think it is the same for all DA8xx SoCs. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] nds32/ag102: add ag102 soc support
Hi Mike, 2011/11/30 Macpaul Lin > Hi Mike, > > err, i thought i saw u-boot had this in common code. seems it is not (i >>> must >>> have been looking in the Linux tree). don't worry about it until we get >>> that >>> addressed. >>> -mike >>> >> >> >> > It seems the only architecture related part in this header are the > following codes. > #define __ALIGN .align 4 > #define __ALIGN_STR ".align 4" > > In Linux, the common linkage.h will include only this part from > architectures' local linkage.h. > > I think we can put the common linkage.h in "include/linux" folder is okay. > > I have done this for blackfin also, but when I ran checkpatch to these patches, I've got several warnings and it looks those warnings should not be problem at all. So I'll send these patches to you and hope you can run checkpatch, too and see if there are something need to be fixed. Thanks. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Almost solved] M5282EVB undefined reference to `environment'
On 11/30/11 00:58, James Steward wrote: > On 25/11/11 14:52, James Steward wrote: > >> So it compiles env_embedded.c, but doesn't include it in libcommon.o? >> >> >> vim common/Makefile >> >> XCOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o >> >> becomes >> >> COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o >> >> :q >> >> >> make all >> >> Hey, presto, build now completes! >> >> So how should this be corrected properly? > > Can anyone suggest how the build process should be fixed? I don't fully understand the logic behind what's done to have ENV_IS_EMBEDDED, as it is used mostly on architectures I haven't worked with (at least till now). So, probably, I will not be the right person to ask... My suggestion would be to look into those linker scripts, Wolfgang mentioned in one of the previous emails and if you think it should be done in some different way, send a patch and start a discussion. But, really, I'm not the right person to ask... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] nds32/ag102: add ag102 soc support
Hi Mike, 2011/11/30 Macpaul Lin > Hi Mike and Wolfgang, > > 2011/11/30 Mike Frysinger > >> > For supporting this kind of implementation, I must to put header support >> > like linkage.h >> >> err, i thought i saw u-boot had this in common code. seems it is not (i >> must >> have been looking in the Linux tree). don't worry about it until we get >> that >> addressed. >> -mike >> > > > It seems the only architecture related part in this header are the following codes. #define __ALIGN .align 4 #define __ALIGN_STR ".align 4" In Linux, the common linkage.h will include only this part from architectures' local linkage.h. I think we can put the common linkage.h in "include/linux" folder is okay. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
On Tue, Nov 29, 2011 at 7:52 PM, Graeme Russ wrote: > Hi Gabe, > > On Wed, Nov 30, 2011 at 2:50 PM, Gabe Black wrote: > > > > > > On Tue, Nov 29, 2011 at 7:39 PM, Graeme Russ > wrote: > >> > >> Hi Gabe, > >> > >> On Wed, Nov 30, 2011 at 2:29 PM, Gabe Black > >> wrote: > >> > Hmm, that's in an intervening patch. I didn't think that one was > >> > necessary > >> > but apparently it is. I'll add that to the series and send this out > >> > again. > >> > >> That would be nice ;) > >> > >> P.S. Please stop top-quoting... > >> > >> Regards, > >> > >> Graeme > > > > > > Actually that patch depends on another one too. Since those don't really > go > > with these, I'll just send them out separately and they'll need to be > > applied first. > > Sounds good me > > Regards, > > Graeme > Since this series has to be applied after the other anyway, I think I will send it out again with another patch or two I was holding back. Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Add support for the 32 bit boot protocol to the x86 zboot command.
On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ wrote: > Hi Gabe, > > On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black > wrote: > > These two patches add support for the 32 bit Linux boot protocol to the > > zboot command. > > Going by our previous offline correspondence, I assume this approach still > uses the bzImage's decompression stub? > > Also, as I discussion offline previously, I'm going through the boot_params > with a fine-tooth comb to get a complete picture of what the Linux kernel > actually requires to be filled out in the boot_params structure - I expect > this will result in a 'built_boot_params()' function which is called by > zboot and bootm - possibly with some weak stubs to helper functions > > Regards, > > Graeme > Yes, this supports the 32 bit protocol which includes the decompression stub. I don't think a build_boot_params function which actually builds the bootstub would work for a number of reasons. First, that's not how the boot protocol works. The kernel provides information there that u-boot needs to read, and u-boot shouldn't just make it up. An example of this is what boot protocol is expected. Second, you might find all the things a particular version of the kernel wants right now, but that could easy change at any time and break booting. Third, the boot_params structure isn't compressed (because otherwise the bootloader couldn't fill it out) and building our own wouldn't serve any purpose. If you mean consolidating the existing boot_params code so that both zboot and bootm can use it, that seems reasonable. I'd point out, though, that filling out the table takes a trivial amount of time, so trying to cut corners and not fill it out completely would not only be dangerous, it would very likely not be worth the effort. Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] x86: Import code from coreboot's libpayload to parse the coreboot table
Signed-off-by: Gabe Black
---
arch/x86/cpu/coreboot/Makefile|3 +
arch/x86/cpu/coreboot/ipchecksum.c| 54 ++
arch/x86/cpu/coreboot/sysinfo.c | 33
arch/x86/cpu/coreboot/tables.c| 183 +++
arch/x86/include/asm/ic/coreboot/ipchecksum.h | 37
arch/x86/include/asm/ic/coreboot/sysinfo.h| 64 +++
arch/x86/include/asm/ic/coreboot/tables.h | 241 +
board/chromebook-x86/coreboot/coreboot.c | 10 +
8 files changed, 625 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/cpu/coreboot/ipchecksum.c
create mode 100644 arch/x86/cpu/coreboot/sysinfo.c
create mode 100644 arch/x86/cpu/coreboot/tables.c
create mode 100644 arch/x86/include/asm/ic/coreboot/ipchecksum.h
create mode 100644 arch/x86/include/asm/ic/coreboot/sysinfo.h
create mode 100644 arch/x86/include/asm/ic/coreboot/tables.h
diff --git a/arch/x86/cpu/coreboot/Makefile b/arch/x86/cpu/coreboot/Makefile
index 0444399..13f5f8a 100644
--- a/arch/x86/cpu/coreboot/Makefile
+++ b/arch/x86/cpu/coreboot/Makefile
@@ -33,7 +33,10 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)lib$(SOC).o
+COBJS-$(CONFIG_SYS_COREBOOT) += tables.o
+COBJS-$(CONFIG_SYS_COREBOOT) += ipchecksum.o
COBJS-$(CONFIG_SYS_COREBOOT) += sdram.o
+COBJS-$(CONFIG_SYS_COREBOOT) += sysinfo.o
SOBJS-$(CONFIG_SYS_COREBOOT) += coreboot_car.o
diff --git a/arch/x86/cpu/coreboot/ipchecksum.c
b/arch/x86/cpu/coreboot/ipchecksum.c
new file mode 100644
index 000..63a3aab
--- /dev/null
+++ b/arch/x86/cpu/coreboot/ipchecksum.c
@@ -0,0 +1,54 @@
+/*
+ * This file is part of the libpayload project.
+ *
+ * It has originally been taken from the FreeBSD project.
+ *
+ * Copyright (c) 2001 Charles Mott
+ * Copyright (c) 2008 coresystems GmbH
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+#include
+
+unsigned short ipchksum(const void *vptr, unsigned long nbytes)
+{
+ int sum, oddbyte;
+ const unsigned short *ptr = vptr;
+
+ sum = 0;
+ while (nbytes > 1) {
+ sum += *ptr++;
+ nbytes -= 2;
+ }
+ if (nbytes == 1) {
+ oddbyte = 0;
+ ((u8 *)&oddbyte)[0] = *(u8 *) ptr;
+ ((u8 *)&oddbyte)[1] = 0;
+ sum += oddbyte;
+ }
+ sum = (sum >> 16) + (sum & 0x);
+ sum += (sum >> 16);
+ return ~sum;
+}
diff --git a/arch/x86/cpu/coreboot/sysinfo.c b/arch/x86/cpu/coreboot/sysinfo.c
new file mode 100644
index 000..464f8a1
--- /dev/null
+++ b/arch/x86/cpu/coreboot/sysinfo.c
@@ -0,0 +1,33 @@
+/*
+ * This file is part of the libpayload project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ * Copyright (C) 2009 coresystems GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. I
[U-Boot] [PATCH 4/4] x86: Add infrastructure to extract an e820 table from the coreboot tables
Signed-off-by: Gabe Black
---
arch/x86/cpu/coreboot/sdram.c | 32 ++--
arch/x86/include/asm/zimage.h |5 +
arch/x86/lib/zimage.c | 10 ++
3 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c
index b5b086b..ce73467 100644
--- a/arch/x86/cpu/coreboot/sdram.c
+++ b/arch/x86/cpu/coreboot/sdram.c
@@ -23,6 +23,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -30,18 +32,36 @@
DECLARE_GLOBAL_DATA_PTR;
+unsigned install_e820_map(unsigned max_entries, struct e820entry *entries)
+{
+ int i;
+
+ unsigned num_entries = min(lib_sysinfo.n_memranges, max_entries);
+ if (num_entries < lib_sysinfo.n_memranges) {
+ printf("Warning: Limiting e820 map to %d entries.\n",
+ num_entries);
+ }
+ for (i = 0; i < num_entries; i++) {
+ struct memrange *memrange = &lib_sysinfo.memrange[i];
+
+ entries[i].addr = memrange->base;
+ entries[i].size = memrange->size;
+ entries[i].type = memrange->type;
+ }
+ return num_entries;
+}
+
int dram_init_f(void)
{
int i;
phys_size_t ram_size = 0;
+
for (i = 0; i < lib_sysinfo.n_memranges; i++) {
- unsigned long long end = \
- lib_sysinfo.memrange[i].base +
- lib_sysinfo.memrange[i].size;
- if (lib_sysinfo.memrange[i].type == CB_MEM_RAM &&
- end > ram_size) {
+ struct memrange *memrange = &lib_sysinfo.memrange[i];
+ unsigned long long end = memrange->base + memrange->size;
+
+ if (memrange->type == CB_MEM_RAM && end > ram_size)
ram_size = end;
- }
}
gd->ram_size = ram_size;
if (ram_size == 0)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index a02637f..b172048 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -24,6 +24,8 @@
#ifndef _ASM_ZIMAGE_H_
#define _ASM_ZIMAGE_H_
+#include
+
/* linux i386 zImage/bzImage header. Offsets relative to
* the start of the image */
@@ -65,6 +67,9 @@
#define BZIMAGE_LOAD_ADDR 0x10
#define ZIMAGE_LOAD_ADDR 0x1
+/* Implementation defined function to install an e820 map. */
+unsigned install_e820_map(unsigned max_entries, struct e820entry *);
+
void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
int auto_boot);
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 6843ff6..1fde13f 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -51,6 +51,16 @@
#define COMMAND_LINE_SIZE 2048
+unsigned generic_install_e820_map(unsigned max_entries,
+ struct e820entry *entries)
+{
+ return 0;
+}
+
+unsigned install_e820_map(unsigned max_entries,
+ struct e820entry *entries)
+ __attribute__((weak, alias("generic_install_e820_map")));
+
static void build_command_line(char *command_line, int auto_boot)
{
char *env_command_line;
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] x86: Force the lib_sysinfo structure to be in the .data section
Otherwise it ends up in the .bss section. U-boot assumes that it doesn't
need to copy it over during relocation, and instead fills that whole
section with zeroes. If we really were booting from ROM that would be
appropriate, but we need some information from the coreboot tables (memory
size) before then and have to fill that structure before relocation. We
skirt u-boot's assumption by putting this in .data where it assumes there
is still read only but non-zero data.
Signed-off-by: Gabe Black
---
arch/x86/cpu/coreboot/sysinfo.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sysinfo.c b/arch/x86/cpu/coreboot/sysinfo.c
index 464f8a1..e74fe0a 100644
--- a/arch/x86/cpu/coreboot/sysinfo.c
+++ b/arch/x86/cpu/coreboot/sysinfo.c
@@ -30,4 +30,10 @@
#include
-struct sysinfo_t lib_sysinfo;
+/*
+ * This needs to be in the .data section so that it's copied over during
+ * relocation. By default it's put in the .bss section which is simply filled
+ * with zeroes when transitioning from "ROM", which is really RAM, to other
+ * RAM.
+ */
+struct sysinfo_t lib_sysinfo __attribute__((section(".data")));
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] x86: Determine the ram size using the coreboot tables
This is really only an approximation using the largest RAM address available
in the tables. There may be areas which are marked as reserved which are
actually at the end of RAM.
Signed-off-by: Gabe Black
---
arch/x86/cpu/coreboot/sdram.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c
index b56085a..b5b086b 100644
--- a/arch/x86/cpu/coreboot/sdram.c
+++ b/arch/x86/cpu/coreboot/sdram.c
@@ -24,12 +24,28 @@
#include
#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
int dram_init_f(void)
{
- gd->ram_size = 64*1024*1024;
+ int i;
+ phys_size_t ram_size = 0;
+ for (i = 0; i < lib_sysinfo.n_memranges; i++) {
+ unsigned long long end = \
+ lib_sysinfo.memrange[i].base +
+ lib_sysinfo.memrange[i].size;
+ if (lib_sysinfo.memrange[i].type == CB_MEM_RAM &&
+ end > ram_size) {
+ ram_size = end;
+ }
+ }
+ gd->ram_size = ram_size;
+ if (ram_size == 0)
+ return -1;
return 0;
}
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add code to read in the coreboot tables and fill in memory info.
These changes add code which reads in the coreboot tables exported by coreboot and puts the info into a single structure for easy access. It also adds some code which uses that info to fill in an e820 table. Gabe Black (4): x86: Import code from coreboot's libpayload to parse the coreboot table x86: Determine the ram size using the coreboot tables x86: Force the lib_sysinfo structure to be in the .data section x86: Add infrastructure to extract an e820 table from the coreboot tables arch/x86/cpu/coreboot/Makefile|3 + arch/x86/cpu/coreboot/ipchecksum.c| 54 ++ arch/x86/cpu/coreboot/sdram.c | 38 - arch/x86/cpu/coreboot/sysinfo.c | 39 arch/x86/cpu/coreboot/tables.c| 183 +++ arch/x86/include/asm/ic/coreboot/ipchecksum.h | 37 arch/x86/include/asm/ic/coreboot/sysinfo.h| 64 +++ arch/x86/include/asm/ic/coreboot/tables.h | 241 + arch/x86/include/asm/zimage.h |5 + arch/x86/lib/zimage.c | 10 + board/chromebook-x86/coreboot/coreboot.c | 10 + 11 files changed, 683 insertions(+), 1 deletions(-) create mode 100644 arch/x86/cpu/coreboot/ipchecksum.c create mode 100644 arch/x86/cpu/coreboot/sysinfo.c create mode 100644 arch/x86/cpu/coreboot/tables.c create mode 100644 arch/x86/include/asm/ic/coreboot/ipchecksum.h create mode 100644 arch/x86/include/asm/ic/coreboot/sysinfo.h create mode 100644 arch/x86/include/asm/ic/coreboot/tables.h -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] nds32/ag102: add ag102 soc support
Hi Mike and Wolfgang, 2011/11/30 Mike Frysinger > > For supporting this kind of implementation, I must to put header support > > like linkage.h > > err, i thought i saw u-boot had this in common code. seems it is not (i > must > have been looking in the Linux tree). don't worry about it until we get > that > addressed. > -mike > I think you can send a patch to move linkage.h to common headers at first, than we can move to this step by step. I'll also fix this in these series of patches with manually added linkage.h to NDS32 architecture. Hope your can do this move sooner hence I do not need to send a commit of adding linkage.h into NDS32. :-) Thanks. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] nds32/ag102: add ag102 soc support
On Tuesday 29 November 2011 23:32:27 Macpaul Lin wrote: > these kind of implementation? I know there are such code in Linux. > One benefits might be alignment (marco ENDPROC), and the other looks like > for coding style. makes sure the visibility/alignment/ELF size is correct. for the last part, gdb won't know where the func ends without it and taking a best guess. > For supporting this kind of implementation, I must to put header support > like linkage.h err, i thought i saw u-boot had this in common code. seems it is not (i must have been looking in the Linux tree). don't worry about it until we get that addressed. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] nds32/ag102: add ag102 soc support
Hi Mike, 2011/11/30 Mike Frysinger > On Tuesday 29 November 2011 04:15:05 Macpaul Lin wrote: > > +.globl turnoff_watchdog > > +turnoff_watchdog: > > should be: > ENTRY(turnoff_watchdog) > > > + ret > > and at the end, add: > ENDPROC(turnoff_watchdog) > > seems a lot of the nds32 code could use this fixup ... > -mike > Thanks for your suggestion, however, I'd like to confirm what is the benefits of these kind of implementation? I know there are such code in Linux. One benefits might be alignment (marco ENDPROC), and the other looks like for coding style. For supporting this kind of implementation, I must to put header support like linkage.h from blackfin into nds32's common includes. Currently I don't see other architecture support these kind of code. Would you like to make some comment in more detail and also suggest other custodians? I think if this kind of implementation is good then it is worthy to be adopt to other architectures as well just like Linux. Thanks. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)
Hi Mike,
On Wed, Nov 30, 2011 at 2:52 PM, Mike Frysinger wrote:
> On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote:
>> On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote:
>> > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
>> >> Now ${upstream}/master is always the 'gold standard', so what does the
>> >> conflicted sub-repo dpo with the already published patches?
>> >
>> > there are merge commits and sometimes conflicts in those merges. it
>> > depends on the conflict type as to what Wolfgang will do: tell you to
>> > rebase onto his master and thus it's your problem to resolve the
>> > conflict, or he'll fix it up locally.
>>
>> At this point, how do you make the merge 'conflict free' without re-writing
>> the sub-repo?
>
> you can't. but the counter point is: why is this a problem ? if one patch is
> tweaking the style, but other is deleting the code block altogether, you get a
> conflict, but it's easy to resolve and commit the result. not the best
> example, but many conflicts are trivial to resolve. this is considered part
> of
> the git workflow as well -- people working in parallel on the same tree are
> bound to touch the same code. rather than rebasing, do a merge, get a
> conflict, and then fix the conflict and commit it as part of the merge commit.
>
> it's happened at least 65 times since we switched to git:
> $ git log | grep -c Conflicts:
> 65
Not that many, all things considered. I think one of the big positive side-
effects of using a distributed SCM is that the more structure you apply
to your code, grouping code components together in logical groups, the
less likely you will get conflicts when two people work on two different
features. And such a design facilitates maintaining multiple 'stable'
branches and appliying the same bug fix across each branch - So a good
distributed SCM actively promotes good software design and actively causes
distress when you start hitting those 'less-than-perfect' parts of the code
which encourages (forces) us to refactor and improve.
>
>> >> I had a look at u-boot-blackfin and I noticed that there are
>> >> non-blackfin patches. u-boot-x86 also has the latest u-boot patches but
>> >> there is no merge commit in u-boot-x86 - So how do the u-boot patches
>> >> get into ${sub-repo}/master without a merge?
>> >
>> > i pull Wolfgang's master, put my Blackfin patches on top, and then
>> > publish it and ask for a pull request. i don't pull newer updates from
>> > Wolfgang until he's merged my changes. or at least, i don't publish the
>> > updates.
>>
>> So you pull u-boot/master straight into u-boot-blackfin/master? From what
>> I gather, this is the same as fetch/merge. So if you merge branch 'A' into
>> branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
>> is no second merge commit because the merge is already done?
>
> correct. so when Wolfgang pulls my branch, he either fast forwards because he
> hasn't done any new work, or he gets a merge commit. in either case, when i
> pull his branch, mine is always a fast forward (since his tree has everything
> mine does already).
OK, it sounds like I have it figured out now - I think I can say to anyone
wanting a 'cutting edge' local x86 repo to pull u-boot/master and then
fetch/merge u-boot-x86/master if they need x86 patches that have not yet
been pulled. If they want 'bleeding edge' they can additionally fetch/merge
u-boot-x86/next as well
Thanks for taking the time to explain
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6] x86: Initial commit for running as a coreboot payload
Add a target for running u-boot as a coreboot payload in boards.cfg, a
board, CPU and a config. This is a skeleton implementation which always
reports the size of memory as 64 MB.
Signed-off-by: Gabe Black
---
Changes in v5:
Merge several smaller commits into this single commit.
Changes in v6:
Merge in a fix for the IDE configuration.
arch/x86/cpu/coreboot/Makefile | 55 ++
arch/x86/cpu/coreboot/asm-offsets.c | 25 +++
arch/x86/cpu/coreboot/coreboot_car.S | 29 +++
arch/x86/cpu/coreboot/sdram.c| 39
board/chromebook-x86/coreboot/Makefile | 53 +
board/chromebook-x86/coreboot/coreboot.c | 77
board/chromebook-x86/coreboot/coreboot_pci.c | 30 +++
board/chromebook-x86/coreboot/coreboot_start.S | 29 +++
board/chromebook-x86/coreboot/coreboot_start16.S | 46 +
boards.cfg |1 +
include/configs/coreboot.h | 225 ++
include/serial.h |2 +-
12 files changed, 610 insertions(+), 1 deletions(-)
create mode 100644 arch/x86/cpu/coreboot/Makefile
create mode 100644 arch/x86/cpu/coreboot/asm-offsets.c
create mode 100644 arch/x86/cpu/coreboot/coreboot_car.S
create mode 100644 arch/x86/cpu/coreboot/sdram.c
create mode 100644 board/chromebook-x86/coreboot/Makefile
create mode 100644 board/chromebook-x86/coreboot/coreboot.c
create mode 100644 board/chromebook-x86/coreboot/coreboot_pci.c
create mode 100644 board/chromebook-x86/coreboot/coreboot_start.S
create mode 100644 board/chromebook-x86/coreboot/coreboot_start16.S
create mode 100644 include/configs/coreboot.h
diff --git a/arch/x86/cpu/coreboot/Makefile b/arch/x86/cpu/coreboot/Makefile
new file mode 100644
index 000..0444399
--- /dev/null
+++ b/arch/x86/cpu/coreboot/Makefile
@@ -0,0 +1,55 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# (C) Copyright 2008
+# Graeme Russ, graeme.r...@gmail.com.
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2002
+# Daniel Engström, Omicron Ceti AB, dan...@omicron.se.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB:= $(obj)lib$(SOC).o
+
+COBJS-$(CONFIG_SYS_COREBOOT) += sdram.o
+
+SOBJS-$(CONFIG_SYS_COREBOOT) += coreboot_car.o
+
+SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/x86/cpu/coreboot/asm-offsets.c
b/arch/x86/cpu/coreboot/asm-offsets.c
new file mode 100644
index 000..97937da
--- /dev/null
+++ b/arch/x86/cpu/coreboot/asm-offsets.c
@@ -0,0 +1,25 @@
+/*
+ * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
+ *
+ * This program is used to generate definitions needed by
+ * assembly language modules.
+ *
+ * We use the technique used in the OSF Mach kernel code:
+ * generate asm statements containing #defines,
+ * compile this file to assembler, and then extract the
+ * #defines from the assembly-language output.
+ *
+ * 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.
+ */
+
+#include
+#include
+
+int main(void)
+{
+ DEFINE(GENERATED_GD_RELOC_OFF, offsetof(gd_t, reloc_off));
+ return 0;
+}
diff --git a/arch/x86/cpu/coreboot/coreboot_car.S
b/arch/x86/cpu/coreboot/coreboot_car.S
new file mode 100644
index 000..3cc2575
--- /dev/null
+++ b/arch/x86/cpu/coreboot/coreboot_car.S
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2010-2011
+ * Graeme Russ,
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program
Re: [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)
On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote:
> On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote:
> > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
> >> Now ${upstream}/master is always the 'gold standard', so what does the
> >> conflicted sub-repo dpo with the already published patches?
> >
> > there are merge commits and sometimes conflicts in those merges. it
> > depends on the conflict type as to what Wolfgang will do: tell you to
> > rebase onto his master and thus it's your problem to resolve the
> > conflict, or he'll fix it up locally.
>
> At this point, how do you make the merge 'conflict free' without re-writing
> the sub-repo?
you can't. but the counter point is: why is this a problem ? if one patch is
tweaking the style, but other is deleting the code block altogether, you get a
conflict, but it's easy to resolve and commit the result. not the best
example, but many conflicts are trivial to resolve. this is considered part of
the git workflow as well -- people working in parallel on the same tree are
bound to touch the same code. rather than rebasing, do a merge, get a
conflict, and then fix the conflict and commit it as part of the merge commit.
it's happened at least 65 times since we switched to git:
$ git log | grep -c Conflicts:
65
> >> I had a look at u-boot-blackfin and I noticed that there are
> >> non-blackfin patches. u-boot-x86 also has the latest u-boot patches but
> >> there is no merge commit in u-boot-x86 - So how do the u-boot patches
> >> get into ${sub-repo}/master without a merge?
> >
> > i pull Wolfgang's master, put my Blackfin patches on top, and then
> > publish it and ask for a pull request. i don't pull newer updates from
> > Wolfgang until he's merged my changes. or at least, i don't publish the
> > updates.
>
> So you pull u-boot/master straight into u-boot-blackfin/master? From what
> I gather, this is the same as fetch/merge. So if you merge branch 'A' into
> branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
> is no second merge commit because the merge is already done?
correct. so when Wolfgang pulls my branch, he either fast forwards because he
hasn't done any new work, or he gets a merge commit. in either case, when i
pull his branch, mine is always a fast forward (since his tree has everything
mine does already).
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
Hi Gabe, On Wed, Nov 30, 2011 at 2:50 PM, Gabe Black wrote: > > > On Tue, Nov 29, 2011 at 7:39 PM, Graeme Russ wrote: >> >> Hi Gabe, >> >> On Wed, Nov 30, 2011 at 2:29 PM, Gabe Black >> wrote: >> > Hmm, that's in an intervening patch. I didn't think that one was >> > necessary >> > but apparently it is. I'll add that to the series and send this out >> > again. >> >> That would be nice ;) >> >> P.S. Please stop top-quoting... >> >> Regards, >> >> Graeme > > > Actually that patch depends on another one too. Since those don't really go > with these, I'll just send them out separately and they'll need to be > applied first. Sounds good me Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
On Tue, Nov 29, 2011 at 7:39 PM, Graeme Russ wrote: > Hi Gabe, > > On Wed, Nov 30, 2011 at 2:29 PM, Gabe Black > wrote: > > Hmm, that's in an intervening patch. I didn't think that one was > necessary > > but apparently it is. I'll add that to the series and send this out > again. > > That would be nice ;) > > P.S. Please stop top-quoting... > > Regards, > > Graeme > Actually that patch depends on another one too. Since those don't really go with these, I'll just send them out separately and they'll need to be applied first. Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Add support for the 32 bit boot protocol to the x86 zboot command.
Hi Gabe, On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black wrote: > These two patches add support for the 32 bit Linux boot protocol to the > zboot command. Going by our previous offline correspondence, I assume this approach still uses the bzImage's decompression stub? Also, as I discussion offline previously, I'm going through the boot_params with a fine-tooth comb to get a complete picture of what the Linux kernel actually requires to be filled out in the boot_params structure - I expect this will result in a 'built_boot_params()' function which is called by zboot and bootm - possibly with some weak stubs to helper functions Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
Hi Gabe, On Wed, Nov 30, 2011 at 2:29 PM, Gabe Black wrote: > Hmm, that's in an intervening patch. I didn't think that one was necessary > but apparently it is. I'll add that to the series and send this out again. That would be nice ;) P.S. Please stop top-quoting... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
Hmm, that's in an intervening patch. I didn't think that one was necessary
but apparently it is. I'll add that to the series and send this out again.
Gabe
On Tue, Nov 29, 2011 at 7:23 PM, Graeme Russ wrote:
> Hi Gabe,
>
> Thanks, I've been itching for this :)
>
> On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black
> wrote:
> > This change conditionally modifies the zboot command so that it can use
> the
> > 32 bit boot protocol. This is necessary because the 16 bit realmode entry
> > point assumes that it can call BIOS services which neither coreboot nor
> > u-boot provide.
> >
> > Signed-off-by: Gabe Black
> > ---
> > arch/x86/include/asm/zimage.h |4 +-
> > arch/x86/lib/bootm.c |6 +++-
> > arch/x86/lib/zimage.c | 49
> +++-
> > 3 files changed, 44 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/zimage.h
> b/arch/x86/include/asm/zimage.h
> > index 1a77e00..8ee6a74 100644
> > --- a/arch/x86/include/asm/zimage.h
> > +++ b/arch/x86/include/asm/zimage.h
> > @@ -46,8 +46,8 @@
> >
> > void *load_zimage(char *image, unsigned long kernel_size,
> > unsigned long initrd_addr, unsigned long initrd_size,
> > - int auto_boot);
> > + int auto_boot, void **load_address);
> >
> > -void boot_zimage(void *setup_base);
> > +void boot_zimage(void *setup_base, void *load_address);
> >
> > #endif
> > diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
> > index bac7b4f..0905809 100644
> > --- a/arch/x86/lib/bootm.c
> > +++ b/arch/x86/lib/bootm.c
> > @@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char * const
> argv[],
> >void*base_ptr = NULL;
> >ulong os_data, os_len;
> >image_header_t *hdr;
> > + void*load_address;
> >
> > #if defined(CONFIG_FIT)
> >const void *data;
> > @@ -75,7 +76,8 @@ int do_bootm_linux(int flag, int argc, char * const
> argv[],
> >
> > #ifdef CONFIG_CMD_ZBOOT
> >base_ptr = load_zimage((void *)os_data, os_len,
> > - images->rd_start, images->rd_end -
> images->rd_start, 0);
> > + images->rd_start, images->rd_end -
> images->rd_start,
> > + 0, &load_address);
> > #endif
> >
> >if (NULL == base_ptr) {
> > @@ -92,7 +94,7 @@ int do_bootm_linux(int flag, int argc, char * const
> argv[],
> >/* we assume that the kernel is in place */
> >printf("\nStarting kernel ...\n\n");
> >
> > - boot_zimage(base_ptr);
> > + boot_zimage(base_ptr, load_address);
> >/* does not return */
> >
> > error:
> > diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> > index 3b33486..1003929 100644
> > --- a/arch/x86/lib/zimage.c
> > +++ b/arch/x86/lib/zimage.c
> > @@ -83,13 +83,12 @@ static void build_command_line(char *command_line,
> int auto_boot)
> >
> > void *load_zimage(char *image, unsigned long kernel_size,
> > unsigned long initrd_addr, unsigned long initrd_size,
> > - int auto_boot)
> > + int auto_boot, void **load_address)
> > {
> >struct boot_params *setup_base;
> >int setup_size;
> >int bootproto;
> >int big_image;
> > - void *load_address;
> >
> >struct boot_params *params = (struct boot_params *)image;
> >struct setup_header *hdr = ¶ms->hdr;
> > @@ -136,14 +135,23 @@ void *load_zimage(char *image, unsigned long
> kernel_size,
> >
> >/* Determine load address */
> >if (big_image)
> > - load_address = (void *)BZIMAGE_LOAD_ADDR;
> > + *load_address = (void *)BZIMAGE_LOAD_ADDR;
> >else
> > - load_address = (void *)ZIMAGE_LOAD_ADDR;
> > + *load_address = (void *)ZIMAGE_LOAD_ADDR;
> > +
> > +#if defined CONFIG_ZBOOT_32
> > + printf("Building boot_params at 0x%8.8lx\n", (ulong)setup_base);
> > + memset(setup_base, 0, sizeof(*setup_base));
> > + setup_base->hdr = params->hdr;
> >
> > + setup_base->e820_entries = install_e820_map(
> > + ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
>
> Where is install_e820_map() defined?
>
> > +#else
> >/* load setup */
> >printf("Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n",
> > (ulong)setup_base, setup_size);
> >memmove(setup_base, image, setup_size);
> > +#endif
> >
> >printf("Using boot protocol version %x.%02x\n",
> > (bootproto & 0xff00) >> 8, bootproto & 0xff);
> > @@ -182,7 +190,7 @@ void *load_zimage(char *image, unsigned long
> kernel_size,
> >
> >if (hdr->setup_sects >= 15) {
> >printf("Linux kernel version %s\n",
> > - (char *)setup_base +
> > + (char *)params +
> > hdr->kernel_version + 0x200);
> >
Re: [U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
Hi Gabe,
Thanks, I've been itching for this :)
On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black wrote:
> This change conditionally modifies the zboot command so that it can use the
> 32 bit boot protocol. This is necessary because the 16 bit realmode entry
> point assumes that it can call BIOS services which neither coreboot nor
> u-boot provide.
>
> Signed-off-by: Gabe Black
> ---
> arch/x86/include/asm/zimage.h | 4 +-
> arch/x86/lib/bootm.c | 6 +++-
> arch/x86/lib/zimage.c | 49 +++-
> 3 files changed, 44 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
> index 1a77e00..8ee6a74 100644
> --- a/arch/x86/include/asm/zimage.h
> +++ b/arch/x86/include/asm/zimage.h
> @@ -46,8 +46,8 @@
>
> void *load_zimage(char *image, unsigned long kernel_size,
> unsigned long initrd_addr, unsigned long initrd_size,
> - int auto_boot);
> + int auto_boot, void **load_address);
>
> -void boot_zimage(void *setup_base);
> +void boot_zimage(void *setup_base, void *load_address);
>
> #endif
> diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
> index bac7b4f..0905809 100644
> --- a/arch/x86/lib/bootm.c
> +++ b/arch/x86/lib/bootm.c
> @@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
> void *base_ptr = NULL;
> ulong os_data, os_len;
> image_header_t *hdr;
> + void *load_address;
>
> #if defined(CONFIG_FIT)
> const void *data;
> @@ -75,7 +76,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
>
> #ifdef CONFIG_CMD_ZBOOT
> base_ptr = load_zimage((void *)os_data, os_len,
> - images->rd_start, images->rd_end - images->rd_start,
> 0);
> + images->rd_start, images->rd_end - images->rd_start,
> + 0, &load_address);
> #endif
>
> if (NULL == base_ptr) {
> @@ -92,7 +94,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
> /* we assume that the kernel is in place */
> printf("\nStarting kernel ...\n\n");
>
> - boot_zimage(base_ptr);
> + boot_zimage(base_ptr, load_address);
> /* does not return */
>
> error:
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 3b33486..1003929 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -83,13 +83,12 @@ static void build_command_line(char *command_line, int
> auto_boot)
>
> void *load_zimage(char *image, unsigned long kernel_size,
> unsigned long initrd_addr, unsigned long initrd_size,
> - int auto_boot)
> + int auto_boot, void **load_address)
> {
> struct boot_params *setup_base;
> int setup_size;
> int bootproto;
> int big_image;
> - void *load_address;
>
> struct boot_params *params = (struct boot_params *)image;
> struct setup_header *hdr = ¶ms->hdr;
> @@ -136,14 +135,23 @@ void *load_zimage(char *image, unsigned long
> kernel_size,
>
> /* Determine load address */
> if (big_image)
> - load_address = (void *)BZIMAGE_LOAD_ADDR;
> + *load_address = (void *)BZIMAGE_LOAD_ADDR;
> else
> - load_address = (void *)ZIMAGE_LOAD_ADDR;
> + *load_address = (void *)ZIMAGE_LOAD_ADDR;
> +
> +#if defined CONFIG_ZBOOT_32
> + printf("Building boot_params at 0x%8.8lx\n", (ulong)setup_base);
> + memset(setup_base, 0, sizeof(*setup_base));
> + setup_base->hdr = params->hdr;
>
> + setup_base->e820_entries = install_e820_map(
> + ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
Where is install_e820_map() defined?
> +#else
> /* load setup */
> printf("Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n",
> (ulong)setup_base, setup_size);
> memmove(setup_base, image, setup_size);
> +#endif
>
> printf("Using boot protocol version %x.%02x\n",
> (bootproto & 0xff00) >> 8, bootproto & 0xff);
> @@ -182,7 +190,7 @@ void *load_zimage(char *image, unsigned long kernel_size,
>
> if (hdr->setup_sects >= 15) {
> printf("Linux kernel version %s\n",
> - (char *)setup_base +
> + (char *)params +
> hdr->kernel_version + 0x200);
> } else {
> printf("Setup Sectors < 15 - "
> @@ -237,17 +245,33 @@ void *load_zimage(char *image, unsigned long
> kernel_size,
> build_command_line((char *)setup_base + COMMAND_LINE_OFFSET,
> auto_boot);
>
> printf("Loading %czImage at address 0x%08x (%ld bytes)\n",
> - big_image ? 'b' : ' ', (u32)load_address, kernel_size);
> + big_image ? 'b' : ' ', (u32)*load_address, kernel_size);
>
>
[U-Boot] [PATCH 2/2] x86: Add support for booting Linux using the 32 bit boot protocol
This change conditionally modifies the zboot command so that it can use the
32 bit boot protocol. This is necessary because the 16 bit realmode entry
point assumes that it can call BIOS services which neither coreboot nor
u-boot provide.
Signed-off-by: Gabe Black
---
arch/x86/include/asm/zimage.h |4 +-
arch/x86/lib/bootm.c |6 +++-
arch/x86/lib/zimage.c | 49 +++-
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 1a77e00..8ee6a74 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -46,8 +46,8 @@
void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
- int auto_boot);
+ int auto_boot, void **load_address);
-void boot_zimage(void *setup_base);
+void boot_zimage(void *setup_base, void *load_address);
#endif
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index bac7b4f..0905809 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
void*base_ptr = NULL;
ulong os_data, os_len;
image_header_t *hdr;
+ void*load_address;
#if defined(CONFIG_FIT)
const void *data;
@@ -75,7 +76,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
#ifdef CONFIG_CMD_ZBOOT
base_ptr = load_zimage((void *)os_data, os_len,
- images->rd_start, images->rd_end - images->rd_start, 0);
+ images->rd_start, images->rd_end - images->rd_start,
+ 0, &load_address);
#endif
if (NULL == base_ptr) {
@@ -92,7 +94,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
/* we assume that the kernel is in place */
printf("\nStarting kernel ...\n\n");
- boot_zimage(base_ptr);
+ boot_zimage(base_ptr, load_address);
/* does not return */
error:
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 3b33486..1003929 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -83,13 +83,12 @@ static void build_command_line(char *command_line, int
auto_boot)
void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
- int auto_boot)
+ int auto_boot, void **load_address)
{
struct boot_params *setup_base;
int setup_size;
int bootproto;
int big_image;
- void *load_address;
struct boot_params *params = (struct boot_params *)image;
struct setup_header *hdr = ¶ms->hdr;
@@ -136,14 +135,23 @@ void *load_zimage(char *image, unsigned long kernel_size,
/* Determine load address */
if (big_image)
- load_address = (void *)BZIMAGE_LOAD_ADDR;
+ *load_address = (void *)BZIMAGE_LOAD_ADDR;
else
- load_address = (void *)ZIMAGE_LOAD_ADDR;
+ *load_address = (void *)ZIMAGE_LOAD_ADDR;
+
+#if defined CONFIG_ZBOOT_32
+ printf("Building boot_params at 0x%8.8lx\n", (ulong)setup_base);
+ memset(setup_base, 0, sizeof(*setup_base));
+ setup_base->hdr = params->hdr;
+ setup_base->e820_entries = install_e820_map(
+ ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
+#else
/* load setup */
printf("Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n",
(ulong)setup_base, setup_size);
memmove(setup_base, image, setup_size);
+#endif
printf("Using boot protocol version %x.%02x\n",
(bootproto & 0xff00) >> 8, bootproto & 0xff);
@@ -182,7 +190,7 @@ void *load_zimage(char *image, unsigned long kernel_size,
if (hdr->setup_sects >= 15) {
printf("Linux kernel version %s\n",
- (char *)setup_base +
+ (char *)params +
hdr->kernel_version + 0x200);
} else {
printf("Setup Sectors < 15 - "
@@ -237,17 +245,33 @@ void *load_zimage(char *image, unsigned long kernel_size,
build_command_line((char *)setup_base + COMMAND_LINE_OFFSET, auto_boot);
printf("Loading %czImage at address 0x%08x (%ld bytes)\n",
- big_image ? 'b' : ' ', (u32)load_address, kernel_size);
+ big_image ? 'b' : ' ', (u32)*load_address, kernel_size);
-
- memmove(load_address, image + setup_size, kernel_size);
+ memmove(*load_address, image + setup_size, kernel_size);
/* ready for booting */
return setup_base;
}
-void boot_zimage(void *setup_base)
+void boot_zimage(void *setup_base, void *load_address)
{
+#if defined CONFIG_ZBOOT_32
+
[U-Boot] [PATCH 0/2] Add support for the 32 bit boot protocol to the x86 zboot command.
These two patches add support for the 32 bit Linux boot protocol to the zboot command. Gabe Black (2): x86: Clean up the x86 zimage code in preparation to extend it x86: Add support for booting Linux using the 32 bit boot protocol arch/x86/include/asm/zimage.h | 25 + arch/x86/lib/bootm.c |6 +- arch/x86/lib/zimage.c | 125 ++--- 3 files changed, 86 insertions(+), 70 deletions(-) -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] x86: Clean up the x86 zimage code in preparation to extend it
This change cleans up some formatting issues in the zimage handling code, and
converts it from using offsets added to a base pointer to using the available
structure definitions which were already being included.
Signed-off-by: Gabe Black
---
arch/x86/include/asm/zimage.h | 21 --
arch/x86/lib/zimage.c | 82 ++--
2 files changed, 45 insertions(+), 58 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index a02637f..1a77e00 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -27,27 +27,6 @@
/* linux i386 zImage/bzImage header. Offsets relative to
* the start of the image */
-#define CMD_LINE_MAGIC_OFF 0x020 /* Magic 0xa33f if the offset below is valid
*/
-#define CMD_LINE_OFFSET_OFF 0x022 /* Offset to comandline */
-#define SETUP_SECTS_OFF 0x1F1 /* The size of the setup in sectors */
-#define ROOT_FLAGS_OFF 0x1F2 /* If set, the root is mounted readonly */
-#define VID_MODE_OFF0x1FA /* Video mode control */
-#define ROOT_DEV_OFF0x1FC /* Default root device number */
-#define BOOT_FLAG_OFF 0x1FE /* 0xAA55 magic number */
-#define HEADER_OFF 0x202 /* Magic signature "HdrS" */
-#define VERSION_OFF 0x206 /* Boot protocol version supported */
-#define REALMODE_SWTCH_OFF 0x208 /* Boot loader hook (see below) */
-#define START_SYS_OFF 0x20C /* Points to kernel version string */
-#define TYPE_OF_LOADER_OFF 0x210 /* Boot loader identifier */
-#define LOADFLAGS_OFF 0x211 /* Boot protocol option flags */
-#define SETUP_MOVE_SIZE_OFF 0x212 /* Move to high memory size (used with
hooks) */
-#define CODE32_START_OFF0x214 /* Boot loader hook (see below) */
-#define RAMDISK_IMAGE_OFF 0x218 /* initrd load address (set by boot loader)
*/
-#define RAMDISK_SIZE_OFF0x21C /* initrd size (set by boot loader) */
-#define HEAP_END_PTR_OFF0x224 /* Free memory after setup end */
-#define CMD_LINE_PTR_OFF0x228 /* 32-bit pointer to the kernel command line
*/
-
-
#define HEAP_FLAG 0x80
#define BIG_KERNEL_FLAG 0x01
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 6843ff6..3b33486 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (c) 2011 The Chromium OS Authors.
* (C) Copyright 2002
* Daniel Engström, Omicron Ceti AB,
*
@@ -84,21 +85,22 @@ void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
int auto_boot)
{
- void *setup_base;
+ struct boot_params *setup_base;
int setup_size;
int bootproto;
int big_image;
void *load_address;
- struct setup_header *hdr;
- hdr = (struct setup_header *)(image + SETUP_SECTS_OFF);
+ struct boot_params *params = (struct boot_params *)image;
+ struct setup_header *hdr = ¶ms->hdr;
/* base address for real-mode segment */
- setup_base = (void *)DEFAULT_SETUP_BASE;
+ setup_base = (struct boot_params *)DEFAULT_SETUP_BASE;
if (KERNEL_MAGIC != hdr->boot_flag) {
- printf("Error: Invalid Boot Flag (found 0x%04x, expected
0x%04x)\n",
- hdr->boot_flag, KERNEL_MAGIC);
+ printf("Error: Invalid Boot Flag "
+ "(found 0x%04x, expected 0x%04x)\n",
+ hdr->boot_flag, KERNEL_MAGIC);
return 0;
} else {
printf("Valid Boot Flag\n");
@@ -133,9 +135,10 @@ void *load_zimage(char *image, unsigned long kernel_size,
(hdr->loadflags & BIG_KERNEL_FLAG);
/* Determine load address */
- load_address = (void *)(big_image ?
- BZIMAGE_LOAD_ADDR :
- ZIMAGE_LOAD_ADDR);
+ if (big_image)
+ load_address = (void *)BZIMAGE_LOAD_ADDR;
+ else
+ load_address = (void *)ZIMAGE_LOAD_ADDR;
/* load setup */
printf("Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n",
@@ -146,8 +149,8 @@ void *load_zimage(char *image, unsigned long kernel_size,
(bootproto & 0xff00) >> 8, bootproto & 0xff);
if (bootproto == 0x0100) {
- *(u16 *)(setup_base + CMD_LINE_MAGIC_OFF) = COMMAND_LINE_MAGIC;
- *(u16 *)(setup_base + CMD_LINE_OFFSET_OFF) =
COMMAND_LINE_OFFSET;
+ setup_base->screen_info.cl_magic = COMMAND_LINE_MAGIC;
+ setup_base->screen_info.cl_offset = COMMAND_LINE_OFFSET;
/*
* A very old kernel MUST have its real-mode code
@@ -159,33 +162,36 @@ void *load_zimage(char *image, unsigned long kernel_size,
/* Copy the command line */
memmove((void *)0x99000,
- setup_base + COMMAND_LINE_OFFSET,
+
Re: [U-Boot] uboot to load uboot
The board is based on MPC8377ERDB S From: Mike Frysinger To: u-boot@lists.denx.de; Sridhar Addagada Sent: Tuesday, November 29, 2011 11:20 AM Subject: Re: [U-Boot] uboot to load uboot On Tuesday 29 November 2011 00:38:40 Sridhar Addagada wrote: > Here is a scenario, i have a working version of the u-boot on my board, and > am trying my changes. Am not sure it is going to freeze the board, so > would like the present version to load the new version for testing before > it can be burned to flash. Is it possible to do this or is it already > done? i think it depends on the architecture. most cannot do this. what arch/cpu/SoC/board exactly are you using ? please fix your e-mail client to wrap long lines -mike___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] reboard: Add generic relocation feature
On Tuesday 29 November 2011 18:49:58 Graeme Russ wrote: > On Wed, Nov 30, 2011 at 10:41 AM, Simon Glass wrote: > > On Tue, Nov 29, 2011 at 3:20 PM, Mike Frysinger wrote: > >> On Tuesday 29 November 2011 17:15:18 Simon Glass wrote: > >>> On Mon, Nov 28, 2011 at 7:07 PM, Mike Frysinger wrote: > >>> > On Monday 21 November 2011 18:57:56 Simon Glass wrote: > >>> >> --- /dev/null > >>> >> +++ b/board/Makefile > >>> >> > >>> >> +ifndef CONFIG_SYS_LEGACY_BOARD > >>> >> +COBJS+= reloc.o > >>> >> +endif > >>> > > >>> > i don't think relocation should be tied "legacy board". not all > >>> > arches do relocation at all, which means they might never opt in to > >>> > this aspect. > >>> > >>> If they don't do reloc then when we move them over we should add a > >>> CONFIG for this I think. But would prefer to wait until we have an > >>> arch moving over that requires no relocation, before addressing this. > >> > >> Blackfin does no relocation, so i'd be annoyed to have to carry a define > >> like "LEGACY_BOARD" forever ;) > > > > Would you be happier with CONFIG_ARCH_NO_RELOCATION? > > CONFIG_SYS_NO_RELOC either is fine by me -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/1] 'patman' patch generation, checking and submission script
What is this?
=
This tool is a Python script which:
- Creates patch directly from your branch
- Cleans them up by removing unwanted tags
- Inserts a cover letter with change lists
- Runs the patches through checkpatch.pl and its own checks
- Optionally emails them out to selected people
It is intended to automate patch creation and make it a less
error-prone process. It is useful for U-Boot and Linux work so far,
since it uses the checkpatch.pl script.
It is configured almost entirely by tags it finds in your commits.
This means that you can work on a number of different branches at
once, and keep the settings with each branch rather than having to
git format-patch, git send-email, etc. with the correct parameters
each time. So for example if you put:
Series-to: fred.bl...@napier.co.nz
in one of your commits, the series will be sent there.
See the README file for full details.
Changes in v2:
- Fix up use of Color in series.py (avoid runtime error)
Changes in v3:
- Use -M with git format-patch to so that file moves are tracked
- Fix generation of cc list to match patch names correctly
- Change cc-list tmpfile name to start with patman
- Support git's alias file if found in config sendemail.aliasesfile
- Support recursive aliases
- Use @{upstream} instead of the previous mess (thanks Anton Staff)
- Find checkpatch.pl in U-Boot tree
- Expand the README to include info about suggested workflow
- Add option to display the README
- Add a few more tests (but still very incomplete)
- Tidy up gitutil and settings to separate code better
Simon Glass (1):
Add 'patman' patch generation, checking and submission script
tools/scripts/patman/.gitignore |1 +
tools/scripts/patman/README | 408
tools/scripts/patman/checkpatch.py | 161 +
tools/scripts/patman/command.py | 72 ++
tools/scripts/patman/commit.py | 81 +++
tools/scripts/patman/gitutil.py | 369 +
tools/scripts/patman/patchstream.py | 437 +++
tools/scripts/patman/patman |1 +
tools/scripts/patman/patman.py | 151
tools/scripts/patman/series.py | 229 ++
tools/scripts/patman/settings.py| 81 +++
tools/scripts/patman/terminal.py| 86 +++
tools/scripts/patman/test.py| 250
13 files changed, 2327 insertions(+), 0 deletions(-)
create mode 100644 tools/scripts/patman/.gitignore
create mode 100644 tools/scripts/patman/README
create mode 100644 tools/scripts/patman/checkpatch.py
create mode 100644 tools/scripts/patman/command.py
create mode 100644 tools/scripts/patman/commit.py
create mode 100644 tools/scripts/patman/gitutil.py
create mode 100644 tools/scripts/patman/patchstream.py
create mode 12 tools/scripts/patman/patman
create mode 100755 tools/scripts/patman/patman.py
create mode 100644 tools/scripts/patman/series.py
create mode 100644 tools/scripts/patman/settings.py
create mode 100644 tools/scripts/patman/terminal.py
create mode 100644 tools/scripts/patman/test.py
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] reboard: Add generic relocation feature
Hi Simon, On Wed, Nov 30, 2011 at 10:41 AM, Simon Glass wrote: > Hi Mike, > > On Tue, Nov 29, 2011 at 3:20 PM, Mike Frysinger wrote: >> On Tuesday 29 November 2011 17:15:18 Simon Glass wrote: >>> On Mon, Nov 28, 2011 at 7:07 PM, Mike Frysinger wrote: >>> > On Monday 21 November 2011 18:57:56 Simon Glass wrote: >>> >> --- /dev/null >>> >> +++ b/board/Makefile >>> >> >>> >> +ifndef CONFIG_SYS_LEGACY_BOARD >>> >> +COBJS += reloc.o >>> >> +endif >>> > >>> > i don't think relocation should be tied "legacy board". not all arches >>> > do relocation at all, which means they might never opt in to this >>> > aspect. >>> >>> If they don't do reloc then when we move them over we should add a >>> CONFIG for this I think. But would prefer to wait until we have an >>> arch moving over that requires no relocation, before addressing this. >> >> Blackfin does no relocation, so i'd be annoyed to have to carry a define like >> "LEGACY_BOARD" forever ;) >> -mike >> > > Would you be happier with CONFIG_ARCH_NO_RELOCATION? CONFIG_SYS_NO_RELOC Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)
Hi Mike,
On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote:
> On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
>> 1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
>> and the order that they get pulled results in a conflict
>
> when a merge is done and a conflict is thrown up, it's up to the guy doing the
> merge to resolve that conflict and commit the result. this is considered
> "normal" in the git workflow. just search the git log for "Conflicts:" to see
> this in action.
>
>> 2) ${sub-repo}/master has been published but not pulled before more
>> patches have been added to ${upstream}/master - If ${sub-repo}/master
>> does a fetch/pull of ${upstream}/master, there will be a conflict
>
> there will only be a conflict, if there's a conflict (i.e. two patches
> changing
> the same file in the same place). simply having different changesets in the
Ah yes, that's what I meant
> repos is normal git workflow. this is why we have "merge commits" in the git
> log. these show up all the time when Wolfgang merges branches.
>> Now ${upstream}/master is always the 'gold standard', so what does the
>> conflicted sub-repo dpo with the already published patches?
>
> there are merge commits and sometimes conflicts in those merges. it depends
> on
> the conflict type as to what Wolfgang will do: tell you to rebase onto his
> master and thus it's your problem to resolve the conflict, or he'll fix it up
> locally.
At this point, how do you make the merge 'conflict free' without re-writing
the sub-repo? Or is this one of those rare occassions where you have to do
what you have to do?
>> Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
>> with ${upstream}/master - I understand how that works when nothing in
>> that you are responsible for ever changes in ${upstream}/master without
>> going through your ${sub-repo}/master, but what about when that is not the
>> case. For example, with some of the major architectural changes being made
>> to create more common code, how to you ensure the patches in your
>> ${sub-repo}/master do not conflict?
>
> i keep them in a topic branch and ask Wolfgang to pull those, and i rewrite
> those branches since they're "development" ones
>
> most common example with my repo i think is the "sf" branch where i merge spi
> flash related changes
>
>> I had a look at u-boot-blackfin and I noticed that there are non-blackfin
>> patches. u-boot-x86 also has the latest u-boot patches but there is no
>> merge commit in u-boot-x86 - So how do the u-boot patches get into
>> ${sub-repo}/master without a merge?
>
> i pull Wolfgang's master, put my Blackfin patches on top, and then publish it
> and ask for a pull request. i don't pull newer updates from Wolfgang until
> he's merged my changes. or at least, i don't publish the updates.
So you pull u-boot/master straight into u-boot-blackfin/master? From what
I gather, this is the same as fetch/merge. So if you merge branch 'A' into
branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
is no second merge commit because the merge is already done?
>> Lastly, is there any real difference between a sub-repo and a branch?
>
> from git's pov, not really. a sub-repo is just to keep things more cleanly
> separated and to grants ACLs on a simpler basis. we could just as easily have
> all sub-repos be in Wolfgang's tree in namespaced branches:
>master
>x86/master
>blackfin/master
>arm/master
>arm/ti/master
>arm/tegra/master
>..
>
> but then things can get "noisy" as you see all the pushes/changes made by
> other people. *shrug*.
I thought that was the case
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix some bugs in the EFI support
The ALLOC_CACHE_ALIGN_BUFFER macro allocates a pointer to a buffer, and the
address of the pointer and not the buffer was being passed to a function
that expected the other. This change fixes a few places that bug crops up.
Also, it provides a default definition for the CONFIG_SYS_CACHELINE_SIZE
macro to avoid compiler errors.
Signed-off-by: Gabe Black
---
disk/part_efi.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index e7f2714..c94d808 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -37,6 +37,10 @@
#include "part_efi.h"
#include
+#ifndef CONFIG_SYS_CACHELINE_SIZE
+#define CONFIG_SYS_CACHELINE_SIZE __BIGGEST_ALIGNMENT__
+#endif
+
#if defined(CONFIG_CMD_IDE) || \
defined(CONFIG_CMD_MG_DISK) || \
defined(CONFIG_CMD_SATA) || \
@@ -130,7 +134,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
}
/* This function validates AND fills in the GPT header and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
-&(gpt_head), &gpt_pte) != 1) {
+gpt_head, &gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
return;
}
@@ -169,7 +173,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int
part,
/* This function validates AND fills in the GPT header and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- &(gpt_head), &gpt_pte) != 1) {
+ gpt_head, &gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
return -1;
}
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Turn on support for EFI's GPT in the coreboot config
Actually, I found some compile errors in the upstream EFI support. The patch I'll be sending out soon should be applied before this one so everything still builds. Gabe On Tue, Nov 29, 2011 at 1:58 PM, Graeme Russ wrote: > Hi Gabe, > > On Wed, Nov 30, 2011 at 7:07 AM, Gabe Black wrote: > > No, that would be fine. > > OK, can you send an updated patch - I'll apply it to u-boot-x86/next > > Regards, > > Graeme > > > > > Gabe > > > > > > On Tue, Nov 29, 2011 at 2:58 AM, Graeme Russ > wrote: > >> > >> Hi Gabe, > >> > >> On 29/11/11 17:57, Gabe Black wrote: > >> > This allows u-boot to figure out the partitions of a chrome-os > install. > >> > > >> > Signed-off-by: Gabe Black > >> > --- > >> > include/configs/coreboot.h |1 + > >> > 1 files changed, 1 insertions(+), 0 deletions(-) > >> > > >> > diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h > >> > index 348a25b..e98201d 100644 > >> > --- a/include/configs/coreboot.h > >> > +++ b/include/configs/coreboot.h > >> > @@ -89,6 +89,7 @@ > >> > / > >> > * DISK Partition support > >> > / > >> > +#define CONFIG_EFI_PARTITION > >> > #define CONFIG_DOS_PARTITION > >> > #define CONFIG_MAC_PARTITION > >> > #define CONFIG_ISO_PARTITION /* Experimental */ > >> > >> Since "x86: Initial commit for running as a coreboot payload" has not > been > >> applied yet, is there any reason this (and "x86: Fix IDE configuration > for > >> the coreboot board") could not be merged into it? > >> > >> Regards, > >> > >> Graeme > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] reboard: Add generic relocation feature
Hi Mike, On Tue, Nov 29, 2011 at 3:20 PM, Mike Frysinger wrote: > On Tuesday 29 November 2011 17:15:18 Simon Glass wrote: >> On Mon, Nov 28, 2011 at 7:07 PM, Mike Frysinger wrote: >> > On Monday 21 November 2011 18:57:56 Simon Glass wrote: >> >> --- /dev/null >> >> +++ b/board/Makefile >> >> >> >> +ifndef CONFIG_SYS_LEGACY_BOARD >> >> +COBJS += reloc.o >> >> +endif >> > >> > i don't think relocation should be tied "legacy board". not all arches >> > do relocation at all, which means they might never opt in to this >> > aspect. >> >> If they don't do reloc then when we move them over we should add a >> CONFIG for this I think. But would prefer to wait until we have an >> arch moving over that requires no relocation, before addressing this. > > Blackfin does no relocation, so i'd be annoyed to have to carry a define like > "LEGACY_BOARD" forever ;) > -mike > Would you be happier with CONFIG_ARCH_NO_RELOCATION? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere
Hi Mike, On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysinger wrote: > On Tuesday 29 November 2011 17:09:19 Simon Glass wrote: >> On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger wrote: >> > On Tuesday 29 November 2011 15:08:09 Simon Glass wrote: >> >> On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote: >> >> > On Monday 21 November 2011 18:57:54 Simon Glass wrote: >> >> >> We are introducing a new unified board setup and we want this to >> >> >> be the default. So we need to opt all architectures out first. >> >> > >> >> > the define says "BOARD", so shouldn't it be in board configs ? we can >> >> > do that easily: add it to include/config_defaults.h. then boards >> >> > that opt into it will #undef it in their own configs. >> >> >> >> Thanks for looking at this. >> >> >> >> I see this as an architecture feature - perhaps a rename to something >> >> like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving >> >> boards over one at a time, or having boards for a particular >> >> architecture that still do things the old way - it just increases >> >> maintenance and means that my eventual patch to remove >> >> arch/xxx/lib/board.c cannot be applied. >> >> >> >> My idea for this CONFIG is purely as a temporary measure before boards >> >> more over to the generic approach. >> > >> > how about we have the reloc code live in lib/reloc/ and be controlled by >> > CONFIG_LEGACY_ARCH_RELOC ? >> >> My only concern is that if something like SPL needs to keep all the >> early code at the start of the image. I personally don't like the >> current method for doing that (would prefer a distinctive .text.early >> section name) and I don't believe that any SPL implementation actually >> relocates itself. > > not sure why this matters ? > -mike > Because if they require linking with reloc.o then we will get link failures some boards. There is some ugly stuff in SPL which pulls in particular files from around U-Boot. Any time I split something out of start.S I may break something. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)
On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
> 1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
> and the order that they get pulled results in a conflict
when a merge is done and a conflict is thrown up, it's up to the guy doing the
merge to resolve that conflict and commit the result. this is considered
"normal" in the git workflow. just search the git log for "Conflicts:" to see
this in action.
> 2) ${sub-repo}/master has been published but not pulled before more
> patches have been added to ${upstream}/master - If ${sub-repo}/master
> does a fetch/pull of ${upstream}/master, there will be a conflict
there will only be a conflict, if there's a conflict (i.e. two patches changing
the same file in the same place). simply having different changesets in the
repos is normal git workflow. this is why we have "merge commits" in the git
log. these show up all the time when Wolfgang merges branches.
> Now ${upstream}/master is always the 'gold standard', so what does the
> conflicted sub-repo dpo with the already published patches?
there are merge commits and sometimes conflicts in those merges. it depends on
the conflict type as to what Wolfgang will do: tell you to rebase onto his
master and thus it's your problem to resolve the conflict, or he'll fix it up
locally.
> Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
> with ${upstream}/master - I understand how that works when nothing in
> that you are responsible for ever changes in ${upstream}/master without
> going through your ${sub-repo}/master, but what about when that is not the
> case. For example, with some of the major architectural changes being made
> to create more common code, how to you ensure the patches in your
> ${sub-repo}/master do not conflict?
i keep them in a topic branch and ask Wolfgang to pull those, and i rewrite
those branches since they're "development" ones
most common example with my repo i think is the "sf" branch where i merge spi
flash related changes
> I had a look at u-boot-blackfin and I noticed that there are non-blackfin
> patches. u-boot-x86 also has the latest u-boot patches but there is no
> merge commit in u-boot-x86 - So how do the u-boot patches get into
> ${sub-repo}/master without a merge?
i pull Wolfgang's master, put my Blackfin patches on top, and then publish it
and ask for a pull request. i don't pull newer updates from Wolfgang until
he's merged my changes. or at least, i don't publish the updates.
> Lastly, is there any real difference between a sub-repo and a branch?
from git's pov, not really. a sub-repo is just to keep things more cleanly
separated and to grants ACLs on a simpler basis. we could just as easily have
all sub-repos be in Wolfgang's tree in namespaced branches:
master
x86/master
blackfin/master
arm/master
arm/ti/master
arm/tegra/master
..
but then things can get "noisy" as you see all the pushes/changes made by
other people. *shrug*.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] reboard: Add generic relocation feature
On Tuesday 29 November 2011 17:15:18 Simon Glass wrote: > On Mon, Nov 28, 2011 at 7:07 PM, Mike Frysinger wrote: > > On Monday 21 November 2011 18:57:56 Simon Glass wrote: > >> --- /dev/null > >> +++ b/board/Makefile > >> > >> +ifndef CONFIG_SYS_LEGACY_BOARD > >> +COBJS+= reloc.o > >> +endif > > > > i don't think relocation should be tied "legacy board". not all arches > > do relocation at all, which means they might never opt in to this > > aspect. > > If they don't do reloc then when we move them over we should add a > CONFIG for this I think. But would prefer to wait until we have an > arch moving over that requires no relocation, before addressing this. Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere
On Tuesday 29 November 2011 17:09:19 Simon Glass wrote: > On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger wrote: > > On Tuesday 29 November 2011 15:08:09 Simon Glass wrote: > >> On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote: > >> > On Monday 21 November 2011 18:57:54 Simon Glass wrote: > >> >> We are introducing a new unified board setup and we want this to > >> >> be the default. So we need to opt all architectures out first. > >> > > >> > the define says "BOARD", so shouldn't it be in board configs ? we can > >> > do that easily: add it to include/config_defaults.h. then boards > >> > that opt into it will #undef it in their own configs. > >> > >> Thanks for looking at this. > >> > >> I see this as an architecture feature - perhaps a rename to something > >> like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving > >> boards over one at a time, or having boards for a particular > >> architecture that still do things the old way - it just increases > >> maintenance and means that my eventual patch to remove > >> arch/xxx/lib/board.c cannot be applied. > >> > >> My idea for this CONFIG is purely as a temporary measure before boards > >> more over to the generic approach. > > > > how about we have the reloc code live in lib/reloc/ and be controlled by > > CONFIG_LEGACY_ARCH_RELOC ? > > My only concern is that if something like SPL needs to keep all the > early code at the start of the image. I personally don't like the > current method for doing that (would prefer a distinctive .text.early > section name) and I don't believe that any SPL implementation actually > relocates itself. not sure why this matters ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] ARM: omap3: add support to Technexion twister board
On Thu, Nov 24, 2011 at 8:44 AM, Stefano Babic wrote: > The twister board is a development board using > the TAM3517 SOM. > > Support for NAND, 2 Ethernet (EMAC and SMC911), > USB (EHCI_OMAP). [snip] > +#if defined(CONFIG_GENERIC_MMC) && defined(CONFIG_OMAP_HSMMC) && \ > + !defined(CONFIG_SPL_BUILD) Another little change, OMAP_HSMMC requires GENERIC_MMC so no need to test both. With this, and Wolfgang's change made in a v3, are you and Tapani otherwise in agreement for how this looks going in? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] worth submitting a patch to fix u-boot for lite 5200b?
On Mon, Nov 21, 2011 at 12:39 PM, Robert P. J. Day wrote: > On Mon, 21 Nov 2011, Tom Rini wrote: > >> On Sun, Nov 20, 2011 at 12:34 PM, Robert P. J. Day >> wrote: >> > >> > from back in april, karim yaghmour pointed out a problem related to >> > older lite5200 boards, and suggested a fix: >> > >> > http://old.nabble.com/-U-Boot---PATCH--Env.-vars-fix-for-lite5200-td31013626.html >> > >> > i checked my git clone of u-boot and it seems that the file >> > include/configs/IceCube.h still contains the original code: >> > >> > #if defined(CONFIG_SYS_LOWBOOT16) >> > #define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE + 0x0004) >> > #endif >> > #endif /* CONFIG_SYS_LOWBOOT */ >> > #endif /* CONFIG_LITE5200B */ >> > >> > would it be proper to submit a patch to change 0x0004 to >> > 0x0005? i admit i don't know enough about what else might be >> > affected or what else might also need to change, i know only that that >> > change is necessary for u-boot to run properly on that type of board. >> > >> > thoughts? is that an appropriate standalone patch? >> >> Well, a patch that addresses Wolfgang's comments and is git am'able >> would be a step in the right direction. > > i don't know enough about what's going on underneath to know if that > single-line patch is standalone, whether it would make logical sense > to group it with any other changes, or even if it's sufficiently > specialized that it should be user-selectable thru a config option. > > i do know that that change is sufficient for the boards we're using. > if that's sufficient to justify a patch, i can submit that to the > list. otherwise, i'm definitely going to need some guidance from a > powerpc expert. It sounds like you've got a number of boards available to you. I would suggest making a git am'able patch, explaining what you know (and what you don't know), posting it and making sure to cc Wolfgang (since he owns IceCube_5200 and mpc5xxx in general), after testing on the various revs available to you, as time permits of course. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] reboard: Add generic relocation feature
Hi Simon, On Wed, Nov 30, 2011 at 9:15 AM, Simon Glass wrote: > Hi Mike, > > On Mon, Nov 28, 2011 at 7:07 PM, Mike Frysinger wrote: >> On Monday 21 November 2011 18:57:56 Simon Glass wrote: >>> board/Makefile | 45 >>> board/reloc.c| 101 >> >> not to bikeshed, but i don't think we want files in board/. how about >> board/common/ or board/generic/ instead ? > > Yes I wasn't sure, let's go with lib/reloc.c unless we hit SPL > problems (do we really need lib/reloc/reloc.c?) Hmmm, I think common/reloc.c may be more appropriate - I think /lib/ is more for externally sourced libraries Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Almost solved] M5282EVB undefined reference to `environment'
On 25/11/11 14:52, James Steward wrote: So it compiles env_embedded.c, but doesn't include it in libcommon.o? vim common/Makefile XCOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o becomes COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o :q make all Hey, presto, build now completes! So how should this be corrected properly? Can anyone suggest how the build process should be fixed? Regards, James. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)
Hi Andy, Mike,
Thanks for all your help. I've managed to clean-up the x86 repo, but I
still have a few lingering thoughts if you can spare a few more moments...
I understand why a published (i.e. pushed onto the denx server) branch
should never be altered and should, therefore, never require a forced push.
But I can think of two (probably the same) problematic scenarios:
1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
and the order that they get pulled results in a conflict
2) ${sub-repo}/master has been published but not pulled before more
patches have been added to ${upstream}/master - If ${sub-repo}/master
does a fetch/pull of ${upstream}/master, there will be a conflict
Now ${upstream}/master is always the 'gold standard', so what does the
conflicted sub-repo dpo with the already published patches?
Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
with ${upstream}/master - I understand how that works when nothing in
that you are responsible for ever changes in ${upstream}/master without
going through your ${sub-repo}/master, but what about when that is not the
case. For example, with some of the major architectural changes being made
to create more common code, how to you ensure the patches in your
${sub-repo}/master do not conflict?
I had a look at u-boot-blackfin and I noticed that there are non-blackfin
patches. u-boot-x86 also has the latest u-boot patches but there is no
merge commit in u-boot-x86 - So how do the u-boot patches get into
${sub-repo}/master without a merge?
Lastly, is there any real difference between a sub-repo and a branch? It
seems to me the principles of pull, merge, rebase etc are about the same
between the two.
Sorry if these questions are 'assumed knowledge' but I really don't want
to get x86 messed up again
Also, I know there are some good git tutorials out there (and I've read
a few) but I find it so much easier when referencing the U-Boot dev
cycle because a) it's what I'm working on and b) as an example, it seems
to be a good balance between 'fairly simple git workflow' and 'insanely
complicated git workflow'
Thanks and Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
The following changes since commit f2695a272849764cda09bcce6f86d03105e9e46d: Marek Vasut (1): PXA: Drop XM250 board are available in the git repository at: git://git.denx.de/u-boot-ti.git master Anatolij Gustschin (1): ARM: davinci_dm6467Tevm: Fix build breakage Aneesh V (13): armv7: disable L2 cache in cleanup_before_linux() armv7: include armv7/cpu.c in SPL build armv7: setup vector start.S: remove omap3 specific code from start.S omap: Improve PLL parameter calculation tool omap4: ttyO2 instead of ttyS2 in default bootargs omap: fix cache line size for omap3/omap4 boards omap4460: fix TPS initialization omap: remove I2C from SPL omap4: emif: fix error in driver omap4460: add ES1.1 identification omap4+: streamline CONFIG_SYS_TEXT_BASE and other SDRAM addresses omap4: fix IO setting Christian Riesch (8): arm, davinci: Move pinmux functions from board to arch tree arm, hawkboard: Remove obsolete struct pinmux_config i2c_pins arm, da850evm: Do pinmux configuration for EMAC together with other pinmuxes arm, da850: Add pinmux configurations to the arch tree arm, da850evm: Use the pinmux configurations defined in the arch tree arm, hawkboard: Use the pinmux configurations defined in the arch tree arm, davinci: Remove duplication of pinmux configuration code arm: printf() is not available in some SPL configurations Heiko Schocher (6): arm, arm926ejs: always do cpu critical inits arm, davinci: move davinci_rtc struct to hardware.h arm, davinci, da850: add uart1 tx rx pinmux config arm, board/davinci/common/misc.c: Codingstyle cleanup arm, davinci: move misc function in arch tree arm, davinci: add support for am1808 based enbw_cmc board Ilya Yanok (10): davinci_emac: move arch-independent defines to separate header davinci_emac: use internal addresses in buffer descriptors davinci_emac: conditionally compile specific PHY support arm926ejs: add noop implementation for dcache ops davinci_emac: fix for running with dcache enabled davinci_emac: hardcode 100Mbps for AM35xx and RMII AM35xx: add EMAC support AM3517: move AM3517 specific mux defines to generic header nand_spl_simple: add support for software ECC omap_gpmc: use SOFTECC in SPL if it's enabled Koen Kooi (1): BeagleBoard: config: Really switch to ttyO2 Prabhakar Lad (1): ARM: davici_emac: Fix condition for number of phy detects Thomas Weber (3): ARM: OMAP3: Remove unused define CONFIG_OMAP3430 ARM: OMAP3: Remove unused define SDRC_R_C_B ARM: OMAP: Remove STACKSIZE for IRQ and FIQ if unused Tom Rini (15): omap3: mem: Comment enable_gpmc_cs_config more OMAP3: Update SDRC dram_init to always call make_cs1_contiguous() OMAP3: Add a helper function to set timings in SDRC OMAP3: Change mem_ok to clear again after reading back OMAP3: Remove get_mem_type prototype omap3: mem: Add MCFG helper macro OMAP3: Add optimal SDRC autorefresh control values OMAP3: Suffix all Micron memory timing parts with their speed OMAP3 SPL: Rework memory initalization and devkit8000 support OMAP3 SPL: Add identify_nand_chip function OMAP3: Add SPL support to Beagleboard OMAP3: Add SPL support to omap3_evm AM3517: Add SPL support AM3517 CraneBoard: Add SPL support OMAP3: Add SPL_BOARD_INIT hook MAINTAINERS|1 + arch/arm/cpu/arm926ejs/Makefile|2 +- arch/arm/cpu/arm926ejs/cache.c | 75 +++ arch/arm/cpu/arm926ejs/davinci/Makefile|3 +- arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c| 36 +- arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c | 171 ++ arch/arm/cpu/arm926ejs/davinci/dp83848.c |1 + arch/arm/cpu/arm926ejs/davinci/et1011c.c |1 + arch/arm/cpu/arm926ejs/davinci/ksz8873.c |1 + arch/arm/cpu/arm926ejs/davinci/lxt972.c|1 + .../arm/cpu/arm926ejs/davinci}/misc.c | 19 +- .../arm/cpu/arm926ejs/davinci/pinmux.c |0 arch/arm/cpu/arm926ejs/start.S |6 +- arch/arm/cpu/armv7/Makefile|4 +- arch/arm/cpu/armv7/cpu.c |1 + arch/arm/cpu/armv7/omap-common/clocks-common.c |8 - arch/arm/cpu/armv7/omap-common/emif-common.c |4 +- arch/arm/cpu/armv7/omap-common/spl.c |5 +- arch/arm/cpu/armv7/omap3/Makefile |4 + arch/arm/cpu/armv7/omap3/board.c |5 + arch/arm/cpu/armv7/omap3/emac.c| 44 ++ arch/arm/cpu/armv7/omap3/lowlevel_init.S |8 + arch/arm/cpu/armv7/omap3/mem.c | 13 +- arch/arm/cpu/armv7/omap3/sdrc.c
Re: [U-Boot] [PATCH v4 12/14] OMAP3: Add SPL support to omap3_evm
On Fri, Nov 18, 2011 at 3:48 PM, Tom Rini wrote: > Add Hynix 200MHz timing information to . > This also changes CONFIG_SYS_TEXT_BASE to 0x8010. > > Signed-off-by: Tom Rini In ToT we now have EFI partition table support in the 'full' build. I'm disabling EFI support for SPL since that's something that the ROM code won't grok anyhow (or rather, it would only grok the compat table and look there for what it needs). This is only noticed since EFI needs crc32 support which we don't expose to SPL today. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] reboard: Add generic relocation feature
Hi Mike, On Mon, Nov 28, 2011 at 7:07 PM, Mike Frysinger wrote: > On Monday 21 November 2011 18:57:56 Simon Glass wrote: >> board/Makefile | 45 >> board/reloc.c | 101 > > not to bikeshed, but i don't think we want files in board/. how about > board/common/ or board/generic/ instead ? Yes I wasn't sure, let's go with lib/reloc.c unless we hit SPL problems (do we really need lib/reloc/reloc.c?) > >> --- /dev/null >> +++ b/board/Makefile >> >> +ifndef CONFIG_SYS_LEGACY_BOARD >> +COBJS += reloc.o >> +endif > > i don't think relocation should be tied "legacy board". not all arches do > relocation at all, which means they might never opt in to this aspect. If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this. > >> --- a/include/common.h >> +++ b/include/common.h >> >> -void relocate_code (ulong, gd_t *, ulong) __attribute__ ((noreturn)); >> +#include > > i'd think very few funcs would need this. so maybe we should make the few > places include reloc.h explicitly. > -mike > Yes I wanted to do that but was concerned about complaints of including multiple headers in every board.c for this. I really don't like common.h so I will change it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere
+omap, samsung, imx maintainers Hi Mike, On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger wrote: > On Tuesday 29 November 2011 15:08:09 Simon Glass wrote: >> On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote: >> > On Monday 21 November 2011 18:57:54 Simon Glass wrote: >> >> We are introducing a new unified board setup and we want this to >> >> be the default. So we need to opt all architectures out first. >> > >> > the define says "BOARD", so shouldn't it be in board configs ? we can do >> > that easily: add it to include/config_defaults.h. then boards that opt >> > into it will #undef it in their own configs. >> >> Thanks for looking at this. >> >> I see this as an architecture feature - perhaps a rename to something >> like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving >> boards over one at a time, or having boards for a particular >> architecture that still do things the old way - it just increases >> maintenance and means that my eventual patch to remove >> arch/xxx/lib/board.c cannot be applied. >> >> My idea for this CONFIG is purely as a temporary measure before boards >> more over to the generic approach. > > how about we have the reloc code live in lib/reloc/ and be controlled by > CONFIG_LEGACY_ARCH_RELOC ? > -mike > Yes I can do that. My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself. Perhaps someone in OMAP / Samsung knows? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] sandbox: Add timer simulation
Hi Mike, On Tue, Nov 29, 2011 at 1:41 PM, Mike Frysinger wrote: > On Tuesday 29 November 2011 15:04:04 Simon Glass wrote: >> On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger wrote: >> > On Tuesday 29 November 2011 11:55:17 Simon Glass wrote: >> >> On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote: >> >> > Simon: did we decide to start a dedicated sandbox repo ? >> >> >> >> We didn't decide - it was an idea and I suppose given Wolfgang's email >> >> about workload and the early and patch-needy state of sandbox I >> >> suspect we should do this. The other option is perhaps for an existing >> >> maintainer to collect things to push into staging (if there is such a >> >> maintainer interested in sandbox). >> >> >> >> Wolfgang, do you want a sandbox repo? >> > >> > well, one of these two things is going to happen :). i'd prefer a >> > dedicated repo, otherwise i'll start using a branch for it in an >> > existing repo. >> >> OK - who can maintain it? Preferably not someone who will be doing a >> lot of sandbox patches I suppose so that rules me out :-) > > you or me or both. i'm fine with any of those three options. > -mike > I vote for you as you already do this for blackfin and I might get back into this and break fourth with a huge bunch of sandbox patches at any moment. But I can help if you want to have a holiday sometime. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Turn on support for EFI's GPT in the coreboot config
Hi Gabe, On Wed, Nov 30, 2011 at 7:07 AM, Gabe Black wrote: > No, that would be fine. OK, can you send an updated patch - I'll apply it to u-boot-x86/next Regards, Graeme > > Gabe > > > On Tue, Nov 29, 2011 at 2:58 AM, Graeme Russ wrote: >> >> Hi Gabe, >> >> On 29/11/11 17:57, Gabe Black wrote: >> > This allows u-boot to figure out the partitions of a chrome-os install. >> > >> > Signed-off-by: Gabe Black >> > --- >> > include/configs/coreboot.h | 1 + >> > 1 files changed, 1 insertions(+), 0 deletions(-) >> > >> > diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h >> > index 348a25b..e98201d 100644 >> > --- a/include/configs/coreboot.h >> > +++ b/include/configs/coreboot.h >> > @@ -89,6 +89,7 @@ >> > / >> > * DISK Partition support >> > / >> > +#define CONFIG_EFI_PARTITION >> > #define CONFIG_DOS_PARTITION >> > #define CONFIG_MAC_PARTITION >> > #define CONFIG_ISO_PARTITION /* Experimental */ >> >> Since "x86: Initial commit for running as a coreboot payload" has not been >> applied yet, is there any reason this (and "x86: Fix IDE configuration for >> the coreboot board") could not be merged into it? >> >> Regards, >> >> Graeme > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/14] Add more framework to OMAP3 SPL, port more boards
On Fri, Nov 18, 2011 at 3:47 PM, Tom Rini wrote: > Hey all, > > This is related to, but a bit different from the RFT thread I made with > beagleboard SPL patches. I've incorporated the feedback about splitting > the changes up a lot more and after talking with Scott Wood on IRC after > the ML thread, I've created an omap3 specific file with the NAND related > stuff these boards need (since it would have gotten very big for what's > really needed here at this stage). The series is checkpatch.pl clean. > > What we have in patches 1-8 is bugfixing and cleanup of the memory code. > It's worth noting that without these changes we do some very 'funny' > (read: wrong) things on some platforms like omap3_evm where we find 384MB > memory when there's really only 256MB (and maybe 256 on the 128MB boards, > not sure). > > Patch 9 adds another hook for SDRC boards to be able to say what timings > they have because on say beagle or omap3_evm, we have a few choices. We > also convert devkit8000 here. > > Patch 10 adds a new CONFIG (CONFIG_SPL_OMAP3_ID_NAND) and file so that > OMAP3 boards which have a PoP chip for NAND/DDR can find out what they are > and decide on timings based on that. > > Patches 11 and 12 convert Beagleboard and OMAP3 EVM to SPL. > > Patches 13 and 14 convert the am3517 evm and am3517 crane boards (which > don't use SDRC but EMIF4) to SPL as well (given Ilya Yanok fixed a bug > in for emif4 this is just a mechanical change). > > Changes in v4: > - Update this to match the feedback I'd incorporated before > - Update enable_gpmc_cs_config to not use so many magic values > and explain the bitshifts. > - Add MCFG macro to calculate this value for the various DDR chips > that are in use. > - Enhance the comments in to say to read the > TRM to understand what all possible values are and bitshifts and > update the comments about rfr_ctrl to explain why they aren't broken > into values + shifts. > - The above three should cover all of Heiko Schocher's feedback. > > Changes in v3: > - Rename CONFIG_SPL_OMAP3_POP_PROBE to CONFIG_SPL_OMAP3_ID_NAND at Igor's > request (and function to identify_nand_chip). > - Drop an unused CONFIG_OMAP3_MICRON_DDR from all of the board config files > > Changes in v2: > - Incorporate Igor Grinberg's feedback (except non-CodingStyle whitespacing). > - Move to ToT (so omap3_evm patch is reworked a good deal, others that > touch reworked and use new macros when applicable) > - Fixed a few more typos and hardcoded values to defines while addressing > Igor's feedback. After talking with Wolfgang, this will be merged to u-boot-ti. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] sandbox: Add timer simulation
On Tuesday 29 November 2011 15:04:04 Simon Glass wrote: > On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger wrote: > > On Tuesday 29 November 2011 11:55:17 Simon Glass wrote: > >> On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote: > >> > Simon: did we decide to start a dedicated sandbox repo ? > >> > >> We didn't decide - it was an idea and I suppose given Wolfgang's email > >> about workload and the early and patch-needy state of sandbox I > >> suspect we should do this. The other option is perhaps for an existing > >> maintainer to collect things to push into staging (if there is such a > >> maintainer interested in sandbox). > >> > >> Wolfgang, do you want a sandbox repo? > > > > well, one of these two things is going to happen :). i'd prefer a > > dedicated repo, otherwise i'll start using a branch for it in an > > existing repo. > > OK - who can maintain it? Preferably not someone who will be doing a > lot of sandbox patches I suppose so that rules me out :-) you or me or both. i'm fine with any of those three options. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere
On Tuesday 29 November 2011 15:08:09 Simon Glass wrote: > On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote: > > On Monday 21 November 2011 18:57:54 Simon Glass wrote: > >> We are introducing a new unified board setup and we want this to > >> be the default. So we need to opt all architectures out first. > > > > the define says "BOARD", so shouldn't it be in board configs ? we can do > > that easily: add it to include/config_defaults.h. then boards that opt > > into it will #undef it in their own configs. > > Thanks for looking at this. > > I see this as an architecture feature - perhaps a rename to something > like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving > boards over one at a time, or having boards for a particular > architecture that still do things the old way - it just increases > maintenance and means that my eventual patch to remove > arch/xxx/lib/board.c cannot be applied. > > My idea for this CONFIG is purely as a temporary measure before boards > more over to the generic approach. how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/7] arm, davinci: Remove duplication of pinmux configuration code
On Tue, Nov 29, 2011 at 2:24 PM, Tom Rini wrote: > On Tue, Nov 29, 2011 at 2:46 AM, Christian Riesch > wrote: >> This patch replaces the pinmux configuration code in >> arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c by the code from >> arch/arm/cpu/arm926ejs/davinci/pinmux.c. > [snip] >> +/* pinmux_resource[] vector is defined in the board specific file */ >> +extern const struct pinmux_resource pinmuxes[]; >> +extern const int pinmuxes_size; > > This is a checkpatch warning. I've moved the extern / comment to > . And on further review / hair pulling, unchanged. The code makes more sense with the externs not hidden and is better with this change than without but I think we need to find something a bit more clever still than what's going on today or was going on before (with pinmux being done in board_init). In this case I also don't think adding spl_board_init() will help matters. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/7] arm, davinci: Remove duplication of pinmux configuration code
On Tue, Nov 29, 2011 at 2:46 AM, Christian Riesch wrote: > This patch replaces the pinmux configuration code in > arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c by the code from > arch/arm/cpu/arm926ejs/davinci/pinmux.c. [snip] > +/* pinmux_resource[] vector is defined in the board specific file */ > +extern const struct pinmux_resource pinmuxes[]; > +extern const int pinmuxes_size; This is a checkpatch warning. I've moved the extern / comment to . -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] omap: fix cache line size for omap3/omap4 boards
On Tue, Nov 22, 2011 at 10:00 PM, Aneesh V wrote: > On Tuesday 22 November 2011 09:28 PM, Tom Rini wrote: >> >> On 11/22/2011 02:38 AM, Aneesh V wrote: >>> >>> Cc: Tom Rini >>> Signed-off-by: Aneesh V >> >> Except for adding whitespace to include/configs/omap3_evm.h, > > Will fix it. To be clear, since there wasn't a v2 and it's just dropping a change, I'll do that as I push this into u-boot-ti. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: vexpress: Extend default boot sequence to load script from MMC
On Tue, Nov 29, 2011 at 6:46 AM, Jon Medhurst (Tixy)
wrote:
> Extend the default boot sequence on Versatile Express to load a boot
> script from MMC.
>
> Signed-off-by: Jon Medhurst
Is there any interest in defining a common 'fancy' boot command? Over
on beagleboard (and a few other eval boards) we are (or will be)
doing, roughly:
Is there mmc? {
Can we load a bootscript? {
load it, do it
}
Can we load uEnv.txt? {
Did it set 'uenvcmd'? {
Run it
}
}
Did we load the kernel? {
bootm it
}
}
Try nand.
And it's not hard to replace NAND with "whatever flash the board sets"
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: davici_emac: Fix condition for number of phy detects
On Mon, Nov 28, 2011 at 9:30 PM, Prabhakar Lad
wrote:
> Sandeep,
>
> Can you take this patch ?
>
> Regards,
> --Prabhakar Lad
>
> On Thu, Nov 17, 2011 at 6:34 PM, Heiko Schocher wrote:
>
>> Hello prabhakar.cse...@gmail.com
>>
>> prabhakar.cse...@gmail.com wrote:
>> > From: Prabhakar Lad
>> >
>> > Fix the condition for number of phys in
>> > davinci_eth_phy_detect() function.
>> > CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
>> > phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
>> > davinci emac initilazed one less than the number of phy count.
>> >
>> > Signed-off-by: Prabhakar Lad
>> > ---
>> > drivers/net/davinci_emac.c | 2 +-
>> > 1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
>> > index 36c33af..34b6f94 100644
>> > --- a/drivers/net/davinci_emac.c
>> > +++ b/drivers/net/davinci_emac.c
>> > @@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
>> > for (i = 0, j = 0; i < 32; i++)
>> > if (phy_act_state & (1 << i)) {
>> > count++;
>> > - if (count < CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
>> > + if (count <= CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
>> > active_phy_addr[j++] = i;
>> > } else {
>> > printf("%s: to many PHYs detected.\n",
>>
>> good catch!
>>
>> Acked-by: Heiko Schocher
(Will be) queued to u-boot-ti, thanks!
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't git clone u-boot-ti.git
On Mon, Nov 28, 2011 at 10:39 PM, bing bing wrote: > Hello, > > Who can help me to this git clone issue? > I'm trying to use git bash tool to get u-boo-ti.git but just get > error"fatal: the remote end hung up unexpectedly", but I can get u-boot.git. > > What's the problem? What is the exact command line you tried? Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Turn on support for EFI's GPT in the coreboot config
No, that would be fine. Gabe On Tue, Nov 29, 2011 at 2:58 AM, Graeme Russ wrote: > Hi Gabe, > > On 29/11/11 17:57, Gabe Black wrote: > > This allows u-boot to figure out the partitions of a chrome-os install. > > > > Signed-off-by: Gabe Black > > --- > > include/configs/coreboot.h |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h > > index 348a25b..e98201d 100644 > > --- a/include/configs/coreboot.h > > +++ b/include/configs/coreboot.h > > @@ -89,6 +89,7 @@ > > / > > * DISK Partition support > > / > > +#define CONFIG_EFI_PARTITION > > #define CONFIG_DOS_PARTITION > > #define CONFIG_MAC_PARTITION > > #define CONFIG_ISO_PARTITION /* Experimental */ > > Since "x86: Initial commit for running as a coreboot payload" has not been > applied yet, is there any reason this (and "x86: Fix IDE configuration for > the coreboot board") could not be merged into it? > > Regards, > > Graeme > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere
Hi Mike, On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote: > On Monday 21 November 2011 18:57:54 Simon Glass wrote: >> We are introducing a new unified board setup and we want this to >> be the default. So we need to opt all architectures out first. > > the define says "BOARD", so shouldn't it be in board configs ? we can do that > easily: add it to include/config_defaults.h. then boards that opt into it > will > #undef it in their own configs. Thanks for looking at this. I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied. My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach. Regards, Simon > -mike > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] sandbox: Add timer simulation
Hi Mike, On Tue, Nov 29, 2011 at 10:40 AM, Mike Frysinger wrote: > On Tuesday 29 November 2011 11:55:17 Simon Glass wrote: >> On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote: >> > Simon: did we decide to start a dedicated sandbox repo ? >> >> We didn't decide - it was an idea and I suppose given Wolfgang's email >> about workload and the early and patch-needy state of sandbox I >> suspect we should do this. The other option is perhaps for an existing >> maintainer to collect things to push into staging (if there is such a >> maintainer interested in sandbox). >> >> Wolfgang, do you want a sandbox repo? > > well, one of these two things is going to happen :). i'd prefer a dedicated > repo, otherwise i'll start using a branch for it in an existing repo. > -mike > OK - who can maintain it? Preferably not someone who will be doing a lot of sandbox patches I suppose so that rules me out :-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] tegra: Add support for UART init in cpu board.c
Hi Stephen, On Tue, Nov 29, 2011 at 9:24 AM, Stephen Warren wrote: > Simon Glass wrote at Monday, November 28, 2011 6:05 PM: >> We add a way of initialising the selected of UARTs prior to relocation. >> Boards can use the board_init_uart_f() instead of repeating this code >> themselves. >> >> Signed-off-by: Simon Glass > > The code looks reasonable. Is there a reason why UARTC and UARTE aren't > supported? Still, they could be added later when needed, so either way, No real reason other than I don't actually have hardware to test those... Patches welcome :-) > > Acked-by: Stephen Warren Thanks, Simon > > -- > nvpublic > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] net: ll_temac: Add LL TEMAC driver to u-boot
Am Sonntag, den 27.11.2011, 23:29 +0100 schrieb Wolfgang Denk: > Dear Stephan Linz, > --snip-- > > > This special 'DCR' function can map into indirect DCR access. But > > unfortunately in_be32() and out_be32() for Microblaze are not real > > functions. They are CPP defines :-( > > Change it? Turning them into inline functions should be not too > difficult. Hello Wolfgang, Hello Michal, I have sync arch/microblaze/include/asm/io.h with Linux kernel code. Now I ask me whether there is any option to test all the io helper functions in a simple way? Do you know one? Best regards, Stephan > > > I will review arch/microblaze/include/asm/io.h together with Michal. > > Until then it would be nice if we could keep this code as it is. I will > > fix the dublicate code if we have in/out functions -- no defines. > > Hm... past experience has shown that the stragey of adding bad code > first and then cleaning it up has never worked really well, nor fast. > Insisting on clean patches from the beginning is probably more > painful, but almost always faster, and more reliable. > > Best regards, > > Wolfgang Denk > -- Viele Grüße, Stephan Linz __ MB-Ref: http://www.li-pro.de/xilinx_mb:mbref:start OpenDCC: http://www.li-pro.net/opendcc.phtml PC/M: http://www.li-pro.net/pcm.phtml Sourceforge: http://sourceforge.net/users/slz Gitorious: https://gitorious.org/~slz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot-ti
Hey all, As you might have gathered from the flurry of emails I'm now a co-custodian of the u-boot-ti tree. I just wanted to take a minute and thank Sandeep for all the work he's put in over the last few years and thank everyone in advance for their patience as I go over the queue of stuff that touches TI stuff and review / pull things in. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] arm: printf() is not available in some SPL configurations
On Tue, Nov 29, 2011 at 3:11 AM, Christian Riesch wrote: > This patch avoids build breakage for SPLs that do not support printf. > > Signed-off-by: Christian Riesch > Cc: Wolfgang Denk > Cc: Albert Aribaud > Acked-by: Tom Rini > Acked-by: Andreas Bießmann (Will be) queued to u-boot-ti, thanks for your patience. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] Remove duplication of pinmux configuration code
On Tue, Nov 29, 2011 at 2:46 AM, Christian Riesch wrote: > Hi, > this is v4 of the first part of my recent patchset > > [PATCH v3 00/15] Add an SPL to boot the da850evm from SPI > http://lists.denx.de/pipermail/u-boot/2011-November/82.html > > Changes for v4: > - split the patchset since its getting quite big, this here is the > pinmuxing part > - added the Acked-bys This series (will be) queued to u-boot-ti, thanks for your patience. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] arm, davinci: add am1808 based enbw_cmc board
On Tue, Nov 29, 2011 at 5:33 AM, Heiko Schocher wrote: > repost from: > [U-Boot] [PATCH v3 0/3] arm, davinci: add am1808 based enbw_cmc board > http://lists.denx.de/pipermail/u-boot/2011-November/111427.html > > changes for v4: > - change gp0[15] output state to high > - change gp6[10] output state to high > add comments from Igor Grinberg: > - removed clean, distclean targets from Makefile > - sorted includes > - aligned table > - use misc functions from board/davinci/common moved for this > board/davinci/common/misc.c to arch/arm/cpu/arm926ejs/davinci/misc.c > in a seperate patch > - use da8xx_configure_lpsc_items() > add comments from Wolfgang Denk: > - return instead continue, if gpio_request fails. > > Following patches are needed for this patchset > - patchset from Christian Riesch: > [U-Boot] [PATCH v3 00/15] Add an SPL to boot the da850evm from SPI > http://lists.denx.de/pipermail/u-boot/2011-November/82.html > > - [U-Boot,1/2] arm, arm926ejs: always do cpu critical inits > patchwork.ozlabs.org/patch/124787/ I've taken this one. > - [U-Boot] arm, fdt: update ethernet mac address before booting Linux > http://patchwork.ozlabs.org/patch/114736/ I've delegated this to Albert. The rest of the series (will be) queued to u-boot-ti, thanks for your patience. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm, arm926ejs: always do cpu critical inits
On Wed, Nov 9, 2011 at 11:06 PM, Heiko Schocher wrote: > always do the cpu critical inits in cpu_init_crit, > and only jump to lowlevel_init, if CONFIG_SKIP_LOWLEVEL_INIT > is not defined. > > Signed-off-by: Heiko Schocher > Cc: Albert ARIBAUD > Cc: Wolfgang Denk > Cc: Sandeep Paulraj > Cc: Tom Rini > Cc: Christian Riesch (Will be) queued to u-boot-ti, thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] davinci_emac: move arch-independent defines to separate header
On Mon, Nov 28, 2011 at 9:37 AM, Ilya Yanok wrote: > DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs > also. This patch moves common defines from arch-davinci/emac_defs.h to > drivers/net/davinci_emac.h > > DaVinci specific PHY drivers hacked to include the new header. We might > want to switch to phylib in future. > > Signed-off-by: Ilya Yanok I missed the 0/13 email but, patches 1 to 10 will be queued up into u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything about 12 (but it's delegated to someone else) and I've commented on 13. This should at least reduce the repost burden, thanks for all your patience here! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot to load uboot
On Tuesday 29 November 2011 02:00:38 Wolfgang Denk wrote: > Sridhar Addagada you wrote: > > Here is a scenario, i have a working version of the u-boot on my > > board, and am trying my changes. Am not sure it is going to freeze > > the board, so would like the present version to load the new version > > for testing before it can be burned to flash. Is it possible to do > > this or is it already done? > > In the strict sense, this usually cannot be done - one of the most > critical parts (that most oftenly is incorrect and thus bricks your > system) is the low-level initialization, like initializing the memory > controller. And you usually cannot re-do this while already running > from RAM. > > Note that this is covered in the FAQ: > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarte > dInRAM i like this one: Answer: Well, yes. Of course this is possible. This is software, so *everything* is possible. not to keep harping, but the Blackfin arch does support this. and does so stable-ly/cleanly imo. the cpu offers a few advantages though that most cores don't (afaik) which makes it possible: dedicated on-chip L1 SRAM that can be directly accessed (which is not cache). and since the majority of the code we have to have anyways for normal booting, the additional "i'm being booted from external RAM" logic adds like ~6 insns of overhead. so when we detect we're in RAM, we copy the initcode to on-chip memory, put external memory into self refresh, reprogram everything, take external memory out of self refresh, and then resume execution from RAM. only caveat i know of is that you can't change some addressing modes (like # of cols used to program the SDRAM chips). otherwise, this changes how bytes are laid out in RAM, so you end up having stride-ed data. what was: 0xab 0xcd 0xef 0x00 ... is now something like: 0xab 0xcd 0xef 0x00 (the specifics here are probably wrong, but you get the general idea) in this case, we aren't about to kick off a DMA to re-pack the data, so that is unsupported. but we find that's significantly less of an issue compared to what people actual want: to play with memory/clock timings. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] mcx: support for HTKW mcx board
On Mon, Nov 28, 2011 at 9:37 AM, Ilya Yanok wrote: > This patch adds support for the HTKW mcx AM3517-based board. > Serial, Ethernet, NAND, MMC, RTC, EHCI USB host and both > NAND and MMC SPLs are supported. [snip] > +#if defined(CONFIG_GENERIC_MMC) && defined(CONFIG_OMAP_HSMMC) && \ > + !defined(CONFIG_SPL_BUILD) OMAP_HSMMC requires GENERIC_MMC so just defined(CONFIG_OMAP_HSMMC) && !definedCONFIG_SPL_BUILD) like the rest is all that's needed. [snip to config header] > +#undef CONFIG_USE_IRQ /* no support for IRQs */ Should be removed, isn't used. > +/* > + * DDR related > + */ > +#define CONFIG_OMAP3_MICRON_DDR /* Micron DDR */ This is unused with SPL. > +#define CONFIG_SYS_MAXARGS 32 /* max number of command */ > + /* args */ Are you sure you don't just need 16 here? This is arguments to u-boot commands and not related to being able to pass in lots of stuff to the kernel via command line. (And yes, I know where you got this from, putting those to 16 is on my low hanging fruit list). And from that same source you copy/pasted a few incorrect multiline comments (the /* --... ones). > +#define CONFIG_STACKSIZE (128 << 10) /* regular stack 128 KiB */ > +#ifdef CONFIG_USE_IRQ > +#define CONFIG_STACKSIZE_IRQ (4 << 10) /* IRQ stack 4 KiB */ > +#define CONFIG_STACKSIZE_FIQ (4 << 10) /* FIQ stack 4 KiB */ > +#endif And given we don't define CONFIG_USE_IRQ.. > +#define CONFIG_SPL_MAX_SIZE 0xB400 /* 45 K */ Better as (45 << 10). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] sandbox: Add tap based networking
Am 29.11.2011 16:24, schrieb Mike Frysinger:
> On Tuesday 29 November 2011 09:09:03 Matthias Weisser wrote:
>> This patch adds support for networking to sandbox architecture using tap. A
>> tap device "tap0" has to be created e.g. using openvpn
>>
>
> this info should be in the changelog as it's useful
Will do
>> As sandbox is build using the native compiler, which is in my case x86_64,
>> ulong is 64 bit in size. This caused non-working IP stuff as IPaddr_t is
>> typedefed to ulong. I changed this typedef to u32 which helped but is
>> quite invasive to all network related stuff. This is the main reason why
>> this patched is marked as RFC.
>
> could you elaborate on "non-working IP stuff" ?
Nothing worked. e.g. ARP wasn't working due to the memcpy in function
NetReadIP in net.h which uses sizeof(IPaddr_t) to copy the IP address
out of the network packet. sizeof(IPaddr_t) yields 8 on x86_64. After
changing the typedef to a type having 32 bits everything worked. So this
is one of the zillion problems fixed which we will see if u-boot is
ported to real 64 bit hardware :-)
>> --- a/arch/sandbox/cpu/cpu.c
>> +++ b/arch/sandbox/cpu/cpu.c
>>
>> +#if defined(CONFIG_DRIVER_TAP)
>
> i think Wolfgang NAK-ed the idea of using "DRIVER" in the config name. so
> let's use something like CONFIG_NET_TAP.
Done.
>> --- a/arch/sandbox/cpu/os.c
>> +++ b/arch/sandbox/cpu/os.c
>>
>> +#include
>> +#include
>> +#include
>> +#include
>
> these should be behind the new CONFIG name, as should the func itself
Done
>> +int os_tap_open(char *dev)
>
> const char *dev
>
>> +if (*dev)
>> +strncpy(ifr.ifr_name, dev, IFNAMSIZ);
>
> let's just make it required
Done
>> --- /dev/null
>> +++ b/drivers/net/tap.c
>>
>> +static int tap_send(struct eth_device *dev, void *packet, int length)
>> ...
>> +os_write(priv->fd, (void *)packet, length);
>
> packet is already void*, so no need to cast
packet of tap_send need to be volatile. So added volatile there and let
the cast there.
>> +static int tap_recv(struct eth_device *dev)
>> +{
>> +struct tap_priv *priv = dev->priv;
>> +uchar buf[PKTSIZE];
>
> there are already common network buffers for you to use: NetRxPackets[0]
Will use them
>> +int length;
>> +
>> +length = os_read(priv->fd, buf, PKTSIZE);
>
> os_read returns ssize_t, not int
NetReceive needs an int later on. I added an explicit cast.
>> +static int tap_set_hwaddr(struct eth_device *dev)
>> +{
>> +/* Nothing to be done here */
>> +return 0;
>> +}
>
> isn't there an ioctl that lets you control this ?
Sure. But if I read the the docs correct it is an privileged operation
and I don't think we wan't to run u-boot as super user all the time. How
is the situation handled on real hardware when the MAC is programmed to
an EEPROM on the NIC. Can the MAC be read from the NIC and set to
u-boot? This would be the best solution as linux should take care about
MAC address assignment.
>> +int tap_initialize(bd_t *bd)
>> ...
>> +struct eth_device *edev;
>
> this should be named "dev" to stay consistent
Done.
>> +edev = (struct eth_device *)malloc(sizeof(struct eth_device));
>> +tap = (struct tap_priv *)malloc(sizeof(struct tap_priv));
>
> no need for the casts
Right
>> +if (!edev) {
>> +puts("tap: not enough malloc memory for eth_device\n");
>> +res = -ENOMEM;
>> +goto err1;
>> +}
>> +
>> +if (!tap) {
>> +puts("tap: not enough malloc memory for tap_priv\n");
>> +res = -ENOMEM;
>> +goto err2;
>> +}
>
> drop the puts(), and return 0, not -ENOMEM
I don't understand why, but done. We are in a PC environment where the
puts shouldn't hurt in code size and may help in debugging.
>> +strncpy(tap->dev, "tap0", sizeof(tap->dev));
>
> no reason we couldn't support more than one tap, is there ? make the device
> name an argument to tap_initialize(), and then the board caller can do:
> tap_initialize("tap0");
> tap_initialize("tap1");
> tap_initialize("fooiefoofoo");
Done.
>> +tap->fd = os_tap_open(tap->dev);
>> +if (tap->fd < 0) {
>> +res = -EIO;
>> +goto err3;
>> +}
>
> this should return -1
Done.
>> +sprintf(edev->name, "TAP");
>
> use the same name as tap->dev. in fact, i'd just chuck tap->dev and only use
> dev->name.
Done
Thanks for the review. Will wait for some additional comments and send a
new version then.
--
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
On 11/28/2011 10:37 AM, Ilya Yanok wrote: > Currently nand_spl_simple puts it's temp data at 0x1 offset in SDRAM > which is likely to contain already loaded data. I can't see any way to > determine some safe address automagically so make it up to board porter > to provide the safe-to-use address via CONFIG_SPL_NAND_WORKSPACE value. > > Signed-off-by: Ilya Yanok > --- > drivers/mtd/nand/nand_spl_simple.c |7 ++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/drivers/mtd/nand/nand_spl_simple.c > b/drivers/mtd/nand/nand_spl_simple.c > index ed821f2..70f3cfe 100644 > --- a/drivers/mtd/nand/nand_spl_simple.c > +++ b/drivers/mtd/nand/nand_spl_simple.c > @@ -199,8 +199,13 @@ static int nand_read_page(int block, int page, void *dst) > > /* No malloc available for now, just use some temporary locations >* in SDRAM > + * Please provide some safe value for CONFIG_SPL_NAND_WORKSPACE in > + * your board configuration, this is just a guess!! >*/ > - ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE + 0x1); > +#ifndef CONFIG_SPL_NAND_WORKSPACE > +#define CONFIG_SPL_NAND_WORKSPACE(CONFIG_SYS_SDRAM_BASE + 0x1) > +#endif > + ecc_calc = (u_char *)CONFIG_SPL_NAND_WORKSPACE; > ecc_code = ecc_calc + 0x100; > oob_data = ecc_calc + 0x200; > Please document this config symbol in README. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] nds32/ag102: add ag102 soc support
On Tuesday 29 November 2011 04:15:05 Macpaul Lin wrote: > +.globl turnoff_watchdog > +turnoff_watchdog: should be: ENTRY(turnoff_watchdog) > + ret and at the end, add: ENDPROC(turnoff_watchdog) seems a lot of the nds32 code could use this fixup ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/13] omap_gpmc: use SOFTECC in SPL if it's enabled
On 11/28/2011 10:37 AM, Ilya Yanok wrote: > Use software ECC for the SPL build if support for software ECC in SPL is > enabled. > > Signed-off-by: Ilya Yanok > --- > drivers/mtd/nand/omap_gpmc.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/13] nand_spl_simple: add support for software ECC
On 11/28/2011 10:37 AM, Ilya Yanok wrote: > This patch adds support for software ECC to the nand_spl_simple driver. > To enable this one have to define CONFIG_SPL_NAND_SOFTECC. > > Tested on OMAP3. > > Signed-off-by: Ilya Yanok > --- > drivers/mtd/nand/nand_ecc.c|2 +- > drivers/mtd/nand/nand_spl_simple.c | 11 ++- > 2 files changed, 11 insertions(+), 2 deletions(-) Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] mx28evk: Add initial support for MX28EVK board
On Tuesday 29 November 2011 13:17:59 Fabio Estevam wrote: > --- /dev/null > +++ b/board/freescale/mx28evk/Makefile > > +all: $(ALL) dead code; please delete -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] devkit8000: MMC/FAT booting problem with SPL
On 11/29/2011 06:14 PM, Simon Schwarz wrote: On 11/29/2011 05:25 PM, Marek Vasut wrote: [SNIP] Stupid question -- isn't some stack corruption / memory corruption going on ? M Not stupid at all. I don't think it is a stack corruption but IMHO it seems that the .bss section is overwritten somehow. The cur_dev pointer is 0x8120 for the first sector and 0xe087c004 before the second one. So either it is changed somewhere or somehow the pointer is overwritten by accident. little status-report: The .bss-section is overwritten. Moving it into the middle of RAM fixes the problem - although this is not a solution it may help to find the root... Regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] sandbox: Add timer simulation
On Tuesday 29 November 2011 11:55:17 Simon Glass wrote: > On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote: > > Simon: did we decide to start a dedicated sandbox repo ? > > We didn't decide - it was an idea and I suppose given Wolfgang's email > about workload and the early and patch-needy state of sandbox I > suspect we should do this. The other option is perhaps for an existing > maintainer to collect things to push into staging (if there is such a > maintainer interested in sandbox). > > Wolfgang, do you want a sandbox repo? well, one of these two things is going to happen :). i'd prefer a dedicated repo, otherwise i'll start using a branch for it in an existing repo. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] sandbox: Add tap based networking
On Tuesday 29 November 2011 13:21:38 Matthias Weisser wrote:
> Am 29.11.2011 16:24, schrieb Mike Frysinger:
> > On Tuesday 29 November 2011 09:09:03 Matthias Weisser wrote:
> >> As sandbox is build using the native compiler, which is in my case
> >> x86_64, ulong is 64 bit in size. This caused non-working IP stuff as
> >> IPaddr_t is typedefed to ulong. I changed this typedef to u32 which
> >> helped but is quite invasive to all network related stuff. This is the
> >> main reason why this patched is marked as RFC.
> >
> > could you elaborate on "non-working IP stuff" ?
>
> Nothing worked. e.g. ARP wasn't working due to the memcpy in function
> NetReadIP in net.h which uses sizeof(IPaddr_t) to copy the IP address
> out of the network packet. sizeof(IPaddr_t) yields 8 on x86_64. After
> changing the typedef to a type having 32 bits everything worked. So this
> is one of the zillion problems fixed which we will see if u-boot is
> ported to real 64 bit hardware :-)
ok, so IPaddr_t is holding the exact contents of the IP address and gets
read/written directly to the network packets. and being an IPv4 address, it
needs to be 32bits exactly.
please split that one line change out into a dedicated patch.
> >> +static int tap_set_hwaddr(struct eth_device *dev)
> >> +{
> >> + /* Nothing to be done here */
> >> + return 0;
> >> +}
> >
> > isn't there an ioctl that lets you control this ?
>
> Sure. But if I read the the docs correct it is an privileged operation
> and I don't think we wan't to run u-boot as super user all the time. How
> is the situation handled on real hardware when the MAC is programmed to
> an EEPROM on the NIC. Can the MAC be read from the NIC and set to
> u-boot? This would be the best solution as linux should take care about
> MAC address assignment.
the tap_initialize() func should read the current MAC address assigned to the
tap device and write that to dev->enetaddr
then when tap_set_hwaddr() gets called, if the MAC is different, it will
attempt to set the MAC to what the user requested. if they don't have
permission, then the code can yell at them. but if they do, this should work
imo. this gets us the best of all worlds i think.
> >> + if (!edev) {
> >> + puts("tap: not enough malloc memory for eth_device\n");
> >> + res = -ENOMEM;
> >> + goto err1;
> >> + }
> >> +
> >> + if (!tap) {
> >> + puts("tap: not enough malloc memory for tap_priv\n");
> >> + res = -ENOMEM;
> >> + goto err2;
> >> + }
> >
> > drop the puts(), and return 0, not -ENOMEM
>
> I don't understand why, but done. We are in a PC environment where the
> puts shouldn't hurt in code size and may help in debugging.
while true, i'm thinking in terms of standard u-boot network driver style here
rather than "let's be as helpful as possible to the user". i'd still prefer
we drop the puts(), but i understand what you mean ...
also, please keep replies on list :)
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/15] arm, davinci: Add SPL support for DA850 SoCs
On Fri, Nov 25, 2011 at 5:37 AM, Christian Riesch wrote: > This code adds an SPL for booting from SPI flash on DA850 SoCs. > > Signed-off-by: Christian Riesch > Cc: Heiko Schocher > Cc: Sandeep Paulraj Parts of this remind me of omap-common/spl.c so I think longer term we need to figure out if we can make everyone live with a few more common SPL files and functions. Aside, what are the size limitations you're dealing with here? Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] arm: printf() is not available in some SPL configurations
On Fri, Nov 25, 2011 at 5:37 AM, Christian Riesch
wrote:
> This patch avoids build breakage for SPLs that do not support printf.
>
> Signed-off-by: Christian Riesch
> Cc: Wolfgang Denk
> Cc: Tom Rini
> Cc: Andreas Bießmann
> Cc: Scott Wood
Acked-by: Tom Rini
> ---
> arch/arm/lib/eabi_compat.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
> index eb3e26d..e1b87be 100644
> --- a/arch/arm/lib/eabi_compat.c
> +++ b/arch/arm/lib/eabi_compat.c
> @@ -13,7 +13,9 @@
>
> int raise (int signum)
> {
> +#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> printf("raise: Signal # %d caught\n", signum);
> +#endif
> return 0;
> }
>
> --
> 1.7.0.4
>
>
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BeagleBoard: config: Really switch to ttyO2
On Sun, Nov 27, 2011 at 6:51 AM, Koen Kooi wrote: > The previous commit changed it to "zero two" instead of the proper "Oh two". > This was completely broken! > > Signed-off-by: Koen Kooi (Will be) queued to u-boot-ti, thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: davinci_dm6467Tevm: Fix build breakage
On Sun, Nov 27, 2011 at 1:16 PM, Anatolij Gustschin wrote: > Fix: > > arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `timer_init': > /work/agust/git/u-boot/arch/arm/cpu/arm926ejs/davinci/timer.c:62: > undefined reference to `davinci_arm_clk_get' > > drivers/i2c/libi2c.o: In function `i2c_init': > /work/agust/git/u-boot/drivers/i2c/davinci_i2c.c:102: > undefined reference to `davinci_arm_clk_get' > > Signed-off-by: Anatolij Gustschin > Cc: Sandeep Paulraj > --- > include/configs/davinci_dm6467Tevm.h | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/include/configs/davinci_dm6467Tevm.h > b/include/configs/davinci_dm6467Tevm.h > index f7c994e..b3a4e44 100644 > --- a/include/configs/davinci_dm6467Tevm.h > +++ b/include/configs/davinci_dm6467Tevm.h > @@ -23,6 +23,7 @@ > /* Spectrum Digital TMS320DM6467T EVM board */ > #define DAVINCI_DM6467EVM > #define DAVINCI_DM6467TEVM > +#define CONFIG_DISPLAY_CPUINFO > #define CONFIG_SYS_USE_NAND > #define CONFIG_SYS_NAND_SMALLPAGE > (Will be) queued to u-boot-ti, thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] Remove unused definitions from config files
On Sat, Nov 26, 2011 at 1:30 PM, Thomas Weber wrote: > This patchset removes some unused definitions from the config files. > It is mostly omap3 centred. > > Changelog > v1->v2 > Cc:ed board maintainers > v2->v3 > Remove comment and empty line around removed definition > > Thomas Weber (3): > ARM: OMAP3: Remove unused define CONFIG_OMAP3430 > ARM: OMAP3: Remove unused define SDRC_R_C_B > ARM: OMAP: Remove STACKSIZE for IRQ and FIQ if unused > > include/configs/am3517_crane.h | 7 --- > include/configs/am3517_evm.h | 7 --- > include/configs/apollon.h | 4 > include/configs/cm_t35.h | 8 > include/configs/devkit8000.h | 8 > include/configs/dig297.h | 4 > include/configs/igep0020.h | 4 > include/configs/igep0030.h | 4 > include/configs/omap3_beagle.h | 8 > include/configs/omap3_evm_common.h | 9 - > include/configs/omap3_mvblx.h | 8 > include/configs/omap3_overo.h | 8 > include/configs/omap3_pandora.h | 8 > include/configs/omap3_sdp3430.h | 8 > include/configs/omap3_zoom1.h | 8 > include/configs/omap3_zoom2.h | 8 > 16 files changed, 0 insertions(+), 111 deletions(-) (Will be) queued to u-boot-ti. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/7] tegra: Move boards over to use arch-level board UART function
Simon Glass wrote at Monday, November 28, 2011 6:05 PM: > Now that we can set up the UART in common tegra code, make the boards > use it. > > Signed-off-by: Simon Glass Acked-by: Stephen Warren -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] tegra: Add support for UART init in cpu board.c
Simon Glass wrote at Monday, November 28, 2011 6:05 PM: > We add a way of initialising the selected of UARTs prior to relocation. > Boards can use the board_init_uart_f() instead of repeating this code > themselves. > > Signed-off-by: Simon Glass The code looks reasonable. Is there a reason why UARTC and UARTE aren't supported? Still, they could be added later when needed, so either way, Acked-by: Stephen Warren -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] tegra: Add a function mux feature
Simon Glass wrote at Monday, November 28, 2011 6:05 PM: > funcmux permits selection of config options for particular peripherals, > such as the pins that are used for that peripheral, if there are several > options. > > Add UART selection to start with. > > Signed-off-by: Simon Glass Acked-by: Stephen Warren -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] tegra: add clock_ll_start_uart() to enable UART prior to reloc
Simon Glass wrote at Monday, November 28, 2011 6:05 PM: > Most boards will want to enable a UART early. This function provides > that feature in Tegra architecture code so the code does not need to be > copied on every board. > > Signed-off-by: Simon Glass Acked-by: Stephen Warren -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] devkit8000: MMC/FAT booting problem with SPL
On 11/29/2011 05:25 PM, Marek Vasut wrote: [SNIP] Stupid question -- isn't some stack corruption / memory corruption going on ? M Not stupid at all. I don't think it is a stack corruption but IMHO it seems that the .bss section is overwritten somehow. The cur_dev pointer is 0x8120 for the first sector and 0xe087c004 before the second one. So either it is changed somewhere or somehow the pointer is overwritten by accident. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] sandbox: Add timer simulation
+Wolfgang Hi Mike, On Tue, Nov 29, 2011 at 7:25 AM, Mike Frysinger wrote: > Acked-by: Mike Frysinger > > Simon: did we decide to start a dedicated sandbox repo ? > -mike > We didn't decide - it was an idea and I suppose given Wolfgang's email about workload and the early and patch-needy state of sandbox I suspect we should do this. The other option is perhaps for an existing maintainer to collect things to push into staging (if there is such a maintainer interested in sandbox). Wolfgang, do you want a sandbox repo? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] devkit8000: MMC/FAT booting problem with SPL
> On 11/29/2011 04:11 AM, Simon Schwarz wrote: > > Hi List, > > > > there seems to be a problem in devkit8000 in combination with mmc boot. > > > > I have this error: > > OMAP SD/MMC: 0 > > reading u-boot.img > > reading u-boot.img > > Error reading cluster > > spl: error reading image u-boot.img, err - -1 > > ### ERROR ### Please RESET the board ### > > > > Some exploring i did some time ago showed that this error is deep in the > > FAT implementation. (a pity that i don't have my notes on this anymore) > > > > I'am aware that there have been changes some time ago regarding FAT/SPL > > and malloc. > > > > Is someone able to guess where the problem might be - to be true I > > didn't had a clue from the FAT code. > > > > I will do some debugging later this day and post the results here. > > The datapoint I want to raise is that I can see this with my SPL series > as well, but only on devkit8000. Beagleboard and omap3evm are fine > booting from MMC with SPL. Which is odd, I know. Stupid question -- isn't some stack corruption / memory corruption going on ? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: vexpress: Extend default boot sequence to load script from MMC
On Tue, 2011-11-29 at 13:46 +, Jon Medhurst (Tixy) wrote:
> Extend the default boot sequence on Versatile Express to load a boot
> script from MMC.
>
> Signed-off-by: Jon Medhurst
Acked-by: Ryan Harkin
>
> ---
> include/configs/vexpress_common.h | 20 ++--
> 1 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/vexpress_common.h
> b/include/configs/vexpress_common.h
> index a4ae5a8..d56f19d 100644
> --- a/include/configs/vexpress_common.h
> +++ b/include/configs/vexpress_common.h
> @@ -178,6 +178,8 @@
> #define CONFIG_CMD_SAVEENV
> #define CONFIG_NET_MULTI
> #define CONFIG_CMD_RUN
> +#define CONFIG_CMD_BOOTD
> +#define CONFIG_CMD_ECHO
>
> #define CONFIG_CMD_FAT
> #define CONFIG_DOS_PARTITION 1
> @@ -226,7 +228,14 @@
> #define CONFIG_SYS_INIT_SP_ADDR CONFIG_SYS_GBL_DATA_OFFSET
>
> /* Basic environment settings */
> -#define CONFIG_BOOTCOMMAND "run bootflash;"
> +#define CONFIG_BOOTCOMMAND \
> + "if mmc rescan ${mmcdev}; then " \
> + "if run loadbootscript; then " \
> + "run bootscript; " \
> + "fi; " \
> + "fi; " \
> + "run bootflash;"
> +
> #ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
> #define CONFIG_PLATFORM_ENV_SETTINGS \
> "loadaddr=0x80008000\0" \
> @@ -258,7 +267,12 @@
> "devtmpfs.mount=0 vmalloc=256M\0" \
> "bootflash=run flashargs; " \
> "cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk}; " \
> - "bootm ${kernel_addr} ${ramdisk_addr_r}\0"
> + "bootm ${kernel_addr} ${ramdisk_addr_r}\0" \
> + "mmcdev=0\0" \
> + "bootscr=boot.scr\0" \
> + "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} ${bootscr}\0"
> \
> + "bootscript=echo Running bootscript from mmc ...; " \
> + "source ${loadaddr}\0"
>
> /* FLASH and environment organization */
> #define PHYS_FLASH_SIZE 0x0400 /* 64MB */
> @@ -305,6 +319,8 @@
> #define CONFIG_SYS_PROMPT"VExpress# "
> #define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + \
> sizeof(CONFIG_SYS_PROMPT) + 16)
> +#define CONFIG_SYS_HUSH_PARSER
> +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
> #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE /* Boot args buffer */
> #define CONFIG_CMD_SOURCE
> #define CONFIG_SYS_LONGHELP
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
