17 Apr, 2018

5 commits

  • For CONFIG_ENV_FAT_INTERFACE != 'mmc' a link error
    env/fat.c:93: undefined reference to `mmc_initialize'
    occurs if CONFIG_MMC_SUPPORT is not enabled.

    Fixes: 26862b4a40c3 ("env: mmc/fat/ext4: make sure that the MMC sub-system
    is initialized before using it")
    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     
  • Relocate env drivers if manual relocation is enabled. This
    patch fixes the issue of u-boot hang incase if env is
    present in any of the flash devices.

    Signed-off-by: Siva Durga Prasad Paladugu
    Signed-off-by: Michal Simek
    Reviewed-by: Simon Glass

    Siva Durga Prasad Paladugu
     
  • Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
    flag") omap GPIO gets bound before relocation. Unfortunately due to
    this, on at least the beaglebone black, the pre-relocation memory pool
    gets exhausted before probing the serial port. This then causes u-boot
    to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...

    Resolve this by resizing the default size of the pre-relocation malloc
    pool for AM335X platforms.

    Signed-off-by: Sjoerd Simons

    Sjoerd Simons
     
  • We enabled CONFIG_ISO_PARTITION by default for distro boot, so that U-Boot
    could load distro images that usually get shipped as iso images. These images
    usually come with a board agnostic boot environment.

    However, there is very little point in having ISO support enabled (for anyone
    really) in SPL, as the whole idea of SPL is to load U-Boot proper which again
    is board specific. So the fact that we enable ISO support in U-Boot proper does
    not mean at all that we want ISO support in U-Boot SPL.

    Hence, let's remove the Kconfig dependency. Along the way, let's also clean up
    all those default configs that disabled SPL ISO support.

    Signed-off-by: Alexander Graf

    Alexander Graf
     
  • Tom Rini
     

16 Apr, 2018

23 commits


15 Apr, 2018

12 commits

  • Signed-off-by: Tom Rini

    Tom Rini
     
  • Tom Rini
     
  • Tom Rini
     
  • These changes bring mainline back into line with the configurations
    that were originally set in our stable BSP.

    Signed-off-by: Jon Nettleton
    Signed-off-by: Fabio Estevam

    Jon Nettleton
     
  • 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
    Cc: Thomas Petazzoni
    Cc: Fabio Estevam
    Signed-off-by: Trent Piepho
    Tested-by: Fabio Estevam

    Trent Piepho
     
  • This platform has been marked as orphaned since September 2013, remove.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • This platform has been marked as orphaned since September 2013, remove.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • Replace fatload with the fs generic loading interface ('load' command).

    Signed-off-by: Vanessa Maegima
    Reviewed-by: Fabio Estevam

    Vanessa Maegima
     
  • 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 O'Donoghue
     
  • By using this file one can avoid cluttering .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
    Reviewed-by: Stefano Babic

    Lukasz Majewski
     
  • 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

    Lukasz Majewski
     
  • 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
    Signed-off-by: Sebastian Reichel

    Ian Ray