No need for per-SoC adjustment for this parameter. It should be
determined by the slowest hardware. Currently, no board overrides
this CONFIG, so 3.2 sec is large enough. (If not, we can make it
even larger.)
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci.c | 6 ++
1 file changed,
If CONFIG_BLK is enabled, add_sdhci() is never called.
So, sdhci_reset() is not called, either. This is a problem for
my board as it needs the reset to start from a sane state.
Move the add_sdhci() call to sdhci_init(), which is visited
by both of the with/without CONFIG_BLK cases.
Signed-off-by
If CONFIG_BLK is enabled, add_sdhci() is never called. Move this
quirk handling to sdhci_setup_cfg(), which is now the central place
for hardware capability checks.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
If CONFIG_BLK is enabled, add_sdhci() is never called. Move this
quirk handling to sdhci_setup_cfg(), which is now the central place
for hardware capability checks.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/
Masahiro Yamada (6):
mmc: sdhci: move sdhci_reset() call to sdhci_init()
mmc: sdhci: move error message to more relevant place
mmc: sdhci: move broken voltage quirk handling to sdhci_setup_cfg()
mmc: sdhci: move SDMA capability check to sdhci_setup_cfg()
mmc: sdhci: drop CONFIG_ from C
"Hardware doesn't specify base clock frequency" may not be only the
error case of sdhci_setup_cfg(). It is better to print this where
the corresponding error is triggered.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(
This CONFIG is not configurable since it is not guarded by #ifndef.
Nobody has complained about that, so there is no need to keep it as
a CONFIG option.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdh
If CONFIG_BLK is enabled, add_sdhci() is never called.
So, sdhci_reset() is not called, either. This is a problem for
my board as it needs the reset to start from a sane state.
Move the add_sdhci() call to sdhci_init(), which is visited
by both of the with/without CONFIG_BLK cases.
Signed-off-by
Changes in v2:
- Adjust comment block
Masahiro Yamada (6):
mmc: sdhci: move sdhci_reset() call to sdhci_init()
mmc: sdhci: move error message to more relevant place
mmc: sdhci: move broken voltage quirk handling to sdhci_setup_cfg()
mmc: sdhci: move SDMA capability check to sdhci_setup
This CONFIG is not configurable since it is not guarded by #ifndef.
Nobody has complained about that, so there is no need to keep it as
a CONFIG option.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
If CONFIG_BLK is enabled, add_sdhci() is never called. Move this
quirk handling to sdhci_setup_cfg(), which is now the central place
for hardware capability checks.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/sdhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deleti
No need for per-SoC adjustment for this parameter. It should be
determined by the slowest hardware. Currently, no board overrides
this CONFIG, so 3.2 sec is large enough. (If not, we can make it
even larger.)
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Adjust comment block
drivers
If CONFIG_BLK is enabled, add_sdhci() is never called. Move this
quirk handling to sdhci_setup_cfg(), which is now the central place
for hardware capability checks.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/sdhci.c | 19 ---
1 file changed, 8 insertion
"Hardware doesn't specify base clock frequency" may not be only the
error case of sdhci_setup_cfg(). It is better to print this where
the corresponding error is triggered.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/sdhci.c | 15 +--
1 file changed, 9 insert
Sometimes boards may need more time to become stable network connection
due to several reasons:
- phy speed
- link-partner (switch)
Therefore we increase the retry-count to 10 for making sure that network
connection works always.
Signed-off-by: Hannes Schmelzer
---
include/configs/bur_cfg_co
>From: Marek Vasut [mailto:ma...@denx.de]
>On 08/24/2016 12:39 PM, Sriram Dash wrote:
>> Currently the controller by default enables the Receive Detect feature
>> in P3 mode in USB 3.0 PHY. However, USB 3.0 PHY does not reliably
>> support receive detection in P3 mode.
>> Enabling the USB3 controll
The eMMC on sLD3 is assigned with dedicated pins (only multiplexed
with GPIO), so it shouldn't hurt to enable eMMC on SPL all the time.
Signed-off-by: Masahiro Yamada
---
arch/arm/dts/uniphier-ph1-sld3-ref.dts | 8
arch/arm/dts/uniphier-ph1-sld3.dtsi| 1 +
2 files changed, 9 insert
Commit 76c52ce29fd7 ("ARM: uniphier: increase CONFIG_SYS_MALLOC_F_LEN
to bind all nodes") missed to increase this config for sLD3.
This change is needed to add "u-boot,dm-pre-reloc" to some nodes;
more devices are bound, more malloc memory is needed.
Signed-off-by: Masahiro Yamada
---
configs/
The revision of the original support card (rev 3.5, rev 3.6) fits in
the 8 bit width revision register. When it was extended in a weird
way, it was versioned in the format of "3.6.x" (where it should have
been "3.7", of course). What is worse, only the sub-level version
"6.x" was recorded in the
Masahiro Yamada (3):
ARM: uniphier: display revision of Micro Support Card 3.6.x kindly
ARM: uniphier: increase CONFIG_SYS_MALLOC_F_LEN for sLD3
ARM: dts: uniphier: add u-boot,dm-pre-reloc to use eMMC boot on sLD3
arch/arm/dts/uniphier-ph1-sld3-ref.dts | 8
arch/arm/dts/uni
Le mercredi 24 août 2016 à 16:52 -0700, Steve Rae a écrit :
> So, I wanted to:
> (1) simplify this to not depend on any env variable, and not depend on
> the CONFIG_BOOTCOMMAND (can this be accidentally wiped out in the
> environment?)
I'm not sure it really simplifies much. fastboot is a boot com
On Wednesday 24 August 2016 07:40 PM, Hannes Schmelzer wrote:
> On 08/24/2016 02:21 PM, Hannes Schmelzer wrote:
>> On 08/24/2016 01:12 PM, Vignesh R wrote:
>>>
>>> On Wednesday 24 August 2016 04:21 PM, Hannes Schmelzer wrote:
On 08/24/2016 12:35 PM, Vignesh R wrote:
[...]
>>> AFAIU, saveen
This introduces two board defconfig files for generating EFI 32-bit
and 64-bit payloads, to run on QEMU x86 target.
With these in place, hopefully buildman will catch any build error
with EFI payload support on x86.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v2:
- Add mai
There are lots of warnings when building EFI 64-bit payload.
include/asm-generic/bitops/__fls.h:17:2:
warning: left shift count >= width of type
if (!(word & (~0ul << 32))) {
^
In fact, U-Boot itself as EFI payload is running in 32-bit mode.
So BITS_PER_LONG need
Since commit 73c5c39 "Makefile: Drop unnecessary -dtb suffixes",
EFI payload does not build anymore. This fixes the build.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v2: None
include/efi.h | 2 +-
lib/efi/efi_stub.c | 6 +++---
2 files changed, 4 insertions(+), 4 del
Hi Fabio,
I just tried 'ums' on mx7d sabresd with latest u-boot-imx codes. It works
well on my board. I don't see your issue. My SD card has a FAT partition. I can
access it from my host after running the "ums 0 mmc 0".
Best regards,
Ye Li
-Original Message-
From: U-Boot [mailto:u-bo
On 08/25/2016 10:39 AM, Vignesh R wrote:
On Wednesday 24 August 2016 07:40 PM, Hannes Schmelzer wrote:
On 08/24/2016 02:21 PM, Hannes Schmelzer wrote:
On 08/24/2016 01:12 PM, Vignesh R wrote:
On Wednesday 24 August 2016 04:21 PM, Hannes Schmelzer wrote:
On 08/24/2016 12:35 PM, Vignesh R wrot
This is very likely to be necessary for normal use cases.
Set its default to 'y' for shorter defconfig files.
Signed-off-by: Masahiro Yamada
---
configs/uniphier_ld11_defconfig | 1 -
configs/uniphier_ld20_defconfig | 1 -
configs/uniphier_ld4_sld8_defconfig | 1 -
configs/uniphier_p
On Thursday 25 August 2016 03:02 PM, Hannes Schmelzer wrote:
> On 08/25/2016 10:39 AM, Vignesh R wrote:
>>
>> On Wednesday 24 August 2016 07:40 PM, Hannes Schmelzer wrote:
>>> On 08/24/2016 02:21 PM, Hannes Schmelzer wrote:
On 08/24/2016 01:12 PM, Vignesh R wrote:
> On Wednesday 24 Augus
The CONFIG_SYS_CACHELINE_SIZE is not defined for
some of the platforms due to which buildman iill
fail for these platforms.
Fixing this issue in generic way in Kconfig by
selecting cacheline size based on arm processor type.
This patch is based on linux kernel commit 5637a126
Signed-off-by: Ravi
(Added Tom to Cc)
On 17.08.2016 09:19, Wenyou Yang wrote:
From: Cyrille Pitchen
This patch fixes the "sf probe" command. The very first SPI flash probe
passes, for instance when u-boot tries to read its environment settings
from a (Q)SPI memory but next "sf probe" commands fail because the fla
check_cache_range() warns that the top boundaries are not properly
aligned when flushing or invalidating the buffers and make these
operations fail.
This gets rid of the warnings:
CACHE: Misaligned operation at range ...
Signed-off-by: Stefan Roese
Cc: Joe Hershberger
---
drivers/net/mvneta.c
This supports the system reset via PSCI for ARMv7 SoCs.
Because the system reset is not supported on PSCI 0.1, let's define
CONFIG_ARMV7_PSCI_1_0. (it is supported since PSCI 0.2, but there
is no CONFIG to enable it in U-Boot for now.)
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/
Clear ecc ON bit while sending read command as all types
of read command(like reading spare) doesnt need ECC to be
enabled. It has been anyway taken care in other places
whereever required using arasan_nand_enable_ecc().
Signed-off-by: Siva Durga Prasad Paladugu
---
drivers/mtd/nand/arasan_nfc.c
On 23 August 2016 at 22:02, Kever Yang wrote:
> From: MengDongyang
>
> This patch add support for rockchip dwc3 controller, which corresponding
> to the two type-C port on rk3399 evb.
> Only support usb2.0 currently for we have not enable the usb3.0 phy
> driver and PD(fusb302) driver.
>
> Signed
Hi Masshiro,
On 24 August 2016 at 19:40, Masahiro Yamada
wrote:
> 2016-08-25 1:51 GMT+09:00 Simon Glass :
>> The moveconfig tool is quite clever and generally produces results that
>> are suitable for sending as a patch without further work. The main required
>> step is to add the changes to a co
Hi Masahiro,
On 24 August 2016 at 19:45, Masahiro Yamada
wrote:
> Hi Simon,
>
>
> 2016-08-25 1:51 GMT+09:00 Simon Glass :
>> At present it is not easy to use moveconfig from a script since it asks
>> for user input a few times. Add a -y option to skip this and assume that
>> 'y' was entered.
>
>
Hi Masahiro,
On 24 August 2016 at 19:34, Masahiro Yamada
wrote:
> 2016-08-25 1:52 GMT+09:00 Simon Glass :
>> Move this option to Kconfig and tidy up existing uses.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> configs/chromebook_jerry_defconfig | 1 +
>> configs/evb-rk3288_defconfig | 1 +
Hi Masahiro,
On 24 August 2016 at 19:28, Masahiro Yamada
wrote:
> 2016-08-25 1:51 GMT+09:00 Simon Glass :
>> There are a lot of SPL options in U-Boot to enable various features and
>> drivers. Currently these do not use Kconfig. Add them to Kconfig along
>> with suitable help, and drop them from
Hi Heiko,
On 24 August 2016 at 22:30, Heiko Schocher wrote:
> Hello Simon,
>
>
> Am 24.08.2016 um 18:51 schrieb Simon Glass:
>>
>> This series moves all the CONFIG_SPL_..._SUPPORT options to Kconfig and
>> fixes up existing boards to continue to build.
>
>>
>>
>> It also adds a few small but usef
Hi Stephen,
On 24 August 2016 at 10:24, Stephen Warren wrote:
> On 08/24/2016 08:44 AM, Simon Glass wrote:
>>
>> New CONFIG options should be added via Kconfig. To help prevent new ad-hoc
>> CONFIGs from being added, give a build error when these are detected.
>
>
> Acked-by: Stephen Warren
> Te
Hi Sandy,
On 24 August 2016 at 15:00, Sandy Patterson wrote:
>
> On Wed, Aug 24, 2016 at 9:27 AM, Sandy Patterson
> wrote:
>>
>>
>> On Fri, Aug 12, 2016 at 8:59 PM, Sandy Patterson
>> wrote:
>>>
>>> CONFIG_SPL_MMC_SUPPORT is used pretty much for every board except jerry,
>>> so we can refactor
Hi Stephen,
On 24 August 2016 at 12:16, Stephen Warren wrote:
> On 08/24/2016 10:51 AM, Simon Glass wrote:
>>
>> At present TPL uses the same options as SPL support. In a few cases the
>> board
>> config enables or disables the SPL options depending on whether
>> CONFIG_TPL_BUILD is defined.
>>
>
Hi Masahiro,
On 24 August 2016 at 20:20, Masahiro Yamada
wrote:
> 2016-08-25 1:51 GMT+09:00 Simon Glass :
>> At present TPL uses the same options as SPL support. In a few cases the board
>> config enables or disables the SPL options depending on whether
>> CONFIG_TPL_BUILD is defined.
>>
>> With
Hi,
On 24 August 2016 at 13:30, Tom Rini wrote:
> On Wed, Aug 24, 2016 at 08:01:54PM +0200, Maxime Ripard wrote:
>> Hi Simon,
>>
>> On Wed, Aug 24, 2016 at 10:52:03AM -0600, Simon Glass wrote:
>> > Move this option to Kconfig and tidy up existing uses.
>> >
>> > Signed-off-by: Simon Glass
>> > -
Hi Ye Li,
On Thu, Aug 25, 2016 at 3:25 AM, Ye Li wrote:
> Hi Fabio,
>
>I just tried 'ums' on mx7d sabresd with latest u-boot-imx codes. It works
> well on my board. I don't see your issue. My SD card has a FAT partition. I
> can access it from my host after running the "ums 0 mmc 0".
Thank
Patch f8a10ed1 [i2c: mvtwsi: Make address length variable] accidentally
inverted the sequence of address bytes sent to the I2C device. This
patch corrects this by sending the highest byte first and the lowest
byte last again.
Tested on theadorable Armada-XP board.
Signed-off-by: Stefan Roese
Cc:
On Thu, Aug 25, 2016 at 03:55:16PM +0530, Ravi Babu wrote:
> The CONFIG_SYS_CACHELINE_SIZE is not defined for
> some of the platforms due to which buildman iill
> fail for these platforms.
>
> Fixing this issue in generic way in Kconfig by
> selecting cacheline size based on arm processor type.
>
On Sun, Aug 21, 2016 at 8:30 AM, Tom Rini wrote:
> This series moves the CONFIG_SYS_CACHELINE_SIZE. First, in nearly all cases
> we
> are mirroring the values used by the Linux Kernel here. Also, so long as (and
> in this case, it is true) we implement flushes in hunks that are no larger
> tha
On Wed, Aug 24, 2016 at 11:51 AM, Simon Glass wrote:
> This series moves all the CONFIG_SPL_..._SUPPORT options to Kconfig and
> fixes up existing boards to continue to build.
>
Tested on DM3730 (OMAP3630) and it seems to work.
Tested by Adam Ford
> It also adds a few small but useful features
Use a board-specific board_sat_r_get() function to configure the board
for PCIe 2.0 capability (e.g. 5GB/s link speed). Otherwise the default
of 2.5GB/s will be established.
Signed-off-by: Stefan Roese
---
board/theadorable/theadorable.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/
Hi Tom,
> On Thu, Aug 25, 2016 at 03:55:16PM +0530, Ravi Babu wrote:
>
> > The CONFIG_SYS_CACHELINE_SIZE is not defined for
> > some of the platforms due to which buildman iill
> > fail for these platforms.
> >
> > Fixing this issue in generic way in Kconfig by
> > selecting cacheline size based
Hi,
Here is a patch series that enables
USB DFU support on AM57x GP EVM.
Thanks,
Sekhar
Sekhar Nori (3):
configs: dra7xx: get rid of duplicate #define
board: ti: am57xx-evm: fix build warnings
ARM: am57xx_evm: enable DFU support
board/ti/am57xx/board.c | 20 --
co
CONFIG_DFU_RAM is repeated twice in dra7xx_evm.h
file. Remove the duplicate.
Signed-off-by: Sekhar Nori
---
include/configs/dra7xx_evm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index b66949f4155b..4ea993d3f5db 100644
--- a/in
USB1 is not used on AM57xx GP EVM in device mode.
Enabling DWC3 USB support for AM57xx EVM gives
the following warnings:
CC board/ti/am57xx/board.o
../board/ti/am57xx/board.c:448:27: warning: 'usb_otg_ss1' defined but not used
[-Wunused-variable]
static struct dwc3_device usb_otg_ss1 = {
AM57xx GP EVM has USB2 port of the SoC exposed as
USB client port.
It is useful to be able to use this port for USB
DFU downloads.
Enable USB DFU support. Tested on AM57x GP EVM Rev
A3 using DFU to download to connected SD card, on
board eMMC and to the RAM.
Also tested to make sure connected ma
On Mon, Aug 22, 2016 at 7:08 AM, Tom Rini wrote:
> On Mon, Aug 22, 2016 at 10:13:24AM +0530, Lokesh Vutla wrote:
>>
>>
>> On Sunday 21 August 2016 06:15 PM, Tom Rini wrote:
>> > On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Ford wrote:
>> >
>> >> Using Git bisect, it appears to me that
>> >> a78c
Hi Gary,
On Wed, Aug 24, 2016 at 7:17 AM, Gary Bisson
wrote:
>> I agree with the comment in your cover letter, that this belongs
>> in a common place.
>
> Does Fabio agree with that? Also, should we differenciate the options
What about placing the options below:
+/* Secure boot (HAB) support *
On 08/24/2016 07:25 PM, Marek Vasut wrote:
> On 08/24/2016 07:41 PM, york sun wrote:
>> Ha! I misunderstood. I read this
>> "Enable burst length set, and define it as 4/8/16" and somehow my brain
>> interpreted it as a date. I must be traveling too much recently. :)
>
> And now you're even top-post
On Thu, Aug 25, 2016 at 6:19 AM, Stefan Roese wrote:
> check_cache_range() warns that the top boundaries are not properly
> aligned when flushing or invalidating the buffers and make these
> operations fail.
>
> This gets rid of the warnings:
> CACHE: Misaligned operation at range ...
>
> Signed-o
Selecting the proper options to enable the build of the HAB tools.
Note, this support is disabled by default, one will have to select
the SECURE_BOOT configuration through menuconfig to enable it.
See doc/README.mxc_hab for more details.
Signed-off-by: Gary Bisson
---
include/configs/mx6_commo
Hi all,
This patch is actually a follow-up of the one from Peng Fan:
https://patchwork.ozlabs.org/patch/616568/
As he mentioned at the time, the current i.MX source code doesn't allow
to build a U-Boot that supports encryption features (dek commands).
The reason is that the commit 2bb01482 did so
From: Peng Fan
This commit "2bb014820c49a63902103bac710bc86b5772e843"
do some clean up to use the code in lib/time.c.
But usec2ticks is still being used by security related job ring code.
Bring back the function to avoid build break when CONFIG_FSL_CAAM
is defined.
The computation logic has been
So the option can easily be selected through menuconfig.
Signed-off-by: Gary Bisson
---
arch/arm/imx-common/Kconfig | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/imx-common/Kconfig b/arch/arm/imx-common/Kconfig
index 1b7da5a..1a09a2c 100644
--- a/arch/arm/imx-common/Kconfig
Declaring a CSF section makes the imximage tool increase the size of
data to be loaded by the BootROM and also adds a pointer to that CSF
section in the IVT header to the BootROM can check the signature.
Signed-off-by: Gary Bisson
---
board/boundary/nitrogen6x/nitrogen6dl.cfg | 3 +++
board/bo
Selecting the proper options to enable the build of the HAB tools.
Note, this support is disabled by default, one will have to select
the SECURE_BOOT configuration through menuconfig to enable it.
See doc/README.mxc_hab for more details.
Also remove duplicate options from board config headers.
When waiting for input in CYGACC_COMM_IF_GETC_TIMEOUT we delay 2
seconds by incrementing and checking a counter variable every 20
uSeconds. The overhead in the loop calling tstc() millions of times
causes the timeout to be closer to 20 seconds. Delay longer per iteration
to reduce overhead and brin
When the inputed usec is too large we process it in chunks of
CONFIG_WD_PERIOD size. Subtracting this from usec until usec is
zero. If usec is not an integer multiple of CONFIG_WD_PERIOD it
will underflow and the condition will not become false when it
should. Fix this logic.
Signed-off-by: Andrew
When booting a mainline kernel on warp7 we have:
- mmc0: Wifi SDIO chip
- mmc1: eMMC
, so point CONFIG_MMCROOT to use mmcblk1 instead.
Signed-off-by: Fabio Estevam
---
include/configs/warp7.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/warp7.h b/include/c
When waiting for input in CYGACC_COMM_IF_GETC_TIMEOUT we delay 2
seconds by incrementing and checking a counter variable every 20
uSeconds. The overhead in the loop calling tstc() millions of times
causes the timeout to be closer to 20 seconds. Delay longer per iteration
to reduce overhead and brin
On 8/25/2016 11:40 AM, Andrew F. Davis wrote:
> When the inputed usec is too large we process it in chunks of
> CONFIG_WD_PERIOD size. Subtracting this from usec until usec is
> zero. If usec is not an integer multiple of CONFIG_WD_PERIOD it
> will underflow and the condition will not become false
On 08/25/2016 02:02 PM, Troy Kisky wrote:
> On 8/25/2016 11:40 AM, Andrew F. Davis wrote:
>> When the inputed usec is too large we process it in chunks of
>> CONFIG_WD_PERIOD size. Subtracting this from usec until usec is
>> zero. If usec is not an integer multiple of CONFIG_WD_PERIOD it
>> will un
On Thu, Aug 25, 2016 at 3:27 PM, Fabio Estevam wrote:
> When booting a mainline kernel on warp7 we have:
> - mmc0: Wifi SDIO chip
> - mmc1: eMMC
>
> , so point CONFIG_MMCROOT to use mmcblk1 instead.
>
> Signed-off-by: Fabio Estevam
As far as I know, the sold WaRP7 boards are shipped with the NXP
Hi Otavio,
On Thu, Aug 25, 2016 at 5:13 PM, Otavio Salvador
wrote:
> On Thu, Aug 25, 2016 at 3:27 PM, Fabio Estevam wrote:
>> When booting a mainline kernel on warp7 we have:
>> - mmc0: Wifi SDIO chip
>> - mmc1: eMMC
>>
>> , so point CONFIG_MMCROOT to use mmcblk1 instead.
>>
>> Signed-off-by: Fa
Jagan,
Are you planning on taking this in via the SPI repo, or can I take it in to
Tegra?
Tom
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Saturday, August 20, 2016 7:17 PM
> To: Simon Glass
> Cc: U-Boot Mailing List ; Jagan Teki
> ; Tom Warren ; S
On Thu, Aug 25, 2016 at 5:26 PM, Fabio Estevam wrote:
> On Thu, Aug 25, 2016 at 5:13 PM, Otavio Salvador
> wrote:
>> On Thu, Aug 25, 2016 at 3:27 PM, Fabio Estevam wrote:
>>> When booting a mainline kernel on warp7 we have:
>>> - mmc0: Wifi SDIO chip
>>> - mmc1: eMMC
>>>
>>> , so point CONFIG_MM
From: Fabio Estevam
NXP kernel expects to boot in secure mode, so introduce
warp7_secure_defconfig target which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT.
Signed-off-by: Fabio Estevam
---
configs/warp7_secure_defconfig | 36
1 file changed, 36 insertions(+)
c
From: Fabio Estevam
The rootfs appears at mmcblk2 in the NXP kernel and at mmcblk1 in mainline
kernel.
Load the correct mmcblk device depending on the selection of the
CONFIG_ARMV7_BOOT_SEC_DEFAULT variable.
CONFIG_ARMV7_BOOT_SEC_DEFAULT is selected in warp7_secure_defconfig, which
is used to b
From: Fabio Estevam
warp7 has two targets:
- warp7_defconfig: boots in non-secure mode
- warp7_secure_defconfig: boots in secure mode
Print the mode that is being used to help users to easily identify
which target is running on the board.
Signed-off-by: Fabio Estevam
---
board/warp7/
On Thu, Aug 25, 2016 at 5:56 PM, Otavio Salvador
wrote:
> Well ...
>
> warp7: Select secure boot
>
> In order to boot NXP 4.1.15 we need to boot in secure mode.
>
> So enable the variable CONFIG_ARMV7_BOOT_SEC_DEFAULT by default.
>
> Signed-off-by: Breno Lima
>
> From Breno, sent to the mailing
On Thu, Aug 25, 2016 at 5:57 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> NXP kernel expects to boot in secure mode, so introduce
> warp7_secure_defconfig target which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT.
>
> Signed-off-by: Fabio Estevam
Breno has sent the patch to include this on the m
On Thu, Aug 25, 2016 at 6:01 PM, Fabio Estevam wrote:
> On Thu, Aug 25, 2016 at 5:56 PM, Otavio Salvador
> wrote:
...
>> Someone using mainline kernel is expected to know how to set mmcroot
>> variable or so. I would not include this patch at all.
>
> This would be a bad customer experience. Much
Currently U-Boot proper has Kconfig options that enable the generation
of U-Boot binaries that are capable of being booted from the selected
boot media type. The same set of generation targets for SPL are assumed
with various methods and config header hackery. On some platforms the
options for SPL,
Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes.
For AM33xx devices additional image types are needed for
various SPL boot modes as the ROM checks for the name of
the boot mode in the fi
Like OMAP54xx and AM43xx family SoCs, AM33xx based SoCs have high
security enabled models. Allow AM33xx devices to be built with
HS Device Type Support.
Signed-off-by: Andrew F. Davis
---
arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/a
Add a new defconfig file for the AM335x High Security EVM. This config
is specific for the case of SD card booting, we the boot types to be
seperate defconfigs as some options change depending on boot type, in
addition this allows us to trim the SPL size as we only need to support
one boot media.
Authentication of images in Falcon Mode is not supported. Do not enable
SPL_OS_BOOT when TI_SECURE_DEVICE is enabled. This prevents attempting
to directly load kernel images which will fail, for security reasons,
on HS devices, the board is locked if a non-authenticatable image load
is attempted, s
This config option seems to be unused and is probably vestigial.
Remove it.
Signed-off-by: Andrew F. Davis
---
include/configs/am335x_evm.h | 2 --
include/configs/am335x_shc.h | 2 --
include/configs/am335x_sl50.h | 2 --
include/configs/bav335x.h | 2 --
4 files changed, 8 deletions(-)
Hello all,
I've recently been tasked with enabling authenticated boot for AM33xx based
devices. This work is similar to what has already been done for the AM43xx
and AM57xx SoCs and leverages much of the infrastructure from them.
The big difference here is the size of SRAM available on AM33xx bei
The SPL load address changes based on boot time in HS devices,
ISW_ENTRY_ADDR is used to set this address for AM43xx based SoCs
for similar reasons. Add this same logic for AM33xx devices.
Signed-off-by: Andrew F. Davis
---
include/configs/ti_am335x_common.h | 2 +-
1 file changed, 1 insertion(+
Add a section describing the additional boot types used on AM33xx
secure devices.
Signed-off-by: Andrew F. Davis
---
doc/README.ti-secure | 32
1 file changed, 32 insertions(+)
diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 54c996d..9b0fbf9 10064
The config option AM33XX is used in several boards and should be
defined as a stand-alone option for this SOC. We break this out
from target boards that use this SoC and common headers then enable
AM33XX on in all the boards that used these targets to eliminate any
functional change with this patch
Before the addition of SPL boot media type Kconfig options there was no
way to determine what boot media the SPL would be booted from, so
it was assumed that if the SPL could load U-Boot proper via SPI then
the SPL itself would probably also be loaded from SPI.
Use the new SPL_SPI_BOOT option to e
When CONFIG_FIT_IMAGE_POST_PROCESS or CONFIG_SPL_FIT_IMAGE_POST_PROCESS
is enabled board_fit_image_post_process will be called, add this
function to am33xx boards when CONFIG_TI_SECURE_DEVICE is set to
verify the loaded image.
Signed-off-by: Andrew F. Davis
---
board/ti/am335x/board.c | 8 ++
On Thu, Aug 25, 2016 at 06:04:47AM -0600, Simon Glass wrote:
> Hi,
>
> On 24 August 2016 at 13:30, Tom Rini wrote:
> > On Wed, Aug 24, 2016 at 08:01:54PM +0200, Maxime Ripard wrote:
> >> Hi Simon,
> >>
> >> On Wed, Aug 24, 2016 at 10:52:03AM -0600, Simon Glass wrote:
> >> > Move this option to Kc
Jens Kuske wrote:
> The H3 PLL5 used for DRAM barely manages to lock to the required
> frequency before DRAM controller starts, sometimes leading to wrong
> delay-line calibration results.
> This patch changes the PLL tuning parameters to the same values as
> boot0 used, which speeds up the lo
Hi Otavio,
On Thu, Aug 25, 2016 at 6:02 PM, Otavio Salvador
wrote:
> Breno has sent the patch to include this on the main config; being the
Breno's patch has not been submitted to the list. It has only being
applied into u-boot-fslc.
> official kernel using this enabled I think it makes sense
Hi Otavio,
On Thu, Aug 25, 2016 at 6:06 PM, Otavio Salvador
wrote:
> Mangling the mmcroot depending of secure boot is hidden things from
> user, in my point of view.
Yes, I agree.
It seems like a more elegant solution is to use UUID to specify the
rootfs location.
Will prepare a v2.
Thanks
_
On Thu, Aug 25, 2016 at 11:02:04AM -0500, Adam Ford wrote:
> On Mon, Aug 22, 2016 at 7:08 AM, Tom Rini wrote:
> > On Mon, Aug 22, 2016 at 10:13:24AM +0530, Lokesh Vutla wrote:
> >>
> >>
> >> On Sunday 21 August 2016 06:15 PM, Tom Rini wrote:
> >> > On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Fo
Tom,
Please pull u-boot-tegra/master into U-Boot/master. Thanks!
All Tegra builds are OK, and Stephen's automated test system reports that
all tests pass.
The following changes since commit 46fe9eb08812cc27a0d5cd97d97373c14d578fe9:
Merge branch 'master' of git://git.denx.de/u-boot-net (2016-0
1 - 100 of 123 matches
Mail list logo
