- 22 May, 2012 4 commits
-
-
Joe Hershberger authored
Fix this: ether_fcc.c: In function 'fec_initialize': ether_fcc.c:453:15: warning: assignment from incompatible pointer type Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com>
-
Joe Hershberger authored
Fix this: ether_fcc.c: In function 'fec_initialize': ether_fcc.c:390:15: warning: assignment from incompatible pointer type Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com>
-
Joe Hershberger authored
Fix this: fec.c: In function 'mpc8220_fec_recv': fec.c:791:9: warning: passing argument 1 of 'NetReceive' discards qualifiers from pointer target type include/net.h:438:13: note: expected 'uchar *' but argument is of type 'volatile uchar *' fec.c: In function 'mpc8220_fec_initialize': fec.c:839:12: warning: assignment from incompatible pointer type Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com>
-
Wolfgang Denk authored
Commit db288a96 "net: Remove volatile from net API" caused a number of build warnings: fec.c: In function 'fec_initialize': fec.c:183:13: warning: assignment from incompatible pointer type [enabled by default] fec.c: In function 'fec_recv': fec.c:284:5: warning: passing argument 1 of 'NetReceive' discards 'volatile' qualifier from pointer target type [enabled by default] /home/wd/git/u-boot/work/include/net.h:433:13: note: expected 'uchar *' but argument is of type 'volatile uchar *' scc.c: In function 'scc_initialize': scc.c:85:14: warning: assignment from incompatible pointer type [enabled by default] Fix these. Signed-off-by:
Wolfgang Denk <wd@denx.de> Cc: Joe Hershberger <joe.hershberger@ni.com>
-
- 18 May, 2012 1 commit
-
-
Scott Wood authored
GOT is now handled the way the main u-boot.lds does it. Without this, the boot hangs when built with newer GCC (since 4.6). Older toolchains hid the issue by converting -fpic to -fPIC. Signed-off-by:
Scott Wood <scottwood@freescale.com>
-
- 15 May, 2012 2 commits
-
-
Mike Frysinger authored
All arches init this the same way, so move the logic into the core net code to avoid duplicating it everywhere else. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Reviewed-by:
Joe Hershberger <joe.hershberger@ni.com>
-
Mike Frysinger authored
This field gets read in one place (by "bdinfo"), and we can replace that with getenv("ipaddr"). After all, the bi_ip_addr field is kept up-to-date implicitly with the value of the ipaddr env var. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Reviewed-by:
Joe Hershberger <joe.hershberger@ni.com>
-
- 25 Apr, 2012 10 commits
-
-
Timur Tabi authored
The CCSR relocation code in start.S writes to MAS7 on all e500 parts, but that register does not exist on e500v1. Signed-off-by:
Timur Tabi <timur@freescale.com>
-
Liu Gang authored
When boot from SRIO, slave's core can be in holdoff after powered on for some specific requirements. Master can release the slave's core at the right time by SRIO interface. Master needs to: 1. Set outbound SRIO windows in order to configure slave's registers for the core's releasing. 2. Check the SRIO port status when release slave core, if no errors, will implement the process of the slave core's releasing. Slave needs to: 1. Set all the cores in holdoff by RCW. 2. Be powered on before master's boot. Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com>
-
Liu Gang authored
When boot from SRIO, slave's ENV can be stored in master's memory space, then slave can fetch the ENV through SRIO interface. NOTE: Because the slave can not erase, write master's NOR flash by SRIO interface, so it can not modify the ENV parameters stored in master's NOR flash using "saveenv" or other commands. Master needs to: 1. Put the slave's ENV into it's own memory space. 2. Set an inbound SRIO window covered slave's ENV stored in master's memory space. Slave needs to: 1. Set a specific TLB entry in order to fetch ucode and ENV from master. 2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV. Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com>
-
Liu Gang authored
When boot from SRIO, slave's ucode can be stored in master's memory space, then slave can fetch the ucode image through SRIO interface. For the corenet platform, ucode is for Fman. Master needs to: 1. Put the slave's ucode image into it's own memory space. 2. Set an inbound SRIO window covered slave's ucode stored in master's memory space. Slave needs to: 1. Set a specific TLB entry in order to fetch ucode from master. 2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode. Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com>
-
Liu Gang authored
For the powerpc processors with SRIO interface, boot location can be configured from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash for u-boot image. The image can be fetched from another processor's memory space by SRIO link connected between them. The processor boots from SRIO is slave, the processor boots from normal flash memory space and can help slave to boot from its memory space is master. They are different environments and requirements: master: 1. NOR flash for its own u-boot image, ucode and ENV space. 2. Slave's u-boot image in master NOR flash. 3. Normally boot from local NOR flash. 4. Configure SRIO switch system if needed. slave: 1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV. 2. Boot location should be set to SRIO1 or SRIO2 by RCW. 3. RCW should configure the SerDes, SRIO interfaces correctly. 4. Slave must be powered on after master's boot. For the master module, need to finish these processes: 1. Initialize the SRIO port and address space. 2. Set inbound SRIO windows covered slave's u-boot image stored in master's NOR flash. 3. Master's u-boot image should be generated specifically by make xxxx_SRIOBOOT_MASTER_config 4. Master must boot first, and then slave can be powered on. Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com>
-
Liu Gang authored
Rewrite this struct for the support of two ports and two message units registers. Signed-off-by:
Liu Gang <Gang.Liu@freescale.com>
-
Prabhakar Kushwaha authored
Currently "u-boot", the elf file generated via u-boot-nand.lds does not contain required debug information i.e. .debug_{line, info, abbrev, aranges, ranges} into their respective _global_ sections. The original ld script line arch/powerpc/cpu/mpc85xx/start.o KEEP(*(.bootpg)) is not entirely correct because the start.o file is already processed by the linker,therefore the file wildcard in "KEEP(*(.bootpg))" will not process start.o again for bootpg. So Fix u-boot-nand.lds to generate these debug information. Signed-off-by:
Anmol Paralkar <b07584@freescale.com> Signed-off-by:
John Russo <John.Russo@freescale.com> Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
Andy Fleming <afleming@freescale.com>
-
Prabhakar Kushwaha authored
NAND SPL code never compile the vector table. So no need to setup interrupt vector table for NAND SPL. Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
Andy Fleming <afleming@freescale.com>
-
Prabhakar Kushwaha authored
After relocation of vector table in SDRAM's lower address, IVORs value should be updated with new handler addresses. As vector tables are relocated to 0x100,0x200... 0xf00 address in DDR.IVORs are updated with 0x100, 0x200,....f00 hard-coded values. Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
Andy Fleming <afleming@freescale.com>
-
Prabhakar Kushwaha authored
For e500 and e500v2 architecturees processor IVPR address should be alinged on 64K boundary. in start.S, CONFIG_SYS_MONITOR_BASE is stored blindly in IVPR assuming it to be 64K aligned. It may not be true always. If it is not aligned, IVPR + IVORs may not point to an exception handler. Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
Andy Fleming <afleming@freescale.com>
-
- 18 Mar, 2012 5 commits
-
-
Mike Frysinger authored
Common code has a mdelay() func, so use that instead of the usb-specific wait_ms() func. This also fixes the build errors: ohci-hcd.c: In function 'submit_common_msg': /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available ohci-hcd.c:1519:9: sorry, unimplemented: called from here /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available ohci-hcd.c:1816:10: sorry, unimplemented: called from here /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available ohci-hcd.c:1827:10: sorry, unimplemented: called from here /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available ohci-hcd.c:1844:10: sorry, unimplemented: called from here /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available ohci-hcd.c:1563:11: sorry, unimplemented: called from here /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available ohci-hcd.c:1583:9: sorry, unimplemented: called from here make[1]: *** [ohci-hcd.o] Error 1 Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Acked-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
These calls should not be made directly any more, since bootstage will call the show_boot_...() functions as needed. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Rather than the caller negating our progress numbers to indicate an error has occurred, which seems hacky, add a function to indicate this. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Mike Frysinger <vapier@gentoo.org>
-
Simon Glass authored
This changes the number 15 as used in boot_stage_progress() to use the new name provided for it. This is a separate patch because it touches so many files. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Mike Frysinger <vapier@gentoo.org>
-
- 03 Mar, 2012 1 commit
-
-
Simon Glass authored
This seems to be unsigned char for no good reason. Tidy this up and remove the casts. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Mike Frysinger <vapier@gentoo.org>
-
- 15 Feb, 2012 2 commits
-
-
ramneek mehresh authored
Add support for fixing usb mode and phy type for MPH(Multi Port Host) USB controllers in device-tree nodes. Required for socs like P3060, P5020, etc having MPH USB controller Signed-off-by:
Ramneek Mehresh <ramneek.mehresh@freescale.com>
-
ramneek mehresh authored
Some code cleanup done for USB device-tree fixup: - handling error value returned from fdt_fixup_usb_mode_phy_type() - using ARRAY_SIZE macro - using snprintf instead of sprintf Signed-off-by:
Ramneek Mehresh <ramneek.mehresh@freescale.com>
-
- 13 Jan, 2012 1 commit
-
-
Paul Gortmaker authored
It can be handy to have these in the output when trying to debug odd behaviour. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
- 10 Jan, 2012 1 commit
-
-
Joe Hershberger authored
Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com> Cc: Joe Hershberger <joe.hershberger@gmail.com> Signed-off-by:
Kim Phillips <kim.phillips@freescale.com>
-
- 13 Dec, 2011 1 commit
-
-
Jerry Huang authored
In the current u-boot code, the value of these fields are the reserved value (0b100), through the signal integrity measurement on freescale's board with these reserved setting, the signal eye is out of the recommended spec for non-transition amplitude at 500mV nominal. According to the errata for MPC8379E, we should make a change to the recommended setting from essentially nothing at this time to 0b001 for SATA. Signed-off-by:
Jerry Huang <Chang-Ming.Huang@freescale.com> Signed-off-by:
Kim Phillips <kim.phillips@freescale.com>
-
- 12 Dec, 2011 1 commit
-
-
Kumar Gala authored
We already flush the kernel image after we've loaded it to ensure visiblity to the other cores. We need to do the same thing for the ramdisk and device tree images. In AMP boot scenarios we might not be HW cache coherent with the secondary core that we are loading and setting the ramdisk and device tree up for. Thus we need to ensure we've flushed the regions of memory utilized by ramdisk and device tree so the loadding and any modifications (from decompression or fdt updates) are made visible to the secondary cores. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
- 07 Dec, 2011 2 commits
-
-
Kyle Moffett authored
Standard Debian powerpc and powerpcspe systems only include hard-float libgcc in their native compilers, which causes scary build warnings when building U-Boot. Debian and other PowerPC-supporting distributions used to provide libgcc and other libraries in a "nof" (soft-float) form in the "multilib" packages. As they were completely unused by the distribution and therefore tended to be very buggy it was decided to save some time on the part of the maintainers and build-servers by removing them. Admittedly, right now the linker warnings do not indicate any problems, as the included routines do not use any floating point at all. The concern is that if floating-point code were ever added it might cause hard-float code to be unexpectedly included in U-Boot without generating a hard error. This would cause unexplained crashes or indeterminate results at runtime. The easiest way to resolve this is to borrow the routines that U-Boot needs from the Linux kernel, which has the same issue. Specifically, the routines are: _ashldi3(), _ashrdi3(), and _lshrdi3(). They were borrowed from arch/powerpc/kernel/misc_32.S as of v2.6.38-rc5, commit 85e2efbb1db9a18d218006706d6e4fbeb0216213, and are GPLv2+. The Makefile framework was copied from the U-Boot ARM port. Signed-off-by:
Kyle Moffett <Kyle.D.Moffett@boeing.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Kim Phillips <kim.phillips@freescale.com> Cc: Andy Fleming <afleming@gmail.com> Cc: Kumar Gala <kumar.gala@freescale.com> Cc: Stefan Roese <sr@denx.de>
-
Stefan Roese authored
As this "driver" doesn't seem to be really used, let's remove it completely. Signed-off-by:
Stefan Roese <sr@denx.de>
-
- 01 Dec, 2011 1 commit
-
-
Wolfgang Denk authored
Fix: cpu.c: In function 'checkcpu': cpu.c:51:7: warning: variable 'ver' set but not used [-Wunused-but-set-variable] Signed-off-by:
Wolfgang Denk <wd@denx.de> Cc: Kumar Gala <galak@kernel.crashing.org> Acked-by:
Kumar Gala <galak@kernel.crashing.org>
-
- 29 Nov, 2011 8 commits
-
-
Ira W. Snyder authored
This adds support for the Freescale COM Express P2020 board. This board is similar to the P1_P2_RDB, but has some extra (as well as missing) peripherals. Unlike all other mpc85xx boards, it uses a watchdog timeout to reset. Using the HRESET_REQ register does not work. This board has no NOR flash, and can only be booted via SD or SPI. This procedure is documented in Freescale Document Number AN3659 "Booting from On-Chip ROM (eSDHC or eSPI)." Some alternative documentation is provided in Freescale Document Number P2020RM "P2020 QorIQ Integrated Processor Reference Manual" (section 4.5). Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
Fix: interactive.c: In function 'fsl_ddr_interactive': interactive.c:1357:15: warning: variable 'len' set but not used [-Wunused-but-set-variable] Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Ira W. Snyder authored
This is useful for boards which cannot be reset in the usual way for the 85xx CPU. An example is a board which can only be reset by a hardware watchdog. Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Timur Tabi authored
The localbus controller node in the device tree is typically a root node, even though the controller is part of CCSR. If we were to put the lbc node under the SOC node, then the 'ranges' property in the lbc node would translate through the 'ranges' property of the parent SOC node, and we don't want that. Since the lbc is a separate node, it's possible for the 'reg' property to be wrong. This happened with the original version of p1022ds.dts, which used a 32-bit value in the 'reg' address, instead of a 36-bit address. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Ira W. Snyder authored
Newer JEDEC DDR3 SPD Specifications define several additional values for the DDR3 module_type field which were undefined when this code was written. Update the code to handle the newer module types. Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Cc: York Sun <yorksun@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Timur Tabi authored
Several macros are used to identify and locate the microcode binary image that U-boot needs to upload to the QE or Fman. Both the QE and the Fman use the QE Firmware binary format to package their respective microcode data, which is why the same macros are used for both. A given SOC will only have a QE or an Fman, so this is safe. Unfortunately, the current macro definition and usage has inconsistencies. For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address of NAND. There's no way to know by looking at a variable how it's supposed to be used. In the future, the code which uploads QE firmware and Fman firmware will be merged. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Timur Tabi authored
On the P1022/P1013, the work-around for erratum SATA_A001 was implemented only if U-Boot initializes SATA, but SATA is not initialized by default. So move the work-around to the CPU initialization function, so that it's always executed on the SOCs that need it. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Timur Tabi authored
Macro CONFIG_FSL_SATA_V2 is defined if the SOC has a V2 Freescale SATA controller, so it should be defined in config_mpc85xx.h instead of the various board header files. So now CONFIG_FSL_SATA_V2 is always defined on the P1013, P1022, P2041, P3041, P5010, and P5020. It was already defined for the P1010 and P1014. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-