- Apr 15, 2018
-
-
Lukasz Majewski authored
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
-
Ian Ray authored
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>
-
Ken Lin authored
Windbond's been in the AVL list and need to enable the support Signed-off-by:
Ken Lin <yungching0725@gmail.com>
-
Bryan O'Donoghue authored
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>
-
Bryan O'Donoghue authored
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>
-
Bryan O'Donoghue authored
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>
-
Bryan O'Donoghue authored
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>
-
Bryan O'Donoghue authored
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>
-
Marek Vasut authored
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>
-
Rasmus Villemoes authored
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>
-
Rasmus Villemoes authored
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>
-
- Mar 29, 2018
-
-
Heinrich Schuchardt authored
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>
-
Eran Matityahu authored
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>
-
Eran Matityahu authored
Add src_base structure global define macro, similarly to imx6 Signed-off-by:
Eran Matityahu <eran.m@variscite.com>
-
Eran Matityahu authored
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 d21bd69b for more info. Signed-off-by:
Eran Matityahu <eran.m@variscite.com>
-
Eran Matityahu authored
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>
-
Jörg Krause authored
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>
-
Jörg Krause authored
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>
-
Nandor Han authored
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>
-
Anatolij Gustschin authored
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>
-
Sriram Dash authored
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>
-
Sriram Dash authored
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>
-
- Mar 11, 2018
-
-
Breno Lima authored
The README.mxc_hab is outdated and need improvements, add the following modifications: - Reorganize document and remove duplicate content - Add CST download link - Update CST package name - Align command lines with CST v2.3.3 - Update U-Boot binary name - Remove CSF padding since is not documented in AN4581 Signed-off-by:
Breno Lima <breno.lima@nxp.com>
-
Breno Lima authored
Currently the High Assurance Boot procedure is documented in two places: - doc/README.imx6 - doc/README.mxc_hab It is better to consolidate all HAB related information into README.mxc_hab file, so move the content from README.imx6 to README.mxc_hab. Signed-off-by:
Breno Lima <breno.lima@nxp.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com>
-
Bryan O'Donoghue authored
commit cd2d4600 ("arm: imx: hab: Add IVT header definitions") declares struct ivt_header as "__attribute__((packed))". commit ed286bc8 ("imx: hab: Check if CSF is valid before authenticating image") declares struct hab_hdr with __packed. This patch makes the __packed convention consistent. 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> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com>
-
Bryan O'Donoghue authored
commit ed286bc8 ("imx: hab: Check if CSF is valid before authenticating image") makes use of "__packed" as a prefix to the "struct hab_hdr" declaration. With my compiler "gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)" we get: ./arch/arm/include/asm/mach-imx/hab.h:42:25: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token struct __packed hab_hdr { Fix this problem by including <linux/compiler.h> 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> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com>
-
Jagan Teki authored
This patch fixes the wrongly included dtsi file which was breaking mainline support for Engicam i.CoreM6 DualLite/Solo RQS. Linux commit details for the same change as "ARM: dts: imx6dl: Include correct dtsi file for Engicam i.CoreM6 DualLite/Solo RQS" (sha1: c0c6bb2322964bd264b4ddedaa5776f40c709f0c) Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com>
-
Jagan Teki authored
usdhc4 node need to update pinctrl, bus-width and non-removable properties, sync the same from Linux. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com>
-
- Mar 09, 2018
-
-
git://git.denx.de/u-boot-imxTom Rini authored
-
Tom Rini authored
Rsync all defconfig files using moveconfig.py Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Stefan Theil authored
The system call used by mkimage to run dtc redirects stdout to a temporary file. This can cause problems on Windows (with a MinGW cross-compiled version). Using the "-o" dtc parameter avoids this problem. Signed-off-by:
Stefan Theil <stefan.theil@mixed-mode.de> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Marek Behún authored
Other filesystem drivers don't do this. Signed-off-by:
Marek Behun <marek.behun@nic.cz>
-
Heinrich Schuchardt authored
NETWORK should be after NAND_FLASH. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
kmerr: verify that malloc and calloc are followed by a check to verify that we are not out of memory. badzero: Compare pointer-typed values to NULL rather than 0 Both checks are copied from the Linux kernel archive. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
The iterator of list_for_each() is never NULL. Identified with coccinelle. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Alexander Graf authored
After the UART was initialized, we may still have bogus data in the RX queue if it was enabled with incorrect pin muxing before. So let's flush the RX queue whenever we initialize baud rates. This fixes a regression with the dynamic pinmuxing code when enable_uart=1 is not set in config.txt on Raspberry Pis that use pl011 for serial. Fixes: caf2233b ("bcm283x: Add pinctrl driver") Reported-by:
Göran Lundberg <goran@lundberg.email> Reported-by:
Peter Robinson <pbrobinson@gmail.com> Signed-off-by:
Alexander Graf <agraf@suse.de> Tested-by:
Peter Robinson <pbrobinson@gmail.com> Tested-by:
Tuomas Tynkkynen <tuomas@tuxera.com>
-
Alexander Graf authored
After the UART was initialized, we may still have bogus data in the RX queue if it was enabled with incorrect pin muxing before. So let's flush the RX queue whenever we initialize baud rates. This fixes a regression with the dynamic pinmuxing code when enable_uart=1 is not set in config.txt. Fixes: caf2233b ("bcm283x: Add pinctrl driver") Reported-by:
Göran Lundberg <goran@lundberg.email> Reported-by:
Peter Robinson <pbrobinson@gmail.com> Signed-off-by:
Alexander Graf <agraf@suse.de> Tested-by:
Peter Robinson <pbrobinson@gmail.com> Tested-by:
Tuomas Tynkkynen <tuomas@tuxera.com>
-
Tuomas Tynkkynen authored
The following config symbols are only defined once and never referenced anywhere else: CONFIG_AT91SAM9263EK CONFIG_AT91SAM9RLEK CONFIG_BARIX_IPAM390 CONFIG_BOARD_H2200 CONFIG_EP9301 CONFIG_KZM_A9_GT CONFIG_PICOSAM CONFIG_PLATINUM_PICON CONFIG_PLATINUM_TITANIUM CONFIG_PM9261 CONFIG_PM9263 CONFIG_PM9G45 CONFIG_SIEMENS_DRACO CONFIG_SIEMENS_PXM2 CONFIG_SIEMENS_RUT CONFIG_SMDKC100 CONFIG_SMDKV310 CONFIG_STM32F4DISCOVERY Most of them are config symbols named after the respective boards which seems to have been a standard practice at some point. Signed-off-by:
Tuomas Tynkkynen <tuomas@tuxera.com>
-
Tuomas Tynkkynen authored
The following config symbols are only defined once and never referenced anywhere else: CONFIG_ARM926EJS CONFIG_CPUAT91 CONFIG_EXYNOS5800 CONFIG_SYS_CORTEX_R4 Most of them are config symbols named after the respective SoCs which seems to have been a standard practice at some point. Signed-off-by:
Tuomas Tynkkynen <tuomas@tuxera.com>
-
Tuomas Tynkkynen authored
The following config symbols are only defined once and never referenced anywhere else: CONFIG_DBAU1X00 CONFIG_PB1X00 Most of them are config symbols named after the respective boards which seems to have been a standard practice at some point. Signed-off-by:
Tuomas Tynkkynen <tuomas@tuxera.com>
-