Hi Jean-Jacques,
On Wed, 2 Oct 2019 at 03:29, Jean-Jacques Hiblot wrote:
>
> The sandbox architecture does not implement the writeX nor readX functions.
> This prevents testing properly the regmaps and the other stuff relying on
> it.
I just added a feature to sandbox to support mmio. I'll send
On Fri, Jul 12, 2019 at 1:50 PM Igor Opaniuk wrote:
>
> i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for
> the rpmsg communication. Both use cases need a fixed location of
> memory reserved. For the rpmsg use case the reserved area needs
> to be in sync with the kernel's hardcoded
On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 08:10:31AM +, Ang, Chee Hong wrote:
> >
> > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > >
> > > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Fri, 2019-03-08
On Wed, Mar 13, 2019 at 08:10:31AM +, Ang, Chee Hong wrote:
> On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> > >
> > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > >
> > > > On Tue, Feb 12, 2019 at 12:27:01A
On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> >
> > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > >
> > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> > > wrote:
> > >
> > > >
> > > >
> > >
On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> > wrote:
> >
> > >
> > > From: "Ang, Chee Hong"
> > >
> > > Currently u-boot only support standard PSCI fu
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> wrote:
>
> >
> > From: "Ang, Chee Hong"
> >
> > Currently u-boot only support standard PSCI functions for power
> > management
> > and lack of convenient method to allow the
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com wrote:
> From: "Ang, Chee Hong"
>
> Currently u-boot only support standard PSCI functions for power management
> and lack of convenient method to allow the users to extend the PSCI functions
> to support platform specific services
On Tue, 2019-02-12 at 00:27 -0800, chee.hong@intel.com wrote:
> From: "Ang, Chee Hong"
Hi Tom/Albert,
Any comment on this patch ?
Best Regards,
Ang
>
> Currently u-boot only support standard PSCI functions for power
> management
> and lack of convenient method to allow the users to e
Hi Tom,
Any comments on this patch ?
Best Regards,
Ang
On Tue, 2019-02-12 at 00:27 -0800, chee.hong@intel.com wrote:
> From: "Ang, Chee Hong"
>
> Currently u-boot only support standard PSCI functions for power
> management
> and lack of convenient method to allow the users to extend
On 6.4.2018 15:58, Jean-Jacques Hiblot wrote:
>
>
> On 06/04/2018 14:00, Michal Simek wrote:
>> Hi,
>>
>> On 6.4.2018 11:13, Jean-Jacques Hiblot wrote:
>>> Enhancements to SCSI support for driver model have broken the support
>>> for
>>> DM_SCSI on DRA7 platforms. This series fixes it.
>>>
>>> Te
On 06/04/2018 14:00, Michal Simek wrote:
Hi,
On 6.4.2018 11:13, Jean-Jacques Hiblot wrote:
Enhancements to SCSI support for driver model have broken the support for
DM_SCSI on DRA7 platforms. This series fixes it.
Tested on:
- dra76 evm
Jean-Jacques Hiblot (2):
dwc_ahci: Fix breakage
Hi,
On 6.4.2018 11:13, Jean-Jacques Hiblot wrote:
> Enhancements to SCSI support for driver model have broken the support for
> DM_SCSI on DRA7 platforms. This series fixes it.
>
> Tested on:
> - dra76 evm
>
>
> Jean-Jacques Hiblot (2):
> dwc_ahci: Fix breakage
> configs: dra7xx_evm/dra7xx_
On Tue, Feb 21, 2017 at 5:17 AM, Philipp Tomsich
wrote:
> This changeset adds support for the A64-uQ7 modules from Theobroma
> Systems, which is based on Allwinner's A64 (sun50iw1p1).
>
> It depends on the device-model support for the sunxi subarchitecture
> and the DM-based, dual-IO capable SPI d
On Sun, Apr 23, 2017 at 09:38:58PM -0600, Simon Glass wrote:
> +Tom
>
> Hi Chris,
>
> On 21 April 2017 at 10:27, Chris Packham wrote:
> >
> > The first patch is the addition of a KConfig option for the date
> > command. I haven't updated any boards to use the new option due to the
> > sheer numb
+Tom
Hi Chris,
On 21 April 2017 at 10:27, Chris Packham wrote:
>
> The first patch is the addition of a KConfig option for the date
> command. I haven't updated any boards to use the new option due to the
> sheer number of boards that would affect. It's probably better if board
> maintainers swi
Hi Eric
Please don't forget the title of cover letter next time.
2017-04-18 16:21 GMT+08:00 Eric Gao :
> Add bmp logo display support for evb-rk3399
>
Can you elaborate the commit message?
>
>
> Changes in v1:
> -Add bmp logo display support.
> -Enable logo display for evb-rk3399
>
> Eric Gao (
On Tue, Feb 21, 2017 at 07:21:42PM +0100, Dr. Philipp Tomsich wrote:
>
> > On 21 Feb 2017, at 18:45, Maxime Ripard
> > wrote:
> >
> > However, I'm a bit skeptical on the /config node. First, this node
> > doesn't exist at all, and needs to be documented and acked by the DT
> > maintainers. And
> On 22 Feb 2017, at 07:11, Rask Ingemann Lambertsen wrote:
>
> On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote:
>> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs
>> (the SPL code needs to reside an 8K offset into the device), we add
>> support for leaving a
On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote:
> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs
> (the SPL code needs to reside an 8K offset into the device), we add
> support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1)
> and GPT partition e
> On 21 Feb 2017, at 18:45, Maxime Ripard
> wrote:
>
> However, I'm a bit skeptical on the /config node. First, this node
> doesn't exist at all, and needs to be documented and acked by the DT
> maintainers. And why would one need to change that per device?
What’s the consensus on this: remove
Maxime,
> On 21 Feb 2017, at 18:45, Maxime Ripard
> wrote:
>
> Hi Philipp,
>
> On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote:
>> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs
>> (the SPL code needs to reside an 8K offset into the device), we add
>> supp
On Fri, Feb 17, 2017 at 06:46:51PM +0100, Philipp Tomsich wrote:
> To ensure compatibility with all PHYs, we need to keep the MDIO clock
> (MDC) below 2.5MHz (the guaranteed operating limit from IEEE 802.3),
> even if some PHYs will tolerate higher speeds.
>
> This changeset also cleans up the MDI
Hi Philipp,
On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote:
> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs
> (the SPL code needs to reside an 8K offset into the device), we add
> support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1)
> and GP
Hi Andreas,
There are several patches I sent two months ago using the your older mail
address,
I am not sure if you received them successfully. If not, I will resent them.
Sorry for the inconvenience caused.
Best Regards,
Wenyou Yang
> -Original Message-
> From: Wenyou Yang [mailto:we
Hello Andrew,
Am 06.10.2016 um 18:29 schrieb Andrew F. Davis:
On 10/06/2016 12:55 AM, Heiko Schocher wrote:
This 2 patches move SPL_OS_BOOT and SYS_OS_BASE
to Kconfig. Checked with tbot testcase:
https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py
result:
Boards
On Thu, Oct 06, 2016 at 11:29:27AM -0500, Andrew F. Davis wrote:
> On 10/06/2016 12:55 AM, Heiko Schocher wrote:
> > This 2 patches move SPL_OS_BOOT and SYS_OS_BASE
> > to Kconfig. Checked with tbot testcase:
> > https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py
> >
On 10/06/2016 12:55 AM, Heiko Schocher wrote:
> This 2 patches move SPL_OS_BOOT and SYS_OS_BASE
> to Kconfig. Checked with tbot testcase:
> https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py
>
> result:
>
> Boards : 1213
> compile err : 13
> not checked : 1
> U
On 29/10/2015 11:40, Heiko Schocher wrote:
> Hello Stefano,
>
> Am 25.09.2015 um 12:31 schrieb Heiko Schocher:
>> setting the gpr 1,8 and 12 registers to a fix value.
>> This is needed because after a WDT reset, this registers
>> are not correct resettet, and prevent linux from booting
>> again.
>
Hello Stefano,
Am 25.09.2015 um 12:31 schrieb Heiko Schocher:
setting the gpr 1,8 and 12 registers to a fix value.
This is needed because after a WDT reset, this registers
are not correct resettet, and prevent linux from booting
again.
with this patches no compileerrors found:
$ ./tools/buildma
Hello York,
For T1040QDS, we can change the name.
For T1024 also, I think there should not be any issue. Shengzhou please confirm.
Regards
Priyanka
From: Sun York-R58495
Sent: Monday, August 10, 2015 8:18 PM
To: Jain Priyanka-B32167; Sun York-R58495; U-Boot Mailing List
Cc: Wood Scott-B07421; S
Priyanka,
If the boards have been officially named T1040D4RDB/T1042D4RDB, we can keep the
names. How about QDS and T1024 boards?
York
Original message
From: Jain Priyanka-B32167
Date:08/09/2015 22:01 (GMT-08:00)
To: Sun York-R58495 , U-Boot Mailing List
Cc: Wood Scott-B07421
Hello York,
T1040D4RDB/T1042D4RDB boards have other difference as well apart from DDR4
w.r.t old T1040RDB/T1042RDB.
T1040D4RDB/T1042D4RDB is the naming convection that has been used to
distinguished new T1040RDB/T1042RDB board with DDR4 memory, new serdes protocol
support , new muxes , etc.
If
Hi all
> -Ursprüngliche Nachricht-
> Von: Heiko Schocher [mailto:h...@denx.de]
> Gesendet: Dienstag, 9. September 2014 16:22
> An: Lukasz Majewski
> Cc: u-boot@lists.denx.de; Tom Rini; Marek Vasut; Liu Bin; Stockmann, Lukas
> Betreff: Re: [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fulls
Hi Bin,
> Lukasz,
>
> On 09/09/2014 08:43 AM, Lukasz Majewski wrote:
> > Hi Heiko,
> >
> >> This patchserie adds the new config option CONFIG_DFU_FULLSPEED.
> >
> > Is there any special reason to support Full Speed (12 Mbit/sec - USB
> > 1.1) and not rely solely on the High Speed (USB 2.0) as we
Hello Lukasz,
Am 09.09.2014 15:43, schrieb Lukasz Majewski:
Hi Heiko,
This patchserie adds the new config option CONFIG_DFU_FULLSPEED.
Is there any special reason to support Full Speed (12 Mbit/sec - USB
1.1) and not rely solely on the High Speed (USB 2.0) as we do now?
If this is enabled
Lukasz,
On 09/09/2014 08:43 AM, Lukasz Majewski wrote:
Hi Heiko,
This patchserie adds the new config option CONFIG_DFU_FULLSPEED.
Is there any special reason to support Full Speed (12 Mbit/sec - USB
1.1) and not rely solely on the High Speed (USB 2.0) as we do now?
The drivers must suppor
Hi Heiko,
> This patchserie adds the new config option CONFIG_DFU_FULLSPEED.
Is there any special reason to support Full Speed (12 Mbit/sec - USB
1.1) and not rely solely on the High Speed (USB 2.0) as we do now?
> If this is enabled DFU uses fullspeed only. This is used on the
> siemens boards.
Ping.
2014-06-30 13:05 GMT+02:00 :
> From: Dirk Eibach
>
>
>
>
> Dirk Eibach (2):
> ppc: Make ppc4xx ready for CONFIG_SYS_GENERIC_BOARD
> board: Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards
>
> arch/powerpc/cpu/ppc4xx/cpu_init.c | 2 ++
> include/configs/controlcenterd.h | 2 ++
> inc
Hi Pekon,
On Tue, Jan 28, 2014 at 07:42:09AM +, Pekon Gupta wrote:
> >From: Brian Norris
> >
> >On Fri, Dec 13, 2013 at 02:42:56PM +0530, Pekon Gupta wrote:
> >> As there were parallel set of patches running between u-boot and kernel.
> >
> >I don't know what patches you're talking about.
> >
Hi Brian,
>From: Gupta, Pekon
>>I'm preparing a 3.14 pull request soon, and since you seem committed to
>>fixing and properly testing a known regression here, I'd like to see
>>this go in. But given the late timing and the unanswered questions, I
>>think it's unlikely to go in -rc1. Perhaps I can
Hi Brian,
>From: Brian Norris
>
>Hi Pekon,
>
>Sorry, I'm revisiting your patch series a bit late. There are a few
>factors that contributed to this, though.
>
>1. This patch series talks extensively about U-Boot. U-Boot is not my
> interest, nor should it be the focus of kernel (driver) developm
Hi Brian,
>From: Brian Norris
>
>1. This patch series talks extensively about U-Boot. U-Boot is not my
> interest, nor should it be the focus of kernel (driver) development.
> Any work done here should be framed in the kernel driver context. [1]
>
Apologies for cross-posting, I understand that
On Mon, Jan 27, 2014 at 9:46 AM, Gupta, Pekon wrote:
>>From: Brian Norris
>>
>>1. This patch series talks extensively about U-Boot. U-Boot is not my
>> interest, nor should it be the focus of kernel (driver) development.
>> Any work done here should be framed in the kernel driver context. [1]
Hi Pekon,
Sorry, I'm revisiting your patch series a bit late. There are a few
factors that contributed to this, though.
1. This patch series talks extensively about U-Boot. U-Boot is not my
interest, nor should it be the focus of kernel (driver) development.
Any work done here should be fra
Hi Brian,
>From: Enric Balletbo Serra [mailto:eballe...@gmail.com]
>>2014/1/6 Stefan Roese :
...
As there were parallel set of patches running between u-boot and kernel.
hence, some patch-sets caused regression for OMAP3x platforms when booting
using u-boot specifically for ecc-sche
Hi Pekon,
On 06.01.2014 08:40, Gupta, Pekon wrote:
> Hello Enric, Nikita, and other OMAP3 users,
>
>>
>> As there were parallel set of patches running between u-boot and kernel.
>> hence, some patch-sets caused regression for OMAP3x platforms when booting
>> using u-boot specifically for ecc-sche
Hello Enric, Nikita, and other OMAP3 users,
>
>As there were parallel set of patches running between u-boot and kernel.
>hence, some patch-sets caused regression for OMAP3x platforms when booting
>using u-boot specifically for ecc-schemes (like BCH4_SW).
>
>Hence this patch series fixes those regr
48 matches
Mail list logo
