- Apr 30, 2011
-
-
While looking to upgrade to zlib-1.2.5, the current mondo merge of multiple files into a single was making things way more difficult than it should have been. Hard to pick out what has been changed to port it to U-Boot, been removed as useless, and bug fixes added after the fact. So split the single file up into the original file names, and merge non-essential changes back from the original tree (for some reason, style in code in a bunch of places was changed to U-Boot style even though this isn't "U-Boot" code). The original build style is retained -- we have a single zlib.c that includes all the other files, and that is the only file we compile. Signed-off-by:Mike Frysinger <vapier@gentoo.org>
-
- Apr 29, 2011
-
-
Signed-off-by:Luca Ceresoli <luca.ceresoli@comelit.it>
-
Currently, some linker scripts are found by common code in config.mk. Some are found using CONFIG_SYS_LDSCRIPT, but the code for that is sometimes in arch config.mk and sometimes in board config.mk. Some are found using an arch-specific rule for looking in CPUDIR, etc. Further, the powerpc config.mk rule relied on CONFIG_NAND_SPL when it really wanted CONFIG_NAND_U_BOOT -- which covered up the fact that not all NAND_U_BOOT builds actually wanted CPUDIR/u-boot-nand.lds. Replace all of this -- except for a handful of boards that are actually selecting a linker script in a unique way -- with centralized ldscript finding. If board code specifies LDSCRIPT, that will be used. Otherwise, if CONFIG_SYS_LDSCRIPT is specified, that will be used. If neither of these are specified, then the central config.mk will check for the existence of the following, in order: $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds (only if CONFIG_NAND_U_BOOT) $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds (only if CONFIG_NAND_U_BOOT) $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds $(TOPDIR)/$(CPUDIR)/u-boot.lds Some boards (sc3, cm5200, munices) provided their own u-boot.lds that were dead code, because they were overridden by a CPUDIR u-boot.lds under the old powerpc rules. These boards' own u-boot.lds have bitrotted and no longer work -- these lds files have been removed. Signed-off-by:
Scott Wood <scottwood@freescale.com> Tested-by:
Graeme Russ <graeme.russ@gmail.com>
-
Signed-off-by:Holger Brunck <holger.brunck@keymile.com> cc: Wolfgang Denk <wd@denx.de> cc: Valentin Longchamp <valentin.longchamp@keymile.com> cc: Heiko Schocher <hs@denx.de>
-
In order to support boardId / hwkey lists, the u-boot default environment has been updated: Added a script checkboardidlist which checks the list of boardId / hwkey if the boadrId / hwkey of the IVM is included in that list. This feature is used if you got different HW variants but you only want to create one boot package. E.g. supx5 board series. Signed-off-by:
Thomas Herzmann <thomas.herzmann@keymile.com> Signed-off-by:
-
Add: - introduce "bootrunner" environment variable This allows to execute consecutive different commands specified in the list "subbootcmd". If one command fails the command serie will stop. - introduce environment variable "develop", "ramfs" and "release" Each variable is one way to boot our linux. "develop" is for development purpose and boots the SW via NFS. "release" is for booting the linux image from flash, "ramfs" allows to load an SW image via tftp into ram and executes from there - introduce "addmem" variable, this command adds the used memory for linux to the bootargs - introduce "addvar" variable, this command adress for the /var directory to the kernel command line - introduce "setramfspram" and "setrootfsaddr" these calculation were done if "ramfs" was used (only for debugging) - introduce "tftpramfs" used for "ramfs" to load the image into RAM (only for debugging) Remove unneeded stuff: - CONFIG_IO_MUXING is obsolete for keymile boards - CONFIG_KM_DEF_ENV_PRIVATE is also obsolete - define CONFIG_SYS_TEXT_BASE in board configs only Signed-off-by: -
This patch adds last_stage_init to all keymile boards. And in the last stage init some environment variables for u-boot were set. Currently these are pnvramaddr, pram and var address. Signed-off-by:
Heiko Schocher <hs@denx.de> Acked-by:
Kim Phillips <kim.phillips@freescale.com> cc: Valentin Longchamp <valentin.longchamp@keymile.com> cc: Wolfgang Denk <wd@denx.de> cc: Kim Phillips <kim.phillips@freescale.com>
-
Normaly the PIGGY_MAC_ADRESS can be read directly from the IVM on keymile boards. On mgcoge3 it differs. Because there are two piggy boards deployed the second MAC adress must be calculated with the IVM mac adress and an offset. This patch allows to set such a offset in the board config. Signed-off-by: -
define KM_IVM_BUS and KM_ENV_BUS macros KM_IVM_BUS is used to define the EEprom_ivm environment variable. These macros allow the reuse of these I2C addresses in other code locations. remove unneeded code On first HW versions the BOCO FPGA was behind a MUX device. These HW versions are not supported anymore. And therefore this code can be removed. added LED initialization for SUEN3 The bootstat LED required to be initialized so to have a green colour after start-up. define CONFIG_SYS_TEXT_BASE This is needed by the relocation code and is not the same for our ARM BEC and thus needs to be defined. remove memsize variable An environment variable for memsize is not needed. this can be get via the board info struct. remove unneeded double access to bi_dram[i].size field Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by:
Luca Haab <luca.haab@keymile.com> Signed-off-by:
-
This patch fix the i2c deblocking facility with the i2c HW-Controller. The required delays for byte reading, the enhanced criteria for stop the dummy read and required 5 start/stop sequences are added. Add i2c deblocking before ivm eeprom read. Improve i2c deblocking sequence by respecting stop hold time. Cleaned function for deblocking. Have now one function i2c_make_abort() available for bitbang, mpc82xx and mpc83xx harware controller. Signed-off-by:
Stefan Bigler <stefan.bigler@keymile.com> Signed-off-by:
-
For the kmsupx5 a new header file was introduced km8321-common.h. Now the common stuff from tuxa1, tuda1 and suvd3 was removed and the new header file included. The defines CONFIG_SYS_PIGGY_BASE and CONFIG_SYS_PIGGY_SIZE are confusing. Because they actually describe the KMBEC FPGA values. The KMBEC FPGA can be PRIO on kmeter1 or upio on mgcoge. Therefore all the defines were renamed. remove unneeded variable CONFIG_KM_DEF_NETDEV, as it is already declared in keymile-common.h Signed-off-by:
-
These new values are: - enables UART0 and UART1 pins in MPP - define some L2 cache settings - changes a SDRAM timing to better fit the hardware - removed three writes that were the same as the reset values Signed-off-by:
-
This patch renames the suen3 defines and functions to KM_KIRKWOOD which is more generic and more precise, because these values and functions where used by all suenX boards and not only suen3. Signed-off-by:
Lukas Roggli <lukas.roggli@keymile.com> Signed-off-by:
-
The Keymile SUPx5 board series is based on a PBEC8321 but contains an additional PBUS FPGA (LPXF) on local bus CS2. Signed-off-by:
Thomas Reufer <thomas.reufer@keymile.com> Signed-off-by:
-
First step for a cleanup of all header files for km8321 boards. Signed-off-by:
-
The mgcoge2 board from keymile deploys two different processors. An ARM based Kirkwood for the "unit" part of the SW and a PPC for the "ne" part of the SW. Therefore in Linux and U-Boot the names for the board are mgcoge2un and mgcoge2ne. This patch adds the mgcoge2ne part of the board. The ppc part of mgboge2 is quite similar to mgcoge, therefore a generic header km82xx-common.h was introduced to collect all similiarities. Currently the only difference is that mgcoge2ne has a 64 MB numonyx NOR flash with a single die. The mgcoge has a dual die flash 2*32MB from spansion. Signed-off-by:
-
The Kirwood based SUEN8 board from Keymile is at this stage the same than the suen3 board. This patch adds the board support for the suen8. Signed-off-by:
-
This board is similar to keymile suen3. Signed-off-by:
Clive Stubbings <clive.stubbings@xentech.co.uk> Signed-off-by:
-
This board is similar to suvd3 board. So most initialisation topics are taken from suvd3 (UART1, Ethernet, piggy PHY, flash, ram) only the application specific chip selects differ. Signed-off-by:
-
This board is similar to suvd3 board. So most initialisation topics are taken from suvd3 (UART1, Ethernet, piggy PHY, flash, ram) only the application specific chip selects differ. Signed-off-by:
-
- serial console on UART1 - Ethernet RMII over UCC4 - PHY SMSC LAN8700 - 64MB Flash - 128 MB DDR2 RAM - I2C - bootcount This board is similiar to the kmeter1 (8360) board, so common config options are extracted into the include/configs/km83xx-common.h file. Signed-off-by:
-
This patch reworks all headerfiles for keymile boards. Furthermore the environment variables are refactored. Changes: - introduce km-powerpc.h file and extract ppc specific parts to it - move ARM specific options and vaiables to km_arm.h - sort the environment variables to logical groups - enhance the description of the environment variables - remove KM specific HW key and board id from kernel command line Signed-off-by:
-
- adapt copyright string - change bootdelay to 2 seconds - set max number of command args to 32 - set I/O buffer size to 512 Signed-off-by:
-
- use I/O accessors -> For accessing the FPGA therefore a struct km_bec_fpga is introduced. - no longer externs needed - to defines, that only select functions, don;t assign a numeric value - Codingstyle changes to prevent checkpatch errors/warnings Signed-off-by: -
The MACH_TYPE SUEN3 is now to specific for keymile boards, because other boards similar to suen3 will follow. So the MACH_SUEN3 was renamed to MACH_KM_KIRKWOOD. Signed-off-by:
-
add following functions to common.h, to prevent extern declarations: void disable_addr_trans(void); void enable_addr_trans(void); void ddr_enable_ecc(unsigned int dram_size); Signed-off-by:
-
-
Thomas Chou authoredSigned-off-by:
Thomas Chou <thomas@wytron.com.tw> -
Jason Liu authored
For freescale i.MX53 eSDHCv2, when using CMD12, cmdtype need to be set to ABORT, otherwise, next read command will hang. This is a software Software Restrictions in i.MX53 reference manual: 29.7.8 Multi-block Read For pre-defined multi-block read operation, that is,the number of blocks to read has been defined by previous CMD23 for MMC, or pre-defined number of blocks in CMD53 for SDIO/SDCombo,or whatever multi-block read without abort command at card side, an abort command, either automatic or manual CMD12/CMD52, is still required by ESDHC after the pre-defined number of blocks are done, to drive the internal state machine to idle mode. In this case, the card may not respond to this extra abort command and ESDHC will get Response Timeout. It is recommended to manually send an abort command with RSPTYP[1:0] both bits cleared. Signed-off-by:Jason Liu <jason.hui@linaro.org>
-
John Rigby authored
Signed-off-by:John Rigby <john.rigby@linaro.org>
-
John Rigby authored
Make existing field b_max field in struct mmc unconditional and use it instead of CONFIG_SYS_MMC_MAX_BLK_COUNT in mmc_bread and mmc_bwrite. Initialize b_max to CONFIG_SYS_MMC_MAX_BLK_COUNT in mmc_register if it has not been initialized by the hw driver. Initialize b_max to 0 in all callers to mmc_register. Signed-off-by:
Andy Fleming <afleming@freescale.com>
-
Thomas Chou authored
As Andy Fleming suggested, we can call mmc_init() in mmc_spi command. So that we don't need to run mmcinfo command next. Signed-off-by:Thomas Chou <thomas@wytron.com.tw> -
Matt Waddel authored
Added the board specific definitions to use the MMCI device. Signed-off-by:Matt Waddel <matt.waddel@linaro.org>
-
Matt Waddel authored
Add support for the ARM PrimeCell MultiMedia Interface - PL180. Ported from original device driver written by ST-Ericsson. Signed-off-by:
-
- Apr 28, 2011
-
-
-
-
Use the 'video-mode' environment variable (for Freescale chips that have a DIU display controller) to designate the full video configuration. Previously, the DIU driver used the 'monitor' variable, and it was used only to determine the output video port. The old definition of the "monitor" environment variable only determines which video port to use for output. This variable was set to a number (0, 1, or sometimes 2) to specify a DVI, LVDS, or Dual-LVDS port. The resolution was hard-coded into board-specific code. The Linux command-line arguments needed to be hard-coded to the proper video definition string. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Anatolij Gustschin <agust@denx.de>
-
Add function video_get_video_mode(), which parses the "video-mode" environment variable and returns each of its components. The format matches the video= command-line option used for Linux: video-mode=<driver>:<xres>x<yres>-<depth>@<freq><,option=string> <driver> The video driver, ignored by U-Boot <xres> The X resolution (in pixels) to use. <yres> The Y resolution (in pixels) to use. <depth> The color depth (in bits) to use. <freq> The frequency (in Hz) to use. <options> A comma-separated list of device-specific options Signed-off-by: -
Anatolij Gustschin authored
There seems to be tools producing incorrect 'end of bitmap data' markers '0100' in a RLE bitmap. Drawing such bitmaps can result in overwriting memory above the frame buffer. E.g. on MPC5121e based boards this memory can contain U-Boot environment. We may not rely on the correct end of bitmap data marker 0001 only, but also have to check whether we are going to draw a valid frame buffer scan line. The patch provides a fix by maintaining a pixel counter which is incremented by the amount of pixels we are going to draw. If the counter exceeds frame buffer pixels limit we stop the drawing with the error message. Reported-by:
Michael Weiss <michael.weiss@ifm.com> Signed-off-by:
-
Grant Likely authored
The following boards gain device tree support with this patch: ca9x4_ct_vxp - Versatile Express i.mx5 boards: efikamx mx51evk mx53evk OMAP boards: devkit8000 igep0020 igep0030 omap3_overo omap3_pandora omap4_sdp3430 omap3_zoom1 omap3_zoom2 omap4_panda omap4_sdp4430 Tegra boards: Harmony Signed-off-by:Grant Likely <grant.likely@linaro.org>
-
