On Sun, May 05, 2013 at 11:43:47AM +0400, Antony Pavlov wrote:
> Signed-off-by: Antony Pavlov
Applied, thanks
Sascha
> ---
> drivers/clk/clkdev.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 338b9e8..256927e 10
On Fri, May 03, 2013 at 06:51:05PM +0200, Thomas Petazzoni wrote:
> The checkpatch.pl script is also used to validate user-space code in
> the scripts/ directory, so it should allow printf() lines to be longer
> than 80 columns.
>
> Signed-off-by: Thomas Petazzoni
Applied this one for now. The r
On Mon, May 06, 2013 at 10:44:29AM +0400, Alexander Shiyan wrote:
>
> Signed-off-by: Alexander Shiyan
Applied, thanks
Sascha
> ---
> arch/arm/boards/ccxmx51/ccxmx51js.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boards/ccxmx51/ccxmx51js.c
> b/arch/arm
Dear Sascha Hauer,
On Mon, 6 May 2013 09:23:44 +0200, Sascha Hauer wrote:
> On Fri, May 03, 2013 at 06:51:05PM +0200, Thomas Petazzoni wrote:
> > The checkpatch.pl script is also used to validate user-space code in
> > the scripts/ directory, so it should allow printf() lines to be longer
> > than
Hi All,
We have a may release. As usual here are the patches applied since the
last release. Most notable change this time is that we no longer use
libfdt which brings us a step closer to good devicetree support in
barebox.
Sascha
---
> Hello.
>
> Is anyone have successful works OTG in device mode on iMX51?
> Thanks!.
ping
---
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
On Mon, May 06, 2013 at 01:52:11PM +0400, Alexander Shiyan wrote:
> > Hello.
> >
> > Is anyone have successful works OTG in device mode on iMX51?
> > Thanks!.
>
> ping
I have the driver working in devicemode on several boards, but not on an
i.MX51 I think. I have no indication though that the UD
> On Mon, May 06, 2013 at 01:52:11PM +0400, Alexander Shiyan wrote:
> > > Hello.
> > >
> > > Is anyone have successful works OTG in device mode on iMX51?
> > > Thanks!.
>
> I have the driver working in devicemode on several boards, but not on an
> i.MX51 I think. I have no indication though that
Signed-off-by: Alexander Shiyan
---
arch/arm/boards/pcm038/pcm038.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boards/pcm038/pcm038.c b/arch/arm/boards/pcm038/pcm038.c
index 4b2fa6c..3aec320 100644
--- a/arch/arm/boards/pcm038/pcm038.c
+++ b/a
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Sun, 5 May 2013 13:19:27 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > > > This patch adds a tool that allows to extract the components and
> > > > configuration of existing images, and to create new images.
> > >
> > > I don't like this
> >
> > Wh
Dear Sascha Hauer,
On Sun, 5 May 2013 08:33:18 +0200, Sascha Hauer wrote:
> > > Great work! Very clean series. I only have one thought. Prafulla
> > > (u-boot kirkwood maintainer) is always asking about consolidating the
> > > kwbimage.cfg files. The three you've submitted for the first three
On 15:53 Mon 06 May , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Sun, 5 May 2013 13:19:27 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > > > > This patch adds a tool that allows to extract the components and
> > > > > configuration of existing images, and
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > Could you please adopt a nicer language? You are very aggressive... and
> > at that the same time completely wrong. Your comments make it entirely
> > clear that you haven't even
On 16:06 Mon 06 May , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > > Could you please adopt a nicer language? You are very aggressive... and
> > > at that the same time completely wrong.
Sascha, Jean-Christophe,
I have one question below regarding the SoC code.
On Fri, 3 May 2013 18:51:08 +0200, Thomas Petazzoni wrote:
> +static inline void mvebu_memory_find(unsigned long *phys_base,
> + unsigned long *phys_size)
> +{
> + void __iomem *sdram_
On 16:09 Mon 06 May , Thomas Petazzoni wrote:
> Sascha, Jean-Christophe,
>
> I have one question below regarding the SoC code.
>
> On Fri, 3 May 2013 18:51:08 +0200, Thomas Petazzoni wrote:
> > +static inline void mvebu_memory_find(unsigned long *phys_base,
> > +
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Mon, 6 May 2013 16:04:39 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > > > Could you please adopt a nicer language? You are very aggressive... and
> > > > at that the same time completely wrong. Your comments make it entirely
> > > > clear that you h
On 16:13 Mon 06 May , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Mon, 6 May 2013 16:04:39 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > > > > Could you please adopt a nicer language? You are very aggressive...
> > > > > and
> > > > > at that the same tim
On Mon, May 06, 2013 at 04:04:39PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 16:06 Mon 06 May , Thomas Petazzoni wrote:
> > Dear Jean-Christophe PLAGNIOL-VILLARD,
> >
> > On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
> > wrote:
> >
> > > > Could you please ado
On Mon, May 06, 2013 at 04:09:16PM +0200, Thomas Petazzoni wrote:
> Sascha, Jean-Christophe,
>
> I have one question below regarding the SoC code.
>
> On Fri, 3 May 2013 18:51:08 +0200, Thomas Petazzoni wrote:
> > +static inline void mvebu_memory_find(unsigned long *phys_base,
> > +
Dear Sascha Hauer,
On Mon, 6 May 2013 16:30:30 +0200, Sascha Hauer wrote:
> > ... and here, I'm directly poking at physical addresses, but it seems
> > like Barebox can run with the MMU enabled. Should I be mapping those
> > registers before accessing them?
>
> We use the MMU, but we use a 1:1 m
On Mon, May 06, 2013 at 04:34:24PM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
>
> On Mon, 6 May 2013 16:30:30 +0200, Sascha Hauer wrote:
>
> > > ... and here, I'm directly poking at physical addresses, but it seems
> > > like Barebox can run with the MMU enabled. Should I be mapping thos
Jean-Christophe,
On Mon, May 06, 2013 at 04:14:47PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > 2) Because it's useful to extract the binary blob needed to configure
> > the DDR3 timing dynamically (for Armada 370/XP).
>
> You do not read the comment
>
> we need *runtime* update not *o
Dear Sascha Hauer,
On Mon, 6 May 2013 16:46:34 +0200, Sascha Hauer wrote:
> > > We use the MMU, but we use a 1:1 mapping. The SDRAM is mapped cached and
> > > the rest is mapped uncached. This means you can simply access all
> > > registers without mapping them
> >
> > Ok, thanks. So you're not
Signed-off-by: Lucas Stach
---
arch/arm/dts/tegra20-paz00.dts | 216 +
1 file changed, 216 insertions(+)
diff --git a/arch/arm/dts/tegra20-paz00.dts b/arch/arm/dts/tegra20-paz00.dts
index 09ccb8b..e8486aa 100644
--- a/arch/arm/dts/tegra20-paz00.dts
+++ b/a
This adds a pinctrl driver for the Tegra 20 line of SoCs. It only
supports the three basic pinconfiguration settings function mux,
tristate control and pullup/down control.
The driver understands the same devicetree bindings as the Linux one,
unimplemented pinconfiguration options will be ignored.
On Mon, May 06, 2013 at 05:23:56PM +0400, Alexander Shiyan wrote:
> > On Mon, May 06, 2013 at 01:52:11PM +0400, Alexander Shiyan wrote:
> > > > Hello.
> > > >
> > > > Is anyone have successful works OTG in device mode on iMX51?
> > > > Thanks!.
> >
> > I have the driver working in devicemode on s
On 16:56 Mon 06 May , Lucas Stach wrote:
> This adds a pinctrl driver for the Tegra 20 line of SoCs. It only
> supports the three basic pinconfiguration settings function mux,
> tristate control and pullup/down control.
>
> The driver understands the same devicetree bindings as the Linux one,
On Fri, May 03, 2013 at 06:51:06PM +0200, Thomas Petazzoni wrote:
> The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> that understand a specific image format, composed of a main header,
> several extension headers and a paylod. This image can be booted from
> NAND, SPI, SATA,
On Fri, May 03, 2013 at 06:51:04PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> Here is a patch set that adds basic support for the Marvell Armada 370
> and Armada XP SoC. For now, the support is quite minimal, since only
> the serial port is supported. However, a significant part of the work
> has
On 16:31 Mon 06 May , Willy Tarreau wrote:
> Jean-Christophe,
>
> On Mon, May 06, 2013 at 04:14:47PM +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> > > 2) Because it's useful to extract the binary blob needed to configure
> > > the DDR3 timing dynamically (for Armada 370/XP).
> >
> > Y
On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > that understand a specific image format, composed of a main header,
> > several extens
On 10:21 Mon 06 May , Jason Cooper wrote:
> On Mon, May 06, 2013 at 04:04:39PM +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> > On 16:06 Mon 06 May , Thomas Petazzoni wrote:
> > > Dear Jean-Christophe PLAGNIOL-VILLARD,
> > >
> > > On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLA
On Mon, May 06, 2013 at 09:34:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > > This is the barebox update that will ensure a binary is correct before
> > > flashing and can only request barebox and not the blob stuff to udpate
> > > itself
> >
> > I have read your comments as well and s
On Mon, May 06, 2013 at 05:27:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > +
> > +static struct pinctrl_ops pinctrl_tegra20_ops = {
> > + .set_state = pinctrl_tegra20_set_state,
> > +};
> > +
> > +static int pinctrl_tegra20_probe(struct device_d *dev)
> > +{
> > + struct pinctrl_teg
Hello,
On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
> > And it's does not require you to generate the image before flashing.
> > And request the blob by XMODEM will NEVER work to update at runtime
> > as can not discuss with the ROM code via XMODEM. So yes this will
> > not work for se
Dear Sascha Hauer,
On Mon, 6 May 2013 21:16:15 +0200, Sascha Hauer wrote:
> > quiet_cmd_csingle = CC $@
> > - cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
> > + cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
>
> This is a whitespace change only, right?
Dear Sascha Hauer,
On Mon, 6 May 2013 21:28:26 +0200, Sascha Hauer wrote:
> So now I have the DDR3 training blob and the payload. I would then
> replace the payload with barebox and call kwbimage again to generate
> a new image, right?
Exact, that's what I'm doing for the moment: retrieve a u-bo
On 22:21 Mon 06 May , Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
>
> > > And it's does not require you to generate the image before flashing.
> > > And request the blob by XMODEM will NEVER work to update at runtime
> > > as can not discuss wi
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Mon, 6 May 2013 22:35:40 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> this is where it's wrong, you does not need such binary at all, barebox update
> will handle this by himself and will never requiere one image per media
>
> As barebox does not car
On Mon, May 06, 2013 at 10:35:40PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 22:21 Mon 06 May , Thomas Petazzoni wrote:
> > Hello,
> >
> > On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
> >
> > > > And it's does not require you to generate the image before flashing.
> > >
On 21:59 Mon 06 May , Sascha Hauer wrote:
> On Mon, May 06, 2013 at 05:27:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> > > +
> > > +static struct pinctrl_ops pinctrl_tegra20_ops = {
> > > + .set_state = pinctrl_tegra20_set_state,
> > > +};
> > > +
> > > +static int pinctrl_tegra20_p
On Mon, May 06, 2013 at 10:44:56PM +0200, Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Mon, 6 May 2013 22:35:40 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > this is where it's wrong, you does not need such binary at all, barebox
> > update
> > will handle thi
Dear Sascha Hauer,
On Mon, 6 May 2013 22:56:31 +0200, Sascha Hauer wrote:
> > > Barebox update will generate the correct image for the storagemedia at
> > > runtime
> >
> > What is "Barebox update" ?
>
> barebox_update is a command that you can call during runtime to update
> barebox. Over writ
The prefix/cleanup series
ad09b59f8bb58c27e3872b41f41beb1b9eb1aeb1
a8c6359667704ffc3bd2249dd76f3fbbb2134b55
4c53af062b38f15f6bc40c586e5760e640f5b8b1
missed a few unprefixed IOMUXC_BASE define users. Fix these.
Signed-off-by: Andreas Pretzsch
---
arch/arm/mach-imx/include/
Patches against tag v2013.05.0.
Functionality tested on customer-specific pcm037 variant with 2013.03.0.
Compile-tested against pcm037_defconfig with 2013.05.0.
Relevant code base is unchanged between versions, no issues expected.
Andreas Pretzsch (2):
ARM i.MX31: cleanup MX31_ prefix: fix lefto
In commit ad09b59f8bb58c27e3872b41f41beb1b9eb1aeb1 "ARM i.MX31: give
register base addresses a proper MX31_ prefix", the IOMUX GPR setup
to enable USBH2 was replaced with an incorrect source register.
Instead of reading the GPR register, USBOTG HWHOST is used as rmw source,
which contains 0x1002000
On Mon, May 06, 2013 at 11:03:37PM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
>
> On Mon, 6 May 2013 22:56:31 +0200, Sascha Hauer wrote:
>
> > > > Barebox update will generate the correct image for the storagemedia at
> > > > runtime
> > >
> > > What is "Barebox update" ?
> >
> > bareb
On Mon, May 06, 2013 at 11:21:26PM +0200, Andreas Pretzsch wrote:
> Patches against tag v2013.05.0.
> Functionality tested on customer-specific pcm037 variant with 2013.03.0.
> Compile-tested against pcm037_defconfig with 2013.05.0.
> Relevant code base is unchanged between versions, no issues expe
49 matches
Mail list logo
