summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* x86: Change default FRAMEBUFFER_VESA_MODE of some boardsBin Meng2018-04-166-6/+6
| | | | | | | | This changes some boards' default FRAMEBUFFER_VESA_MODE to use 32-bit pixel format for better VxWorks compatibility. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* video: vesa: Change default FRAMEBUFFER_VESA_MODEBin Meng2018-04-161-1/+1
| | | | | | | | This changes the default FRAMEBUFFER_VESA_MODE to use 32-bit pixel format for better VxWorks compatibility. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODEBin Meng2018-04-162-0/+8
| | | | | | | | | If CONFIG_FRAMEBUFFER_SET_VESA_MODE is not set, don't switch graphics card to VESA mode. This applies to both native mode and emulator mode of running the VGA BIOS. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* elf: Add a very simple ELF64 loaderBin Meng2018-04-161-1/+43
| | | | | | | | This adds a very simple ELF64 loader via program headers, similar to load_elf_image_phdr() that we already have. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* elf: Add ELF64 related structure definesBin Meng2018-04-161-0/+43
| | | | | | | | This adds ELF header, program header and section header structure defines for the 64-bit ELF image. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* elf: Clean up the ELF header fileBin Meng2018-04-161-146/+138
| | | | | | | | | | | | Fix various style violations in elf.h - use correct comment format if the comment fits in just one line - remove the ending period for the one-line comment - use tab for the indention instead of space - put the opening brace at the same line of a typedef/union - remove <name> in a 'typedef struct' for consistency Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* x86: Rename e820entry to e820_entryBin Meng2018-04-169-13/+13
| | | | | | | | This changes 'struct e820entry' to 'struct e820_entry' to conform with the coding style. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* x86: Use 'unsigned int' in install_e820_map() functionsBin Meng2018-04-166-11/+17
| | | | | | | | | This fixes the following checkpatch warning: warning: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* vxworks: x86: Rename e820info to e820_infoBin Meng2018-04-162-4/+4
| | | | | | | | This changes 'struct e820info' to 'struct e820_info' to conform with the coding style. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* bootvx: x86: Explicitly clear the bootloader image sizeBin Meng2018-04-162-0/+16
| | | | | | | | | | | | | | | VxWorks bootloader stores its size at a pre-defined offset @ 0x5004. Later when VxWorks kernel boots up and system memory information is retrieved from the E820 table, the bootloader size will be subtracted from the total system memory size to calculate the size of available memory for the OS. Explicitly clear the bootloader image size otherwise if memory at this offset happens to contain some garbage data, the final available memory size for the kernel is insane. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* bootvx: x86: Prepare e820 related stuff from the given kernel memory base ↵Bin Meng2018-04-163-27/+23
| | | | | | | | | | | | | | | address At present two environment variables 'e820data'/'e820info' are required to boot a VxWorks x86 kernel, but this is superfluous. The offset of these two tables are actually at a fixed offset from the kernel memory base address and we can provide the kernel memory base address to U-Boot via only one variable 'vx_phys_mem_base'. Note as it name indicates, the physical address should be provided. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* doc: vxworks: Minor update for clarityBin Meng2018-04-161-5/+5
| | | | | | | This corrects a typo and updates several places for clarity. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* x86: Update the io.h file to use {out|in}_{be|le}X macrosLukasz Majewski2018-04-161-17/+17
| | | | | | | | | | | | | The commit 3f70a6f57734 ("x86: Add clr/setbits functions") introduced the {read|write}_ macros to manipulate data. Those macros are not used by any code in the u-boot project (despite the io.h itself). Other architectures use io.h with {in|out}_* macros. This commit brings some unification across u-boot supported architectures. Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Add 64-bit memory-mapped I/O functionsIvan Gorinov2018-04-161-0/+4
| | | | | | | | | | | Add readq() and writeq() definitions for x86. Please note: in 32-bit code readq/writeq will generate two 32-bit memory access instructions instead of one atomic 64-bit operation. Signed-off-by: Ivan Gorinov <ivan.gorinov@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* Merge git://git.denx.de/u-boot-imxTom Rini2018-04-1569-1329/+1439
|\ | | | | | | Signed-off-by: Tom Rini <trini@konsulko.com>
| * mx6cuboxi: Fix some memory configuration errorsJon Nettleton2018-04-151-2/+1
| | | | | | | | | | | | | | | | These changes bring mainline back into line with the configurations that were originally set in our stable BSP. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
| * imx: Create distinct pre-processed mkimage config filesTrent Piepho2018-04-151-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each imx image is created by a separate sub-make and during this process the mkimage config file is run though cpp. The cpp output is to the same file no matter what imx image is being created. This means if two imx images are generated in parallel they will attempt to independently produce the same pre-processed mkimage config file at the same time. Avoid the problem by making the pre-processed config file name unique based on the imx image it will be used in. This way each image will create a unique config file and they won't clobber each other when run in parallel. This should fixed the build bug referenced in b5b0e4e3 ("imximage: Remove failure when no IVT offset is found"). Cc: Breno Lima <breno.lima@nxp.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Trent Piepho <tpiepho@impinj.com> Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
| * mx31ads: DeleteTom Rini2018-04-159-687/+0
| | | | | | | | | | | | This platform has been marked as orphaned since September 2013, remove. Signed-off-by: Tom Rini <trini@konsulko.com>
| * imx31_phycore: DeleteTom Rini2018-04-1512-568/+0
| | | | | | | | | | | | This platform has been marked as orphaned since September 2013, remove. Signed-off-by: Tom Rini <trini@konsulko.com>
| * pico-imx7d: Replace fatload commandVanessa Maegima2018-04-152-2/+3
| | | | | | | | | | | | | | Replace fatload with the fs generic loading interface ('load' command). Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * imx: mx7: snvs: Add an SNVS init routineBryan O'Donoghue2018-04-154-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Working with HAB on the i.MX7 we've encountered a case where a board that successfully authenticates u-boot when booting Linux via OPTEE subsequently fails to properly bring up the RTC. The RTC registers live in the low-power block of the Secure Non-Volatile Storage (SNVS) block. The root cause of the error has been traced to the HAB handing off the SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the Non-Privileged Software Access Enable bit is zero. In ordinary circumstances this is OK since we typically do not run in TZ mode, however when we boot via HAB and enablng TrustZone, it is required to set HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have sufficient permissions to manipulate the SNVS-LP block. On our reference board it is the difference between Linux doing this: root@imx7s-warp-mbl:~# dmesg | grep rtc snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034 snvs_rtc_enable read 0x00000021 from SNVS_LPCR @ 0x00000038 snvs_rtc_enable read 0x00000000 from SNVS_HPLR @ 0x00000000 snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x00000004 snvs_rtc 30370000.snvs:snvs-rtc-lp: rtc core: registered 30370000.snvs:snvs-rtc-lp as rtc0 snvs_rtc 30370000.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 UTC (1522543864) and doing this: root@imx7s-warp-mbl:~# dmesg | grep rtc snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034 snvs_rtc_enable read 0x00000020 from SNVS_LPCR @ 0x00000038 snvs_rtc_enable read 0x00000001 from SNVS_HPLR @ 0x00000000 snvs_rtc_enable read 0x00002020 from SNVS_HPCOMR @ 0x00000004 snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110 snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110 hctosys: unable to open rtc device (rtc0) Note bit 1 of LPCR is not set in the second case and is set in the first case and that bit 31 of HPCOMR is set in the second case but not in the first. Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone and continue onto the kernel. The kernel then has the necessary permissions to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in contrast - in the failing case the non-privileged kernel cannot do so. This patch adds a simple init_snvs() call which sets the permission-bit called from soc.c for the i.MX7. It may be possible, safe and desirable to perform this on other i.MX processors but for now this is only tested on i.MX7 as working. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
| * boot: script: The boot.scr file for K+P's boardsLukasz Majewski2018-04-151-0/+96
| | | | | | | | | | | | | | | | | | | | | | By using this file one can avoid cluttering <board>.h file with u-boot HUSH commands necessary for booting target device. With such approach the commands are stored only in one place and can be reused if needed. Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Stefano Babic <sbabic@denx.de>
| * imx: board: Add support for the K+P's kp_imx6q_tpc boardLukasz Majewski2018-04-158-0/+863
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit provides support for Kieback & Peter GmbH IMX6Q based TPC board. U-boot console output: U-Boot SPL 2018.05-rc1-00005-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200) Trying to boot from MMC1 U-Boot 2018.05-rc1-00005-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200) CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 37C Reset cause: POR Board: K+P KP_IMX6Q_TPC i.MX6Q Watchdog enabled I2C: ready DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: FEC [PRIME] Autoboot in 3 seconds
| * board: ge: bx50v3: enable backlight on demandIan Ray2018-04-152-17/+29
| | | | | | | | | | | | | | | | | | Enable display backlight only if a message needs to be displayed. The kernel re-initializes the backlight, which results in some unwanted artifacts. Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
| * arm: imx: Add Winbond SPI-NOR support for Advantech DMS-BA16 boardKen Lin2018-04-152-0/+2
| | | | | | | | | | | | Windbond's been in the AVL list and need to enable the support Signed-off-by: Ken Lin <yungching0725@gmail.com>
| * imx: hab: Provide hab_auth_img_or_fail commandBryan O'Donoghue2018-04-151-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds hab_auth_img_or_fail() a command line function that encapsulates a common usage of authenticate and failover, namely if authenticate image fails, then drop to BootROM USB recovery mode. For secure-boot systems, this type of locked down behavior is important to ensure no unsigned images can be run. It's possible to script this logic but, when done over and over again the environment starts get very complex and repetitive, reducing that script repetition down to a command line function makes sense. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com> Cc: Breno Lima <breno.lima@nxp.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Breno Lima <breno.lima@nxp.com>
| * imximage: Encase majority of header in __ASSEMBLY__ declarationBryan O'Donoghue2018-04-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Subsequent patches will want to include imageimage.h but in doing so include it on an assembly compile path causing a range of compile errors. Fix the errors pre-emptively by encasing the majority of the declarations in imximage.h inside an ifdef __ASSEMBLY__ block. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com> Cc: Breno Lima <breno.lima@nxp.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Breno Lima <breno.lima@nxp.com>
| * warp7: Set u-boot serial# based on OTP valueBryan O'Donoghue2018-04-152-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | u-boot has a standard "serial#" environment variable that is suitable for storing the iSerial number we will supply via the USB device descriptor. serial# is automatically picked up by the disk subsystem in u-boot - thus providing a handy unique identifier in /dev/disk/by-id as detailed below. Storing the hardware serial identifier in serial# means we can change the serial# if we want before USB enumeration - thus making iSerial automatic via OTP but overridable if necessary. This patch reads the defined OTP fuse and sets environment variable "serial#" to the value read. With this patch in place the USB mass storage device will appear in /dev/disk/by-id with a unique name based on the OTP value. For example /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0:0 Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Rui Miguel Silva <rui.silva@linaro.org> Cc: Ryan Harkin <ryan.harkin@linaro.org> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * imx: mx7: Add comment to describe OTP TESTER registersBryan O'Donoghue2018-04-151-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tester registers provide a unique chip-level identifier which get_board_serial() returns in a "struct tag_serialnr". This patch documents the properties of the registers; in summary. 31:0 OCOTP_TESTER0 (most significant) - FSL-wide unique, encoded LOT ID STD II/SJC CHALLENGE/ Unique ID OCOTP_TESTER1 (least significant) 31:24 - The X-coordinate of the die location on the wafer/SJC CHALLENGE/ Unique ID 23:16 - The Y-coordinate of the die location on the wafer/SJC CHALLENGE/ Unique ID 15:11 - The wafer number of the wafer on which the device was fabricated/SJC CHALLENGE/ Unique ID 10:0 - FSL-wide unique, encoded LOT ID STD II/SJC CHALLENGE/ Unique ID The 64 bits of data generate a unique serial number per-chip. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * imx: mx7: Fix CONFIG_SERIAL_TAG compilationBryan O'Donoghue2018-04-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when we define CONFIG_SERIAL_TAG we will barf with a failure to define "struct tag_serialnr". This structure is defined in <asm/setup.h>, this patch includes <asm/setup.h> to fix. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * ARM: mx6: ddr: Add write leveling correction codeMarek Vasut2018-04-151-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the DDR calibration is enabled, a situation may happen that it will fail on a few select boards out of a whole production lot. In particular, after the first write leveling stage, the MPWLDECTRLx registers will contain a value 0x1nn , for nn usually being 0x7f or slightly lower. What this means is that the HW write leveling detected that the DQS rising edge on one or more bundles arrives slightly _after_ CLK and therefore when the DDR DRAM samples CLK on the DQS rising edge, the CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18). The HW write leveling then ends up adding almost an entire cycle (thus the 0x17f) to the DQS delay, which indeed aligns it, but also triggers subsequent calibration failure in DQS gating due to this massive offset. There are two observations here: - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the DQS gating passes, the entire calibration passes as well and the DRAM is perfectly stable even under massive load. - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so in MPWLDECTRx register is not there, but it is replaced by 0x0 as one would expect. Someone from NXP finally explains why, quoting [1]: " Having said all that, the DDR Stress Test does something that we do not advertise to the users. The Stress Test iself looks at the values of the MPWLDECTRL0/1 fields before reporting results, and if it sees any filed with a value greater than 200/256 delay (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR Stress test will reset the Write Leveling delay for this lane to 0x000 and not report it in the log. The reason that the DDR Stress test does this is because a delay of more than 78% a clock cycle means that the DQS edge is arriving within the JEDEC tolerence of 25% of the clock edge. In most cases, DQS is arriving < 5% tCK of the SDCLK edge in the early case, and it does not make sense to delay the DQS strobe almost a full clock cycle and add extra latency to each Write burst just to make the two edges align exactly. In this case, we are guilty of making a decision for the customer without telling them we are doing it so that we don't have to provide the above explanation to every customer. They don't need to know it. " This patch adds the correction described above, that is if the MPWLDECTRx value is over 0x148, the value is corrected back to 0x0. [1] https://community.nxp.com/thread/456246 Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by: Eric Nelson <eric@nelint.com> Reviewed-by: Stefano Babic <sbabic@denx.de>
| * tools/imximage: use 0x prefix in HAB Blocks lineRasmus Villemoes2018-04-152-8/+8
| | | | | | | | | | | | | | | | | | | | | | The u-boot-ivt.img.log file contains 0x prefixes in the HAB Blocks line, while the SPL.log does not. For consistency, and to make it easier to extract and put into a .csf file for use with NXP's code signing tool, add 0x prefixes here. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Breno Lima <breno.lima@nxp.com>
| * Makefile: always preserve output for images that can contain HAB BlocksRasmus Villemoes2018-04-153-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current makefile logic disables creation of the SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command line, the rationale presumably being that the user wants and gets the information on the console. However, from general principles, I don't think a higher V= level should affect which build artifacts get generated (and certainly shouldn't produce fewer). Concretely, it's also a problem that when doing a V=1 build in a terminal, the relevant HAB blocks lines easily drown in all the other V=1 output. Moreover, build systems such as Yocto by default pass V=1, so in that case the information gets hidden away in the do_compile log file, making it nigh impossible to create a recipe for creating signed U-boot images - I don't want to disable V=1, because having verbose output in the log file is valuable when things go wrong, but OTOH trying to go digging in the do_compile log file (and getting exactly the right lines) is not pleasant to even think about. So change the logic so that for V=0, the mkimage output is redirected to MKIMAGEOUTPUT (which is also the current behaviour), while for any other value of V, we _additionally_ write the information to make's stdout, whatever that might be. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Tested-by: Breno Lima <breno.lima@nxp.com>
| * wandboard: remove superfluous includeHeinrich Schuchardt2018-03-291-1/+0
| | | | | | | | | | | | | | No definition provided by input.h is used in the board file. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * imx7: spl: Check for Serial Downloader in spl_boot_deviceEran Matityahu2018-03-291-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to imx6, before reading the boot device, first check bmode to see if the serial downloader has been selected explicitly, then check whether the serial downloader has been activated due to unbootable primary boot devices (e.g. empty eMMC). If the serial downloader is activated, return BOOT_DEVICE_BOARD. This allows SPL with SDP support to wait for the U-Boot image to be loaded via the serial download protocol using imx_usb_loader. Signed-off-by: Eran Matityahu <eran.m@variscite.com>
| * imx7: Add src_base structure define macroEran Matityahu2018-03-291-0/+2
| | | | | | | | | | | | Add src_base structure global define macro, similarly to imx6 Signed-off-by: Eran Matityahu <eran.m@variscite.com>
| * Makefile: Build firmware-ivt image type for HAB verification also for mx7Eran Matityahu2018-03-291-0/+4
| | | | | | | | | | | | | | | | | | Create u-boot-ivt.img and u-boot-ivt.img.log when building U-Boot with SPL and Secure Boot enabled for imx7 (like it is done for imx6). See commit d21bd69b6e95ca7824941e7f527871cd5c63c7f7 for more info. Signed-off-by: Eran Matityahu <eran.m@variscite.com>
| * mx7_common: Fix SPL compilation with secure boot support enabledEran Matityahu2018-03-291-0/+3
| | | | | | | | | | | | | | The SPL MISC driver support must be enabled, so that the driver can use OTP fuse to check if HAB is enabled. Signed-off-by: Eran Matityahu <eran.m@variscite.com>
| * ARM: dts: imx6ull: add wdog3Jörg Krause2018-03-291-0/+8
| | | | | | | | | | | | | | | | | | | | The i.MX6ULL has a WDOG3 located at start address 0x021E0000 in the AIPS-2 memory region [1]. [1] i.MX 6ULL Applications Processor Reference Manual, Rev. 1, 11/2017, Table 2-3. AIPS-2 memory map, p. 178 Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
| * ARM: dts: imx6ul: add wdog3Jörg Krause2018-03-291-0/+8
| | | | | | | | | | | | | | | | | | | | The i.MX6UL has a WDOG3 located at start address 0x021E0000 in the AIPS-2 memory region [1]. [1] i.MX 6UltraLite Applications Processor Reference Manual, Rev. 1, 04/2016, Table-2-3 AIPS-2 memory map, p. 166 Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
| * board: ge: ppd: Fix environment variable locationNandor Han2018-03-291-2/+2
| | | | | | | | | | | | | | | | | | This fixes environment variable location to avoid overlapping with U-Boot itself. Also more space for environment variables has been reserved to prevent future issues. Signed-off-by: Nandor Han <nandor.han@ge.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
| * imx: fix CAAM base for i.MX6ULAnatolij Gustschin2018-03-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HW accelerated "hash sha256 ..." command doesn't work on i.MX6UL, we get "CAAM was not setup properly or it is faulty" error message. This is due to wrong CAAM base 0x02100000, on i.MX6UL the CAAM base address is 0x02140000. Fix it. Note: with this patch applied the "hash sha256" commant still has some issues on i.MX6UL ("Invalid KEY Command" or other errors). With data cache off the "hash sha256" command works as expected. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * drivers: i2c: mxc: Update support to 8 I2C controllersSriram Dash2018-03-292-0/+136
| | | | | | | | | | | | | | | | | | | | | | Existing driver supports upto 4 I2C controllers. But some of future NXPs SoCs like lx2160a has eight I2C controllers. Update MXC driver to support upto 8 I2C controllers Signed-off-by: Sriram Dash <sriram.dash@nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
| * drivers: i2c: mxc: Update SYS_I2C_MXC_I2C support in KconfigSriram Dash2018-03-299-32/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | NXP layerscape platforms like ls1088a, ls2088a uses MXC I2C Controller. -Remove dependency of MX6 for the same. Update related configs to use Kconfig file. -Add SYS_I2C_MXC_I2C1,_I2C2,_I2C3,_I2C4 in Kconfig -Add CONFIG_SYS_MXC_I2C1_SPEED,_I2C2_,_I2C3_,_I2C4_ in Kconfig -Add CONFIG_SYS_MXC_I2C1_SLAVE,_I2C2_,_I2C3_,_I2C4_ in Kconfig Signed-off-by: Sriram Dash <sriram.dash@nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
* | Merge git://git.denx.de/u-boot-netTom Rini2018-04-1533-118/+221
|\ \
| * | net: phy: Don't limit phy addresses by defaultJoe Hershberger2018-04-1316-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some boards expect to find more than one phy while other boards are old and need to be limited to a specific phy address. Only limit the phy address for boards that opt in. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
| * | xilinx: Only enable dist boot pxe when DHCP is enabledJoe Hershberger2018-04-133-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise, we see this: In file included from include/configs/zynq-common.h:183:0, from include/config.h:5, from include/common.h:21, from env/common.c:11: include/config_distro_bootcmd.h:319:2: error: expected ?}? before ?BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE? BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE ^ include/config_distro_bootcmd.h:319:2: note: in definition of macro ?BOOTENV_DEV_NAME_PXE? Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
| * | Revert "Kconfig: cmd: Make networking command dependent on NET"Joe Hershberger2018-04-134-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts the parts of commit 3b3ea2c56ec4bc5588281fd103c744e608f8b25c where it changed the EFI dependency on NET. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Duncan Hare <dh@synoia.com>
| * | net: Make core net code depend on NET instead of CMD_NETJoe Hershberger2018-04-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | No commands are necessary to have a network stack. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Duncan Hare <dh@synoia.com>
| * | net: Make the BOOTP options defaultJoe Hershberger2018-04-132-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BOOTP options used to be and should still be default for all boards with CMD_NET enabled. One should not be forced to use DISTRO_DEFAULTS to get them. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Duncan Hare <dh@synoia.com>
View Lorry Controller Status