On 01/06/2018 10:09 PM, Jason Rush wrote:
> On 1/6/2018 1:29 PM, Marek Vasut wrote:
>> On 01/06/2018 07:46 PM, Jason Rush wrote:
>>> On 1/6/2018 9:42 AM, Marek Vasut wrote:
>
>
>
>>> There was a minor upstream change to one of the files since I submitted v4
>>> of my
>>> cadence device-tree pat
On 01/06/2018 07:17 PM, Jason Rush wrote:
> Adopt the Linux DT bindings. This also fixes an issue
> with the indaddrtrig register on the Cadence QSPI
> device being programmed with the wrong value for the
> socfpga arch.
>
> Tested on TI K2G platform:
> Tested-by: Vignesh R
>
> Tested on a socfp
I'd like to enable the CANbus on a Beagle Bone Black (on Fedora ...
which doesn't do "cape manager").
The crux is a fdt command in u-boot :
fdt set d_can1 status okay
Is there a way to do this in extlinux.conf ?
I didn't see a way (in uboot 2017.09), so I wrote a uEnv.txt script
(see attached).
Best Regards!
Anson Huang
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018-01-07 6:48 AM
> To: Anson Huang
> Cc: Stefano Babic ; Fabio Estevam
> ; Albert ARIBAUD ;
> Christian Gmeiner ; Peng Fan
> ; U-Boot-Denx
> Subject: Re: [U-Boot] [PATCH V2] imx:
Best Regards!
Anson Huang
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018-01-07 12:05 AM
> To: Anson Huang
> Cc: Stefano Babic ; Fabio Estevam
> ; Albert ARIBAUD ;
> Troy Kisky ; Christian Gmeiner
> ; Peng Fan ; U-Boot-
> Denx
> Subject: Re: [U-Boot
Best Regards!
Anson Huang
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018-01-07 6:48 AM
> To: Anson Huang
> Cc: Stefano Babic ; Fabio Estevam
> ; Albert ARIBAUD ;
> Christian Gmeiner ; Peng Fan
> ; U-Boot-Denx
> Subject: Re: [U-Boot] [PATCH V2] imx:
Use PSCI 1.0 instead of 0.1 to support more power
management feature like system reset, power off etc..
Signed-off-by: Anson Huang
---
include/configs/mx7_common.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h
index 16e4d95..786
Add i.MX7 PSCI system reset support, linux
kernel can use "reboot" command to reset
system even wdog driver is disabled in kernel.
Signed-off-by: Anson Huang
---
arch/arm/mach-imx/mx7/psci-mx7.c | 15 ++-
arch/arm/mach-imx/mx7/psci.S | 7 +++
2 files changed, 21 insertions(+
Add i.MX7 PSCI system power off support, linux
kernel can use "poweroff" command to power off
system via SNVS, PMIC power will be disabled.
Signed-off-by: Anson Huang
---
arch/arm/mach-imx/mx7/psci-mx7.c | 18 ++
arch/arm/mach-imx/mx7/psci.S | 7 +++
2 files changed, 25
Hi Lukasz,
On 3 January 2018 at 14:08, Lukasz Majewski wrote:
> Hi Anand,
>
>> Hi Lukasz
>>
>> On 3 January 2018 at 03:47, Lukasz Majewski wrote:
>> > On Wed, 3 Jan 2018 01:54:57 +0530
>> > Anand Moon wrote:
>> >
>> >> Hi All,
>> >>
>> >> I would like to get the s2mps11 regulator binding for u-
From: Drew Moseley
CONFIG_OF_EMBED in particular is needed to allow the Raspberry Pi
firmware to pass the DTB to U-Boot and on to the kernel.
Signed-off-by: Drew Moseley
---
configs/rpi_0_w_defconfig | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configs/rpi_0_w_defconfig b/configs
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> This is needed for reading registers that are not aligned to 32 bits.
>
> Signed-off-by: Álvaro Fernández Rojas
> ---
> v6: Introduce changes suggested by Jagan Teki:
> - Swit
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> This driver is a simplified version of linux/drivers/spi/spi-bcm63xx.c
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Simon Glass
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
___
U-Boot mailing
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
___
U-Boot mailing
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
Reviewed-by: Jagan Teki
___
U-Boot mailing list
U
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
___
U-Boot mailing
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> This driver manages the low speed SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
___
U-Boo
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> It's a Spansion (s25fl064a) 8 MB SPI flash.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
___
U-Boot mailing list
U-Boot@list
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
wrote:
> It's a Winbond (w25x32) 4 MB SPI flash.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Daniel Schwierzeck
> ---
Reviewed-by: Jagan Teki
___
U-Boot mailing list
U-Boot@lists.de
The blob_encap and blob_decap functions were not flushing the dcache
before passing data to CAAM/DMA and not invalidating the dcache when
getting data back.
Therefore, blob encapsulation and decapsulation failed with errors like
the following due to data cache incoherency:
"4006: DECO: desc idx
The category of memory allocated for an EFI image should depend on
its type (application, bootime service driver, runtime service driver).
Our helloworld.efi built on arm64 has an illegal image type. Treat it
like an EFI application.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_ima
On Sun, Jan 07, 2018 at 08:26:29PM +0100, Clemens Gruber wrote:
> The blob_encap and blob_decap functions were not flushing the dcache
> before passing data to CAAM/DMA and not invalidating the dcache when
> getting data back.
> Therefore, blob encapsulation and decapsulation failed with errors li
On Sun, Jan 7, 2018 at 4:04 AM, Ken Harris wrote:
> I'd like to enable the CANbus on a Beagle Bone Black (on Fedora ...
> which doesn't do "cape manager").
Well Fedora doesn't so stuff that's not upstream, and while there's
been a bunch of discussion there's been no decision upstream of how
best
On Wed, Jan 3, 2018 at 9:54 PM, Tom Rini wrote:
> We only need to compile and link these files when building for full
> U-Boot. Move them to under cmd/x86/ to make sure they aren't linked in
> and undiscarded due to u_boot_list_2_cmd_* being included).
>
> Cc: Bin Meng
> Signed-off-by: Tom Rini
On Wed, Jan 3, 2018 at 11:23 PM, Heinrich Schuchardt wrote:
> Allow to override CONFIG_BOOTCOMMAND in .config.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/configs/x86-common.h | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Bin Meng
_
The DB-88F6820-AMC connects ethernet@34000 and ethernet@7 which are
labeled as eth2 and eth0 in armada-38x.dts. The ethernet@3 (eth1) is
not used on the AMC board.
This eliminates the following bootup message
Device 'ethernet@7': seq 0 is in use by 'ethernet@34000'
Signed-off-by: C
On Fri, Jan 5, 2018 at 12:40 AM, Andy Shevchenko
wrote:
> The recent commit 03c4749dd6c7
> ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
> in the Linux kernel reveals the issue we have in ACPI tables here,
> i.e. we must use hardware numbers for GPIO resources and,
> taki
On Fri, Jan 5, 2018 at 12:40 AM, Andy Shevchenko
wrote:
> As defined on reference board followed by Intel Edison a Bluetooth
> device is attached to HSU0, i.e. PCI :04.1.
>
> Describe it in ACPI accordingly.
>
> Note, we use BCM2E95 ID here as one most suitable for such device based
> on the d
Hi Heinrich,
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> Add color coding to output:
> test sectionblue
> success green
> errors red
> todoyellow
> summary white
> others light gray
>
> Signed-off-by: Heinrich Schuchardt
> ---
> i
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> Replace list_for_each_safe() and list_entry() by
> list_for_each_entry_safe().
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_boottime.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
Reviewed-by: Si
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> CloseProtocol cannot be called without agent handle.
>
> There is no need to close the device path protocol if
> it has been opened without agent handle.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_selftest/efi_selftest_device
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> Add a list of open protocol infos to each protocol of a handle.
>
> Provide helper functions to access the list items.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_loader.h | 15 ++-
> lib/efi_loader/ef
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> efi_open_protocol_information provides the agent and controller
> handles as well as the attributes and open count of an protocol
> on a handle.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_boottime.c | 41 ++
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> efi_open_protocol has to keep track of opened protocols.
>
> OpenProtocol enters the agent and controller handle
> information into this list.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_boottime.c | 107
>
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> efi_open_protocol and efi_close_protocol have to keep track of
> opened protocols.
>
> Check if the protocol was opened for the same agent and
> controller.
>
> Remove all open protocol information for this pair.
>
> Signed-off-by: Heinric
Hi Heinrick,
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> Implement the ConnectController boot service.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_api.h | 22 ++
> include/efi_loader.h | 2 +
> lib/efi_loader/efi_boottime.c | 178
>
Hi Heinrich,
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> Unfortunately we need a forward declaration because both
> OpenProtocol and CloseProtocol have to call DisconnectController.
> And DisconnectController calls both OpenProtcol and CloseProtocol.
>
> Signed-off-by: Heinrich Sch
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> When a device path protocol is installed write the device
> path to the console in debug mode.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_boottime.c | 7 +++
> 1 file changed, 7 insertions(+)
Reviewed-by: Simo
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> This unit test checks the following protocol services:
> ConnectController, DisconnectController,
> InstallProtocol, UninstallProtocol,
> OpenProtocol, CloseProtcol, OpenProtocolInformation
>
> Signed-off-by: Heinrich Schuchardt
> ---
>
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> Handles should be passed as efi_handle_t and not as void *.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_api.h | 6 --
> lib/efi_loader/efi_boottime.c | 7 ---
> 2 files changed, 8 insertions(+), 5 delet
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> The installation of UninstallProtocol is functional now.
> So we do not expect errors when calling it.
>
> Call UninstallProtocol with correct level of indirection
> for parameter handle.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> li
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> The UninstallProtocol boot service should first try to
> disconnect controllers that have been connected with
> EFI_OPEN_PROTOCOL_BY_DRIVER.
>
> If the protocol is still opened by an agent, it should be
> closed.
>
> Signed-off-by: Heinric
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> The installation of UninstallProtocols is functional now.
> So we do not expect errors when calling it.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_selftest/efi_selftest_manageprotocols.c | 22 +++---
> 1 file
On 17 December 2017 at 08:43, Heinrich Schuchardt wrote:
> We should consistently use the efi_handle_t typedef when
> referring to handles.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/bootefi.c | 10 -
> include/efi_api.h | 20 ++
> incl
Hi Stephen,
On 19 December 2017 at 18:30, Stephen Warren wrote:
> From: Stephen Warren
>
> U-Boot typically uses a hard-coded value for the stack pointer before
> relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
> the initial SP at run-time. This is useful to avoid hard-c
On 19 December 2017 at 18:30, Stephen Warren wrote:
> From: Stephen Warren
>
> No 64-bit Tegra uses SPL. Remove various unused definitions from config
> headers.
>
> Signed-off-by: Stephen Warren
> ---
> include/configs/tegra-common.h| 2 ++
> include/configs/tegra186-common.h | 5 -
>
On 1/7/2018 5:39 AM, Marek Vasut wrote:
> On 01/06/2018 10:09 PM, Jason Rush wrote:
>> On 1/6/2018 1:29 PM, Marek Vasut wrote:
>>> On 01/06/2018 07:46 PM, Jason Rush wrote:
On 1/6/2018 9:42 AM, Marek Vasut wrote:
>>
>>
There was a minor upstream change to one of the files since I submitt
On 19 December 2017 at 18:30, Stephen Warren wrote:
> From: Stephen Warren
>
> Enable CONFIG_SYS_INIT_SP_BSS_OFFSET for all 64-bit Tegra boards. Place
> the stack/... 512KiB from the end of the U-Boot binary. This should be
> plenty to accommodate the current DTBs (max 64 KiB), early malloc regio
Hi Jagan,
On 27 December 2017 at 23:12, Jagan Teki wrote:
> initialize spi-nor framework during boot, so-that detected
> buses can appears at boot log.
>
> Signed-off-by: Suneel Garapati
> Signed-off-by: Jagan Teki
> ---
> common/board_r.c | 13 +
> drivers/mtd/
On 26 December 2017 at 03:07, Heinrich Schuchardt wrote:
> For debugging efi_loader we need the capability to print EFI
> device paths. With this patch we can write:
>
> debug("device path: %pD", dp);
>
> A possible output would be
>
> device path: /MemoryMapped(0x0,0x3ff93a82,0x3ff93a82)
On 28 December 2017 at 05:06, Marek Vasut wrote:
> Rename CONFIG_FIT_SPL_PRINT to CONFIG_SPL_FIT_PRINT and add Kconfig
> entry for it.
>
> Signed-off-by: Marek Vasut
> Cc: Pantelis Antoniou
> Cc: Simon Glass
> ---
> Kconfig| 6 ++
> README | 2 +-
> common/image-fit
On 28 December 2017 at 05:06, Marek Vasut wrote:
> These functions may be needed in SPL, so add empty variants of them
> if CONFIG_SPL_FIT_PRINT is disabled.
>
> Signed-off-by: Marek Vasut
> Cc: Pantelis Antoniou
> Cc: Simon Glass
> ---
> common/image-fit.c | 4 +++-
> 1 file changed, 3 insert
On 28 December 2017 at 05:06, Marek Vasut wrote:
> Just add IH_TYPE_STANDALONE to fit_get_image_type_property().
>
> Signed-off-by: Marek Vasut
> Cc: Pantelis Antoniou
> Cc: Simon Glass
> ---
> common/image-fit.c | 2 ++
> include/image.h| 1 +
> 2 files changed, 3 insertions(+)
Reviewed-
On 28 December 2017 at 05:06, Marek Vasut wrote:
> Rather than verifying configuration signature of the configuration node
> containing the kernel image types, verify all configuration nodes, even
> those that do not contain kernel images. This is useful when the nodes
> contain ie. standalone OSe
Hi Marek,
On 28 December 2017 at 05:06, Marek Vasut wrote:
> Add support for loading U-Boot and optionally FDT from a fitImage
> in SPL by using the full fitImage support from U-Boot. While we do
> have limited SPL loading support in SPL with a small footprint, it
> is missing a lot of important
> -Original Message-
> From: Clemens Gruber [mailto:clemens.gru...@pqgruber.com]
> Sent: Monday, January 08, 2018 12:56 AM
> To: York Sun
> Cc: u-boot@lists.denx.de; Fabio Estevam ; Tom Rini
> ; Vini Pillai ; Ruchika Gupta
> ; Breno Matheus Lima ;
> Fabio Estevam ; Sumit Garg ;
> Arun Path
Hi Marek,
On 28 December 2017 at 05:06, Marek Vasut wrote:
> Add support for loading fitImage with device tree overlay image, which
> is applied to the U-Boot's own device tree. Once the DT is applied, the
> fitImage loading process is restarted.
>
> This patch allows a usecase where the DTO patc
Hi Marek,
On 28 December 2017 at 05:06, Marek Vasut wrote:
> Add support for fetching the image position in RAM from control DT
> rather than hard-coding it. While doing so, return the return value
> of spl_parse_header_image() to make it possible to test application
> of DTOs on U-Boot's control
Hi Marek,
On 28 December 2017 at 07:29, Lukasz Majewski wrote:
> Hi Marek,
>
>> Add support for fetching the image position in RAM from control DT
>> rather than hard-coding it. While doing so, return the return value
>> of spl_parse_header_image() to make it possible to test application
>> of DT
On 29 December 2017 at 10:00, Masahiro Yamada
wrote:
> This series can be cleanly applied to u-boot-mmc/next.
>
> I really hope the HS200 support will be pulled in the next MW.
Yes please, it has been too long.
___
U-Boot mailing list
U-Boot@lists.denx.
Hi Emmanuel,
On 2 January 2018 at 14:27, Emmanuel Vadot wrote:
> Some commands (like sysboot) might want to call go as they can encounter
> a raw binary.
> Make do_go callable for everyone.
>
> Signed-off-by: Emmanuel Vadot
> ---
> cmd/boot.c| 2 +-
> include/command.h | 4
> 2 fil
Hi Masahiro,
On 29 December 2017 at 10:00, Masahiro Yamada
wrote:
> dev_read_u32_default() always returns something even when the property
> is missing. So, it is impossible to do nothing in the case. One
> solution is to use ofnode_read_u32() instead, but adding dev_read_u32()
> will be helpfu
Hi Emmanuel,
On 2 January 2018 at 14:27, Emmanuel Vadot wrote:
> As do_bootm/do_booti/do_bootz will not return if the boot succeded, always
> call them if enable by the config.
> Also add a fallback to go if the binary is a raw one.
Do we not know which type of binary it is? It seems like we sho
Hi Stephen,
On 2 January 2018 at 16:54, Stephen Warren wrote:
> From: Stephen Warren
>
> Enable CONFIG_LINUX_KERNEL_IMAGE_HEADER for all 64-bit Tegra boards.
> cboot (the boot SW that runs before U-Boot) will eventually use this
> information.
How does U-Boot use it? Does it not come from the F
On 3 January 2018 at 07:23, Tom Rini wrote:
> The command portion of the GPIO driver can only be used in full SPL so
> re-work to guard the command related portions and mark it as static.
>
> Cc: Bin Meng
> Cc: Simon Glass
> Cc: Philipp Tomsich
> Signed-off-by: Tom Rini
> ---
> drivers/gpio/p
On 3 January 2018 at 14:32, Stephen Warren wrote:
> From: Stephen Warren
>
> Apply a few small fixes for the DTB /memory node parsing from NVIDIA's
> downstream U-Boot:
>
> - Allow arbitrary number of DRAM banks.
> - Correctly calculate the number of DRAM banks.
> - Clip PCIe memory in the same w
Hi Quentin,
On 3 January 2018 at 02:18, Quentin Schulz
wrote:
> Hi Simon,
>
> On 29/12/2017 04:13, Simon Glass wrote:
>> Hi Quentin,
>>
>> On 22 December 2017 at 14:13, Quentin Schulz
>> wrote:
>>> This patch series is based on this[1] patch series from Maxime.
>>>
>>> This is an RFC. It's been
Hi Heinrich,
On 3 January 2018 at 08:23, Heinrich Schuchardt wrote:
> Allow to override CONFIG_BOOTCOMMAND in .config.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/configs/x86-common.h | 2 ++
> 1 file changed, 2 insertions(+)
This is a Chrome OS boot line. I think you should conside
On 3 January 2018 at 14:32, Stephen Warren wrote:
> From: Stephen Warren
>
> On this platform, there may be up to 1024 unusable chunks of memory.
> Increase CONFIG_NR_DRAM_BANKS so that U-Boot can remember all the banks
> required to represent such fragmented memory.
>
> Signed-off-by: Stephen Wa
On 3 January 2018 at 14:32, Stephen Warren wrote:
> From: Stephen Warren
>
> In the future, the list of DRAM regions passed to U-Boot in the DTB may
> be quite long and fragmented. Due to this, U-Boot must search through the
> regions to find the best region to relocate into, rather than relying
On 4 January 2018 at 09:40, Andy Shevchenko
wrote:
> The recent commit 03c4749dd6c7
> ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
> in the Linux kernel reveals the issue we have in ACPI tables here,
> i.e. we must use hardware numbers for GPIO resources and,
> taking in
On 5 January 2018 at 13:04, Stephen Warren wrote:
> From: Stephen Warren
>
> arch_lmb_reserve() currently assumes that the stack pointer is within DRAM
> bank 0. This is not necessarily true. Enhance the code to search through
> DRAM banks until the bank that does contain SP is found, and then re
+masahiro
On 4 January 2018 at 23:05, Peng Fan wrote:
> Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6")
> to use enum pin_config_param.
>
> Signed-off-by: Peng Fan
> ---
> include/dm/pinctrl.h | 112
> ++-
> 1 file changed, 66 insertio
On 4 January 2018 at 09:40, Andy Shevchenko
wrote:
> As defined on reference board followed by Intel Edison a Bluetooth
> device is attached to HSU0, i.e. PCI :04.1.
>
> Describe it in ACPI accordingly.
>
> Note, we use BCM2E95 ID here as one most suitable for such device based
> on the descri
On 6 January 2018 at 16:54, Heinrich Schuchardt wrote:
> initr_mem() is already enclosed by
> #if defined(CONFIG_PRAM)
> #endif
>
> So there is no need to check CONFIG_PRAM again inside the
> function.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> common/board_r.c | 2 --
> 1 fi
Hi Maxime,
On 5 January 2018 at 02:29, Maxime Ripard
wrote:
> Hi Simon,
>
> On Thu, Dec 28, 2017 at 08:13:42PM -0700, Simon Glass wrote:
>> Hi Maxime,
>>
>> On 28 November 2017 at 03:24, Maxime Ripard
>> wrote:
>> > Allow boards and architectures to override the default environment lookup
>> > c
On 5 January 2018 at 11:17, Masahiro Yamada
wrote:
> U-Boot pulled in several core makefiles from Linux. The following
> are not used in U-Boot:
>
> - CONFIG_DEBUG_SECTION_MISMATCH
> - CONFIG_FTRACE_MCOUNT_RECORD
> - CONFIG_GCOV_KERNEL
> - CONFIG_GCOV_PROFILE_ALL
> - CONFIG_KASAN
> -
On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
[...]
>>> 1. The indaddrtrig register was being programmed with an incorrect value
>>> for socfpga
>>> as the result of assuming it should be programmed with the same address as
>>> the
>>> ahbbase address. This issue is resolved by adoptin
On 01/08/2018 12:34 AM, Anand Moon wrote:
> Hi Lukasz,
>
> On 3 January 2018 at 14:08, Lukasz Majewski wrote:
>> Hi Anand,
>>
>>> Hi Lukasz
>>>
>>> On 3 January 2018 at 03:47, Lukasz Majewski wrote:
On Wed, 3 Jan 2018 01:54:57 +0530
Anand Moon wrote:
> Hi All,
>
> I w
QMAP value contains information about QSPI chip-selects.
These bits are used to display information of boot device
in checkboard() function.
QMAP value is stored in most significant 3-bits
of 8-bit register brdcfg[0] in Qixis, this patch
corrects code to get QMAP bits using below logic:
(b
Hi Jaehoon,
On 8 January 2018 at 11:56, Jaehoon Chung wrote:
> On 01/08/2018 12:34 AM, Anand Moon wrote:
>> Hi Lukasz,
>>
>> On 3 January 2018 at 14:08, Lukasz Majewski wrote:
>>> Hi Anand,
>>>
Hi Lukasz
On 3 January 2018 at 03:47, Lukasz Majewski wrote:
> On Wed, 3 Jan 2018
Remove Board Arch print as its value is always
constant '1' and does not contain any important
information to display during boot
Add print to display Board FPGA version.
Signed-off-by: Priyanka Jain
---
This patch is split version of another patch
https://patchwork.ozlabs.org/patch/803117/
bo
83 matches
Mail list logo
