Add NAND support to dra71x-evm defconfig
Signed-off-by: Faiz Abbas
---
configs/dra7xx_evm_defconfig| 3 +++
configs/dra7xx_hs_evm_defconfig | 3 +++
2 files changed, 6 insertions(+)
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 3f25a2ec28..d71d989c4c 100644
Now that NAND is supported on DRA71x include various NAND environment
settings
Signed-off-by: Faiz Abbas
---
configs/dra7xx_evm_defconfig | 4 +++-
configs/dra7xx_hs_evm_defconfig | 4 +++-
include/configs/dra7xx_evm.h | 2 +-
include/configs/ti_omap5_common.h | 3 ++-
From: Franklin S Cooper Jr
If SW 8 pins 0 and 1 indicate that NAND should be enabled then
the pins pinmux must be reconfigured for NAND mode.
Therefore, enable NAND by reconfiguring the pinmux.
Signed-off-by: Franklin S Cooper Jr
Signed-off-by: Faiz Abbas
---
board/ti/dra7xx/evm.c | 56
The following patches add support for NAND and booting from
NAND in dra71x-evm.
v2:
Patch4: Moved NANDARGS to its own file in include/environment/ti
Faiz Abbas (2):
configs: dra71x-evm: Add Support for NAND
configs: ti_omap5_common: Add NAND environment settings
Franklin S Cooper Jr (2):
From: Franklin S Cooper Jr
By default VOUT3 occupies the pins required for NAND. Therefore, create
a seperate entry that can be use to reconfigure these pins to work for
NAND.
On the EVM SWITCH 8 pins 0 and 1 will be used to determine if NAND is
enabled or not. For NAND to be selected pin 0
Hi Tom,
On 22/02/19 4:52 AM, Tom Rini wrote:
> On Wed, Feb 20, 2019 at 03:34:53PM +0530, Faiz Abbas wrote:
>
>> Now that NAND is supported on DRA71x include various NAND environment
>> settings
>>
>> Signed-off-by: Faiz Abbas
> [snip]
>> +#ifdef CONFIG_NAND
>> +#define NANDARGS \
>> +
On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
>>> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> "run -e"
Hi Joe,
Can you please check and ACK this patch?
This patch is related to http://patchwork.ozlabs.org/patch/990131/
Regards,
Pankaj Bansal
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, 11 February, 2019 03:19 PM
> To: Pankaj Bansal ; Joe Hershberger
>
> Cc:
On Wed, Feb 27, 2019 at 07:39:50AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 7:27 AM, AKASHI Takahiro wrote:
> > On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote:
> >> On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
> >>> On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich
On Wed, Feb 27, 2019 at 07:31:06AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> With this patch applied, we will be able to selectively
On 2/27/19 7:27 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
>>> On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> See UEFI
On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> "run -e" allows for executing EFI application with a
On Tue, 2019-02-26 at 07:58 -0800, Dalon L Westergreen wrote:
> On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote:
> >
> > On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> > >
> > > On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> > > >
> > > > On 19. 02. 19 4:47,
On Tue, 2019-02-26 at 16:46 +0100, Michal Simek wrote:
> On 26. 02. 19 15:53, Chee, Tien Fong wrote:
> >
> > On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> > >
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee
> > > >
> > > > Add
On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> With this patch applied, we will be able to selectively execute
>>> an EFI application by specifying a load option, say "1" for
On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> "run -e" allows for executing EFI application with a specific "Boot"
>>> variable. If no "Boot" is specified or "BootOrder" is
On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> See UEFI v2.7, section 3.1.2 for details of the
On Tue, 2019-02-26 at 16:46 +0100, Michal Simek wrote:
> On 26. 02. 19 15:53, Chee, Tien Fong wrote:
> >
> > On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> > >
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee
> > > >
> > > > Add
On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> See UEFI v2.7, section 3.1.2 for details of the specification.
>>>
>>> With my efitool command, you can try as the following:
>>> =>
On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > "run -e" allows for executing EFI application with a specific "Boot"
> > variable. If no "Boot" is specified or "BootOrder" is specified,
> > it tries to run an EFI
On Tue, 2019-02-26 at 16:43 +0100, Michal Simek wrote:
> On 26. 02. 19 15:30, Chee, Tien Fong wrote:
> >
> > On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
> > >
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee
> > > >
> > > > Add
On Wed, Feb 27, 2019 at 1:47 PM Keerthy wrote:
>
>
>
> On 22/02/19 12:08 AM, Joe Hershberger wrote:
> > On Wed, Feb 20, 2019 at 6:33 AM Keerthy wrote:
> >>
> >> Currently stop is being called unconditionally without even
> >> checking if start is called. In case of multiple instances eth
> >>
On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > With this patch applied, we will be able to selectively execute
> > an EFI application by specifying a load option, say "1" for Boot0001,
> > "2" for Boot0002 and so on.
> >
> >
On 22/02/19 12:08 AM, Joe Hershberger wrote:
On Wed, Feb 20, 2019 at 6:33 AM Keerthy wrote:
Currently stop is being called unconditionally without even
checking if start is called. In case of multiple instances eth
being present many devices might just be initialized without
a start call in
On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > See UEFI v2.7, section 3.1.2 for details of the specification.
> >
> > With my efitool command, you can try as the following:
> > => efi boot add 1 SHELL ...
> > => efi boot
Hi Tom,
Please pull some riscv updates:
SiFive FU540 Support
https://travis-ci.org/rickchen36/u-boot-riscv/builds/499037971
Thanks
Rick
The following changes since commit b3820ba997f004a376efc5446683101ff42b05af:
Merge tag 'efi-2019-04-rc3' of https://github.com/xypron2/u-boot (2019-02-26
Use quad write if SPI_TX_QUAD flag is set.
Tested quad write on Stratix 10 SoC board (Micron
serial NOR flash, mt25qu02g)
Signed-off-by: Ley Foon Tan
---
v1 -> v2:
- Update commit message
- Restore file permission
---
drivers/spi/cadence_qspi.c | 2 +-
drivers/spi/cadence_qspi.h | 2
Hi Anup
Anup Patel 於 2019年2月26日 週二 下午7:55寫道：
>
> On Mon, Feb 25, 2019 at 12:50 PM Rick Chen wrote:
> >
> > Hi Anup
> >
> > Anup Patel 於 2019年2月25日 週一 上午11:28寫道：
> > >
> > > On Mon, Feb 25, 2019 at 7:50 AM Rick Chen wrote:
> > > >
> > > > Hi Anup
> > > >
> > > > Rick Chen 於 2019年2月22日 週五
On Wed, 2019-02-27 at 10:38 +0530, Vignesh R wrote:
>
> On 26/02/19 1:59 PM, Ley Foon Tan wrote:
> >
> > Use quad write if SPI_TX_QUAD flag is set.
> >
> How was the patch tested? Could you add that info to commit msg?
Tested on Stratix 10 SoC board.
Will update commit message.
>
> >
> >
On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren wrote:
>
> From: Stephen Warren
>
> Without this, the arch-dtbs target only gets evaluated when building
> U-Boot the first time, not when re-building (incrementally building)
> U-Boot. Thus incremental builds ignore changes to DTB files.
>
>
On 26/02/19 1:59 PM, Ley Foon Tan wrote:
> Use quad write if SPI_TX_QUAD flag is set.
>
How was the patch tested? Could you add that info to commit msg?
> Signed-off-by: Ley Foon Tan
> ---
> drivers/spi/cadence_qspi.c | 2 +-
> drivers/spi/cadence_qspi.h | 2 +-
>
On Wed, Feb 27, 2019 at 4:20 AM Stephen Warren wrote:
>
> From: Stephen Warren
>
> *.dts are processed using a custom command, then the C pre-processor is
> run on them, then they are compiled using dtc. Thus, the dependency
> files generated by both cpp and dtc reference a temporary file name
>
On 26/02/19 10:45 PM, Faiz Abbas wrote:
> With U-boot supporting environment in multiple places, enable only
> ENV_IS_IN_EMMC
>
> Signed-off-by: Faiz Abbas
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
> configs/dra7xx_evm_defconfig| 1 +
> configs/dra7xx_hs_evm_defconfig
Please ignore, it is sent by mistake.
> -Original Message-
> From: U-Boot On Behalf Of Meenakshi
> Aggarwal
> Sent: Wednesday, February 27, 2019 2:41 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
>
> Subject: [U-Boot] [PATCH 1/2] cmd: efidebug: add memmap command
>
> From: AKASHI
ls2088, ls1088 : minimum MC Memory size is 128 MB
lx2 : minimum MC memory size is 256 MB
Signed-off-by: Meenakshi Aggarwal
---
drivers/net/fsl-mc/mc.c | 23 +++
include/configs/ls1088a_common.h | 2 +-
include/configs/ls2080a_common.h | 2 +-
From: AKASHI Takahiro
"memmap" command prints uefi-specific memory map information.
=> efi memmap
Type StartEnd Attributes
==
CONVENTIONAL 4000-7de27000 WB
RUNTIME DATA
On Wed, Feb 27, 2019 at 11:17 AM Masahiro Yamada
wrote:
>
> On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren wrote:
> >
> > From: Stephen Warren
> >
> > Without this, the arch-dtbs target only gets evaluated when building
> > U-Boot the first time, not when re-building (incrementally building)
>
On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren wrote:
>
> From: Stephen Warren
>
> Without this, the arch-dtbs target only gets evaluated when building
> U-Boot the first time, not when re-building (incrementally building)
> U-Boot. Thus incremental builds ignore changes to DTB files.
Really?
Am 15.02.19 um 12:56 schrieb Rosy Song:
> Signed-off-by: Rosy Song
this should have some commit message explaining the error. In fact all
of your commits should have some meaningful commit message.
> ---
> arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 4 ++--
> 1 file changed, 2
Am 15.02.19 um 12:56 schrieb Rosy Song:
> Signed-off-by: Rosy Song
> ---
> arch/mips/dts/Makefile| 1 +
> arch/mips/dts/ap152.dts | 48 ++
> arch/mips/dts/qca956x.dtsi| 87
> arch/mips/mach-ath79/Kconfig
On Tue, Feb 19, 2019 at 9:31 AM wrote:
> I am working on an application needing the ability to update to a verified
> image from the running kernel/application.
>
> We can follow the "normal" verified image boot sequence, where the chain
> of trust is verified from U-Boot to image to execution,
To find out how big the early malloc heap must be in SPL, add a debug
print statement that dumps its usage before switching to relocated heap
in spl_relocate_stack_gd() via CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN.
Signed-off-by: Simon Goldschmidt
---
common/spl/spl.c | 2 ++
1 file changed, 2
On Tue, Feb 26, 2019 at 12:21:53PM -0700, Stephen Warren wrote:
> On 2/25/19 4:49 PM, Stephen Warren wrote:
> >On 2/21/19 4:45 PM, Stephen Warren wrote:
> >>With the latest push to u-boot.git master branch, I'm seeing the
> >>following failures running test/py on sandbox:
> >>
> >>=> ut dm
This adds reset handling to the devicetree-enabled Denali NAND driver.
For backwards compatibility, only a warning is printed when failing to
get reset handles.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- add DM_FLAG_OS_PREPARE flag
Changes in v2:
- fix copy/paste issues
- add
This commit removes ad-hoc reset handling for peripheral resets from SPL
for socfpga gen5.
This is done because as U-Boot drivers support reset handling by now.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- keep the call to enable fpga bridges in SPL
Changes in v2:
- removed Kconfig
This adds reset handling to the cadence qspi driver.
For backwards compatibility, only a warning is printed when failing to
get reset handles.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- add DM_FLAG_OS_PREPARE flag
Changes in v2:
- add .remove callback to release the resets
To clean up reset handling for socfpga gen5, port the DDR driver to DM
using UCLASS_RAM and implement proper reset handling.
This gets us rid of one ad-hoc call to socfpga_per_reset().
The gen5 driver is implemented in 2 distinct files. One of it (containing
the calibration training) is not
This adds code to take peripherals out of reset based on an environment
variable. This is in preparation for removing the code that does this from
SPL.
However, some drivers even in current Linux cannot handle peripheral reset,
so until this works, we need a compatibility workaround.
This
To keep the current behaviour of taking all peripherals out of reset
before booting the OS before removing that code from socfpga gen5 SPL,
this enables the new behaviour by default for all gen5 boards by adding
the environment variable "socfpga_legacy_reset_compat=1" to the default
environment.
The SPL for socfpga gen5 currently takes all peripherals out of reset
unconditionally. To implement proper reset handling for peripherals,
the reset node has to be provided with the SPL dts.
In preparation to move the DDR driver to DM, the sdr node is required
in SPL, too.
This patch adds
This is again a sync to linux-next + pending patches in Dinh's tree at
commit 1c909b2dfe6a ("ARM: dts: socfpga: update more missing reset
properties")'
It adds missing peripheral reset properties to socfpga.dtsi and removes
U-Boot specific leftovers from socfpga_cyclone5_socrates.dts.
This series implements peripheral reset handling for socfpga gen5.
It moves from enabling all peripherals during SPL startup to using the
socfpga reset driver from all peripherals and enabling peripherals when
they are used.
As Linux cannot even handle this in 4.20, the reset driver implements a
On 22.02.2019 22:14, Marek Vasut wrote:
On 2/22/19 8:55 PM, Simon Goldschmidt wrote:
Am Fr., 22. Feb. 2019, 20:47 hat Marek Vasut mailto:ma...@denx.de>> geschrieben:
On 2/22/19 8:42 PM, Simon Goldschmidt wrote:
>
>
> Am Fr., 22. Feb. 2019, 20:37 hat Marek Vasut
Hi, Marek
+}
+
+/*
+ * Reset vector for secondary CPUs.
+ * This will be mapped at address 0 by SBAR register.
+ * We need _long_ jump to the physical address.
+ */
+asm(" .arm\n"
+ " .align 12\n"
+ " .globl shmobile_boot_vector\n"
+ "shmobile_boot_vector:\n"
+ " ldr
On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> With this patch applied, we will be able to selectively execute
> an EFI application by specifying a load option, say "1" for Boot0001,
> "2" for Boot0002 and so on.
>
> => bootefi bootmgr 1, or
> bootefi bootmgr - 1
You already introduced the
On 2/25/19 4:49 PM, Stephen Warren wrote:
On 2/21/19 4:45 PM, Stephen Warren wrote:
With the latest push to u-boot.git master branch, I'm seeing the
following failures running test/py on sandbox:
=> ut dm pch_base
Test: dm_test_pch_base: pch.c
From: Stephen Warren
Without this, the arch-dtbs target only gets evaluated when building
U-Boot the first time, not when re-building (incrementally building)
U-Boot. Thus incremental builds ignore changes to DTB files.
Signed-off-by: Stephen Warren
---
dts/Makefile | 1 +
1 file changed, 1
From: Stephen Warren
*.dts are processed using a custom command, then the C pre-processor is
run on them, then they are compiled using dtc. Thus, the dependency
files generated by both cpp and dtc reference a temporary file name
rather than the actual source file. While this information isn't
On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> "run -e" allows for executing EFI application with a specific "Boot"
> variable. If no "Boot" is specified or "BootOrder" is specified,
> it tries to run an EFI application specified in the order of "bootOrder."
>
If we cannot specify the
On 2019-02-26, Leigh Brown wrote:
> I tested u-boot 2019.01+dfsg-1 on my Globalscale Dreamplug and it
> doesn't work:
>
> U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
> Marvell-DreamPlug
>
> SoC: Kirkwood 88F6281_A1
> DRAM: 512 MiB
> Loading Environment from SPI Flash... Invalid bus 0
On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> See UEFI v2.7, section 3.1.2 for details of the specification.
>
> With my efitool command, you can try as the following:
> => efi boot add 1 SHELL ...
> => efi boot add 2 HELLO ...
> => efi boot order 1 2
> => efi bootmgr
> (starting
On Mon, Feb 25, 2019 at 07:32:35PM +0100, Heinrich Schuchardt wrote:
> The following changes since commit afd46c5f13d0c93c44008bd7040227d0b84e31b9:
>
> Merge branch '2019-02-22-master-imports' (2019-02-22 22:40:24 -0500)
>
> are available in the Git repository at:
>
>
On Sat, Feb 23, 2019 at 06:54:03PM +0100, Fabien Parent wrote:
> Add support for MediaTek MT8516 SoC. This include the file
> that will initialize the SoC after boot and its device tree.
>
> Signed-off-by: Fabien Parent
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
Hi, Marek
2. It should be new pm-r8a7791.c file which will don't have any CA7
related stuff (CPU cores, SCU, etc).
I'd like to have a generic pm-gen2.c file , which parses the DT and
figures the configuration out that way. We are trying to get rid of all
the ad-hoc hardcoded configuration
With U-boot supporting environment in multiple places, enable only
ENV_IS_IN_EMMC
Signed-off-by: Faiz Abbas
---
configs/dra7xx_evm_defconfig| 1 +
configs/dra7xx_hs_evm_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/dra7xx_evm_defconfig
On 2/26/19 12:46 PM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Function term_read_reply tries to read from the serial console until
> the end_char was read. This can hang forever if we are, for some reason,
> not be able to read the full response (e.g. serial buffer too small,
From: Matthias Brugger
Serial device function pending allows to check the state of the input
and output buffers. But in fact only a check for the input buffers
is used in the device model. There are even some driver which discard a
check on the output buffers. So delete the check for the output
On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote:
> On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> > On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > > From: Tien Fong Chee
> > > >
> > > > This patch adds description on
If node /board_info/ports does not exist in the DPC file,
function mc_fixup_dpc() will skip not only MAC address fixup,
but also the cache flush at the end. This may cause the other
fixup changes (e.g. ICID relatd ones) to be ignored by MC.
Fixes: 1161dbcc0a36 ("drivers: net: fsl-mc: Include MAC
Hi,
when I try to load a sparse file via ext4load, I am getting the error message
'invalid extent'
After a deeper look in the code, it seems to be an issue in the function
ext4fs_get_extent_block in fs/ext4/ext4_common.c:
The file starts with 1k of zeros. The blocksize is 1024. So the first
On 26. 02. 19 15:53, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
>> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee
>>>
>>> Add FPGA driver to support program FPGA with FPGA bitstream loading
>>> from
>>> filesystem. The driver
On 26. 02. 19 15:30, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
>> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee
>>>
>>> Add default fitImage file bundling FPGA bitstreams for Arria10.
>>>
>>> Signed-off-by: Tien Fong Chee
On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
>> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee
>>>
>>> This patch adds description on properties about file name used for
>>> both
>>> peripheral bitstream and
On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > Add FPGA driver to support program FPGA with FPGA bitstream loading
> > from
> > filesystem. The driver are designed based on generic firmware
> >
On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > Add FPGA driver to support program FPGA with FPGA bitstream loading
> > from
> > filesystem. The driver are designed based on generic firmware
> >
On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > Add default fitImage file bundling FPGA bitstreams for Arria10.
> >
> > Signed-off-by: Tien Fong Chee
> >
> > ---
> >
> > changes for v8
> > -
On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > Add default fitImage file bundling FPGA bitstreams for Arria10.
> >
> > Signed-off-by: Tien Fong Chee
> >
> > ---
> >
> > changes for v8
> > -
On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > This patch adds description on properties about file name used for
> > both
> > peripheral bitstream and core bitstream.
> >
> > Signed-off-by: Tien
On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Add FPGA driver to support program FPGA with FPGA bitstream loading from
> filesystem. The driver are designed based on generic firmware loader
> framework. The driver can handle FPGA program operation from loading
On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Add default fitImage file bundling FPGA bitstreams for Arria10.
>
> Signed-off-by: Tien Fong Chee
>
> ---
>
> changes for v8
> - Reordered the images and fpga configurations.
> - Removed the load property at core
On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Add default fitImage file bundling FPGA bitstreams for Arria10.
>
> Signed-off-by: Tien Fong Chee
>
> ---
>
> changes for v8
> - Reordered the images and fpga configurations.
> - Removed the load property at core
On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> This patch adds description on properties about file name used for both
> peripheral bitstream and core bitstream.
>
> Signed-off-by: Tien Fong Chee
>
> ---
>
> changes for v8
> - Removed explanation about support
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月26日 20:36
> To: sba...@denx.de
> Cc: dl-uboot-imx ; Peng Fan ;
> Abel Vesa ; u-boot@lists.denx.de; Fabio Estevam
>
> Subject: [PATCH 2/2] mx6sabreauto: README: Adjust the binary name after
> DM
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月26日 20:36
> To: sba...@denx.de
> Cc: dl-uboot-imx ; Peng Fan ;
> Abel Vesa ; u-boot@lists.denx.de; Fabio Estevam
>
> Subject: [PATCH 1/2] mx6sabresd: README: Adjust the binary name after DM
> conversion
On Fri, 2019-02-15 at 14:35 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> In previously label which will be expanded to the node's full path
> was
> used, and now replacing label with most commonly used DT phandle. The
> codes were changed accordingly to the use of DT phandle
After the conversion to DM the U-Boot binary is called u-boot-dtb.imx,
so fix the README file accordingly.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6sabreauto/README | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/board/freescale/mx6sabreauto/README
After the conversion to DM the U-Boot binary is called u-boot-dtb.imx,
so fix the README file accordingly.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6sabresd/README | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/board/freescale/mx6sabresd/README
On Tue, 2019-02-19 at 11:47 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> This version mainly resolved comments from Marek in [v8].
>
> This series is working on top of u-boot.git - http://git.denx.de/u-b
> oot.git .
>
> These patches are required before applying this
From: Siva Durga Prasad Paladugu
This patch relocates the pointers inside phy_drivers incase
of manual reloc. Without this reloc, these points to invalid
pre relocation address and hence causes exception or hang.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
From: Siva Durga Prasad Paladugu
Don't ignore return value of phy_probe() call as
the probe may fail and it needs to be reported.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
drivers/net/phy/phy.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
From: Matthias Brugger
Function term_read_reply tries to read from the serial console until
the end_char was read. This can hang forever if we are, for some reason,
not be able to read the full response (e.g. serial buffer too small,
frame error). This patch moves the timeout detection into
Alignment with kernel directory name as it have already bindings for
DDR controllers in the directory:
Documentation/devicetree/bindings/memory-controller
PS: the drivers using RAM u-class should be associated with
this binding directory
Signed-off-by: Patrick Delaunay
---
On Mon, Feb 25, 2019 at 12:50 PM Rick Chen wrote:
>
> Hi Anup
>
> Anup Patel 於 2019年2月25日 週一 上午11:28寫道：
> >
> > On Mon, Feb 25, 2019 at 7:50 AM Rick Chen wrote:
> > >
> > > Hi Anup
> > >
> > > Rick Chen 於 2019年2月22日 週五 下午12:05寫道：
> > > >
> > > > Hi Anup
> > > >
> > > > Anup Patel 於 2019年2月21日
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Note, I2C6, which is available to user, has no DMA request lines connected.
Signed-off-by: Andy Shevchenko
---
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 3 +++
1 file
Livetree implemented functions does not have conditional compilation so
check if CONFIG_IS_ENABLED prior using those functions.
The issue does not report any error in a normal build as the toolchain
optimize the code. Using -O0 triggers the error so the patch is intended
to fix issues on a
Intel Edison has three UART ports, i.e.
port 0 - Bluetooth
port 1 - auxiliary, available for general purpose use
port 2 - debugging, usually console output is here
Enable all of them for future use.
Signed-off-by: Andy Shevchenko
---
arch/x86/dts/edison.dts | 18 ++
1 file
The console is actually serial #2. When we would like to enable other ports,
this would be not okay to mess up with the ordering.
Thus, fix the number of default console interface to be 2.
Signed-off-by: Andy Shevchenko
---
arch/x86/dts/edison.dts | 6 +++---
1 file changed, 3 insertions(+), 3
From: Laurentiu Tudor
sec_firmware reserves JR3 for it's own usage and deletes the JR3 node
from the device tree. This causes this warning to be issued when doing
the device tree fixup:
WARNING could not find node fsl,sec-v4.0-job-ring: FDT_ERR_NOTFOUND.
Fix it by excluding the device tree
From: Laurentiu Tudor
The SEC QI ICID setup in the QIIC_LS register is actually an offset
that is being added to the ICID coming from the qman portal. Setting
it with a non-zero value breaks SMMU setup as the resulting ICID is
not known. On top of that, the SEC QI ICID must match the qman portal
1 - 100 of 111 matches
Mail list logo
