Re: [U-Boot] da850evm: u-boot does not start without UBL since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c
Hello Christian, Christian Riesch wrote: I have tried to run recent versions of u-boot on the da850evm (AM1808 eXperimenter's Kit) board. Using Texas Instrument's User Boot Loader (UBL) to start u-boot (the default configuration for the EVM) everything works fine. However, if I try to get rid of this UBL (I don't need to voltage scaling features that it provides, so it's useless for me, just additional code that needs maintenance), I run into trouble. Instead of using UBL, I use AIS [1] to configure PLLs and mDDR timings. My AIS script is generated by the HexAIS tool [2], the settings in the input file of HexAIS are Never used AIS, so I could not say much (I read also the response from Ben, so just one more idea): [General] busWidth=8 BootMode=SPIMASTER Is this the same bootmode when using UBL? By different bootmodes, the cpu inits different the pinmux. crcCheckType=NO_CRC [PLLANDCLOCKCONFIG] PLL0CFG0 = 0x00180001 PLL0CFG1 = 0x0205 PERIPHCLKCFG = 0x000a [EMIF3DDR] PLL1CFG0 = 0x15010001 PLL1CFG1 = 0x0002 DDRPHYC1R = 0x00C4 SDCR = 0x0A034622 SDTIMR = 0x184929C8 SDTIMR2 = 0xB80FC700 SDRCR = 0x0406 CLK2XSRC = 0x [INPUTFILE] FILENAME=u-boot.bin LOADADDRESS=0xC108 ENTRYPOINTADDRESS=0xC108 While this configuration works fine for older versions of u-boot (like v2009.11), it fails with recent u-boot versions (no sign of life on the serial port). I have bisected down to the commits from commit f1d2b313c9eb6808d30c16a9eb5251240452a56c ARM: add relocation support to commit ab86f72c354f9b2572340f72b74ca0a258c451bd ARM: implement relocation for ARM926 Maybe RAM init wrong? So RAM works not correct, or RAM size gets wrong detected? Since these commits u-boot does not boot without the help of UBL. So I guess these commits require some additional initialization that is done by UBL, but not by my AIS. I have tried to figure out what I am missing, but without success so far. I think, you need a debugger here, to find out, where u-boot crashes (if it crashes), sorry! 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 v2] mx31ads: Use the new relocation scheme
On 06/01/2011 09:46 PM, Fabio Estevam wrote:
This fixes the MX31ADS build by using the new relocation scheme.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com ---
Hi Fabio,
Changes since v1:
- Fixed lines over 80 characters.
Build tested only.
Do not have the hardware handy to test.
Maybe someone can help on this topic ;-)
-int dram_init (void) +int dram_init(void) +{ + /* dram_init must
store complete ramsize in gd-ram_size */ + gd-ram_size =
get_ram_size((volatile void *)CONFIG_SYS_SDRAM_BASE,
I know it is the same, but if you use PHYS_SDRAM_1 instead of
CONFIG_SYS_SDRAM_BASE (as most boards do), the reader understands easier
that the start address and the size are strictly connected.
--- a/board/freescale/mx31ads/u-boot.lds +++
b/board/freescale/mx31ads/u-boot.lds @@ -48,23 +48,47 @@ SECTIONS
Can we get rid of this file ? We do not need anymore, and you can also
remove config.mk as well.
Your patch makes u-boot.lds in board directory identical (if I have not
missed something) to arch/arm/cpu/arm1136/u-boot.lds.
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] post, arm, memorytest: add support for arm based boards
Dear Heiko Schocher, In message 4de72566.9040...@denx.de you wrote: Hmm.. I thought of that too, but wouldn;t it be better to use gd-ram_size in post/drivers/memory.c, as this is defined in global_data for all archs? Indeed. Can you do this, please? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A list is only as strong as its weakest link.-- Don Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Lawyer Needed
I need a Business/Commercial litigation lawyer who can handle a collection issue. Please let know if you can be of assistance to me or If not a referral Contact privately via email: bryan.steve...@cafuc.net could be helpful. Regards Steve Bryan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] common/cmd_nand.c: add ifdef protection for do_bootm
On Wednesday, June 01, 2011 15:21:54 Wolfgang Denk wrote: Mike Frysinger wrote: actually, if you dont mind, i'd like to obsolete this patch with the one below. what do you think ? Please submit it as a proper patch then. i was going to once i got feedback from the interested parties -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] post, arm, memorytest: add support for arm based boards
On Thursday, June 02, 2011 01:53:42 Heiko Schocher wrote: Mike Frysinger wrote: so add bi_memsize to arm ? it's the only arch that lacks it. Hmm.. I thought of that too, but wouldn;t it be better to use gd-ram_size in post/drivers/memory.c, as this is defined in global_data for all archs? makes me wonder why we have bd-bi_memsize in the first place. and how can this possibly work ? arch/arm/lib/board.c: sprintf ((char *)memsz, %ldk, (bd-bi_memsize / 1024) - pram); -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] Pull request u-boot-blackfin.git
On Wednesday, June 01, 2011 15:58:50 Wolfgang Denk wrote: It appears this is mostly new stuff, right? not really these are absolutely fixes: Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings Blackfin: use on-chip reset func with newer parts Blackfin: bf548-ezkit/bf561-ezkit: update env location Blackfin: boards: build zlib dir with -O2 this was waiting on a patch that you didnt merge until later and so i couldnt push with my earlier set: Blackfin: use common LDSCRIPT logic this is partially new stuff, and partially fixing existing behavior to match the hardware: Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings this is new stuff, but i was lazy and didnt want to figure out the patch relationship with the other changes to these files, and it's safe: Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support -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] autostart: unify duplicated logic into the bootm code
Rather than having a bunch of random commands handle autostart behavior,
unify the logic in a single place. This also fixes building of these
different commands when bootm is disabled.
Acked-by: Matthew McClintock m...@freescale.com
Acked-by: Scott Wood scottw...@freescale.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
common/cmd_bootm.c | 15 +++
common/cmd_fdc.c | 15 +--
common/cmd_fdos.c | 11 +--
common/cmd_ide.c | 15 +--
common/cmd_nand.c | 14 +-
common/cmd_net.c | 13 ++---
common/cmd_scsi.c | 11 +--
common/cmd_usb.c | 13 ++---
include/command.h |8
9 files changed, 32 insertions(+), 83 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 18019d6..8982c92 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -707,6 +707,21 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
return 1;
}
+int bootm_maybe_autostart(cmd_tbl_t *cmdtp, const char *cmd)
+{
+ const char *ep = getenv(autostart);
+
+ if (ep !strcmp(ep, yes)) {
+ char *local_args[2];
+ local_args[0] = (char *)cmd;
+ local_args[1] = NULL;
+ printf(Automatic boot of image at addr 0x%08lX ...\n,
load_addr);
+ return do_bootm(cmdtp, 0, 1, local_args);
+ }
+
+ return 0;
+}
+
/**
* image_get_kernel - verify legacy format kernel image
* @img_addr: in RAM address of the legacy format image to be verified
diff --git a/common/cmd_fdc.c b/common/cmd_fdc.c
index cdb050c..20ebf6c 100644
--- a/common/cmd_fdc.c
+++ b/common/cmd_fdc.c
@@ -722,7 +722,6 @@ int do_fdcboot (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
unsigned char boot_drive;
int i,nrofblk;
char *ep;
- int rcode = 0;
#if defined(CONFIG_FIT)
const void *fit_hdr = NULL;
#endif
@@ -823,19 +822,7 @@ int do_fdcboot (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
/* Loading ok, update default load address */
load_addr = addr;
- /* Check if we should attempt an auto-start */
- if (((ep = getenv(autostart)) != NULL) (strcmp(ep,yes) == 0)) {
- char *local_args[2];
-
- local_args[0] = argv[0];
- local_args[1] = NULL;
-
- printf (Automatic boot of image at addr 0x%08lX ...\n, addr);
-
- do_bootm (cmdtp, 0, 1, local_args);
- rcode ++;
- }
- return rcode;
+ return bootm_maybe_autostart(cmdtp, argv[0]);
}
U_BOOT_CMD(
diff --git a/common/cmd_fdos.c b/common/cmd_fdos.c
index 2af4ca0..d714af8 100644
--- a/common/cmd_fdos.c
+++ b/common/cmd_fdos.c
@@ -40,7 +40,6 @@ int do_fdosboot(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
char *name;
char *ep;
int size;
-int rcode = 0;
char buf [12];
int drive = CONFIG_SYS_FDC_DRIVE_NUMBER;
@@ -98,15 +97,7 @@ int do_fdosboot(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
printf(Floppy DOS load complete: %d bytes loaded to 0x%lx\n,
size, load_addr);
-/* Check if we should attempt an auto-start */
-if (((ep = getenv(autostart)) != NULL) (strcmp(ep,yes) == 0)) {
- char *local_args[2];
- local_args[0] = argv[0];
- local_args[1] = NULL;
- printf (Automatic boot of image at addr 0x%08lX ...\n, load_addr);
- rcode = do_bootm (cmdtp, 0, 1, local_args);
-}
-return rcode;
+return bootm_maybe_autostart(cmdtp, argv[0]);
}
/*-
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index a1f7e57..07890e7 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -356,7 +356,6 @@ int do_diskboot (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
ulong addr, cnt;
disk_partition_t info;
image_header_t *hdr;
- int rcode = 0;
#if defined(CONFIG_FIT)
const void *fit_hdr = NULL;
#endif
@@ -495,19 +494,7 @@ int do_diskboot (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
load_addr = addr;
- /* Check if we should attempt an auto-start */
- if (((ep = getenv(autostart)) != NULL) (strcmp(ep,yes) == 0)) {
- char *local_args[2];
-
- local_args[0] = argv[0];
- local_args[1] = NULL;
-
- printf (Automatic boot of image at addr 0x%08lX ...\n, addr);
-
- do_bootm (cmdtp, 0, 1, local_args);
- rcode = 1;
- }
- return rcode;
+ return bootm_maybe_autostart(cmdtp, argv[0]);
}
/* - */
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 7bd37de..92ae186 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -799,19 +799,7 @@ static int
[U-Boot] [PATCH] net: designware: fix unused warning when CONFIG_DW_AUTONEG is enabled
The ctrl variable is only used when autoneg support is disabled, so only
declare it under those conditions to avoid an unused variable warning.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
drivers/net/designware.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 3f5eeb7..96f20d1 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -368,11 +368,13 @@ static int configure_phy(struct eth_device *dev)
{
struct dw_eth_dev *priv = dev-priv;
int phy_addr;
- u16 bmcr, ctrl;
+ u16 bmcr;
#if defined(CONFIG_DW_AUTONEG)
u16 bmsr;
u32 timeout;
u16 anlpar, btsr;
+#else
+ u16 ctrl;
#endif
#if defined(CONFIG_DW_SEARCH_PHY)
--
1.7.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: designware: fix uninitialized phy_addr usage
When CONFIG_DW_SEARCH_PHY is disabled, the local phy_addr variable never gets initialized causes random behavior at runtime and a gcc warning. So set it by default to the stored phy address. Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/net/designware.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/designware.c b/drivers/net/designware.c index 96f20d1..bfa4384 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -383,6 +383,8 @@ static int configure_phy(struct eth_device *dev) priv-address = phy_addr; else return -1; +#else + phy_addr = priv-address; #endif if (dw_reset_phy(dev) 0) return -1; -- 1.7.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Hi Wolfgang, What's your final view on the Makefile structure of SPL. best regards, Aneesh On Thursday 26 May 2011 06:55 PM, Aneesh V wrote: Hi Wolfgang, On Tuesday 17 May 2011 06:23 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd26b36.4050...@ti.com you wrote: And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis? The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place. 1. How about the case where there is some board dependent code but also code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc? 2. I think one key thing that you are perhaps missing is that in SPL the board level Makefile is not just meant for board level files. Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable. Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did? Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other. Considering point 2 above I think this is logical. The board level Makefile needs to have all the files. For the SoC level selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too. I wouldn't really consider the include statements as duplication of code. Instead, that was a way of avoiding duplication of code given the constraints of the SPL model. best regards, Aneesh Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories. Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated. Having to maintain multiple copies of identical Makefiles is more complicated and error prone in the long run. Let's rather spoend a few thoughts initially and solve this problem before it spreads. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]Uboot tool Makefile patch for Mac OSX Snow leopard
could you provide some real details as to what the problem is you're hitting and why/how this fixes things ? 2011.03 builds fine for me on leopard (10.5). -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 08/22] omap: add spl support
Hi Wolfgang, On Thursday 26 May 2011 07:21 PM, Aneesh V wrote: Hi Wolfgang, On Tuesday 17 May 2011 01:46 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd21cd8.2080...@ti.com you wrote: There are common, board independent parts both in spl/nand and spl/onenand. How about having them at the root level in 'spl/' ? Why? It seems more logical to me to group nand and onenand related files in their own subdirectories. I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this: spl/ mmc/ nand/ one-nand/ board/vendor/board/Makefile The idea is to have the board level Makefile in 'spl/board/vendor /board/' no matter what the SPL type is. This will help in better consolidation of SPLs. I see 3 SPL use-cases in general: 1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM) 2. A single SPL supporting a single media(the board supports only one media) 3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small). Supporting (1) and (2) is straight forward with the above directory structure. To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on. Please let me know if any of you have better ideas. I would like to finalize on this before re-working on my patch-set. What's your views on the above scheme. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx31ads: Use the new relocation scheme
Hi Stefano,
On Thu, Jun 2, 2011 at 3:28 AM, Stefano Babic sba...@denx.de wrote:
...
I know it is the same, but if you use PHYS_SDRAM_1 instead of
CONFIG_SYS_SDRAM_BASE (as most boards do), the reader understands easier
that the start address and the size are strictly connected.
OK.
--- a/board/freescale/mx31ads/u-boot.lds +++
b/board/freescale/mx31ads/u-boot.lds @@ -48,23 +48,47 @@ SECTIONS
Can we get rid of this file ? We do not need anymore, and you can also
remove config.mk as well.
If I remove the board/freescale/mx31ads/u-boot.ld then I get the
following error:
010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map
u-boot.map -o u-boot
common/libcommon.o:(.data+0x80c): undefined reference to `environment'
and I think that is due to the fact that
board/freescale/mx31ads/u-boot.ld is a bit customized as per the
comment below:
.text :
{
/* WARNING - the following is hand-optimized to fit within*/
/* the sector layout of our flash chips! XXX FIXME XXX */
arch/arm/cpu/arm1136/start.o (.text)
board/freescale/mx31ads/libmx31ads.o (.text)
arch/arm/lib/libarm.o (.text)
net/libnet.o (.text)
drivers/mtd/libmtd.o (.text)
. = DEFINED(env_offset) ? env_offset : .;
common/env_embedded.o(.text)
My intention on this patch was to fix the MX31ADS build so that this
board does not get removed from U-boot.
Would it be OK if I resend a new patch taking in consideration your
other comments, except the removal of
board/freescale/mx31ads/u-boot.ld ?
Or would you have any other suggestion?
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx31ads: Use the new relocation scheme
On 06/02/2011 06:02 PM, Fabio Estevam wrote: Hi Stefano, Hi Fabio, My intention on this patch was to fix the MX31ADS build so that this board does not get removed from U-boot. Sure. This is the first goal. Would it be OK if I resend a new patch taking in consideration your other comments, except the removal of board/freescale/mx31ads/u-boot.ld ? Agree. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Dreamplug into mainline
Prafulla, As a practical learning exercise, I'm going to attempt to add support for the Dreamplug into the mainline u-boot tree. I'm starting with the board number. It is currently 2659. The same as the Guruplug. This is less than ideal because the Dreamplug has 2MB (yes, megabytes) of SPI flash, whereas the Guruplug had 512 MB of flash. There are other peripherals on the Dreamplug that aren't on the Guruplug (audio, etc) but I don't see that as immediately relevant with U-Boot. I've found [1] for requesting a new board number, but can I do it? I'm not related to Marvell in any way... My plan right now is to make copies of all the guruplug stuff, do s/guruplug/dreamplug/g on the new files, consolidate, then add the support for the SPI. Any holes in that? thx, Jason. [1] http://www.arm.linux.org.uk/developer/machines/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Issues building for the P2020 (linking)
Hi, I'm currently trying to build out of git and am seeing an issue with the final linking during the build. I've included the relevant dump: Using P2020DS_config UNDEF_SYM=`powerpc-linux-gnu-objdump -x board/freescale/p2020ds/libp2020ds.o api/libapi.o arch/powerpc/cpu/mpc85xx/libmpc85xx.o arch/powerpc/cpu/mpc8xxx/ddr/libddr.o arch/powerpc/cpu/mpc8xxx/lib8xxx.o arch/powerpc/lib/libpowerpc.o board/freescale/common/libfreescale.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/qe/libqe.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.a drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/mstafford/sandbox/u-boot powerpc-linux-gnu-ld -n -T u-boot.lds --gc-sections -Bstatic -Ttext 0xeff8 $UNDEF_SYM arch/powerpc/cpu/mpc85xx/start.o arch/powerpc/cpu/mpc85xx/resetvec.o --start-group api/libapi.o arch/powerpc/cpu/mpc85xx/libmpc85xx.o arch/powerpc/cpu/mpc8xxx/ddr/libddr.o arch/powerpc/cpu/mpc8xxx/lib8xxx.o arch/powerpc/lib/libpowerpc.o board/freescale/common/libfreescale.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/qe/libqe.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.a drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/freescale/p2020ds/libp2020ds.o --end-group -L /opt/freescale/usr/local/gcc-4.4.78-eglibc-2.10.78/powerpc-linux-gnu/lib /gcc/powerpc-linux-gnu/4.4.1/nof -lgcc -Map u-boot.map -o u-boot powerpc-linux-gnu-ld: section .bootpg loaded at [e000,e237] overlaps section .data loaded at [efffc16c,f000347b] powerpc-linux-gnu-ld: u-boot: section .bootpg vma 0xe000 overlaps previous sections powerpc-linux-gnu-ld: u-boot: section .resetvec vma 0xeffc overlaps previous sections powerpc-linux-gnu-ld: u-boot: section .u_boot_cmd vma 0xf000347c overlaps previous sections make: *** [u-boot] Error 1 Any thoughts? Regards, Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] mx31ads: Use the new relocation scheme
This fixes the MX31ADS build by using the new relocation scheme.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v2:
- Use PHYS_SDRAM_1 in get_ram_size
- Remove local config.mk
Changes since v1:
- Fixed lines over 80 characters.
Build tested only.
Do not have the hardware handy to test.
board/freescale/mx31ads/config.mk |1 -
board/freescale/mx31ads/mx31ads.c | 19 ---
board/freescale/mx31ads/u-boot.lds | 42 ---
include/configs/mx31ads.h | 11 +
4 files changed, 59 insertions(+), 14 deletions(-)
delete mode 100644 board/freescale/mx31ads/config.mk
diff --git a/board/freescale/mx31ads/config.mk
b/board/freescale/mx31ads/config.mk
deleted file mode 100644
index 0131edf..000
--- a/board/freescale/mx31ads/config.mk
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_SYS_TEXT_BASE = 0x87f0
diff --git a/board/freescale/mx31ads/mx31ads.c
b/board/freescale/mx31ads/mx31ads.c
index a298e05..9bf9c18 100644
--- a/board/freescale/mx31ads/mx31ads.c
+++ b/board/freescale/mx31ads/mx31ads.c
@@ -28,15 +28,21 @@
DECLARE_GLOBAL_DATA_PTR;
-int dram_init (void)
+int dram_init(void)
+{
+ /* dram_init must store complete ramsize in gd-ram_size */
+ gd-ram_size = get_ram_size((volatile void *)PHYS_SDRAM_1,
+ PHYS_SDRAM_1_SIZE);
+ return 0;
+}
+
+void dram_init_banksize(void)
{
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
-
- return 0;
}
-int board_init (void)
+int board_early_init_f(void)
{
int i;
@@ -94,6 +100,11 @@ int board_init (void)
readb(CS4_BASE + 8);
readb(CS4_BASE + 7);
+ return 0;
+}
+
+int board_init(void)
+{
gd-bd-bi_arch_number = MACH_TYPE_MX31ADS; /* board id for linux */
gd-bd-bi_boot_params = 0x8100;/* adress of boot parameters */
diff --git a/board/freescale/mx31ads/u-boot.lds
b/board/freescale/mx31ads/u-boot.lds
index b081b21..79eb7ac 100644
--- a/board/freescale/mx31ads/u-boot.lds
+++ b/board/freescale/mx31ads/u-boot.lds
@@ -48,23 +48,47 @@ SECTIONS
*(.text)
}
-
. = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+ .rodata : { *(.rodata) }
. = ALIGN(4);
- .data : { *(.data) }
+ .data : {
+ *(.data)
+ }
. = ALIGN(4);
- .got : { *(.got) }
-
- . = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
. = ALIGN(4);
- __bss_start = .;
- .bss : { *(.bss) . = ALIGN(4); }
- __bss_end__ = .;
+
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .dynsym : {
+ __dynsym_start = .;
+ *(.dynsym)
+ }
+
+ _end = .;
+
+ .bss __rel_dyn_start (OVERLAY) : {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ __bss_end__ = .;
+ }
+
+ /DISCARD/ : { *(.bss*) }
+ /DISCARD/ : { *(.dynstr*) }
+ /DISCARD/ : { *(.dynsym*) }
+ /DISCARD/ : { *(.dynamic*) }
+ /DISCARD/ : { *(.hash*) }
+ /DISCARD/ : { *(.plt*) }
+ /DISCARD/ : { *(.interp*) }
+ /DISCARD/ : { *(.gnu*) }
}
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 5ea59b4..f8be3e9 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -33,6 +33,8 @@
#define CONFIG_DISPLAY_CPUINFO
#define CONFIG_DISPLAY_BOARDINFO
+#define CONFIG_SYS_TEXT_BASE 0x87f0
+
/*
* Disabled for now due to build problems under Debian and a significant
increase
* in the final file size: 144260 vs. 109536 Bytes.
@@ -160,6 +162,15 @@
#define CONFIG_NR_DRAM_BANKS 1
#define PHYS_SDRAM_1 CSD0_BASE
#define PHYS_SDRAM_1_SIZE (128 * 1024 * 1024)
+#define CONFIG_BOARD_EARLY_INIT_F
+
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR
+#define CONFIG_SYS_INIT_RAM_SIZE IRAM_SIZE
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - \
+ GENERATED_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \
+ CONFIG_SYS_GBL_DATA_OFFSET)
/*---
* FLASH and environment organization
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issues building for the P2020 (linking)
/opt/freescale/usr/local/gcc-4.4.78-eglibc-2.10.78/powerpc-linux-gnu/lib /gcc/powerpc-linux-gnu/4.4.1/nof -lgcc -Map u-boot.map -o u-boot powerpc-linux-gnu-ld: section .bootpg loaded at [e000,e237] overlaps section .data loaded at [efffc16c,f000347b] powerpc-linux-gnu-ld: u-boot: section .bootpg vma 0xe000 overlaps previous sections powerpc-linux-gnu-ld: u-boot: section .resetvec vma 0xeffc overlaps previous sections powerpc-linux-gnu-ld: u-boot: section .u_boot_cmd vma 0xf000347c overlaps previous sections make: *** [u-boot] Error 1 Any thoughts? It looks like the .bootpg code segment is too big. It could be that recent changes to the NAND spl used by PPC chips is causing this. I will try to recreate your error. Regards, Alex -- Alex Waterman Computer Engineer Phone: 215-896-4920 Email: awater...@dawning.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] nand_spl/spiboot/sdboot: Add ability to have smaller middle loader
From: Matthew McClintock m...@freescale.com
This patch allows some boards do define CONFIG_BOOTSTRAP to let them
build a MPL or middle program loader to setup the board before booting
to the full u-boot build. The advantage is that we are using the same
build system and linker scripts that would be used in a normal u-boot
build.
This is used on powerpc/85xx parts that only have 256kB of cache
and also need to perform DDR SPD. So, the nand_spl will load the
MPL to L2 SRAM and there DDR will be configured. Afterwards the
MPL uses the CONFIG_BOOTCOMMAND environment variable to boot to
the appropriate media. This also works with SD and SPI via the
on chip rom but instead it goes from on-chip-rom to MPL to full
version of u-boot.
Depends on previous icache/dcache command changes and various
build fixes for add cases that occur when trying to build an
extremely minimal image
Signed-off-by: Matthew McClintock m...@freescale.com
---
Makefile | 38 +-
mkconfig |1 +
2 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0400930..7a9cae7 100644
--- a/Makefile
+++ b/Makefile
@@ -317,6 +317,16 @@ ifeq ($(CONFIG_NAND_U_BOOT),y)
ALL += $(obj)u-boot-nand.bin
endif
+ifndef CONFIG_IN_BOOTSTRAP
+ifeq ($(CONFIG_SPIFLASH), y)
+ALL += $(obj)u-boot-spi.bin
+endif
+
+ifeq ($(CONFIG_SDCARD), y)
+ALL += $(obj)u-boot-sd.bin
+endif
+endif
+
ifeq ($(CONFIG_ONENAND_U_BOOT),y)
ALL += $(obj)u-boot-onenand.bin
ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
@@ -404,8 +414,16 @@ $(obj)u-boot.lds: $(LDSCRIPT)
nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
+NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin
+NAND_SPL_OBJS-$(CONFIG_BOOTSTRAP) += $(obj)u-boot-bootstrap.bin
+NAND_SPL_OBJS-y += $(obj)u-boot.bin
+
+ifeq ($(CONFIG_BOOTSTRAP),y)
+$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot-bootstrap.bin $(obj)u-boot.bin
+else
$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin
- cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin
$(obj)u-boot-nand.bin
+endif
+ cat $(NAND_SPL_OBJS-y) $(obj)u-boot-nand.bin
onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
$(MAKE) -C onenand_ipl/board/$(BOARDDIR) all
@@ -413,6 +431,23 @@ onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE)
$(obj)include/autoconf.mk
$(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin $(obj)u-boot-onenand.bin
+ifdef CONFIG_BOOTSTRAP
+$(obj)u-boot-spi.bin: $(obj)u-boot.bin $(obj)u-boot-bootstrap.bin
+ cat $(obj)u-boot-bootstrap.bin $(obj)u-boot.bin
$(obj)u-boot-spi.bin
+$(obj)u-boot-sd.bin: $(obj)u-boot.bin $(obj)u-boot-bootstrap.bin
+ cat $(obj)u-boot-bootstrap.bin $(obj)u-boot.bin
$(obj)u-boot-sd.bin
+else
+$(obj)u-boot-spi.bin: $(obj)u-boot.bin
+ ln -s u-boot.bin u-boot-spi.bin
+$(obj)u-boot-sd.bin: $(obj)u-boot.bin
+ ln -s u-boot.bin u-boot-sd.bin
+endif
+
+$(obj)u-boot-bootstrap.bin:
+ rm -rf $(BUILD_DIR)bootstrap
+ $(MAKE) $(CONFIG_BOARD_NAME) O=bootstrap/
EXTRA_OPTS=IN_BOOTSTRAP
+ cp $(BUILD_DIR)bootstrap/u-boot.bin u-boot-bootstrap.bin
+
$(VERSION_FILE):
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
printf '#define PLAIN_VERSION %s%s\n' \
@@ -1130,6 +1165,7 @@ clean:
\( -name 'core' -o -name '*.bak' -o -name '*~' \
-o -name '*.o' -o -name '*.a' -o -name '*.exe' \) -print \
| xargs rm -f
+ @rm -fr $(BUILD_DIR)bootstrap/
clobber: clean
@find $(OBJTREE) -type f \( -name '*.depend' \
diff --git a/mkconfig b/mkconfig
index e72ec3d..74294ec 100755
--- a/mkconfig
+++ b/mkconfig
@@ -159,6 +159,7 @@ for i in ${TARGETS} ; do
done
cat EOF config.h
+#define CONFIG_BOARD_NAME $BOARD_NAME
#define CONFIG_BOARDDIR board/$BOARDDIR
#include config_cmd_defaults.h
#include config_defaults.h
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] common/env_common: Add CONFIG_SILENT_CONSOLE_AT_BOOT env option
From: Matthew McClintock m...@freescale.com
Just setting CONFIG_SILENT_CONSOLE does not make the CONSOLE
silent without the silent env variable set. This adds a new
define to add this to the default environment easily
Signed-off-by: Matthew McClintock m...@freescale.com
---
README |4
common/env_common.c |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/README b/README
index ed73981..8779544 100644
--- a/README
+++ b/README
@@ -546,6 +546,10 @@ The following options need to be configured:
the silent environment variable. See
doc/README.silent for more information.
+ When CONFIG_SILENT_CONSOLE_AT_BOOT is set u-boot
+ will be built with silent defined in the default
+ environment for a completly silent console at boot
+
- Console Baudrate:
CONFIG_BAUDRATE - in bps
Select one of the baudrates listed in
diff --git a/common/env_common.c b/common/env_common.c
index c3e6388..3b09373 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -123,6 +123,9 @@ uchar default_environment[] = {
#if defined(CONFIG_PCI_BOOTDELAY) (CONFIG_PCI_BOOTDELAY 0)
pcidelay= MK_STR(CONFIG_PCI_BOOTDELAY)\0
#endif
+#ifdef CONFIG_SILENT_CONSOLE_AT_BOOT
+ silent=1\0
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] common/env_common: Add CONFIG_SILENT_CONSOLE_AT_BOOT env option
Ugh. I just messed that up. Ignore this patch series.
-M
On Thu, Jun 2, 2011 at 2:27 PM, y...@right.am.freescale.net wrote:
From: Matthew McClintock m...@freescale.com
Just setting CONFIG_SILENT_CONSOLE does not make the CONSOLE
silent without the silent env variable set. This adds a new
define to add this to the default environment easily
Signed-off-by: Matthew McClintock m...@freescale.com
---
README | 4
common/env_common.c | 3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/README b/README
index ed73981..8779544 100644
--- a/README
+++ b/README
@@ -546,6 +546,10 @@ The following options need to be configured:
the silent environment variable. See
doc/README.silent for more information.
+ When CONFIG_SILENT_CONSOLE_AT_BOOT is set u-boot
+ will be built with silent defined in the default
+ environment for a completly silent console at boot
+
- Console Baudrate:
CONFIG_BAUDRATE - in bps
Select one of the baudrates listed in
diff --git a/common/env_common.c b/common/env_common.c
index c3e6388..3b09373 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -123,6 +123,9 @@ uchar default_environment[] = {
#if defined(CONFIG_PCI_BOOTDELAY) (CONFIG_PCI_BOOTDELAY 0)
pcidelay= MK_STR(CONFIG_PCI_BOOTDELAY) \0
#endif
+#ifdef CONFIG_SILENT_CONSOLE_AT_BOOT
+ silent=1\0
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] common/env_common: Add CONFIG_SILENT_CONSOLE_AT_BOOT env option
Just setting CONFIG_SILENT_CONSOLE does not make the CONSOLE
silent without the silent env variable set. This adds a new
define to add this to the default environment easily
Signed-off-by: Matthew McClintock m...@freescale.com
---
README |4
common/env_common.c |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/README b/README
index ed73981..8779544 100644
--- a/README
+++ b/README
@@ -546,6 +546,10 @@ The following options need to be configured:
the silent environment variable. See
doc/README.silent for more information.
+ When CONFIG_SILENT_CONSOLE_AT_BOOT is set u-boot
+ will be built with silent defined in the default
+ environment for a completly silent console at boot
+
- Console Baudrate:
CONFIG_BAUDRATE - in bps
Select one of the baudrates listed in
diff --git a/common/env_common.c b/common/env_common.c
index c3e6388..3b09373 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -123,6 +123,9 @@ uchar default_environment[] = {
#if defined(CONFIG_PCI_BOOTDELAY) (CONFIG_PCI_BOOTDELAY 0)
pcidelay= MK_STR(CONFIG_PCI_BOOTDELAY)\0
#endif
+#ifdef CONFIG_SILENT_CONSOLE_AT_BOOT
+ silent=1\0
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] nand_spl/spiboot/sdboot: Add ability to have smaller middle loader
This patch allows some boards do define CONFIG_BOOTSTRAP to let them
build a MPL or middle program loader to setup the board before booting
to the full u-boot build. The advantage is that we are using the same
build system and linker scripts that would be used in a normal u-boot
build.
This is used on powerpc/85xx parts that only have 256kB of cache
and also need to perform DDR SPD. So, the nand_spl will load the
MPL to L2 SRAM and there DDR will be configured. Afterwards the
MPL uses the CONFIG_BOOTCOMMAND environment variable to boot to
the appropriate media. This also works with SD and SPI via the
on chip rom but instead it goes from on-chip-rom to MPL to full
version of u-boot.
Depends on previous icache/dcache command changes and various
build fixes for add cases that occur when trying to build an
extremely minimal image
Signed-off-by: Matthew McClintock m...@freescale.com
---
Makefile | 38 +-
mkconfig |1 +
2 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0400930..7a9cae7 100644
--- a/Makefile
+++ b/Makefile
@@ -317,6 +317,16 @@ ifeq ($(CONFIG_NAND_U_BOOT),y)
ALL += $(obj)u-boot-nand.bin
endif
+ifndef CONFIG_IN_BOOTSTRAP
+ifeq ($(CONFIG_SPIFLASH), y)
+ALL += $(obj)u-boot-spi.bin
+endif
+
+ifeq ($(CONFIG_SDCARD), y)
+ALL += $(obj)u-boot-sd.bin
+endif
+endif
+
ifeq ($(CONFIG_ONENAND_U_BOOT),y)
ALL += $(obj)u-boot-onenand.bin
ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
@@ -404,8 +414,16 @@ $(obj)u-boot.lds: $(LDSCRIPT)
nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
+NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin
+NAND_SPL_OBJS-$(CONFIG_BOOTSTRAP) += $(obj)u-boot-bootstrap.bin
+NAND_SPL_OBJS-y += $(obj)u-boot.bin
+
+ifeq ($(CONFIG_BOOTSTRAP),y)
+$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot-bootstrap.bin $(obj)u-boot.bin
+else
$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin
- cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin
$(obj)u-boot-nand.bin
+endif
+ cat $(NAND_SPL_OBJS-y) $(obj)u-boot-nand.bin
onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
$(MAKE) -C onenand_ipl/board/$(BOARDDIR) all
@@ -413,6 +431,23 @@ onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE)
$(obj)include/autoconf.mk
$(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin $(obj)u-boot-onenand.bin
+ifdef CONFIG_BOOTSTRAP
+$(obj)u-boot-spi.bin: $(obj)u-boot.bin $(obj)u-boot-bootstrap.bin
+ cat $(obj)u-boot-bootstrap.bin $(obj)u-boot.bin
$(obj)u-boot-spi.bin
+$(obj)u-boot-sd.bin: $(obj)u-boot.bin $(obj)u-boot-bootstrap.bin
+ cat $(obj)u-boot-bootstrap.bin $(obj)u-boot.bin
$(obj)u-boot-sd.bin
+else
+$(obj)u-boot-spi.bin: $(obj)u-boot.bin
+ ln -s u-boot.bin u-boot-spi.bin
+$(obj)u-boot-sd.bin: $(obj)u-boot.bin
+ ln -s u-boot.bin u-boot-sd.bin
+endif
+
+$(obj)u-boot-bootstrap.bin:
+ rm -rf $(BUILD_DIR)bootstrap
+ $(MAKE) $(CONFIG_BOARD_NAME) O=bootstrap/
EXTRA_OPTS=IN_BOOTSTRAP
+ cp $(BUILD_DIR)bootstrap/u-boot.bin u-boot-bootstrap.bin
+
$(VERSION_FILE):
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
printf '#define PLAIN_VERSION %s%s\n' \
@@ -1130,6 +1165,7 @@ clean:
\( -name 'core' -o -name '*.bak' -o -name '*~' \
-o -name '*.o' -o -name '*.a' -o -name '*.exe' \) -print \
| xargs rm -f
+ @rm -fr $(BUILD_DIR)bootstrap/
clobber: clean
@find $(OBJTREE) -type f \( -name '*.depend' \
diff --git a/mkconfig b/mkconfig
index e72ec3d..74294ec 100755
--- a/mkconfig
+++ b/mkconfig
@@ -159,6 +159,7 @@ for i in ${TARGETS} ; do
done
cat EOF config.h
+#define CONFIG_BOARD_NAME $BOARD_NAME
#define CONFIG_BOARDDIR board/$BOARDDIR
#include config_cmd_defaults.h
#include config_defaults.h
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Add P1021MDS board support
From: Haiying Wang haiying.w...@freescale.com
This patch supports P1021MDS board to boot from NAND flash (No NOR flash on this
board). And because P1021 only has 256K L2 SRAM, which can not used for final
uboot image it makes use of the MPL.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
Signed-off-by: Mohit Kumar mohit.ku...@freescale.com
Signed-off-by: Yu Liu yu@freescale.com
Signed-off-by: Kai Jiang kai.ji...@freescale.com
Signed-off-by: Zhao Chenhui b35...@freescale.com
Signed-off-by: Matthew McClintock m...@freescale.com
---
This patch requires some previously sent patches to build correctly. They
deal build fixes for building the 256k middle u-boot image:
http://patchwork.ozlabs.org/patch/97219/
http://patchwork.ozlabs.org/patch/97177/
http://patchwork.ozlabs.org/patch/97174/
http://patchwork.ozlabs.org/patch/97026/
and one from Mike Frysinger
http://patchwork.ozlabs.org/patch/98422/
I'm skipping the following checkpatch warnings since they don't seem
to apply:
WARNING: Use #include linux/io.h instead of asm/io.h
+#include asm/io.h
WARNING: Use #include linux/io.h instead of asm/io.h
+#include asm/io.h
WARNING: suspect code indent for conditional statements (8, 8)
if (uec-the_first_run == 0) {
[...]
+ /* P1021MDS board needs to reset micrel phy for each UEC */
ERROR: Macros with multiple statements should be enclosed in a do - while loop
+#define CONFIG_SYS_I2C_NOPROBES{ {0, 0x69} } /* Don't probe these
addrs */
ERROR: need consistent spacing around '/' (ctx:WxV)
+#define CONFIG_ROOTPATH/nfsroot
^
ERROR: Macros with complex values should be enclosed in parenthesis
+#define CONFIG_ROOTPATH/nfsroot
WARNING: Use #include linux/io.h instead of asm/io.h
+#include asm/io.h
MAINTAINERS |4 +
README| 13 +
board/freescale/p1021mds/Makefile | 52 ++
board/freescale/p1021mds/ddr.c| 81
board/freescale/p1021mds/law.c| 32 ++
board/freescale/p1021mds/p1021mds.c | 181 +++
board/freescale/p1021mds/tlb.c| 100
boards.cfg|1 +
drivers/qe/uec.c |9 +
include/configs/P1021MDS.h| 629 +
nand_spl/board/freescale/p1021mds/Makefile| 137 ++
nand_spl/board/freescale/p1021mds/nand_boot.c | 69 +++
12 files changed, 1308 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1021mds/Makefile
create mode 100644 board/freescale/p1021mds/ddr.c
create mode 100644 board/freescale/p1021mds/law.c
create mode 100644 board/freescale/p1021mds/p1021mds.c
create mode 100644 board/freescale/p1021mds/tlb.c
create mode 100644 include/configs/P1021MDS.h
create mode 100644 nand_spl/board/freescale/p1021mds/Makefile
create mode 100644 nand_spl/board/freescale/p1021mds/nand_boot.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e2c48a8..71a1310 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17,6 +17,10 @@
# Board CPU #
#
+Haiying Wang haiying.w...@freescale.com
+
+ P1021MDSP1021
+
Poonam Aggrwal poonam.aggr...@freescale.com
P2020RDBP2020
diff --git a/README b/README
index 8779544..cd785c5 100644
--- a/README
+++ b/README
@@ -2225,6 +2225,19 @@ FIT uImage format:
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
+- NAND Boot Support
+ CONFIG_NAND_U_BOOT
+
+ Builds a U-Boot image that boots from NAND, prefixed by a small
+ loader stub (secondary program loader -- SPL) that loads the
+ rest of U-Boot into RAM. This symbol will be set in all build
+ phases.
+
+ CONFIG_NAND_SPL
+
+ This is set by the build system when compiling code to go into
+ the SPL. It is not set when building the code that the SPL
+ loads.
Modem Support:
--
diff --git a/board/freescale/p1021mds/Makefile
b/board/freescale/p1021mds/Makefile
new file mode 100644
index 000..50d4743
--- /dev/null
+++ b/board/freescale/p1021mds/Makefile
@@ -0,0 +1,52 @@
+#
+# Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY
[U-Boot] [PATCH 2/4] build/mkconfig: Add EXTRA_OPTS argument to make to modify build
Allow users to pass in extra defines via make so they can
modify the build. Example
make P1022DS EXTRA_OPTS=NAND
is equivalent to
make P1022DS_NAND
Signed-off-by: Matthew McClintock m...@freescale.com
---
mkconfig |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/mkconfig b/mkconfig
index 6ff533f..e72ec3d 100755
--- a/mkconfig
+++ b/mkconfig
@@ -81,6 +81,12 @@ if [ ${ARCH} -a ${ARCH} != ${arch} ]; then
exit 1
fi
+if [ -z ${options} ] ; then
+options+=$EXTRA_OPTS
+else
+options+=,$EXTRA_OPTS
+fi
+
if [ $options ] ; then
echo Configuring for ${BOARD_NAME} - Board: ${CONFIG_NAME}, Options:
${options}
else
@@ -146,7 +152,7 @@ else
config.h # Create new config file
fi
echo /* Automatically generated - do not edit */ config.h
-
+TARGETS+=`echo $EXTRA_OPTS | tr ',' ' '`
for i in ${TARGETS} ; do
i=`echo ${i} | sed '/=/ {s/=/\t/;q } ; { s/$/\t1/ }'`
echo #define CONFIG_${i} config.h ;
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Add P1021MDS board support
From: Haiying Wang haiying.w...@freescale.com
This patch supports P1021MDS board to boot from NAND flash (No NOR flash on this
board). And because P1021 only has 256K L2 SRAM, which can not used for final
uboot image it makes use of the MPL.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
Signed-off-by: Mohit Kumar mohit.ku...@freescale.com
Signed-off-by: Yu Liu yu@freescale.com
Signed-off-by: Kai Jiang kai.ji...@freescale.com
Signed-off-by: Zhao Chenhui b35...@freescale.com
Signed-off-by: Matthew McClintock m...@freescale.com
---
This patch requires some previously sent patches to build correctly. They
deal build fixes for building the 256k middle u-boot image:
http://patchwork.ozlabs.org/patch/97219/
http://patchwork.ozlabs.org/patch/97177/
http://patchwork.ozlabs.org/patch/97174/
http://patchwork.ozlabs.org/patch/97026/
and one from Mike Frysinger
http://patchwork.ozlabs.org/patch/98422/
I'm skipping the following checkpatch warnings since they don't seem
to apply:
WARNING: Use #include linux/io.h instead of asm/io.h
+#include asm/io.h
WARNING: Use #include linux/io.h instead of asm/io.h
+#include asm/io.h
WARNING: suspect code indent for conditional statements (8, 8)
if (uec-the_first_run == 0) {
[...]
+ /* P1021MDS board needs to reset micrel phy for each UEC */
ERROR: Macros with multiple statements should be enclosed in a do - while loop
+#define CONFIG_SYS_I2C_NOPROBES{ {0, 0x69} } /* Don't probe these
addrs */
ERROR: need consistent spacing around '/' (ctx:WxV)
+#define CONFIG_ROOTPATH/nfsroot
^
ERROR: Macros with complex values should be enclosed in parenthesis
+#define CONFIG_ROOTPATH/nfsroot
WARNING: Use #include linux/io.h instead of asm/io.h
+#include asm/io.h
MAINTAINERS |4 +
README| 13 +
board/freescale/p1021mds/Makefile | 52 ++
board/freescale/p1021mds/ddr.c| 81
board/freescale/p1021mds/law.c| 32 ++
board/freescale/p1021mds/p1021mds.c | 181 +++
board/freescale/p1021mds/tlb.c| 100
boards.cfg|1 +
drivers/qe/uec.c |9 +
include/configs/P1021MDS.h| 629 +
nand_spl/board/freescale/p1021mds/Makefile| 137 ++
nand_spl/board/freescale/p1021mds/nand_boot.c | 69 +++
12 files changed, 1308 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1021mds/Makefile
create mode 100644 board/freescale/p1021mds/ddr.c
create mode 100644 board/freescale/p1021mds/law.c
create mode 100644 board/freescale/p1021mds/p1021mds.c
create mode 100644 board/freescale/p1021mds/tlb.c
create mode 100644 include/configs/P1021MDS.h
create mode 100644 nand_spl/board/freescale/p1021mds/Makefile
create mode 100644 nand_spl/board/freescale/p1021mds/nand_boot.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e2c48a8..71a1310 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17,6 +17,10 @@
# Board CPU #
#
+Haiying Wang haiying.w...@freescale.com
+
+ P1021MDSP1021
+
Poonam Aggrwal poonam.aggr...@freescale.com
P2020RDBP2020
diff --git a/README b/README
index 8779544..cd785c5 100644
--- a/README
+++ b/README
@@ -2225,6 +2225,19 @@ FIT uImage format:
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
+- NAND Boot Support
+ CONFIG_NAND_U_BOOT
+
+ Builds a U-Boot image that boots from NAND, prefixed by a small
+ loader stub (secondary program loader -- SPL) that loads the
+ rest of U-Boot into RAM. This symbol will be set in all build
+ phases.
+
+ CONFIG_NAND_SPL
+
+ This is set by the build system when compiling code to go into
+ the SPL. It is not set when building the code that the SPL
+ loads.
Modem Support:
--
diff --git a/board/freescale/p1021mds/Makefile
b/board/freescale/p1021mds/Makefile
new file mode 100644
index 000..50d4743
--- /dev/null
+++ b/board/freescale/p1021mds/Makefile
@@ -0,0 +1,52 @@
+#
+# Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY
[U-Boot] [PATCH 2/4] build/mkconfig: Add EXTRA_OPTS argument to make to modify build
From: Matthew McClintock m...@freescale.com
Allow users to pass in extra defines via make so they can
modify the build. Example
make P1022DS EXTRA_OPTS=NAND
is equivalent to
make P1022DS_NAND
Signed-off-by: Matthew McClintock m...@freescale.com
---
mkconfig |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/mkconfig b/mkconfig
index 6ff533f..e72ec3d 100755
--- a/mkconfig
+++ b/mkconfig
@@ -81,6 +81,12 @@ if [ ${ARCH} -a ${ARCH} != ${arch} ]; then
exit 1
fi
+if [ -z ${options} ] ; then
+options+=$EXTRA_OPTS
+else
+options+=,$EXTRA_OPTS
+fi
+
if [ $options ] ; then
echo Configuring for ${BOARD_NAME} - Board: ${CONFIG_NAME}, Options:
${options}
else
@@ -146,7 +152,7 @@ else
config.h # Create new config file
fi
echo /* Automatically generated - do not edit */ config.h
-
+TARGETS+=`echo $EXTRA_OPTS | tr ',' ' '`
for i in ${TARGETS} ; do
i=`echo ${i} | sed '/=/ {s/=/\t/;q } ; { s/$/\t1/ }'`
echo #define CONFIG_${i} config.h ;
--
1.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dreamplug into mainline
On Thu, Jun 02, 2011 at 02:11:04PM -0400, Jason wrote: Prafulla, As a practical learning exercise, I'm going to attempt to add support for the Dreamplug into the mainline u-boot tree. I'm starting with the board number. It is currently 2659. The same as the Guruplug. This is less than ideal because the Dreamplug has 2MB (yes, megabytes) of SPI flash, whereas the Guruplug had 512 MB of flash. I've found [1] for requesting a new board number, but can I do it? I'm not related to Marvell in any way... Well, no going back now [2] ... ;-) The Dreamplug is now 3550. Off to start writing patches. [1] http://www.arm.linux.org.uk/developer/machines/ [2] http://www.arm.linux.org.uk/developer/machines/list.php?id=3550 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Albert/Wolfgang, I believe this patchset should be GTG. Are there any objections outstanding that I've failed to answer? Thanks, Tom On Tue, May 3, 2011 at 12:29 PM, Mike Frysinger vap...@gentoo.org wrote: On Tue, May 3, 2011 at 12:49, Michael Walle wrote: Am Di, 3.05.2011, 00:45, schrieb Tom Warren: Changes in V2: - use 'gpio_pin' enum in gpio.h (Simon Glass review request) - change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request) - change 'offset' to 'pin' globally arch/arm/include/asm/arch-tegra2/gpio.h | 244 - drivers/gpio/Makefile | 1 + drivers/gpio/tegra2_gpio.c | 299 Does this (SoC) driver belong to drivers/gpio/ or arch/arm/cpu/armv7/tegra2/? To me it seems that both are used for architectures/SoCs specific drivers (eg. blackfin, omap in arch/ and at91 in drivers/gpio/). What is the preferred directory? following the Linux style makes sense to me. only gpio expanders and such live in drivers/gpio/. but until we get a more unified api effort, i'm not sure sweating the location of the driver is important. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-blackfin.git
Dear Mike Frysinger, In message 201106021102.08032.vap...@gentoo.org you wrote: these are absolutely fixes: Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings Blackfin: use on-chip reset func with newer parts Blackfin: bf548-ezkit/bf561-ezkit: update env location Blackfin: boards: build zlib dir with -O2 this was waiting on a patch that you didnt merge until later and so i couldnt push with my earlier set: Blackfin: use common LDSCRIPT logic OK. this is partially new stuff, and partially fixing existing behavior to match the hardware: Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings So this should be split into two separate commits, or has to wait. this is new stuff, but i was lazy and didnt want to figure out the patch relationship with the other changes to these files, and it's safe: Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support It will go into next, then. Please prepare an updated pull request. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issues building for the P2020 (linking)
Dear Stafford, Matthew, In message 0b0a20d0b3ecd742aa2514c8dda3b06505122...@vgaexch01.hq.corp.viasat.com you wrote: Hi, I'm currently trying to build out of git and am seeing an issue with the final linking during the build. I've included the relevant dump: Using P2020DS_config It's a tool chain issue. The same config builds fine for me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, The Trouble with Tribbles, stardate 4525.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Dear Tom Warren, In message banlktik3em_qlp7ahfpx2svvmvo0ens...@mail.gmail.com you wrote: I believe this patchset should be GTG. Are there any objections outstanding that I've failed to answer? GTG ??? I did not see any cleanup resulting from Mike's comment here: 05/02 Mike Frysinger Re: [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99112 05/02 Tom Warren Re: [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99114 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Little known fact about Middle Earth: The Hobbits had a very sophi- sticated computer network! It was a Tolkien Ring... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
On Thu, Jun 2, 2011 at 1:56 PM, Wolfgang Denk w...@denx.de wrote: Dear Tom Warren, In message banlktik3em_qlp7ahfpx2svvmvo0ens...@mail.gmail.com you wrote: I believe this patchset should be GTG. Are there any objections outstanding that I've failed to answer? GTG ??? Good To Go. I did not see any cleanup resulting from Mike's comment here: 05/02 Mike Frysinger Re: [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99112 05/02 Tom Warren Re: [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99114 Let me double-check. IIRC, one (cmd_gpio) didn't apply since it was from another SoC and didn't have the commands we use on Tegra, and the other (where the driver should go) ended with Mike saying i'm not sure sweating the location of the driver is important, so I've left it with the other GPIO drivers. Mike - you good with that status? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Little known fact about Middle Earth: The Hobbits had a very sophi- sticated computer network! It was a Tolkien Ring... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Dear Tom Warren, In message BANLkTi=w1u7q+w-vkrycq-wb50e7edf...@mail.gmail.com you wrote: Let me double-check. IIRC, one (cmd_gpio) didn't apply since it was from another SoC and didn't have the commands we use on Tegra, and the other (where the driver should go) ended with Mike saying i'm not sure sweating the location of the driver is important, so I've left it with the other GPIO drivers. What I'm referring to is the lots of duplicated code part. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2011.06-rc2 released
Hello everybody: * U-Boot v2011.06-rc2 was released on Thu, June 02, 2011 * Release v2011.06 is scheduled in 10 days - on June 12, 2011. Please help testing, and check if all your relevant patches have been included. Note that still a large number of ARM boards are broken. I hope many people join the efforts and fix at least some of the currently broken boards. Note: Boards that will not be fixed for this release will be removed with the next one. [See following warning message.] Thanks in advance to everybody who lends a helping hand. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When you die, the first thing you lose is your life. The next thing is the illusions. - Terry Pratchett, _Pyramids_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] WARNING: huge ARM board removal pending
Hi, this is a * W A R N I N G * message to maintainers / users / owners of ARM boards. If your board fails to build in the current release, it will be subject to a big cleanup action which is going to remove all old, unmaintained and broken boards in the next merge window. According to our current schedule, this is in 10 days from now. At present, the following 112 boards are scheduled for removal: B2 at91sam9m10g45ekedb9307aomap2420h4 CPU9260 at91sam9rlekedb9312 omap5912osk CPU9G20 cmc_pu2 edb9315 omap730p2 CPUAT91 cp1026 edb9315aotc570_dataflash SBC35_A9G20 cp1136 ep7312 pm9261 SMN42 cp920t evb4510 pm9263 TNY_A9260 cp922_XA10 gcplus pm9g45 TNY_A9G20 cp926ejsimpa7 sbc2410x afeb9260cp946es imx31_phycore scb9328 ap7 cp966 imx31_phycore_eet shannon ap720t cpu9260 integratorapsmdk2400 ap920t cpu9260_128Mintegratorcpsmdk6400 ap922_XA10 cpu9260_nandjornada snapper9260 ap926ejscpu9260_nand_128M kb9202 snapper9g20 ap946es cpu9G20 lartspear300 ap966 cpu9G20_128Mlpc2292sodimm spear310 apollon cpu9G20_nandlpd7a400spear320 armadillo cpu9G20_nand_128M m501sk spear600 assabet cpuat91 meesc tnetv107x_evm at91cap9adk cpuat91_ram meesc_dataflash top9000eval_xe at91rm9200dkcsb226 modnet50top9000su_xe at91rm9200ekcsb637 mx1ads trab at91rm9200ek_ramdnp1110 mx1fs2 versatile at91sam9260ek eb_cpux9k2 mx31ads versatileab at91sam9261ek edb9301 netstar versatilepb at91sam9263ek edb9302 omap1510inn voiceblue at91sam9g10ek edb9302aomap1610h2 zipitz2 at91sam9g20ek edb9307 omap1610inn zylonite Please submit fixes to prevent removal. Note: countdown is T minus 10 days, and counting. You have been warned. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de C++ is the best example of second-system effect since OS/360. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
On Thu, Jun 2, 2011 at 2:34 PM, Wolfgang Denk w...@denx.de wrote: Dear Tom Warren, In message BANLkTi=w1u7q+w-vkrycq-wb50e7edf...@mail.gmail.com you wrote: Let me double-check. IIRC, one (cmd_gpio) didn't apply since it was from another SoC and didn't have the commands we use on Tegra, and the other (where the driver should go) ended with Mike saying i'm not sure sweating the location of the driver is important, so I've left it with the other GPIO drivers. What I'm referring to is the lots of duplicated code part. Actually, if you do a kompare between cmd_gpio.c and tegra2_gpio.c, there's virtually no 'duplicated' code, just 2 different implementations of do_gpio, with different args and parsing of params, etc. I use info, port, input and output, and cmd_gpio uses input, set, clear and toggle. Since cmd_gpio.c isn't built, it's not duplicating any code in the U-Boot binary, space-wise. So there's no advantage to using it instead of my own driver's cmd parser. Note that the PCA953x GPIO driver also does it's own cmd parsing in do_pca953x(). Tom Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dreamplug into mainline
-Original Message- From: Jason [mailto:u-b...@lakedaemon.net] Sent: Thursday, June 02, 2011 11:41 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Dreamplug into mainline Prafulla, As a practical learning exercise, I'm going to attempt to add support for the Dreamplug into the mainline u-boot tree. Hi Jason Grand Welcome on a board as u-boot developer for Kirkwood support. I'm starting with the board number. It is currently 2659. The same as the Guruplug. This is less than ideal because the Dreamplug has 2MB (yes, megabytes) of SPI flash, whereas the Guruplug had 512 MB of flash. There are other peripherals on the Dreamplug that aren't on the Guruplug (audio, etc) but I don't see that as immediately relevant with U-Boot. I've found [1] for requesting a new board number, but can I do it? I'm not related to Marvell in any way... My plan right now is to make copies of all the guruplug stuff, do s/guruplug/dreamplug/g on the new files, consolidate, then add the support for the SPI. Any holes in that? I suggest- you should definitely go for new board number for Dreamplug. If your delta is relatively small w.r.to Guruplug and has additional code to support additional peripherals, you can still reuse Guruplug board support files. Check how different OpenRD board versions are supported using same code. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SMDKV310: MMC_SPL: Fix building when using make O=
Fixes dependency build error with make O= option. make O= option is used to specify output directory. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- mmc_spl/board/samsung/smdkv310/Makefile | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mmc_spl/board/samsung/smdkv310/Makefile b/mmc_spl/board/samsung/smdkv310/Makefile index f1ce066..d4d7ad7 100644 --- a/mmc_spl/board/samsung/smdkv310/Makefile +++ b/mmc_spl/board/samsung/smdkv310/Makefile @@ -40,7 +40,7 @@ CFLAGS+= -DCONFIG_PRELOADER SOBJS = start.o mem_setup.o lowlevel_init.o COBJS = mmc_boot.o -SRCS := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c)) +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) __OBJS := $(SOBJS) $(COBJS) LNDIR := $(OBJTREE)/mmc_spl/board/$(BOARDDIR) @@ -76,25 +76,25 @@ $(mmcobj)u-boot.lds: $(LDSCRIPT) # create symbolic links for common files # from cpu directory -$(obj)start.S: +start.S: @rm -f $@ @ln -s $(TOPDIR)/arch/arm/cpu/armv7/start.S $@ # from board directory -$(obj)mem_setup.S: +mem_setup.S: @rm -f $@ @ln -s $(TOPDIR)/board/samsung/smdkv310/mem_setup.S $@ -$(obj)lowlevel_init.S: +lowlevel_init.S: @rm -f $@ @ln -s $(TOPDIR)/board/samsung/smdkv310/lowlevel_init.S $@ # -$(obj)%.o: $(obj)%.S +$(obj)%.o: %.S $(CC) $(AFLAGS) -c -o $@ $ -$(obj)%.o: $(obj)%.c +$(obj)%.o: %.c $(CC) $(CFLAGS) -c -o $@ $ # defines $(obj).depend target -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Dear Tom Warren, In message BANLkTi=z7tb7s1ghjkierz812eoym8t...@mail.gmail.com you wrote: Let me double-check. IIRC, one (cmd_gpio) didn't apply since it was from another SoC and didn't have the commands we use on Tegra, and the other (where the driver should go) ended with Mike saying i'm not sure sweating the location of the driver is important, so I've left it with the other GPIO drivers. What I'm referring to is the lots of duplicated code part. Actually, if you do a kompare between cmd_gpio.c and tegra2_gpio.c, there's virtually no 'duplicated' code, just 2 different implementations of do_gpio, with different args and parsing of params, etc. I use info, port, input and output, and cmd_gpio uses input, set, clear and toggle. Since cmd_gpio.c isn't built, it's not duplicating any code in the U-Boot binary, space-wise. So there's no advantage to using it instead of my own driver's cmd parser. There is duplication (at least function-wise) in the U-Boot source code base. This is to be avoided. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [WIKI][Timer]New Timer API Page added to Wiki
Hi all, I've just created a new Wiki entry for the new Timer API at: http://www.denx.de/wiki/U-Boot/TaskTimerAPI Right now it only details the user-level interface to the API while we still work out the nuts and bolts underneath - Please take a look and comment Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] common/env_common: Add CONFIG_SILENT_CONSOLE_AT_BOOT env option
On Thursday, June 02, 2011 15:27:29 y...@right.am.freescale.net wrote: Just setting CONFIG_SILENT_CONSOLE does not make the CONSOLE silent without the silent env variable set. This adds a new define to add this to the default environment easily any reason you couldnt add silent=0 to CONFIG_EXTRA_ENV_SETTINGS ? -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/4] build/mkconfig: Add EXTRA_OPTS argument to make to modify build
On Thursday, June 02, 2011 15:27:30 y...@right.am.freescale.net wrote:
--- a/mkconfig
+++ b/mkconfig
@@ -81,6 +81,12 @@ if [ ${ARCH} -a ${ARCH} != ${arch} ]; then
exit 1
fi
+if [ -z ${options} ] ; then
+options+=$EXTRA_OPTS
+else
+options+=,$EXTRA_OPTS
+fi
style is broken (lacking indentation), and the += operator is not in the
POSIX shell spec
-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 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
On Thursday, June 02, 2011 17:30:09 Tom Warren wrote: Let me double-check. IIRC, one (cmd_gpio) didn't apply since it was from another SoC no, it isnt. it's using the generic GPIO API as defined by Linux and implemented by many ports in u-boot. any new GPIO provider in u-boot should probably be implementing that API too. -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 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
On Thursday, June 02, 2011 17:55:55 Tom Warren wrote: Actually, if you do a kompare between cmd_gpio.c and tegra2_gpio.c, there's virtually no 'duplicated' code, just 2 different implementations of do_gpio, with different args and parsing of params, etc. I use info, port, input and output, and cmd_gpio uses input, set, clear and toggle. you're duplicating functionality. if the common cmd_gpio.c lacks features that yours adds, then send a patch to extend cmd_gpio.c. the fact that yours takes different arguments to do the same thing is irrelevant. change your scripts and/or muscle memory to the common cmd_gpio.c. Note that the PCA953x GPIO driver also does it's own cmd parsing in do_pca953x(). then someone should clean it up -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] common/env_common: Add CONFIG_SILENT_CONSOLE_AT_BOOT env option
On Thursday, June 02, 2011 15:34:57 Matthew McClintock wrote: Just setting CONFIG_SILENT_CONSOLE does not make the CONSOLE silent without the silent env variable set. This adds a new define to add this to the default environment easily any reason you couldnt add silent=0 to CONFIG_EXTRA_ENV_SETTINGS ? -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/4] build/mkconfig: Add EXTRA_OPTS argument to make to modify build
On Thursday, June 02, 2011 15:34:58 Matthew McClintock wrote:
--- a/mkconfig
+++ b/mkconfig
@@ -81,6 +81,12 @@ if [ ${ARCH} -a ${ARCH} != ${arch} ]; then
exit 1
fi
+if [ -z ${options} ] ; then
+options+=$EXTRA_OPTS
+else
+options+=,$EXTRA_OPTS
+fi
style is broken (lacking indentation), and the += operator is not in the
POSIX shell spec
-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] post, arm, memorytest: add support for arm based boards
Hello Mike, Mike Frysinger wrote: On Thursday, June 02, 2011 01:53:42 Heiko Schocher wrote: Mike Frysinger wrote: so add bi_memsize to arm ? it's the only arch that lacks it. Hmm.. I thought of that too, but wouldn;t it be better to use gd-ram_size in post/drivers/memory.c, as this is defined in global_data for all archs? makes me wonder why we have bd-bi_memsize in the first place. and how can this possibly work ? arch/arm/lib/board.c: sprintf ((char *)memsz, %ldk, (bd-bi_memsize / 1024) - pram); -mike Yep, good question ... maybe, no arm based board has defined #if defined(CONFIG_PRAM) || defined(CONFIG_LOGBUFFER) ? I can make a fix and change this to gd-ram_size? 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 v2] post, memorytest: add support for none powerpc archs
change bd-bi_memsize to gd-ram_size, as this is defined
on all archs, so this post test can used on none powerpc
archs too.
Signed-off-by: Heiko Schocher h...@denx.de
cc: Wolfgang Denk h...@denx.de
cc: Mike Frysinger vap...@gentoo.org
---
changes for v2:
added comment from Wolfgang Denk:
- add comment, that this function is only valid
for contiguous memory banks.
added comment from Mike Frysinger:
- use gd-ram_size instead of bd-bi_memsize
- no ifdef needed.
post/drivers/memory.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/post/drivers/memory.c b/post/drivers/memory.c
index b7943ef..b286e3f 100644
--- a/post/drivers/memory.c
+++ b/post/drivers/memory.c
@@ -452,13 +452,17 @@ static int memory_post_tests (unsigned long start,
unsigned long size)
return ret;
}
+/*
+ * !! this is only valid, if you have contiguous memory banks !!
+ */
__attribute__((weak))
int arch_memory_test_prepare(u32 *vstart, u32 *size, phys_addr_t *phys_offset)
{
bd_t *bd = gd-bd;
+
*vstart = CONFIG_SYS_SDRAM_BASE;
- *size = (bd-bi_memsize = 256 20 ?
- 256 20 : bd-bi_memsize) - (1 20);
+ *size = (gd-ram_size = 256 20 ?
+ 256 20 : gd-ram_size) - (1 20);
/* Limit area to be tested with the board info struct */
if ((*vstart) + (*size) (ulong)bd)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
