[U-Boot] Please pull u-boot-atmel/master
Dear Albert, The following changes since commit 0d8bc1c7b3caffd5626b6cf4888bfb5751f24041: Fabio Estevam (1): mx31pdk: Add DHCP command are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Eric Benard (4): arm926ejs/at91/lowlevel_init.S: fix defines cpu9260/9G20: fix board support cpuat91: fix board support include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme Jens Scharsig (1): update arm/at91rm9200 work with rework rework110202 Reinhard Meyer (3): AT91 rework: fix at91sam(9260/9g20/9xe)ek board port to build again: AT91 rework: fix TOP9000 files to build again ATMEL spi_dataflash driver - fix to build again Ryan Mallon (1): Add support for Bluewater Systems Snapper 9260/9G20 modules Sergey Lapin (1): Build fix/update of AFEB9260 andreas.de...@googlemail.com (2): at91_emac: fix compile warning macb: fix compile warning MAINTAINERS |5 + MAKEALL |3 - Makefile | 45 - arch/arm/cpu/arm920t/at91/reset.c|2 +- arch/arm/cpu/arm920t/at91/timer.c| 12 +- arch/arm/cpu/arm926ejs/at91/lowlevel_init.S | 24 ++-- arch/arm/include/asm/arch-at91/at91_matrix.h | 10 +- arch/arm/include/asm/arch-at91/at91_mc.h | 12 +- arch/arm/include/asm/arch-at91/at91_pio.h| 14 +- arch/arm/include/asm/arch-at91/at91_pmc.h| 10 +- arch/arm/include/asm/arch-at91/at91_rstc.h |2 +- arch/arm/include/asm/arch-at91/at91_wdt.h|2 +- arch/arm/include/asm/arch-at91/at91rm9200.h | 209 -- arch/arm/include/asm/arch-at91/at91sam9260.h |1 + arch/arm/include/asm/arch-at91/at91sam9261.h |1 + arch/arm/include/asm/arch-at91/at91sam9263.h |1 + arch/arm/include/asm/arch-at91/at91sam9_sdramc.h | 30 ++-- arch/arm/include/asm/arch-at91/at91sam9_smc.h| 12 +- board/BuS/eb_cpux9k2/cpux9k2.c | 52 +++--- board/afeb9260/afeb9260.c| 101 ++- board/atmel/at91rm9200ek/at91rm9200ek.c |4 +- board/atmel/at91rm9200ek/led.c | 22 ++- board/atmel/at91sam9260ek/at91sam9260ek.c| 127 +++-- board/atmel/at91sam9260ek/config.mk |1 - board/atmel/at91sam9260ek/led.c |8 +- board/bluewater/snapper9260/Makefile | 53 ++ board/bluewater/snapper9260/snapper9260.c| 169 + board/emk/top9000/top9000.c | 64 --- board/eukrea/cpu9260/cpu9260.c | 33 ++-- board/eukrea/cpu9260/led.c |6 +- board/eukrea/cpuat91/cpuat91.c |6 +- boards.cfg |9 + drivers/net/at91_emac.c | 44 +++--- drivers/net/macb.c |5 +- drivers/spi/atmel_dataflash_spi.c|3 +- include/configs/afeb9260.h | 78 + include/configs/at91rm9200ek.h |5 +- include/configs/at91sam9260ek.h | 107 +++- include/configs/cpu9260.h| 11 +- include/configs/eb_cpux9k2.h | 23 ++-- include/configs/snapper9260.h| 191 include/configs/top9000.h| 30 ++-- 42 files changed, 996 insertions(+), 551 deletions(-) delete mode 100644 board/atmel/at91sam9260ek/config.mk create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/snapper9260.c create mode 100644 include/configs/snapper9260.h Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91rm9200 linking problem (?)
Dear Marcin Górski, Am 20.06.2011 10:36, schrieb Marcin Górski: Hello, I'm trying to port U-Boot to ARMEVA board (with AT92RM9200 cpu). I'm a little bit confused about usage of CONFIG_SYS_TEXT_BASE macro. As mentioned many times before U-Boot shouldn't be run from RAM, so I set CONFIG_SYS_TEXT_BASE to point a DataFlash memory. But when I do that not only .text section but also .data and .bss sections are linked to flash memory. When I run U-Boot I get prefetch_abort exception (which I believe is due to invalid memory location access). On the other hand, when I set CONFIG_SYS_TEXT_BASE to point to RAM location U-Boot hangs just after the start: unfortunately I did not get at91rm9200ek working to boot from NOR flash or dataflash correctly. I'm working on that, but only in my rare spare time. If you get it working, please tell it to me. U-Boot go 0x2200 ## Starting application at 0x2200 ... U-Boot 2011.03 (Jun 20 2011 - 00:56:19) DRAM: 1 MiB To load a new image I use an old version of U-Boot (1.1.6) that was previously installed on this board. This is the very first time when I use U-Boot , any suggestion will be appreciated. That is Ok, but you need to SKIP_LOWLEVEL_INIT (or similar) to prevent the start.S to re-initiate the SDRAM (which was done by the first loader, u-boot 1.1.6 here). You need to link your new U-Boot to an address somewhere in SDRAM (e.g. 0x2200, if your system has more than 32MiB) and then use the first stage loader (u-boot 1.1.6 here) to transfer the new u-boot exactely to that address! But keep in mind to _not_ touch the SDRAM configuration if you have some data in SDRAM ;) You can use the at91bootstarp as first stage bootloader in future. But I recommend you to invest some time to get U-Boot as SPL working on that architecture. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Not able access External peripherals in PPC440EP
Hi, I am using a PPC 440EP processor based custom designed board which is based on AMCC's Yosemite as reference design. I have ported u-boot-1.1.6 onto it. It is working fine but not able to access external peripherals like NVRAM, ADC, DAC etc. in the board. When try to read those addresses with MD command it is generating exception. Can anybody please help me how to access them Regards Suresh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA SD
2011/6/18 Albert ARIBAUD albert.u.b...@aribaud.net: Hi, Le 17/06/2011 10:29, Alexei Ozhigov a écrit : 2011/6/17 Prafulla Wadaskarprafu...@marvell.com: -Original Message- From: Philip Hands [mailto:p...@hands.com] Sent: Friday, June 17, 2011 1:33 AM To: Alexei Ozhigov Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] OpenRD Ultimate SATA SD On Thu, 16 Jun 2011 16:18:46 +0400, Alexei Ozhigov alexei.ozhi...@gmail.com wrote: ... I am experiencing the same problem with SATA right now with v2011.06-rc2 (tried also the latest master). If MVSATA_STATUS_TIMEOUT in mvsata_ide_initialize_port is ignored, SATA drive is found on the second port and I am able to read the drive's content. Inspired by what you say about timeouts, I thought perhaps increasing the timeout from 10ms to 1s might make a difference -- that worked! ... except that now, it's working regardless :-( So, I've no idea if that's really related to what's going on, because I've now gone as far as reducing the timeout to 5ms and it's _still_ working fine, so perhaps some part of the SATA subsystem was in a state that was somehow reset by waiting a bit longer for the startup once, and that's somehow fixed it. It is still working despite powering down the machine for a while, so I'm guessing whatever changed is something to do with the state of the hard drive. Sadly that means that I've now lost the ability to test this, since trying any of the versions that were previously failing now work. Anyway, Alexei, try increasing the timeout (i.e. the value being assigned to timeleft) --- if that works for you too, it seems pretty harmless, so might be appropriate for wider adoption. I have already tried longer timeouts for timeleft and it does not help. Also with timeout circumvention the SATA flash card I was hoping to boot from (Transcend TS1GSDOM22V) is identified as follows: Bus 0: OK Bus 1: OK Device 0: Model: TRANSCEND Firm: 20080128 Ser#: 20080407 0005 Type: Hard Disk Capacity: 955.8 MB = 0.9 GB (1957536 x 512) IDE read: device 0 not ready IDE read: device 0 not ready Device 1: Model: Firm: Ser#: Type: Hard Disk Capacity: not available And then the card cannot be read. First attempt shows OK although the data written to memory are wrong, next attempts result in device 0 not ready. On the other hand, Linux (Debian ARM port) does not recognize the card either. So if this problem is not related to improper initialization, the question is how SATA flash differs from regular SATA drives with respect to SATA controller in 88F6281 and if it is actually possible to work with SATA flash on OpenRD. Can you #define DEBUG at the start of common/cmd_ide.c and rerun the test? Amicalement, -- Albert. That is what is printed with regular SATA drive: Marvell ide reset Reset IDE: MVSATA_STATUS_TIMEOUT ide_preinit failed Bus 0: ide_outb (dev= 0, port= 0x118, val= 0xe0) : @ 0xf1082118 ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x50 OK Bus 1: ide_outb (dev= 1, port= 0x118, val= 0xf0) : @ 0xf1082118 ide_inb (dev= 1, port= 0x11c) : @ 0xf108211c - 0x50 OK Device 0: ide_outb (dev= 0, port= 0x118, val= 0xe0) : @ 0xf1082118 ide_outb (dev= 0, port= 0x11c, val= 0xec) : @ 0xf108211c ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0xd0 ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x58 in input data base for read is f1082100 Model: TOSHIBA MK1637GSX Firm: DL030G Ser#: 97FXT4OUT Type: Hard Disk Supports 48-bit addressing Capacity: 152627.8 MB = 149.0 GB (312581808 x 512) ide_read dev 0 start 10010, blocks 1FFBAC64 buffer at 10 ide_outb (dev= 0, port= 0x118, val= 0xe0) : @ 0xf1082118 ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x50 ide_outb (dev= 0, port= 0x11c, val= 0xe5) : @ 0xf108211c ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x50 ide_inb (dev= 0, port= 0x108) : @ 0xf1082108 - 0xff Powersaving FF ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x50 ide_outb (dev= 0, port= 0x108, val= 0x01) : @ 0xf1082108 ide_outb (dev= 0, port= 0x10c, val= 0x10) : @ 0xf108210c ide_outb (dev= 0, port= 0x110, val= 0x00) : @ 0xf1082110 ide_outb (dev= 0, port= 0x114, val= 0x00) : @ 0xf1082114 ide_outb (dev= 0, port= 0x118, val= 0xe0) : @ 0xf1082118 ide_outb (dev= 0, port= 0x11c, val= 0x20) : @ 0xf108211c ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0xd0 ... ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0xd0 ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x58 in input data base for read is f1082100 ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x50 ide_read dev 0 start 1, blocks 1FE32A78 buffer at 0 ide_outb (dev= 0, port= 0x118, val= 0xe0) : @ 0xf1082118 ide_inb (dev= 0, port= 0x11c) : @ 0xf108211c - 0x50 ide_outb (dev= 0, port= 0x11c, val= 0xe5) : @ 0xf108211c ide_inb (dev=
Re: [U-Boot] at91rm9200 linking problem (?)
Dear Marcin Górski, please no TOFU, use inline quoting (and send also to the list). Am 20.06.2011 11:39, schrieb Marcin Górski: Hello, I already use CONFIG_SKIP_LOWLEVEL_INIT to prevent U-Boot from reinitilizing hardware. My board has 128MB RAM, so 0x2200 address is not a problem. Ok so far. Have you got any ideas why U-Boot cannot correctly detect RAM size (it shows DRAM: 1 MiB) and crashes after that? How do you setup your gd_t? Have you written a correct 'int dram_init()' in your board code (see board/atmel/at91rm9200ek/at91rm9200ek.c for example)? To compile it I also had to add 3 macros to the configuration file: CONFIG_SYS_INIT_RAM_ADDR, Why this? I guess you mean CONFIG_SYS_SDRAM_BASE here. CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_SP_ADDR. Can this cause this problem? SYS_INIT_SP_ADDR is required, if you see 'DRAM: ...' output it is likely to be a correct value for you. I guess your gd_t parameters for SDRAM size are not correct which leads to a wrong relocation address and therefore relocate_code() fails. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot
Hello Guys, I am very new to u boot and want to know more in detail about u boot including the software flow, drivers and adding a new board configuration to u boot. Please let me know how to start with this task and also provide me few documents if available. Thanks and Regards, Yash. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Not able access External peripherals in PPC440EP
Dear suresh kumar, In message BANLkTik0R4ho5d_9XK3iG1ywgJZB=qy...@mail.gmail.com you wrote: I am using a PPC 440EP processor based custom designed board which is based on AMCC's Yosemite as reference design. I have ported u-boot-1.1.6 onto it. It is working fine but not able to U-Boot 1.1.6 is more than 5 years old, i. e. it predates the stone age. We don;t support this any more. Please update to current code (v2011.06-rc2 or later). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's hard to make a program foolproof because fools are so ingenious. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot
Dear Yash Jain, In message BANLkTikSK11q6=t5eqxtlrjvirjxv42...@mail.gmail.com you wrote: I am very new to u boot and want to know more in detail about u boot including the software flow, drivers and adding a new board configuration to u boot. Please let me know how to start with this task and also provide me few documents if available. Start reading at the home page: http://www.denx.de/wiki/U-Boot Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The Gates in my computer are AND, OR and NOT; they are not Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-marvell.git
Hi Prafulla, Le 20/06/2011 07:16, Prafulla Wadaskar a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Saturday, June 18, 2011 11:16 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: Pull request u-boot-marvell.git (resent as this was not sent to the list, sorry Prafulla for the duplicate) Hi Prafulla, Le 16/06/2011 13:23, Prafulla Wadaskar a écrit : Hi Albert Please kindly pull The following changes since commit 7b2fac7654f7420c2787f74ec3b1540fa3b343e9: Aneesh V (1): omap730p2: fix build breaks are available in the git repository at: u-boot-marvell.git next branch. Are these meant for this release, i.e. should I pull that in u-boot-arm/master? If so, can you please rebase your master branch onto your next branch? Next is supposed to hold commits waiting for next merge window. Hi Albert By default they should go in next release that's why I put them in next branch Still not clear to me -- next release is 2011-06, but next merge window is for *after* 2011-06, and anyway, the U-Boot wiki clearly describes pull reqs as being done on master branches, not next. So: - if you want these commits in for 2011-06, then please move your master to have them in, and send a pull req for master, not next. - if you want them in after 2011-06, then simply wait for the merge window, then move them to your master and issue the pull request. Which is it? Sorry if I seem either convoluted or dense (or both). Regards.. Prafulla . . Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/master
Hi Reinhard, Le 20/06/2011 08:49, Reinhard Meyer a écrit : Dear Albert, The following changes since commit 0d8bc1c7b3caffd5626b6cf4888bfb5751f24041: Fabio Estevam (1): mx31pdk: Add DHCP command are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Eric Benard (4): arm926ejs/at91/lowlevel_init.S: fix defines cpu9260/9G20: fix board support cpuat91: fix board support include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme Jens Scharsig (1): update arm/at91rm9200 work with rework rework110202 Reinhard Meyer (3): AT91 rework: fix at91sam(9260/9g20/9xe)ek board port to build again: AT91 rework: fix TOP9000 files to build again ATMEL spi_dataflash driver - fix to build again Ryan Mallon (1): Add support for Bluewater Systems Snapper 9260/9G20 modules Sergey Lapin (1): Build fix/update of AFEB9260 andreas.de...@googlemail.com (2): at91_emac: fix compile warning macb: fix compile warning Applied, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH MX31:] smc911x MII made available
On 06/20/2011 08:10 AM, helmut.rai...@hale.at wrote: From: Helmut Raiger helmut.rai...@hale.at Hi Helmut, The driver already had the MII functions, but they have not been registered using miiphy_register(). Signed-off-by: Helmut Raiger helmut.rai...@hale.at Not noted before, thanks for fixing it. Only to remark the issue, on boards with SMC911x (at least the one I tested your patch) and CONFIG_CMD_MII set, a simple mii info returns Read MDIO failed.. You should always put in CC the maintainer for your patches. Because this patch is related to network, you should send your changes to Wolfgang Denk (Network Maintaner), too. I have already set his name in CC. +#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) +/* wrapper for smc911x_miiphy_read */ +static int _phy_read(char *devname, u8 phy, u8 reg, u16 *val) Is there some reason to use name starting with _ ? They have special meaning, and there is no need here. I have tested your patch on the mx35pdk board. Tested-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Nand: Uboot-Environment at bad block
In one of my devices, uboot-environment is located at a bad block. save Saving Environment to NAND... Erasing Nand... Skipping bad block at 0x000c Writing to Nand... FAILED! In my memory mapping I have already reseverd 2blocks. How can I setup uboot in a way, that it will look at c or (in case of bad block) at the next block e? In my configs file I found somewhat like: #define CONFIG_ENV_SIZE (128 10) /* 128 KiB */ #define SMNAND_ENV_OFFSET 0xC /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZEboot_flash_sec in mem.c of my processor I found: f_sec = (128 10);/* 128 KiB */ /* env setup */ boot_flash_base = base; boot_flash_off = f_off; boot_flash_sec = f_sec; uboot is based on 2010.03 release. Maybe someone can give me an advice? Thanks - Arno PS: Move the base address of environment is not an option, as in next device the bad block might be on exact this location. Environment itself is just 2kB, but a block is 128k. Can I decrease the environment to that size and still use access from linux (via fw_printenv)? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] da850evm: u-boot does not start without UBL since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c
Dear Christian Riesch, In message banlktimhjss_urkzb-q5y7gqzawswe0...@mail.gmail.com you wrote: What is AIS ? I apologize for using that many abbreviations in my mail and not explaining them :-/ AIS is short for Application Image Script [1]. It is a boot script that is processed by the ROM bootloader on Texas Instrument's AM1808/DA850/OMAP-L138 processors. The script allows configuration of boot modes, PLLs, DDR memory, Pinmuxes etc and loading the an application like u-boot from flash to RAM and executing it. Using a suitable AIS one can configure PLL and DDR memory and then directly start u-boot on these processors, without using Texas Instruments's user boot loader (UBL) [2]. In the default configuration of the da850evm the boot sequence is like this: 1) ROM bootloader (RBL): starts reading from flash 2) In the SPI-flash, a very simple AIS is present. This AIS tells the RBL to load the UBL from flash and to start it. 3) The UBL does a lot of hardware initialization and then loads u-boot from flash and starts it. 4) u-boot does a lot of hardware initialization that has already been done by the UBL and then loads the Linux kernel. For my application I would like to get rid of the UBL since most of the configuration it does is also done by u-boot (although there seems to be a bug in it) or can be done by AIS (like PLL and DDR memory configuration), the resulting boot sequence will be: 1) ROM bootloader (RBL): starts reading from flash 2) In the SPI-flash, an AIS is present. This AIS tells the RBL to configure PLLs and DDR memory and to load u-boot from flash and to start it. 3) u-boot loads the Linux kernel. Thanks for the explanations. You might want to synchronize your efforts with Heiko Schocher (on cc:) who might be working on similar things. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any time things appear to be going better, you have overlooked some- thing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/5] Add support for SMSC95XX USB 2.0 10/100MBit Ethernet Adapter
Dear Skacore Systems, In message BANLkTimcxaEJp3wwdbaeuA5acE=datv...@mail.gmail.com you wrote: I can't find this patch applied in the U-boot sources (or any of the forks). Is this functionality going to be merged into U-Boot ? Did I miss something ? Any answer would be greatly appreciated. v8 of these patches has been posted only 7 days ago, i. e. at a point of time in the release cycle where no new stuff gets added to the tree; they will have to wait for the next merge window. 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 Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PCIe Configuration on MPC8544 processor
Hi all, I am trying to activate a PCIe link between two MPC8544 processor's on a custom board. One processor is configured as Root Complex (cfg_host_agt[0:2] = '111') and the other processor as endpoint (cfg_host_agt[0:2] = '101'). Only PCIe1 is active in both processors (cfg_IO_ports[0:2] = '010') In u-boot I set the following flags in both processors: #define CONFIG_PCI/* Enable PCI/PCIE */ #define CONFIG_PCIE1/* PCIE controler 1 (slot 1) */ //MJ #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */ In the first processor (configured as RC) I get the following output: * pci_init_board: devdisr=708, io_sel=2, host_agent=7 PCIE1 connected to Slot2 as Root Complex (base address e000a000) PCIE link error. Skipping scan.LTSSM=0x00 PCIE1 on bus 00 - 00* In the second processor (configured as EP) I get the following output: * pci_init_board: devdisr=708, io_sel=2, host_agent=5 **PCIE1 connected to Slot2 as End Point (base address e000a000) Scanning PCI bus 00 PCI Scan: Found Bus 0, Device 1, Function 0 00 01 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 2, Function 0 00 02 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 3, Function 0 00 03 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 4, Function 0 00 04 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 5, Function 0 00 05 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 6, Function 0 00 06 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 7, Function 0 00 07 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 8, Function 0 00 08 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 9, Function 0 00 09 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 10, Function 0 00 0a 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 11, Function 0 00 0b 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 12, Function 0 00 0c 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 13, Function 0 00 0d 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 14, Function 0 00 0e 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 15, Function 0 00 0f 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 16, Function 0 00 10 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 17, Function 0 00 11 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 18, Function 0 00 12 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 19, Function 0 00 13 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 20, Function 0 00 14 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 21, Function 0 00 15 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 22, Function 0 00 16 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 23, Function 0 00 17 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 24, Function 0 00 18 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 25, Function 0 00 19 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 26, Function 0 00 1a 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 27, Function 0 00 1b 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 28, Function 0 00 1c 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 29, Function 0 00 1d 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 30, Function 0 00 1e 1957 0033 0b20 00 PCI Scan: Found Bus 0, Device 31, Function 0 00 1f 1957 0033 0b20 00 PCIE1 on bus 00 - 00* Each processor is detecting it's own PCIe interface but it is not detecting the other interface on the bus. From the output of the RC processor: PCIE link error. Skipping scan.LTSSM=0x00 from table Table 18-109, the controller doesn't detect any activity on the bus. I proceed trying to check in the HW for any activity in the PCIe bus. I don't see any activity in the bus from any of the processors. Both controller are getting the clock, and apart the PCIe detection both processor are working an proceed the booting stage. Is there any configuration missing in u-boot for the PCIe configuration? Does anyone has any clue/hint to aid in the debugging process of the PCIe interface either for the SW and HW side? Thanks in advance, Antonio ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: NAND init problems
Dear Sughosh, I guess this is the same as nand_spl. Do you use nand_boot.c in the spl code. This file has the nand_chip object declared as a local variable on the stack, and not bss. I first tried to use the standard NAND implementation - but I think you are right - using nand_spl implementation is much smaller. the auto recognition functions are nice but the trade-off in size is huge. I solved the problem - it was the .bss section not initialized to zero - thanks for the hint! Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Sun, 19 Jun 2011 15:52:29 +0530 V, Aneesh ane...@ti.com wrote: On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood scottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber: clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Still, what would go in those files? It'd have to be something more specific, like: LIBS-$(CONFIG_SYS_SPL_NAND_SIMPLE) += nand/nand_boot.o LIBS-$(CONFIG_SYS_SPL_NAND_FSL_ELBC) += nand/nand_boot_fsl_elbc.o ... Hmm, I guess you'd stick this in a recursive makefile. Seems like overkill. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). Couldn't there be only OBJS? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/master
Hi Wolfgang, Le 20/06/2011 15:44, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4dff3389.30...@aribaud.net you wrote: git://git.denx.de/u-boot-atmel.git master ... Applied, thanks! Thanks. Can you please send an ARM pull req ASAP, too, so we can get -rc3 out? I can do a pull request now, but if I did and if Prafulla actually wanted the marvell next branch to be pulled in ARM master for inclusion in 2011-06, I'll then have to issue yet another pull req after rc3. Would that be ok with you? Thanks a lot in advance. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
On Sat, 18 Jun 2011 15:49:36 +0200 Albert ARIBAUD albert.u.b...@aribaud.net wrote: 2) terse vs verbose. I like terse more, and yes, I concur with Wolfgang that as far as output verbosity is concerned, this should be done natively in make, not in makefiles -- but it might be easier said than done, because the 'terse' output may not be easily deduced from the build command in the make rule that causes it. Couldn't it simply print the name of the target buing built? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/4] Add Ethernet hardware MAC address framework to usbnet
Hi, 2011/6/14 Simon Glass s...@chromium.org: Built-in Ethernet adapters support setting the mac address by means of a ethaddr environment variable for each interface (ethaddr, eth1addr, eth2addr). This adds similar support to the USB network side, using the names usbethaddr, usbeth1addr, etc. They are kept separate since we don't want a USB device taking the MAC address of a built-in device or vice versa. Changes for v2: - eth_set_hwaddr - eth_write_hwaddr - tided up other users of eth_getenv_enetaddr_by_index() Changes for v5: - Changed NULL to eth in eth_getenv_enetaddr_by_index() API Signed-off-by: Simon Glass s...@chromium.org Tested-by: Eric Bénard e...@eukrea.com --- Applied to u-boot-usb AFTER cleaning up commit message (Change history of the patch should be below the '---' line) Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 1/4] Add support for SMSC95XX USB 2.0 10/100MBit Ethernet Adapter
Hi, 2011/6/14 Simon Glass s...@chromium.org: The SMSC95XX is a USB hub with a built-in Ethernet adapter. This adds support for this, using the USB host network framework. Changes for v2: - Coding style cleanup - Changed some comments as suggested Changes for v3: - Change turbo_mode to #define Changes for v4: - Dropped Tegra2 specific bit - Fixed a few broken bits in SMSC from my testing Changes for v5: - Code style clean-ups in SMSC - Cleaned up debugging of errors in SMSC driver Changes for v6: - Set NET_IP_ALIGN to 0 always Changes for v8: - Add setup of SMSC write_hwaddr function Signed-off-by: Simon Glass s...@chromium.org Tested-by: Eric Bénard e...@eukrea.com Applied to u-boot-usb AFTER cleaning up commit message. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 3/4] Add documentation for USB Host Networking
Hi, 2011/6/14 Simon Glass s...@chromium.org: This describes what it is for, devices supported, how to enable for your board in U-Boot, setting up the server, and notes about MAC addresses. Changes for v6: - Adjust documentation file according to Wolfgang's comments Signed-off-by: Simon Glass s...@chromium.org Tested-by: Eric Bénard e...@eukrea.com --- Applied to u-boot-usb AFTER cleaning up commit message (Change history of the patch should be below the '---' line) Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 4/4] Put common autoload code into auto_load() function
Hi, 2011/6/14 Simon Glass s...@chromium.org: This is a small clean-up patch. Changes for v8: - Fix typo in auto_load Signed-off-by: Simon Glass s...@chromium.org Tested-by: Eric Bénard e...@eukrea.com --- Applied to u-boot-usb AFTER cleaning up commit message (Change history of the patch should be below the '---' line) Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make it possible to build tools unconfigured
On Sat, 18 Jun 2011 15:03:09 -0400 Mike Frysinger vap...@gentoo.org wrote: considering LDSCRIPT/CONFIG_SYS_LDSCRIPT only get used by the top level u-boot file, and only when the system is configured, i wonder if we shouldnt just rip it out of config.mk and into the top level Makefile. let's see what Scott thinks ... Sounds fine. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/master
Dear Albert ARIBAUD, In message 4dff737a.4040...@aribaud.net you wrote: I can do a pull request now, but if I did and if Prafulla actually wanted the marvell next branch to be pulled in ARM master for inclusion in 2011-06, I'll then have to issue yet another pull req after rc3. Would that be ok with you? No. I understand MV next branch is not intended to go into this release. When -rc3 is out, we may create a next branch, where this can be pulled into. 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 Out of register space (ugh) - vi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
On Thu, Jun 16, 2011 at 18:03, Wolfgang Denk w...@denx.de wrote: I think it is fundamentally wrong to implement such a feature (let's call it terse make output) in the Makefiles of many projects, using a lot of trickery and magic. If a specific verbosity of make output is needed, this should most naturally be implemented as a feature in make itself - we already have make options like -d (for very verbose output) or -s (for silent mode), so why not add a new verbosity level which produces exactly the short output format you want? So yes, patches are welcome, but these should go directly to the make mailing lists / patch system, see http://savannah.gnu.org/mail/?group=make not to kick sand just for fun, but this is an example of you getting final veto power. this has been requested by many people, and ive seen very few people against it (off the top of my head, i can only recall you, but i havent looked at previous threads to be sure). i'm not saying your logic is without merit, just that in all practicality, i dont think it's going to happen the way you desire. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
On Mon, Jun 20, 2011 at 12:53 PM, Mike Frysinger vap...@gentoo.org wrote: On Thu, Jun 16, 2011 at 18:03, Wolfgang Denk w...@denx.de wrote: I think it is fundamentally wrong to implement such a feature (let's call it terse make output) in the Makefiles of many projects, using a lot of trickery and magic. If a specific verbosity of make output is needed, this should most naturally be implemented as a feature in make itself - we already have make options like -d (for very verbose output) or -s (for silent mode), so why not add a new verbosity level which produces exactly the short output format you want? So yes, patches are welcome, but these should go directly to the make mailing lists / patch system, see http://savannah.gnu.org/mail/?group=make not to kick sand just for fun, but this is an example of you getting final veto power. this has been requested by many people, and ive seen very few people against it (off the top of my head, i can only recall you, but i havent looked at previous threads to be sure). i'm not saying your logic is without merit, just that in all practicality, i dont think it's going to happen the way you desire. -mike Hi, Great to see the discussion here. My feeling is that the right approach is for the subdir Makefiles to be #included so that make can operate the way it was originally intended (full tree dependency). We don't have the kind of memory limitations that once made the size of its dependency table worth worrying about. The verbosity or not of make is mostly a side issue in my view since it is possible to have this approach and still print all the gcc commands lines. I don't personally find it useful 90% of the time, but that's personal preference. The one message that I think is superfluous is 'Entering directory... / Leaving directory ...'. Perhaps there is disagreement on this too? I think it is better to include the full path with each filename that is built. My IDE agrees :-) The change I am talking about does not affect make at all, and I can't think what manner of patches might get make to automatically build a picture from all subdirectories before starting its work. If I were the make maintainer I would almost certainly reject them. I would like to name this feature 'Full dependency make' instead of 'terse make output'. The terse-ness could be an option. Who was it that volunteered to modify the makefiles? :-) I was very encouraged by Mike's comment earlier: indeed. it shouldnt be that bad now that more stuff has converted to FOO-$(CONFIG) syntax. it could probably even be done piece by piece rather than the whole tree to make transition easier. Indeed it is not like the U-Boot subdir Makefiles are a mess - they are pretty tidy and describe the dependencies in a clean way that should be usable when included by a top-level Makefile. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/master
Hi Wolfgang, Le 20/06/2011 21:43, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4dff737a.4040...@aribaud.net you wrote: I can do a pull request now, but if I did and if Prafulla actually wanted the marvell next branch to be pulled in ARM master for inclusion in 2011-06, I'll then have to issue yet another pull req after rc3. Would that be ok with you? No. I understand MV next branch is not intended to go into this release. When -rc3 is out, we may create a next branch, where this can be pulled into. Wolfgang: I am not as convinced as you are about the MV next branch pull request not being intended for this release: the custodian wiki addresses pull requests for master branches only, and considers next branches only as temp storage for commits accepted outside a merge window. Next branches are supposed to be used only to rebase the master the same repo; there is no process, nor reason, reason to ask for a pull of a next branch. So if Prafulla asked for a pull, it may be that he actually wanted a pull into ARM master, somehow mentally squezing the 'rebase MV master onto MV next then ask for a pull of master' process. Prafulla: can you make it clear onto which branch of ARM, master or next, you intend MV next to be pulled? Please let me know before 7:30 GMT+2. Around 8:00 GMT+2 I'll issue a pull request for ARM/master, with or without MV next pulled in. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/master
Dear Albert ARIBAUD, In message 4dffb961.7070...@aribaud.net you wrote: No. I understand MV next branch is not intended to go into this release. When -rc3 is out, we may create a next branch, where this can be pulled into. Wolfgang: I am not as convinced as you are about the MV next branch pull request not being intended for this release: the custodian wiki Prafulla, can you please comment what your actual intentions were, i. e. wether Albert or me are interpreting your pull request correctly? addresses pull requests for master branches only, and considers next branches only as temp storage for commits accepted outside a merge window. ... Right, but that means (or is supposed to mean - sorry if this is not documented clear enough) that all custodians can do this as well, i. e. they can pull patches into their own next branches and send pull requests for the next branch. ... Next branches are supposed to be used only to rebase the master the same repo; there is no process, nor reason, reason to ask for a pull of a next branch. ... I disagree here. It makes perfecxt sense to keep the stack of open patches small, and a next branch is a good way to handle stuff that is waiting for the next merge window to open. The only issue with this is that I am not very strict with this process; theoretically we should (1) create -rc1 as soon as the merge window closes and all patches have checked in, and (2) create a next branch as soon as we have -rc1. My problems with this is that usually there is a lot of unprocesses stuff queued when the MW closes, so I wait with the -rc1 until at least most of this has gone in; additionally I wait with next until I feel the tree is reasonable stable - in the current release for example I'm waiting for all these ARM build fixes, i. e. especially the AT91 stuff. ... So if Prafulla asked for a pull, it may be that he actually wanted a pull into ARM master, somehow mentally squezing the 'rebase MV master onto MV next then ask for a pull of master' process. I don't think so. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious defi- ciencies. - Charles Anthony Richard Hoare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
Dear Simon Glass, In message BANLkTi=SJseedJ=vcwr2i+kasc8a_4eqatf69+y5skoqh2f...@mail.gmail.com you wrote: So yes, patches are welcome, but these should go directly to the make mailing lists / patch system, see http://savannah.gnu.org/mail/?group=make not to kick sand just for fun, but this is an example of you getting final veto power. this has been requested by many people, and ive seen very few people against it (off the top of my head, i can only recall you, but i havent looked at previous threads to be sure). i'm not saying your logic is without merit, just that in all practicality, i dont think it's going to happen the way you desire. Great to see the discussion here. My feeling is that the right approach is for the subdir Makefiles to be #included so that make can operate the way it was originally intended (full tree dependency). We don't have the kind of memory limitations that once made the size of its dependency table worth worrying about. Be casreful not to mix topics. Mike's message to which you reply here has actually asolutely nothing to do with nested or recursive Makefiles or such. He is referring to the other topic (terse make output) instead. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What's the sound a name makes when it's dropped? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
Dear Mike Frysinger, In message BANLkTim5nXA8fF=o24ghegl+xybtqlm...@mail.gmail.com you wrote: On Thu, Jun 16, 2011 at 18:03, Wolfgang Denk w...@denx.de wrote: I think it is fundamentally wrong to implement such a feature (let's call it terse make output) in the Makefiles of many projects, using a lot of trickery and magic. =A0If a specific verbosity of make output is needed, this should most naturally be implemented as a feature in make itself - we already have make options like -d (for very verbose output) or -s (for silent mode), so why not add a new verbosity level which produces exactly the short output format you want? So yes, patches are welcome, but these should go directly to the make mailing lists / patch system, see http://savannah.gnu.org/mail/?group=3Dmake not to kick sand just for fun, but this is an example of you getting final veto power. this has been requested by many people, and ive seen very few people against it (off the top of my head, i can only recall you, but i havent looked at previous threads to be sure). i'm not saying your logic is without merit, just that in all practicality, i dont think it's going to happen the way you desire. We should probably split this thread and adapt the Subject, as we are discussing two completely independend topics here: One is about Nested Makefiles (or recursive Makefiles), which the subject mentions. I have to admit that I don't have a clear opinion about this yet, so I lean back and wait what the results of this discussion might be. When we see any code we have probably a better base to discuss this. The other topic is actually terse make output, and here indeed I insist that the problem should be solved at the base, like I always insisted that GCC / libgcc issues should not be worked around again and again and in every software package that uses GCC but rather at the base of the problem, in GCC itself. Any other approach might just appear to need less efforts, but you have to multiply this with the number of projects that do the same, and the silly waste of efforts for multiple similar implementations. In total, a clean solution at the correct place is not only less effort, but the only mentally clean solution. At least that's my 0.02 insert your favorite unit of currency here. YMMV... 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 dog always bit deepest on the veterinary hand. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] tools/Makefile: fix errors during deps generation for envcrc
From: Mike Frysinger vap...@gentoo.org Dependencies for the envcrc objects should be generated only in the case we are going to build envcrc itself. Otherwise it's a waste of work and can lead to the (harmless but annoying) errors during dependency generation. Signed-off-by: Ilya Yanok ya...@emcraft.com --- tools/Makefile | 24 ++-- 1 files changed, 14 insertions(+), 10 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 623f908..97f83f8 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -48,17 +48,21 @@ CONFIG_NETCONSOLE = y CONFIG_SHA1_CHECK_UB_IMG = y endif +# Merge all the different vars for envcrc into one +ENVCRC-$(CONFIG_ENV_IS_EMBEDDED) = y +ENVCRC-$(CONFIG_ENV_IS_IN_DATAFLASH) = y +ENVCRC-$(CONFIG_ENV_IS_IN_EEPROM) = y +ENVCRC-$(CONFIG_ENV_IS_IN_FLASH) = y +ENVCRC-$(CONFIG_ENV_IS_IN_ONENAND) = y +ENVCRC-$(CONFIG_ENV_IS_IN_NAND) = y +ENVCRC-$(CONFIG_ENV_IS_IN_NVRAM) = y +ENVCRC-$(CONFIG_ENV_IS_IN_SPI_FLASH) = y +CONFIG_BUILD_ENVCRC ?= $(ENVCRC-y) + # Generated executable files BIN_FILES-$(CONFIG_LCD_LOGO) += bmp_logo$(SFX) BIN_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_EMBEDDED) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_DATAFLASH) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_EEPROM) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_FLASH) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_ONENAND) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_NAND) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_NVRAM) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_SPI_FLASH) += envcrc$(SFX) +BIN_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc$(SFX) BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX) BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX) BIN_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes$(SFX) @@ -67,7 +71,7 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) # Source files which exist outside the tools directory -EXT_OBJ_FILES-y += common/env_embedded.o +EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o EXT_OBJ_FILES-y += common/image.o EXT_OBJ_FILES-y += lib/crc32.o EXT_OBJ_FILES-y += lib/md5.o @@ -77,7 +81,7 @@ EXT_OBJ_FILES-y += lib/sha1.o OBJ_FILES-$(CONFIG_LCD_LOGO) += bmp_logo.o OBJ_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo.o NOPED_OBJ_FILES-y += default_image.o -OBJ_FILES-y += envcrc.o +OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o NOPED_OBJ_FILES-y += fit_image.o OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] config.mk: move LDSCRIPT processing to the top-level Makefile
LDSCRIPT is used only from the top-level Makefile and only when the system is configured so we can move LDSCRIPT and CONFIG_SYS_LDSCRIPT related logic into the top level Makefile and under configured condition to avoid errors when building tools from unconfigured tree. Signed-off-by: Ilya Yanok ya...@emcraft.com --- Makefile | 30 ++ config.mk | 30 -- 2 files changed, 30 insertions(+), 30 deletions(-) diff --git a/Makefile b/Makefile index dcf5d93..e73cfc7 100644 --- a/Makefile +++ b/Makefile @@ -163,6 +163,36 @@ endif # load other configuration include $(TOPDIR)/config.mk +# If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use +# that (or fail if absent). Otherwise, search for a linker script in a +# standard location. + +ifndef LDSCRIPT + #LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug + ifdef CONFIG_SYS_LDSCRIPT + # need to strip off double quotes + LDSCRIPT := $(subst ,,$(CONFIG_SYS_LDSCRIPT)) + endif +endif + +ifndef LDSCRIPT + ifeq ($(CONFIG_NAND_U_BOOT),y) + LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds + ifeq ($(wildcard $(LDSCRIPT)),) + LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds + endif + endif + ifeq ($(wildcard $(LDSCRIPT)),) + LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds + endif + ifeq ($(wildcard $(LDSCRIPT)),) + LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot.lds + endif + ifeq ($(wildcard $(LDSCRIPT)),) +$(error could not find linker script) + endif +endif + # # U-Boot objectsorder is important (i.e. start must be first) diff --git a/config.mk b/config.mk index 7ce554e..2eb7fa2 100644 --- a/config.mk +++ b/config.mk @@ -154,36 +154,6 @@ RELFLAGS= $(PLATFORM_RELFLAGS) DBGFLAGS= -g # -DDEBUG OPTFLAGS= -Os #-fomit-frame-pointer -# If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use -# that (or fail if absent). Otherwise, search for a linker script in a -# standard location. - -ifndef LDSCRIPT - #LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug - ifdef CONFIG_SYS_LDSCRIPT - # need to strip off double quotes - LDSCRIPT := $(subst ,,$(CONFIG_SYS_LDSCRIPT)) - endif -endif - -ifndef LDSCRIPT - ifeq ($(CONFIG_NAND_U_BOOT),y) - LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds - ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds - endif - endif - ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds - endif - ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot.lds - endif - ifeq ($(wildcard $(LDSCRIPT)),) -$(error could not find linker script) - endif -endif - OBJCFLAGS += --gap-fill=0xff gccincdir := $(shell $(CC) -print-file-name=include) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] Makefile: move $(VERSION_FILE) rule out of ifeq configured
mkimage relies on autogenerated version so we need to move
$(VERSION_FILE) rule out of ifeq and make tools rule depend on it to be
able to run 'make tools' from the unconfigured tree.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Makefile | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Makefile b/Makefile
index e73cfc7..f264c0c 100644
--- a/Makefile
+++ b/Makefile
@@ -140,7 +140,7 @@ SUBDIRS = tools \
examples/standalone \
examples/api
-.PHONY : $(SUBDIRS)
+.PHONY : $(SUBDIRS) $(VERSION_FILE)
ifeq ($(obj)include/config.mk,$(wildcard $(obj)include/config.mk))
@@ -293,7 +293,7 @@ LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
LIBS := $(addprefix $(obj),$(sort $(LIBS)))
-.PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE)
+.PHONY : $(LIBS) $(TIMESTAMP_FILE)
LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o
LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
@@ -452,19 +452,6 @@ mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
-$(VERSION_FILE):
- @( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
- printf '#define PLAIN_VERSION %s%s\n' \
- $(U_BOOT_VERSION) $${localvers} ; \
- printf '#define U_BOOT_VERSION U-Boot %s%s\n' \
- $(U_BOOT_VERSION) $${localvers} ; \
- ) $@.tmp
- @( printf '#define CC_VERSION_STRING %s\n' \
-'$(shell $(CC) --version | head -n 1)' ) $@.tmp
- @( printf '#define LD_VERSION_STRING %s\n' \
-'$(shell $(LD) -v | head -n 1)' ) $@.tmp
- @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@
-
$(TIMESTAMP_FILE):
@LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y' $@
@LC_ALL=C date +'#define U_BOOT_TIME %T' $@
@@ -539,20 +526,33 @@ $(obj)lib/asm-offsets.s: $(obj)include/autoconf.mk.dep \
else # !config.mk
all $(obj)u-boot.hex $(obj)u-boot.srec $(obj)u-boot.bin \
$(obj)u-boot.img $(obj)u-boot.dis $(obj)u-boot \
-$(filter-out tools,$(SUBDIRS)) $(TIMESTAMP_FILE) $(VERSION_FILE) \
+$(filter-out tools,$(SUBDIRS)) $(TIMESTAMP_FILE) \
updater depend dep tags ctags etags cscope $(obj)System.map:
@echo System not configured - see README 2
@ exit 1
-tools:
+tools: $(VERSION_FILE)
$(MAKE) -C $@ all
endif # config.mk
+$(VERSION_FILE):
+ @( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
+ printf '#define PLAIN_VERSION %s%s\n' \
+ $(U_BOOT_VERSION) $${localvers} ; \
+ printf '#define U_BOOT_VERSION U-Boot %s%s\n' \
+ $(U_BOOT_VERSION) $${localvers} ; \
+ ) $@.tmp
+ @( printf '#define CC_VERSION_STRING %s\n' \
+'$(shell $(CC) --version | head -n 1)' ) $@.tmp
+ @( printf '#define LD_VERSION_STRING %s\n' \
+'$(shell $(LD) -v | head -n 1)' ) $@.tmp
+ @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@
+
easylogo env gdb:
$(MAKE) -C tools/$@ all MTD_VERSION=${MTD_VERSION}
gdbtools: gdb
-tools-all: easylogo env gdb
+tools-all: easylogo env gdb $(VERSION_FILE)
$(MAKE) -C tools HOST_TOOLS_ALL=y
.PHONY : CHANGELOG
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] Add pxecfg command
Dear Wolfgang,
I've prepared a new series of patches that I believe adresses most of
your comments, but I have a few responses and a question before sending
the new patch series out.
On Mon, Jun 06, 2011 at 09:45:22PM +0200, Wolfgang Denk wrote:
Add pxecfg command, which is intended to mimic PXELINUX functionality.
'pxecfg get' uses tftp to retrieve a file based on UUID, MAC address or
IP address. 'pxecfg boot' interprets the contents of PXELINUX config
like file to boot using a specific initrd, kernel and kernel command
line.
This patch also adds a README.pxecfg file - see it for more details on
the pxecfg command.
Any reason for not calling this command simply pxe ?
PXE itself is a protocol made of some additional options in BOOTP
requests and responses, along with a bunch of specifics about what a
host platform is supposed to implement to run PXE images. This doesn't
provide PXE proper, it just mimics what PXELINUX does. PXELINUX isn't
PXE either - it just uses PXE to get its job done, by being retrieved
via the PXE protocol and using the PXE runtime environment to retrieve
files and continue booting. Since this isn't PXE and it isn't PXELINUX,
I made up 'pxecfg', and welcome other naming suggetions.
+ if (bootfile_path == NULL) {
+ printf(No bootfile path in environment.\n);
+ return -ENOENT;
+ }
+
+ path_len = strlen(bootfile_path) + strlen(file_path) + 1;
+
+ if (path_len MAX_TFTP_PATH_LEN) {
+ printf(Base path too long (%s/%s)\n,
+ bootfile_path, file_path);
+
+ free(bootfile_path);
+ return -ENAMETOOLONG;
+ }
+
+ sprintf(bootfile, %s/%s, bootfile_path, file_path);
+
+ free(bootfile_path);
+
+ printf(Retreiving file: %s\n, bootfile);
+
+ sprintf(addr_buf, %p, file_addr);
+
+ tftp_argv[1] = addr_buf;
+ tftp_argv[2] = bootfile;
This looks like an extremly complicated way for a plain TFTP
download. Why are you performing all this acrobatics and juggling
with bootfile, instead of simply using what the user provided?
The directory (if any) that bootfile exists in is to be used as the base
for relative paths given in PXELINUX files. pxecfg should follow the
same pattern, hence the acrobatics to modify what's given to us by the
user to prepend the base directory.
+ /*
+* We must dup the environment variable value here, because getenv
+* returns a pointer directly into the environment, and the contents
+* of the environment might shift during execution of a command.
+*/
+ dupcmd = strdup(localcmd);
What do you mean by the contents of the environment might shift ???
One scenario is a localcmd that assigns a new value to the localcmd
variable as part of its execution:
setenv(localcmd, setenv localcmd; iminfo 0x0);
localcmd = getenv(localcmd);
run_command2(localcmd, 0);
From a previous patch in the series, run_command2() calls either
run_command() or parse_string_outer() depending on whether or not hush
is enabled. Should the simple/hush command execution always be safe with
a command like this?
+ printf(running: %s\n, dupcmd);
This should probably be a debug() ?
I don't think so - it's the one place a user watching the screen would
get to see what is being executed, which might be very useful to end
users who aren't eager to recompile to get some verbosity.
Thanks,
Jason
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
On Mon, Jun 20, 2011 at 3:17 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message BANLkTi=SJseedJ=vcwr2i+kasc8a_4eqatf69+y5skoqh2f...@mail.gmail.com you wrote: So yes, patches are welcome, but these should go directly to the make mailing lists / patch system, see http://savannah.gnu.org/mail/?group=make not to kick sand just for fun, but this is an example of you getting final veto power. this has been requested by many people, and ive seen very few people against it (off the top of my head, i can only recall you, but i havent looked at previous threads to be sure). i'm not saying your logic is without merit, just that in all practicality, i dont think it's going to happen the way you desire. Great to see the discussion here. My feeling is that the right approach is for the subdir Makefiles to be #included so that make can operate the way it was originally intended (full tree dependency). We don't have the kind of memory limitations that once made the size of its dependency table worth worrying about. Be casreful not to mix topics. Mike's message to which you reply here has actually asolutely nothing to do with nested or recursive Makefiles or such. He is referring to the other topic (terse make output) instead. Hi Wolfgang, OK sorry. It was the nested/recursive makefiles with which I started this thread. I think it might have been misunderstood as a question about terse make but it wasn't. Regards, Simon Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What's the sound a name makes when it's dropped? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config.mk: move LDSCRIPT processing to the top-level Makefile
Acked-by: Mike Frysinger vap...@gentoo.org -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/3] Makefile: move $(VERSION_FILE) rule out of ifeq configured
Acked-by: Mike Frysinger vap...@gentoo.org -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 3/3] tools/Makefile: fix errors during deps generation for envcrc
Signed-off-by: Mike Frysinger vap...@gentoo.org -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] Nested Makefiles
On Monday, June 20, 2011 16:30:15 Simon Glass wrote: On Mon, Jun 20, 2011 at 12:53 PM, Mike Frysinger wrote: indeed. it shouldnt be that bad now that more stuff has converted to FOO-$(CONFIG) syntax. it could probably even be done piece by piece rather than the whole tree to make transition easier. Indeed it is not like the U-Boot subdir Makefiles are a mess - they are pretty tidy and describe the dependencies in a clean way that should be usable when included by a top-level Makefile. at one point i wrote a generic board/board.mk that board/*/Makefile could inherit. then all board/*/Makefile would need is to declare COBJS-y. i'm not sure if that's a useful step, or if we just pick a single dir like common and make it work by a direct include of the top level Makefile. once we get those issues hashed out, we can move on to others one by one. -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] SPL framework re-design
On Monday 20 June 2011 09:49 PM, Scott Wood wrote: On Sun, 19 Jun 2011 15:52:29 +0530 V, Aneeshane...@ti.com wrote: On Sat, Jun 18, 2011 at 3:58 AM, Scott Woodscottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh Vane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber:clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Still, what would go in those files? That's actually one rule per sub-directory in the directory structure. What goes in there can be decided by the respective Makefile in the sub-directory. It can have more fine-grained selection like what you have mentioned below. It'd have to be something more specific, like: LIBS-$(CONFIG_SYS_SPL_NAND_SIMPLE) += nand/nand_boot.o LIBS-$(CONFIG_SYS_SPL_NAND_FSL_ELBC) += nand/nand_boot_fsl_elbc.o ... Hmm, I guess you'd stick this in a recursive makefile. Seems like overkill. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). Couldn't there be only OBJS? It looks to me at the moment that the root directory for SPL, 'spl/', need not have any source files. We will have an spl/common directory for such needs(I forgot to add this in the list of libraries) If this framework looks reasonable I shall go ahead an convert the OMAP4 spl to this framework, so that we can thrash out some more details. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
http://tjtintas.com.br/google.php___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] da850evm: u-boot does not start without UBL since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c
Hello Wolfgang, On Monday, June 20, 2011, Wolfgang Denk w...@denx.de wrote: You might want to synchronize your efforts with Heiko Schocher (on cc:) who might be working on similar things. Thanks! I put Heiko on cc in my first email in this thread, but then forgot it later. Sorry about that, Heiko, I am looking forward to your comments. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/22] omap4: add clock support
Dear Wolfgang,
On Sunday 15 May 2011 08:51 PM, Aneesh V wrote:
[snip ..]
+static const u32 clk_modules_hw_auto_essential[] = {
+ CM_WKUP_GPIO1_CLKCTRL,
+ CM_L4PER_GPIO2_CLKCTRL,
+ CM_L4PER_GPIO3_CLKCTRL,
+ CM_L4PER_GPIO4_CLKCTRL,
+ CM_L4PER_GPIO5_CLKCTRL,
+ CM_L4PER_GPIO6_CLKCTRL,
+ CM_MEMIF_EMIF_1_CLKCTRL,
+ CM_MEMIF_EMIF_2_CLKCTRL,
+ CM_L3INIT_HSUSBOTG_CLKCTRL,
+ CM_L3INIT_USBPHY_CLKCTRL,
+ CM_L4CFG_L4_CFG_CLKCTRL,
+ 0
+};
In this series you asked me to convert the base + offset mode of
register address definition to struct based register address
definition. While doing this I am facing a problem. Please note the
above array that contain register addresses. This is a group of
registers that control our clock modules. All these registers have
similar bit fields and they can be programmed in same manner. So, I
keep them in an array and pass the array to a function that iterates
through array and does similar processing on all the registers(see
below).
I am finding it difficult to implement this using the struct based
approach. I tried the sample code below:
struct my_regs_struct {
const unsigned int reg1;
const unsigned int reg2;
const unsigned int reg3;
};
static struct my_regs_struct *const my_regs = (struct my_regs_struct
*)0x1000;
static unsigned int *const reg_arr[] = {
my_regs-reg1,
my_regs-reg3
};
void main(void)
{
printf(regs %x %x \n, reg_arr[0], reg_arr[1]);
}
I am getting the following errors on compiling this:
main.c:10: error: initializer element is not constant
main.c:10: error: (near initialization for ‘reg_arr[0]’)
main.c:12: error: initializer element is not constant
main.c:12: error: (near initialization for ‘reg_arr[1]’)
I can't make it work unless I make my_regs a statically defined
structure itself and not a pointer - like this:
static struct my_regs_struct my_regs;
This seems quite strange(behavior is the same with gcc and Microsoft
compiler). Am I missing something?
Any ideas to make it work? If not, can I go back to defines for the
addresses. All the registers we have are 32 bit long and we always use
u32 for them and use readl/writel for accessor functions. Using the
wrong accessor function is highly unlikely.
[snip ...]
+ /* Clock modules that need to be put in HW_AUTO */
+ for (i = 0; (i max) clock_modules_hw_auto[i]; i++) {
+ enable_clock_module(clock_modules_hw_auto[i],
+ MODULE_CLKCTRL_MODULEMODE_HW_AUTO,
+ wait_for_enable);
+ };
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
