Hello Heiko,
Le 30/06/2017 à 06:15, Heiko Schocher a écrit :
Hello Christophe,
Am 29.06.2017 um 18:51 schrieb Christophe LEROY:
Dear Wolfgang,
Le 23/06/2017 à 14:11, Wolfgang Denk a écrit :
Dear Christophe,
In message <71d351cb-2c42-99a0-0b4b-64cfa74ec...@c-s.fr> you wrote:
Ok, noted. Ple
Hi Eddie,
> 2017-06-29 18:49 GMT+08:00 Lukasz Majewski :
> > On Thu, 29 Jun 2017 08:44:47 +0800
> > Eddie Cai wrote:
> >
> >> >
> >> > The issue is not with this one particular board.
> >> >
> >> > I'm concerned, since your patch set causes build errors for other
> >> > boards.
> >> >
> >> > Can
Hi Vanessa, hi Fabio,
On 29/06/2017 14:33, Vanessa Maegima wrote:
> From: Fabio Estevam
>
> Currently the following build error is seen when a board using MMC SPL
> is built and the MXS nand driver is also selected:
>
> arch/arm/cpu/armv7/built-in.o: In function `arch_cpu_init':
> arch/arm/cpu/
On 29/06/2017 14:33, Vanessa Maegima wrote:
> Add support for mx6q, mx6dl and mx6qp sabreauto boards in SPL.
>
> Retrieved the mx6q DCD table from:
> board/freescale/mx6qsabreauto/imximage.cfg
>
> Retrieved the mx6dl DCD table from:
> board/freescale/mx6qsabreauto/mx6dl.cfg
>
> Retrieved the mx6
On 29/06/2017 14:33, Vanessa Maegima wrote:
> As mx6sabreauto supports SPL now, all variants can boot using the same
> defconfig.
>
> This patch:
> - Removes non-SPL targets.
> - Renames target to mx6sabreauto_defconfig.
> - Renames folder and board files to mx6sabreauto.
> - Updates MAINTAINERS,
On Fri, Jun 30, 2017 at 12:48:20PM +0900, Jaehoon Chung wrote:
> Dear Tom,
>
> Could you pull these patches into u-boot/master?
> If there is a problem, let me know, plz.
>
> The following changes since commit 08546df976b79b1694af3ff12b26baf2931f371a:
>
> Merge git://git.denx.de/u-boot-x86 (2
Hi Stefano,
On Fri, Jun 30, 2017 at 5:51 AM, Stefano Babic wrote:
> But if this is the case, should we not also add a dependency in Kconfig
> for NAND_MXS, selecting automatically APBH_DMA ?
>
> config NAND_MXS
> bool "MXS NAND support"
> depends on MX6 || MX7
> + select AP
Hi Tom,
On Thu, Jun 29, 2017 at 10:00:55AM -0400, Tom Rini wrote:
> On Wed, Jun 28, 2017 at 09:19:43PM +0300, Baruch Siach wrote:
> > Since commit 5b9d44df2307f (mkimage: Display a better list of available
> > image
> > types) mkimage usage text suggest to "use -T to see a list of available
> >
Since commit 5b9d44df2307f (mkimage: Display a better list of available image
types) mkimage usage text suggest to "use -T to see a list of available image
types". Unfortunately, commit 02221f29deb8 (mkimage: Convert to use getopt())
broke that feature, because getopt() fails when -T has no option
Hi all,
This is Shiwen, good morning! :)
I wan to do fast boot for arm , but I am not familiar with U-boot, as title
says, I'm curious that U-boot for smdk2410 allow snapshot restoration? If
allowed, can you tell me witch function do this work?
Any advice will be appreciated, thanks.
Have a ni
Hi all,
This is Shiwen, good morning! :)
I wan to do fast boot for arm , but I am not familiar with U-boot, as title
says, I'm curious that U-boot for smdk2410 allow snapshot restoration? If
allowed, can you tell me witch function do this work?
Any advice will be appreciated, thanks.
Have a ni
Hi Fabio,
On 30/06/2017 13:21, Fabio Estevam wrote:
> Hi Stefano,
>
> On Fri, Jun 30, 2017 at 5:51 AM, Stefano Babic wrote:
>
>> But if this is the case, should we not also add a dependency in Kconfig
>> for NAND_MXS, selecting automatically APBH_DMA ?
>>
>> config NAND_MXS
>> bool "MXS
Hi Tom,
On 06/30/2017 07:48 PM, Tom Rini wrote:
> On Fri, Jun 30, 2017 at 12:48:20PM +0900, Jaehoon Chung wrote:
>
>> Dear Tom,
>>
>> Could you pull these patches into u-boot/master?
>> If there is a problem, let me know, plz.
>>
>> The following changes since commit 08546df976b79b1694af3ff12b26b
Hi Stefano,
On Fri, Jun 30, 2017 at 8:49 AM, Stefano Babic wrote:
> I agree with you, the rest requires more cleanup and should be done in
> separate patches.
Great, so I will submit the Kconfig cleanups separately as suggested.
Thanks
___
U-Boot mai
Dear Christophe,
In message <7335469c-1e12-c59c-4ac4-3fda0f665...@c-s.fr> you wrote:
>
> > 8xx is gone. Please get used to that fact.
>
> Yes he is gone by accident, lets get it back as some orphan boards need it.
This discussionis useless, but please understand that this was in no
way an acci
Dear Christophe,
In message <20170629165215.9672c67...@pc13941vm.idsi0.si.c-s.fr> you wrote:
>
> This commit partially restores support for the 8xx, with the
> following limitations:
Hmm... may I ask what you use as reference for this patch? It
appears I cannot apply it to curent mainline:
-> g
Dear Christophe,
In message <20170629165215.9672c67...@pc13941vm.idsi0.si.c-s.fr> you wrote:
>
> This commit partially restores support for the 8xx, with the
> following limitations:
checkpatch complains about this patch like this:
total: 97 errors, 714 warnings, 87 checks, 6380 lines ch
Dear Christophe Leroy,
In message
<8947f895b86efe0396b1825998a64a3340fff597.1498751837.git.christophe.le...@c-s.fr>
you wrote:
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/cpu/mpc8xx/cpu_init.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/cpu/mpc
The 82xx board mgcoge3ne was removed from the codebase, so this is dead
code.
Signed-off-by: Holger Brunck
Cc: Heiko Schocher
---
board/keymile/common/common.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c
index 0829b7fa06..4
Hello Holger,
Am 30.06.2017 um 15:33 schrieb Holger Brunck:
The 82xx board mgcoge3ne was removed from the codebase, so this is dead
code.
Signed-off-by: Holger Brunck
Cc: Heiko Schocher
---
board/keymile/common/common.c | 3 ---
1 file changed, 3 deletions(-)
nice catch! Thanks!
Reviewe
On Fri, Jun 30, 2017 at 03:50:28PM +0200, Ricardo Ribalda Delgado wrote:
> Hi
>
> On Thu, Jun 29, 2017 at 7:26 PM, Tom Rini wrote:
>
>
> > I also recall this. Ricardo? Do you still have interest here?
> > Otherwise I'm going to remove these soon, thanks!
>
> This also makes me quite sad. It
Hi
On Thu, Jun 29, 2017 at 7:26 PM, Tom Rini wrote:
> I also recall this. Ricardo? Do you still have interest here?
> Otherwise I'm going to remove these soon, thanks!
This also makes me quite sad. It has been my first big contribution to OS.
I personally do not have the time to maintain i
This patch allows uboot to handle overlays in a manner that uses
a base DT blob and an arbitrary number of DT overlays blobs.
It is intended to be used with FIT images since handling a multitude
of device tree blobs manually is a chore.
The first 3 patches have already been submitted to DTC for r
Overlays require malloc so add it in the libfdt environment.
Signed-off-by: Pantelis Antoniou
---
include/libfdt_env.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/libfdt_env.h b/include/libfdt_env.h
index 6c6845f..59463c0 100644
--- a/include/libfdt_env.h
+++ b/include/libfdt_env
Introduce FDT_PATH_MAX
Signed-off-by: Pantelis Antoniou
---
lib/libfdt/libfdt.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/libfdt/libfdt.h b/lib/libfdt/libfdt.h
index 2f7ebf8..c369015 100644
--- a/lib/libfdt/libfdt.h
+++ b/lib/libfdt/libfdt.h
@@ -100,6 +100,9 @@
#define FDT_ER
Introduce an overlay based method for constructing a base DT blob
to pass to the kernel.
Both canned and runtime feature selection is supported.
Signed-off-by: Pantelis Antoniou
---
common/image-fdt.c | 7 +-
common/image-fit.c | 215 +++
Verify that stacked overlays work.
Signed-off-by: Pantelis Antoniou
---
test/overlay/Makefile | 1 +
test/overlay/cmd_ut_overlay.c | 34 ++-
test/overlay/test-fdt-overlay-stacked.dts | 21 +++
3 files changed, 55 insert
This patch enables an overlay to refer to a previous overlay's
labels by performing a merge of symbol information at application
time.
In a nutshell it allows an overlay to refer to a symbol that a previous
overlay has defined. It requires both the base and all the overlays
to be compiled with the
Wolfgang Denk a écrit :
Dear Christophe,
In message <20170629165215.9672c67...@pc13941vm.idsi0.si.c-s.fr> you wrote:
This commit partially restores support for the 8xx, with the
following limitations:
Hmm... may I ask what you use as reference for this patch? It
appears I cannot apply it
Dear Christophe,
In message <20170630190420.horde.wz1ezqqb1mporrqdyjko...@messagerie.c-s.fr> you
wrote:
>
> I did rebase it to the mainline a few minutes before sending it.
> Did you apply 4xx removal patch first ? I wrote it in the patch after
> the ---, it is the way we do it in Linux, maybe
On Fri, Jun 30, 2017 at 09:20:19PM +0200, Wolfgang Denk wrote:
> Dear Christophe,
>
> In message <20170630190420.horde.wz1ezqqb1mporrqdyjko...@messagerie.c-s.fr>
> you wrote:
> >
> > I did rebase it to the mainline a few minutes before sending it.
> > Did you apply 4xx removal patch first ? I wr
I am trying to add in Android Fastboot to my i.MX6Q.
I am using DM_USB to enable the USB through the device tree. This
device tree works in Linux, so I am assumming I've missed some
configuration somewhere:
I've added the following the defconfig file:
+CONFIG_CMD_USB=y
+CONFIG_DM_USB=y
+CONFIG_
On Fri, Jun 30, 2017 at 4:39 PM, Adam Ford wrote:
> I am trying to add in Android Fastboot to my i.MX6Q.
>
> I am using DM_USB to enable the USB through the device tree. This
> device tree works in Linux, so I am assumming I've missed some
> configuration somewhere:
>
> I've added the following t
On 03/12/2017 09:26 AM, Jonathan Gray wrote:
> Add some of the invalid parameter checks described in the UEFI
> specification for CreateEvent(). This does not include checking
> the validity of the type and tpl parameters.
>
> Signed-off-by: Jonathan Gray
> ---
> lib/efi_loader/efi_boottime.c |
This change sets the VLDO4 settings output to 2.8V in PMIC
initialization. I accidentally noticed this when I was testing
the DSI voltage input which was 3.3V. Not setting the proper voltage
can harm some of the voltage sensitive peripheral.
Changes in v2:
- Removed extra parentheses for 0xF.
- M
This change sets the VLDO4 settings output to 2.8V in PMIC
initialization so that the MIPI DSI/CSI input voltage is 2.8V
as per the schematics. The original code provides an output of
3.3V which violates the voltage mentioned in the schematics.
Acked-by: Fabio Estevam
Signed-off-by: Gautam Bhat
36 matches
Mail list logo
