TI-SCI firmware will only respond to messages when the
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages
already do this, set this for the ones that do not.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Tested-by: Alejandro Hernandez <ajhernandez@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
commit 95f4bbd581 ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
introduced Kconfig option for gzip in U-Boot, but help text
says gzip for SPL, which is wrong. Fix this.
Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
The existing comments where confusing read and write. The comment for
fs_write() had:
"@addr: The address to read into"
So let's rework the comments and format them in Sphinx style.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Switch from using the high priority DMSC transmit message queue used
by the secure R5 MCU island boot context to the low priority message
queue. While the change in priority is irrelevant for the current boot
architecture it however gives us access to a deeper message queue that
will allow us to buffer more messages. This is an important aspect when
sending several messages without requesting and waiting for a response
in a row which is a communication scheme used during core shutdown for
example. See AM654 TISCI User Guide for additional details.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
In commit ad6054f1fe where support for the
Sancloud BeagleBone Enhanced (BBE) was added, new conditional
configuration of either MII pin muxing or RGMII pin muxing is done
depending on the board type. However, the old call to set up MII pin
muxing was not removed.
This may result in misconfiguration of the pin muxing for the BBE or
duplicate configuration for other boards and so we remove this obsolete
call.
Signed-off-by: Paul Barker <paul.barker@sancloud.co.uk>
Restart operation never exists and reset operation never
makes the watchdog expire immediately but expire_now operation
does.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Upcoming sysfw (2019.03) will not open the channelized firewalls during
init, it only going to do so in response to the channel configuration
message.
Remove the channel state checks done before the channel configuration and
move it after the configuration for warning purposes.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
An earlier commit converted the TISCI receive timeouts to be specified
in ms rather than us however it failed to take this change into account
when passing the actual timeout to be used when invoking the mailbox
receive API. This leads to the actual timeout to be 1,000 times shorter
than expected and as a result certain TISCI operations would fail.
Fix the issue by converting the timeout declared in ms to us on the fly
as expected by the respective API.
Fixes: fd6b40b1ba ("firmware: ti_sci: Add support for NAVSS resource management")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Update the mmc maintainer from Jaehoon to me.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Marek Vasut <marex@denx.de>
Currently packet data is wrongly extracted when metadata is NULL.
Fix it and negate the if check.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
This pull request provides error fixes for the handling of GPT partitions
and for the UEFI subsystem.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAlzLSXQACgkQxIHbvCwF
GsSdeQ/9HM7NELIDgo8lK9+v4i1oFLbfO0a/W8I1p2d8o19RKLKfDe9hE5fs5cmu
Ky/qnGIfNbtv1YdJg9TNLWbdE9lrLRJVWXbDhG6rh99W8vDEhFwPMhwzmTsoyJnR
H5qXgEpwqG7FYidiVWvN6J3MB9pZRn+Be6Rt28NUrM0QJWrJ9MPkN3/tHNbtYGbs
jbsm/GDhTBVXLlOcOjXtJvrcC/W/fLyPEz9oR0POzOtKDAZPISfZhORwipnu3DAb
WVzH1Slg7Icy7fRPJDFpQGwiefcuFngLShL6JP2tA4HcMVAhdhjDo+YYwR0vXoM5
QfvrIE2hpNrOUhHkNrcYRWynHVZHnuoxdwdQpeBs3y0G8Ig1K0xvB5nwUGZhigzY
qmOWZZoNt1IJByvZdS+gVa0Mx0akRF9tJy/Kou90acPuSRAbsAaEjeuP5umYqBhl
o9isRLyc+jjfpS2WyRzy4vfIhmR+FA8BU7KPUF/GppA+q0ZplGizJ+a1M5WBZWMN
JIjIMuYmbbHOjcfrksDfPCfE5WyS5QZyV7jyec8xAXe/cW045uqaeWV/215sr9hr
dcJS6rKfYJ1CO5OSYjZCJJLKBbSoS/RE31iLBxRvOLjR0o8kJGm7IN//sTtVL7uJ
OWRpeLVQ35JFAmDzr8LlEtDdkbTrPM5AMMUCie+SU8R7b+ldnwU=
=GUpA
-----END PGP SIGNATURE-----
Merge tag 'efi-2019-07-rc2' of git://git.denx.de/u-boot-efi
Pull request for UEFI sub-system for v2019.07-rc2
This pull request provides error fixes for the handling of GPT partitions
and for the UEFI subsystem.
Some SPI controllers can't write nor->page_size bytes in a single step
because their TX FIFO is too small, but when that happens we should
make sure a WRITE_EN command before each write access and READ_SR command
after each write access is issued.
We should allow nor->write() to return a size that is smaller than the
requested write size to gracefully handle this case.
Also, the spi_nor_write_data() should return the actual number of bytes
that were written during the spi_mem_exec_op() operation.
This patch is a combination of two commits backported from kernel:
commit 630d6bd8a3b4 ("mtd: spi-nor: Support controllers with limit ...")
commit 3baa8ec88c2f ("mtd: devices: m25p80: Make sure WRITE_EN is ...")
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Acked-by: Vignesh R <vigneshr@ti.com>
Tested-by: Shyam Saini <shyam.saini@amarulasolutions.com> # microzed
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
This options will be enabled by default by CZ.NIC shipped U-Boot. Enable
them in defconfig.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Add support for the gpio command and driver for the I2C connected
pca9538 controller, to be able to determine if SFP module is present in
the Turris Omnia router.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.
On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.
My theory is that the controller does approximately this:
1. sets interrupt flag in control register,
2. sets the value of status register,
3. causes an interrupt
In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.
The bug does not appear if I add a small delay before reading status
register.
Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
There is a Factory RESET button on the back side of the Turris Omnia
router. When user presses this button before powering the device up and
keeps it pressed, the microcontroller prevents the main CPU from booting
and counts how long the RESET button is being pressed (and indicates
this by lighting up front LEDs).
The idea behind this is that the user can boot the device into several
Factory RESET modes.
This patch adds support for U-Boot to read into which Factory RESET mode
the user booted the device. The value is an integer stored into the
omnia_reset environment variable. It is 0 if the button was not pressed
at all during power up, otherwise it is the number identifying the
Factory RESET mode.
This patch also changes bootcmd to a special hardcoded value if Factory
RESET button was pressed during device powerup. This special bootcmd
value sets the colors of all the LEDs on the front panel to green and
then tries to load the rescue image from the SPI flash memory and boot
it.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
The regdomain environment variable is set according to value read from
EEPROM. This has to be done in board_late_init, after the environment
variables are read from SPI. Select CONFIG_BOARD_LATE_INIT in Kconfig
for the Turris Omnia target.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Since board watchdog is now unified and not handled in board files,
remove the unnecessary includes.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Unify the way how Omnia and Mox print board information (RAM size and
serial number).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Refactor RAM size reading from EEPROM in preparation for next patch.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
This driver is required for Turris Omnia to read ethernet addresses.
Move the dependency from turris_omnia_defconfig to Kconfig.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Refactor code which accesses the microcontroller and EEPROM via I2C.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
If SCSI is enabled, U-Boot should try to boot also from SCSI device on
Turris Omnia.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
The I2C dependencies are defined in include/configs/turris_omnia.h,
because Turris Omnia won't boot correctly without I2C support.
Move these dependencies to Kconfig, so that they are selected if Turris
Omnia is selected as target.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
These are not needed if MMC and SCSI DM drivers are used.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Enable AHCI, SCSI and SATA for compliance with the driver model
migration.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Add XHCI_HOST and XHCI_MVEBU to defconfig, so that user's can by default
boot from USB on Turris Omnia.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
The i2c slave disabling is done by mvtwsi driver and is not needed here.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
EVP_VerifyFinal would return one of three values:
1 if the data is verified to be correct;
0 if it is incorrect;
-1 if there is any failure in the verification process.
The varification in unpatched version is wrong, since it ignored
the return value of -1.
The bug allows a malformed signature to be treated as a good
signature rather than as an error. This issue affects the
signature checks on DSA ans ECDSA keys used with SSL/TLS.
This issue is similar to CVE-2008-5077, CVE-2009-0021,
CVE-2009-0025, CVE-2009-0046 ~ CVE-2009-0049.
Signed-off-by: Young Xiao <92siuyang@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
platform are always the same. Below is consistent on each cold boot:
=> ### interrupt autoboot
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7
While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.
Assuming U-Boot with RANDOM_UUID=y is deployed on a large number of
devices, all those devices would essentially expose the same UUID,
breaking the assumption of system/RFS/application designers who rely
on UUID as being globally unique (e.g. a database using UUID as key
would alias/mix up entries/records due to duplicated UUID).
The root cause seems to be simply _not_ seeding PRNG before generating
a random value. It turns out this belongs to an established class of
PRNG-specific problems, commonly known as "unseeded randomness", for
which I am able to find below bugs/CVE/CWE:
- https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
("CVE-2015-0285 openssl: handshake with unseeded PRNG")
- https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded
randomness")
- https://cwe.mitre.org/data/definitions/336.html
("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")
The first revision [1] of this patch updated the seed based on the
output of get_timer(), similar to [4].
There are two problems with this approach:
- get_timer() has a poor _ms_ resolution
- when gen_rand_uuid() is called in a loop, get_timer() returns the
same result, leading to the same seed being passed to srand(),
leading to the same uuid being generated for several partitions
with different names
The above drawbacks have been addressed in the second version [2].
In its third revision (current), the patch reworded the description
and summary line to emphasize it is a *fix* rather than an improvement.
Testing [3] consisted of running 'gpt write mmc 1 $partitions' in a
loop on R-Car3 for several minutes, collecting 8844 randomly generated
UUIDS. Two consecutive cold boots are concatenated in the log.
As a result, all uuid values are unique (scripted check).
Thanks to Roman, who reported the issue and provided support in fixing.
[1] https://patchwork.ozlabs.org/patch/1091802/
[2] https://patchwork.ozlabs.org/patch/1092945/
[3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
[4] commit da384a9d76 ("net: rename and refactor eth_rand_ethaddr() function")
Reported-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Apply the following changes:
- Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME',
since 'gpt read' is not available on CMD_GPT_RENAME=n
- Prefix the {read,swap,rename} commands with one space for consistency
- Prefix the 'guid' commands with 'gpt' for consistency
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:
=> ### interrupt autoboot
=> gpt verify mmc 1
No partition list provided - only basic check
Verify GPT: success!
=> ### keep calling 'gpt verify mmc 1'
=> ### on 58th call, we are out of memory:
=> gpt verify mmc 1
alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
GPT: Failed to allocate memory for PTE
gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
Verify GPT: error!
This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().
With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.
[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions
Fixes: cef68bf904 ("gpt: part: Definition and declaration of GPT verification functions")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:
=> ### interrupt autoboot
=> gpt guid mmc 1
21200400-0804-0146-9dcc-a8c51255994f
success!
=> ### keep calling 'gpt guid mmc 1'
=> ### on 59th call, we are out of memory:
=> gpt guid mmc 1
alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
GPT: Failed to allocate memory for PTE
get_disk_guid: *** ERROR: Invalid GPT ***
alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
GPT: Failed to allocate memory for PTE
get_disk_guid: *** ERROR: Invalid Backup GPT ***
error!
After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b71 ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().
With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.
Fixes: 73d6d18b71 ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In case of a failure exit data may be passed to Exit() which in turn is
returned by StartImage().
Let the `bootefi` command print the exit data string in case of an error.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When printing an UEFI variable an error may arise while converting an
illegal hexadecimal value. In this case a buffer is leaked.
Close the memory leak. Provide an error message.
Reported-by: Coverity (CID 185830)
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
data.
When we use `efidebug boot add` we should convert the 5th argument from
UTF-8 to UTF-16 before putting it into the BootXXXX variable.
When printing boot variables with `efidebug boot dump` we should support
the OptionalData being arbitrary binary data. So let's dump the data as
hexadecimal values.
Here is an example session protocol:
=> efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
=> efidebug boot add 00a2 label2 scsi 0:1 doit2
=> efidebug boot dump
Boot00A0:
attributes: A-- (0x00000001)
label: label1
file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
data:
00000000: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00 m.y. .o.p.t.i.o.
00000010: 6e 00 00 00 n...
Boot00A1:
attributes: A-- (0x00000001)
label: label2
file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
data:
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Currently in do_efi_boot_dump(), we directly read EFI variables from
related environment variables. To accommodate alternative storage
backends, we should switch to using the UEFI API instead.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
UEFI variables should be installed using well-defined API.
Currently we don't support much, but the value of OsIndicationsSupported
will be updated once some features are added in the future.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Add comments. Rename a variable.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
CreateEvent() and CreateEventEx() should check that a notify function is
provided for either of EVT_NOTIFY_SIGNAL or EVT_NOTIFY_WAIT.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
------------------------
- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8
-----BEGIN PGP SIGNATURE-----
iQHDBAABCgAtFiEEiZClFGvhzbUNsmAvKMTY0yrV63cFAlzDBtoPHHNiYWJpY0Bk
ZW54LmRlAAoJECjE2NMq1et3UpQL/ipaUejQOOr00oOgUBQqt3JCPZ7KNu8ruih/
nIFUDrI8nP+4psaOhRp1sEPFJUxUjdIqODeAZD8zrlEi1pXNAgPWYrFRfbz54bzw
jLsqqMz1/djQseLydQTcqZTSz8Ys7o+8OfKH64fdsZn+y9no9tHBN5hz5qWdXexN
kbyykkg8TJC3eUyRZqKuULOqzDV9BAdASOXu7UTa04sEekLdVvS2+zkUdB6UVZTN
LOAzm+7xY8Tey1BZxLuZUJDpHzFEMvPvlbbQRrxeDn/feZJwNgIP6hGcMeVOwOIf
KEwFn/m/HI2JWS4taXb5aT+v3xmiQvyCC3jNW0XTf5rq02pbfgyPsVhGQIGyU2yY
Fj7zIN7hVCLJNBpctvXyuAd1MjOlGEPIrHNjRnIZjtr7/iA1AIRn7Hg4cGNCHw6V
5gdza3B/xFODN+Ts6O+UVIukI61MJ6mGGdNCueOnWDviNROOL82D7Jh02KfNNNxR
q+yPsHSpo6rC1MGXv4SOReZtgpng/w==
=CzWQ
-----END PGP SIGNATURE-----
Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx
Porting to DM and i.MX8
------------------------
- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8
To avoid a warning, we need to include the header defining
back_to_bootrom for us.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
After applying the series for debug_uart_init(), Travis-CI reports:
arch/arm/mach-rockchip/rk3399/rk3399.c:90:2: error: implicit declaration of function 'spl_gpio_set_pull' [-Werror=implicit-function-declaration]
spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 2), GPIO_PULL_NORMAL);
^~~~~~~~~~~~~~~~~
This is caused by a missing header-file include. Fix it.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
