Re: [PATCH] uboot-lantiq: fix out of bounds cache invalidate

[Daniel Schwierzeck]

Am Mittwoch, dem 10.11.2021 um 21:59 +0100 schrieb Mathias Kresin:
> 11/3/21 2:43 PM, Daniel Schwierzeck:
> > Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin:
> > > If u-boot is compiled with gcc 10+ the relevant part of the
> > > memory is
> > > used as following:
> > > 
> > > variable BootFile is at address: 0x83ffe4ec
> > > variable data is at address: 0x83ffdee2
> > > variable data has len:   0x600
> > > 
> > > Within invalidate_dcache_range() the cache covering the data
> > > variable
> > > should be invalidated (0x83ffdee2 till 0x83ffdef2).
> > > 
> > > Due to dcache line size of 32 and some alignment correction, the
> > > actual
> > > memory range for which the cache is invalidated is from
> > > 0x83ffdee0
> > > till
> > > 0x83ffe500, which includes the location of the BootFile variable
> > > as
> > > well.
> > > 
> > > Afterwards the BootFile variable is 0. The issue can be observed
> > > by
> > > using tftpboot, which always uses the default/generated filename
> > > instead
> > > of the specified one.
> > > 
> > > To fix the issue, align the memory addresses properly before
> > > passing
> > > them to invalidate_dcache_range(). The misalignment can be
> > > observed
> > > with
> > > older gcc versions as well but the BootFile variable is placed
> > > more
> > > than
> > > 0x1000 bytes after the data variable and doesn't get null'ed.
> > > 
> > > Fixes: FS#4113
> > > 
> > > Signed-off-by: Mathias Kresin 
> > > ---
> > >   ...q-fix-out-of-bounds-cache-invalidate.patch | 48
> > > +++
> > >   1 file changed, 48 insertions(+)
> > >   create mode 100644 package/boot/uboot-lantiq/patches/0031-dma-
> > > lantiq-fix-out-of-bounds-cache-invalidate.patch
> > > 
> > > diff --git a/package/boot/uboot-lantiq/patches/0031-dma-lantiq-
> > > fix-
> > > out-of-bounds-cache-invalidate.patch b/package/boot/uboot-
> > > lantiq/patches/0031-dma-lantiq-fix-out-of-bounds-cache-
> > > invalidate.patch
> > > new file mode 100644
> > > index 00..5a2bf39441
> > > --- /dev/null
> > > +++ b/package/boot/uboot-lantiq/patches/0031-dma-lantiq-fix-out-
> > > of-
> > > bounds-cache-invalidate.patch
> > > @@ -0,0 +1,48 @@
> > > +From f10ffb65865d5bfa5679293b13e027e0474df1fe Mon Sep 17
> > > 00:00:00
> > > 2001
> > > +From: Mathias Kresin 
> > > +Date: Tue, 2 Nov 2021 21:24:29 +0100
> > > +Subject: [PATCH] dma: lantiq: fix out of bounds cache invalidate
> > > +
> > > +If u-boot is compiled with gcc 10+ the relevant part of the
> > > memory
> > > is
> > > +used as following:
> > > +
> > > +variable BootFile is at address: 0x83ffe4ec
> > > +variable data is at address: 0x83ffdee2
> > > +variable data has len:   0x600
> > > +
> > > +Within invalidate_dcache_range() the cache covering the data
> > > variable
> > > +should be invalidated (0x83ffdee2 till 0x83ffdef2).
> > > +
> > > +Due to dcache line size of 32 and some alignment correction, the
> > > actual
> > > +memory range for which the cache is invalidated is from
> > > 0x83ffdee0
> > > till
> > > +0x83ffe500, which includes the location of the BootFile variable
> > > as
> > > +well.
> > > +
> > > +Afterwards the BootFile variable is 0. The issue can be observed
> > > by
> > > +using tftpboot, which always uses the default/generated filename
> > > instead
> > > +of the specified one.
> > > +
> > > +To fix the issue, align the memory addresses properly before
> > > passing
> > > +them to invalidate_dcache_range(). The misalignment can be
> > > observed
> > > with
> > > +older gcc versions as well but the BootFile variable is placed
> > > more
> > > than
> > > +0x1000 bytes after the data variable and doesn't get null'ed.
> > > +
> > > +Signed-off-by: Mathias Kresin 
> > > +---
> > > + drivers/dma/lantiq_dma.c | 4 ++--
> > > + 1 file changed, 2 insertions(+), 2 deletions(-)
> > > +
> > > +--- a/drivers/dma/lantiq_dma.c
> > >  b/drivers/dma/lantiq_dma.c
> > > +@@ -122,9 +122,9 @@ static inline void ltq_dma_dcach

Re: [PATCH] uboot-lantiq: danube: fix SPL boot

[Daniel Schwierzeck]

Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin:
> On danube we only have 0x6800 bytes of usable SRAM. Everything behind
> can't be written to and a SPL u-boot locks up during boot.
> 
> Since it's a hard to debug issue and took me more than two years to
> fix
> it, I consider it worth to include fix albeit SPL u-boots are not
> build
> in OpenWrt.
> 
> I faced the issue while trying to shrink the u-boot to 64K since some
> board only have an u-boot partition of that size from the days ifx-
> uboot
> was used.
> 
> Signed-off-by: Mathias Kresin 
> ---
>  ...0032-MIPS-lantiq-danube-fix-SPL-boot.patch | 33
> +++
>  1 file changed, 33 insertions(+)
>  create mode 100644 package/boot/uboot-lantiq/patches/0032-MIPS-
> lantiq-danube-fix-SPL-boot.patch
> 
> diff --git a/package/boot/uboot-lantiq/patches/0032-MIPS-lantiq-
> danube-fix-SPL-boot.patch b/package/boot/uboot-lantiq/patches/0032-
> MIPS-lantiq-danube-fix-SPL-boot.patch
> new file mode 100644
> index 00..794fd8cc2a
> --- /dev/null
> +++ b/package/boot/uboot-lantiq/patches/0032-MIPS-lantiq-danube-fix-
> SPL-boot.patch
> @@ -0,0 +1,33 @@
> +From 65f1f160139c2bac83650c9c7c4aee4e5fd74c7c Mon Sep 17 00:00:00
> 2001
> +From: Mathias Kresin 
> +Date: Sun, 2 May 2021 02:03:05 +0200
> +Subject: [PATCH] MIPS: lantiq: danube: fix SPL boot
> +
> +On danube we only have 0x6800 bytes of usable SRAM. Everything
> behind
> +can't be written to and a SPL u-boot locks up during boot.
> +
> +Signed-off-by: Mathias Kresin 
> +---
> + arch/mips/include/asm/arch-danube/config.h | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +--- a/arch/mips/include/asm/arch-danube/config.h
>  b/arch/mips/include/asm/arch-danube/config.h
> +@@ -61,7 +61,7 @@
> + 
> + /* SRAM */
> + #define CONFIG_SYS_SRAM_BASE0xBE1A
> +-#define CONFIG_SYS_SRAM_SIZE0x1
> ++#define CONFIG_SYS_SRAM_SIZE0x6800

this is not really documented in the datasheets, but 0x6800 would
correspond to the PPE Shared Buffer size and seems to be correct.

> + 
> + /* ASC/UART driver and console */
> + #define CONFIG_LANTIQ_SERIAL
> +@@ -117,7 +117,7 @@
> + #define CONFIG_CMD_NET
> + #endif
> + 
> +-#define CONFIG_SPL_MAX_SIZE (32 * 1024)
> ++#define CONFIG_SPL_MAX_SIZE (18 * 1024)
> + #define CONFIG_SPL_BSS_MAX_SIZE (8 * 1024)
> + #define CONFIG_SPL_STACK_MAX_SIZE   (8 * 1024)
> + #define CONFIG_SPL_MALLOC_MAX_SIZE  (32 * 1024)

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] uboot-lantiq: fix out of bounds cache invalidate

[Daniel Schwierzeck]

Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin:
> If u-boot is compiled with gcc 10+ the relevant part of the memory is
> used as following:
> 
> variable BootFile is at address: 0x83ffe4ec
> variable data is at address: 0x83ffdee2
> variable data has len:   0x600
> 
> Within invalidate_dcache_range() the cache covering the data variable
> should be invalidated (0x83ffdee2 till 0x83ffdef2).
> 
> Due to dcache line size of 32 and some alignment correction, the
> actual
> memory range for which the cache is invalidated is from 0x83ffdee0
> till
> 0x83ffe500, which includes the location of the BootFile variable as
> well.
> 
> Afterwards the BootFile variable is 0. The issue can be observed by
> using tftpboot, which always uses the default/generated filename
> instead
> of the specified one.
> 
> To fix the issue, align the memory addresses properly before passing
> them to invalidate_dcache_range(). The misalignment can be observed
> with
> older gcc versions as well but the BootFile variable is placed more
> than
> 0x1000 bytes after the data variable and doesn't get null'ed.
> 
> Fixes: FS#4113
> 
> Signed-off-by: Mathias Kresin 
> ---
>  ...q-fix-out-of-bounds-cache-invalidate.patch | 48
> +++
>  1 file changed, 48 insertions(+)
>  create mode 100644 package/boot/uboot-lantiq/patches/0031-dma-
> lantiq-fix-out-of-bounds-cache-invalidate.patch
> 
> diff --git a/package/boot/uboot-lantiq/patches/0031-dma-lantiq-fix-
> out-of-bounds-cache-invalidate.patch b/package/boot/uboot-
> lantiq/patches/0031-dma-lantiq-fix-out-of-bounds-cache-
> invalidate.patch
> new file mode 100644
> index 00..5a2bf39441
> --- /dev/null
> +++ b/package/boot/uboot-lantiq/patches/0031-dma-lantiq-fix-out-of-
> bounds-cache-invalidate.patch
> @@ -0,0 +1,48 @@
> +From f10ffb65865d5bfa5679293b13e027e0474df1fe Mon Sep 17 00:00:00
> 2001
> +From: Mathias Kresin 
> +Date: Tue, 2 Nov 2021 21:24:29 +0100
> +Subject: [PATCH] dma: lantiq: fix out of bounds cache invalidate
> +
> +If u-boot is compiled with gcc 10+ the relevant part of the memory
> is
> +used as following:
> +
> +variable BootFile is at address: 0x83ffe4ec
> +variable data is at address: 0x83ffdee2
> +variable data has len:   0x600
> +
> +Within invalidate_dcache_range() the cache covering the data
> variable
> +should be invalidated (0x83ffdee2 till 0x83ffdef2).
> +
> +Due to dcache line size of 32 and some alignment correction, the
> actual
> +memory range for which the cache is invalidated is from 0x83ffdee0
> till
> +0x83ffe500, which includes the location of the BootFile variable as
> +well.
> +
> +Afterwards the BootFile variable is 0. The issue can be observed by
> +using tftpboot, which always uses the default/generated filename
> instead
> +of the specified one.
> +
> +To fix the issue, align the memory addresses properly before passing
> +them to invalidate_dcache_range(). The misalignment can be observed
> with
> +older gcc versions as well but the BootFile variable is placed more
> than
> +0x1000 bytes after the data variable and doesn't get null'ed.
> +
> +Signed-off-by: Mathias Kresin 
> +---
> + drivers/dma/lantiq_dma.c | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +--- a/drivers/dma/lantiq_dma.c
>  b/drivers/dma/lantiq_dma.c
> +@@ -122,9 +122,9 @@ static inline void ltq_dma_dcache_wb_inv
> + 
> + static inline void ltq_dma_dcache_inv(const void *ptr, size_t size)
> + {
> +-unsigned long addr = (unsigned long) ptr;
> ++unsigned long addr = (unsigned long) ptr & ~(ARCH_DMA_MINALIGN
> - 1);
> + 
> +-invalidate_dcache_range(addr, addr + size);
> ++invalidate_dcache_range(addr, ALIGN(addr + size,
> ARCH_DMA_MINALIGN));
> + }

actually invalidate_dcache_range() already aligns start and end address
to CONFIG_SYS_CACHELINE_SIZE which is the same as ARCH_DMA_MINALIGN.

In mainline we fixed the cache functions to always issue a sync() after
the cache ops to wait for all HW transactions to be complete. The
Lantiq DMA driver only does this in ltq_dma_dcache_wb_inv() but not
in ltq_dma_dcache_inv(). Maybe adding a ltq_dma_sync() there would also
fix your problem?

> + 
> + void ltq_dma_init(void)
-- 
- Daniel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] uboot-lantiq: danube: fix hanging lzma kernel uncompression

[Daniel Schwierzeck]

Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin:
> At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the
> assembly  of LzmaProps_Decode. The instructions are using unaligned
> access, which locks up danube boards using memory mapped NOR flash.
> 
> It isn't clear whether it is a limitation of the flash chip or a
> limitation of the EBU.
> 
> Moving the pointer to the next int position and accessing accessing
> just
> the first byte, let gcc use sll instead of lwr/lwl and prevents the
> unaligned access.
> 
> Signed-off-by: Mathias Kresin 
> ---
>  .../0030-lzma-fix-unaligned-access.patch  | 32
> +++
>  1 file changed, 32 insertions(+)
>  create mode 100644 package/boot/uboot-lantiq/patches/0030-lzma-fix-
> unaligned-access.patch
> 
> diff --git a/package/boot/uboot-lantiq/patches/0030-lzma-fix-
> unaligned-access.patch b/package/boot/uboot-lantiq/patches/0030-lzma-
> fix-unaligned-access.patch
> new file mode 100644
> index 00..de9afe0bf5
> --- /dev/null
> +++ b/package/boot/uboot-lantiq/patches/0030-lzma-fix-unaligned-
> access.patch
> @@ -0,0 +1,32 @@
> +From a335c4c0532cf0d09b31e73f8461d3b4d0ce6f9a Mon Sep 17 00:00:00
> 2001
> +From: Mathias Kresin 
> +Date: Sun, 31 Oct 2021 23:04:54 +0100
> +Subject: [PATCH] lzma: fix unaligned access
> +
> +At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the
> +assembly  of LzmaProps_Decode. The instructions are using unaligned
> +access, which locks up danube boards using memory mapped NOR flash.
> +
> +It isn't clear whether it is a limitation of the flash chip or a
> +limitation of the EBU.

I think the problem is not the unaligned access but the 32bit read
operation. The internal EBU data bus has a 16 bit width and can access
8bit or 16bit flash devices. So 8bit read operations at odd addresses
shouldn't be a problem. I'm not sure what happens exactly at 32bit
reads but this maybe involves multiple reads from flash and also some
internal endianess swapping.

Maybe a more robust solution would be to use readb(data[n] to always
force 8bit reads.

> +
> +Moving the pointer to the next int position and accessing accessing
> just
> +the first byte, let gcc use sll instead of lwr/lwl and prevents the
> +unaligned access.
> +
> +Signed-off-by: Mathias Kresin 
> +---
> + lib/lzma/LzmaDec.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +--- a/lib/lzma/LzmaDec.c
>  b/lib/lzma/LzmaDec.c
> +@@ -929,7 +929,7 @@ SRes LzmaProps_Decode(CLzmaProps *p, con
> +   if (size < LZMA_PROPS_SIZE)
> + return SZ_ERROR_UNSUPPORTED;
> +   else
> +-dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3]
> << 16) | ((UInt32)data[4] << 24);
> ++dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3]
> << 16) | ((UInt32)(data+1)[0] << 24);
> + 
> +   if (dicSize < LZMA_DIC_MIN)
> + dicSize = LZMA_DIC_MIN;
-- 
- Daniel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Daniel Schwierzeck]

Am Samstag, den 16.01.2016, 18:03 +0100 schrieb Martin Blumenstingl:
> On Sat, Jan 16, 2016 at 4:34 PM, Daniel Schwierzeck
> <daniel.schwierz...@gmail.com> wrote:
> > nice, thanks for testing :)
> Thanks for writing nice patches ;-)
> 
> > > - replace INIT_COMPLECTION with reinit_completion (this is due
> > > the
> > > newer kernel version in OpenWrt)
> > > - use clk_get_fpi() to obtain the FPI clock (horrible, I am
> > > currently
> > > porting the lantiq clock code to the common clk framework, then
> > > we
> > > can
> > > pass this in correctly)
> > > - remove the " - 1" in "cs - 1" (it seems that your chipselect
> > > indexing in the .dts begins at 1, whereas the previous driver
> > > started
> > > at 0)
> > 
> > I fixed that because datasheets and pin descriptions in schematics
> > use
> > CS1..CS6. I think DT should be in sync to the datasheets.
> I am not sure if this would work with GPIO chipselects then, see [0].
> If I understand it correctly then you would have to change the "reg"
> property of each device to "0" if you would use GPIO CS0 and then
> back
> to "1" if you want to use hardware CS0.
> Let me know if we should still go with chipselects starting at 1,
> then
> I will simply adjust them in the commit which switches to your new
> SPI
> driver.

If you use native CS, you should use the same numbering as in the
datasheet:

 {
...
spi-nor@4 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <4>;
spi-max-frequency = <2500>;
};
};

If you use GPIO CS, you can ignore the native CS numbering and choose
your own and you can also start with 0:

 {
...
cs-gpios = < 10 1>;

spi-nor@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <2500>;
};
};

If you use native CS 4, you have to manipulate bits 3 and 11 in the
GPOCON and FGPO registers. Thus you have to keep the (cs - 1)
translation. 

> 
> > linux-4.4 finally has the patch [1] I was referring to. Maybe we
> > should
> > also add it to 4.1. It is important to be able to setup each SPI
> > pin
> > separately. You always should explicitely setup spi_clk and spi_do
> > to
> > "lantiq,output = <1>" and spi_di to "lantiq,input". Depending on
> > the
> > board, you optionally have to enable internal pull-up's, if there
> > are
> > no external ones. The current DT pinmux setup with only one spi pin
> > group relies on the bootloader setup. This only works if the board
> > boots from SPI and the bootloader have to setup the SPI pins. With
> > other boot variants the SPI pins are likely not setup.
> I am assuming that you are speaking of upstream commit
> be14811c03cf20c793fd176a347625335110b0e6.

yes, sorry 

> I went ahead and also backported that to 4.1, you can find the
> updated
> patchset here: [1]
> 
> While reviewing my changes I may have found a small problem with your
> driver:
> You don't have a separate "lantiq,spi-xrx100" OF-match. I think you
> should add one with the same settings as for the other xrx-SoCs.
> If you look at DGN3500.dtsi [2] you'll see that it's an ARX100 board
> using spi_cs4.

that's because I couldn't test it. But according to the datasheet,
xRX100 also supports six native CS lines.

> 
> 
> Martin
> 
> [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/
> spi-bus.txt
> [1] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-d
> aniel-v3
> [2] https://dev.openwrt.org/browser/trunk/target/linux/lantiq/dts/DGN
> 3500.dtsi
-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Daniel Schwierzeck]

Am Samstag, den 16.01.2016, 15:39 +0100 schrieb Martin Blumenstingl:
> Hi Daniel,
> 
> On Sat, Jan 16, 2016 at 1:06 AM, Martin Blumenstingl
>  wrote:
> > > It is a complete rewrite with DT support and runs against the UGW
> > > -6.1.1
> > > kernel. Unfortunately I hadn't time yet to adapt and test it with
> > > OpenWRT. Maybe you want to volunteer for that ;)
> > Thanks for this update! I am going to test it on kernel 4.1 in the
> > next days and let you know about the results.
> I had to make 3 adjustments to get it working on OpenWrt:

nice, thanks for testing :)

> - replace INIT_COMPLECTION with reinit_completion (this is due the
> newer kernel version in OpenWrt)
> - use clk_get_fpi() to obtain the FPI clock (horrible, I am currently
> porting the lantiq clock code to the common clk framework, then we
> can
> pass this in correctly)
> - remove the " - 1" in "cs - 1" (it seems that your chipselect
> indexing in the .dts begins at 1, whereas the previous driver started
> at 0)

I fixed that because datasheets and pin descriptions in schematics use
CS1..CS6. I think DT should be in sync to the datasheets.

> 
> After that everything is working nicely on linux 4.1 (on my TD
> -W8970):
> [0.926597] spi-lantiq 1e100800.spi: using internal chipselect 3
> [0.931499] spi-lantiq 1e100800.spi: spi_clk 12500,
> max_speed_hz 3325, brt 2
> [0.939351] m25p80 spi0.3: s25fl064k (8192 Kbytes)
> [0.943763] 4 ofpart partitions found on MTD device spi0.3
> [0.949192] Creating 4 MTD partitions on "spi0.3":
> [0.953984] 0x-0x0002 : "u-boot"
> [0.960136] 0x0002-0x007c : "firmware"
> [0.966720] 0x001cf40c-0x007c : "rootfs"
> [0.971380] mtd: device 2 (rootfs) set to be root filesystem
> [0.976814] 1 squashfs-split partitions found on MTD device rootfs
> [0.982126] 0x0046-0x007c : "rootfs_data"
> [1.030051] 0x007c-0x007d : "config"
> [1.034667] 0x007d-0x0080 : "boardconfig"
> [1.040154] spi-lantiq 1e100800.spi: Lantiq SPI controller (TXFS
> 8,
> RXFS 8, DMA 32)
> 
> I have pushed my changes to the OpenWrt tree here: [0]
> My plan is to finish them soon (I want to do a little more testing,
> and I need to verify that my other dts changes are correct).

linux-4.4 finally has the patch [1] I was referring to. Maybe we should
also add it to 4.1. It is important to be able to setup each SPI pin
separately. You always should explicitely setup spi_clk and spi_do to
"lantiq,output = <1>" and spi_di to "lantiq,input". Depending on the
board, you optionally have to enable internal pull-up's, if there are
no external ones. The current DT pinmux setup with only one spi pin
group relies on the bootloader setup. This only works if the board
boots from SPI and the bootloader have to setup the SPI pins. With
other boot variants the SPI pins are likely not setup.

> 
> Thank you for your help!
> 
> 
> Regards,
> Martin
> 
> [0] https://github.com/xdarklight/openwrt/commits/lantiq-spi-driver-d
> aniel-v2
-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Daniel Schwierzeck]

Am Samstag, den 16.01.2016, 21:17 +0100 schrieb Martin Blumenstingl:

> So compared to your patch the final list of changes is:
> - INIT_COMPLETION -> reinit_completion
> - use clk_get_fpi()
> - of_device_id for "lantiq,spi-xrx100"
> 
> I only have three small questions left:
> - The "spi_frm" interrupt is currently unused - is that on purpose?

yes, this interrupt is only needed for DMA transfers.

> - I went ahead and added multiple "compatible" strings to the
> soc.dtsi, for example: compatible = "lantiq,spi-ase",
> "lantiq,spi-xway"; - do you see any problems with that?

there should be only one compatible string in the DTS. For backward
compatibility the driver could support old and new strings.

> 
> Please let me know if you have more feedback - otherwise I'll do the
> final round of tests and send the patches later.

AFAIK the upstream preference is to have "lantiq,-spi". I forgot
to fix that in the driver. Could you change that? Thanks.

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq: Initial linux 4.4 support (with SPI problems)

[Daniel Schwierzeck]

Hi Martin,

Am Mittwoch, den 13.01.2016, 20:23 +0100 schrieb Martin Blumenstingl:
> Hi John,
> 
> On Mon, Jan 11, 2016 at 3:25 PM, Martin Blumenstingl
> <martin.blumensti...@googlemail.com> wrote:
> > Here's the kernel log from the TD-W8970: 
> > https://paste.kde.org/pia7p73i9
> > I have debugged it and split_tplink_kernel gets 0x2 as offset
> > and
> > 0x7A as size (which looks correct). However, when mtd_read
> > tries to
> > read the magic bytes it only gets 0x.
> I found out that reverting this upstream commit makes SPI work again:
> [0]
> 
> Then I had a deeper look at our SPI driver - that's where I need some
> help from you.

could you retry with the attached driver? 

It is a complete rewrite with DT support and runs against the UGW-6.1.1
kernel. Unfortunately I hadn't time yet to adapt and test it with
OpenWRT. Maybe you want to volunteer for that ;)

The driver works on xRX200 with following DT bindings:

xrx200.dtsi:
fpi {
...
spi: spi@e100800 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-spi";
reg = <0xe100800 0x100>;
interrupt-parent = <>;
interrupts = <22 23 24 25>;
interrupt-names = "spi_rx", "spi_tx", "spi_err",
"spi_frm";

status = "disabled";
};
...
};


board.dts:

 {
...
pins_spi_default: pins_spi_default {
spi_in {
lantiq,groups = "spi_din";
lantiq,function = "spi";
};
spi_out {
lantiq,groups = "spi_dout", "spi_clk",
"spi_cs4";
lantiq,function = "spi";
lantiq,output = <1>;
};
};
...
};

 {
pinctrl-names = "default";
pinctrl-0 = <_spi_default>;

status = "ok";

m25p80@4 {
#address-cells = <1>;
    #size-cells = <1>;
compatible = "spansion,m25p80";
reg = <4>;
spi-max-frequency = <2500>;
    };
};

-- 
- Daniel
>From 0175fc559debc22fe8d17e9b8ffd1452e0a4667d Mon Sep 17 00:00:00 2001
From: Daniel Schwierzeck <daniel.schwierz...@gmail.com>
Date: Tue, 16 Dec 2014 15:40:32 +0100
Subject: [PATCH 1/2] spi: add support for Lantiq SPI controller

Signed-off-by: Daniel Schwierzeck <daniel.schwierz...@gmail.com>
---
 drivers/spi/Kconfig  |7 +
 drivers/spi/Makefile |1 +
 drivers/spi/spi-lantiq.c | 1089 ++
 3 files changed, 1097 insertions(+)
 create mode 100644 drivers/spi/spi-lantiq.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bc36db5..af8aaf1 100755
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -266,6 +266,13 @@ config SPI_FSL_ESPI
 	  From MPC8536, 85xx platform uses the controller, and all P10xx,
 	  P20xx, P30xx,P40xx, P50xx uses this controller.
 
+config SPI_LANTIQ
+	tristate "Lantiq SPI controller"
+	depends on LANTIQ && (SOC_TYPE_XWAY || SOC_FALCON)
+	help
+	  This driver supports the Lantiq SPI controller in master
+	  mode.
+
 config SPI_OC_TINY
 	tristate "OpenCores tiny SPI"
 	depends on GPIOLIB
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 658f181..f981db9 100755
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
 obj-$(CONFIG_SPI_GPIO_OLD)		+= spi_gpio_old.o
 obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
+obj-$(CONFIG_SPI_LANTIQ)		+= spi-lantiq.o
 obj-$(CONFIG_SPI_LM70_LLP)		+= spi-lm70llp.o
 obj-$(CONFIG_SPI_MPC512x_PSC)		+= spi-mpc512x-psc.o
 obj-$(CONFIG_SPI_MPC52xx_PSC)		+= spi-mpc52xx-psc.o
diff --git a/drivers/spi/spi-lantiq.c b/drivers/spi/spi-lantiq.c
new file mode 100644
index 000..03c730d
--- /dev/null
+++ b/drivers/spi/spi-lantiq.c
@@ -0,0 +1,1089 @@
+/*
+ * Copyright (C) 2011-2015 Daniel Schwierzeck <daniel.schwierz...@gmail.com>
+ *
+ * This program is free software; you can distribute it and/or modify it
+ * under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define SPI_RX_IRQ_NAME		"spi_rx"
+#define SPI_TX_IRQ_NAME		"spi_tx"
+#define SPI_ERR_IRQ_NAME	"spi_err"
+#define SPI_FRM_IRQ_NAME	"spi_frm"
+

Re: [OpenWrt-Devel] [PATCH 2/4] lantiq: base-files: drop the dsl tone settings

[Daniel Schwierzeck]

Am 02.12.2015 um 21:38 schrieb Andre Heider:
> Unused since r46920.

I think the removal of the tone setup in r46920 should be reverted. It
is still the only way to exactly control which pilot tones are sent by
the DSL firmware. I would not trust the default setting of the
dsl_cpe_control daemon. Especially in Germany you may not send a V43
tone on a Deutsche Telekom port according to 1TR112 specification, only
B43 is allowed.

> 
> Signed-off-by: Andre Heider 
> ---
>  target/linux/lantiq/base-files/etc/uci-defaults/02_network | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/target/linux/lantiq/base-files/etc/uci-defaults/02_network 
> b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
> index b22060c..4974b48 100644
> --- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
> +++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
> @@ -41,13 +41,11 @@ EOF
>  set_vdsl_modem() {
>   local annex=$1
>   local firmware=$2
> - local tone=$3
>   local xfer_mode=$4
>   uci batch <  set network.dsl='vdsl'
>  set network.dsl.annex='$annex'
>  set network.dsl.firmware='$firmware'
> -set network.dsl.tone='$tone'
>  set network.dsl.xfer_mode='$xfer_mode'
>  EOF
>  }
> @@ -198,7 +196,7 @@ esac
>  [ -z "$(ls /lib/modules/`uname -r`/ltq_atm*)" ] || set_atm_wan "$vpi" "$vci" 
> "$encaps" "$payload"
>  
>  if [ -n "$(grep "system type.*: VR9" /proc/cpuinfo)" ]; then
> - set_vdsl_modem "$annex" "/lib/firmware/vdsl.bin" "av" "ptm"
> + set_vdsl_modem "$annex" "/lib/firmware/vdsl.bin" "ptm"
>  else
>   set_adsl_modem "$annex" "/lib/firmware/adsl.bin"
>  fi
> 

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/4] lantiq: fall back to a more appropriate default dsl firmware

[Daniel Schwierzeck]

Am 02.12.2015 um 21:38 schrieb Andre Heider:
> Signed-off-by: Andre Heider 
> ---
> 
> What I'm not sure about is annex j.
> Is that using the a or b firmware or will it get its own?

Annex J is only valid with B firmware. It is only additionally enabled
along with Annex B.

> 
>  package/network/config/ltq-vdsl-app/files/dsl_control | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>  mode change 100644 => 100755 
> package/network/config/ltq-vdsl-app/files/dsl_control
> 
> diff --git a/package/network/config/ltq-vdsl-app/files/dsl_control 
> b/package/network/config/ltq-vdsl-app/files/dsl_control
> old mode 100644
> new mode 100755
> index d7eb4cd..48815ab
> --- a/package/network/config/ltq-vdsl-app/files/dsl_control
> +++ b/package/network/config/ltq-vdsl-app/files/dsl_control
> @@ -69,11 +69,12 @@ start_service() {
>   eval "xtse_adsl=\"\${xtse_adsl_$annex}\""
>   if [ "${xtse_adsl}" ]; then
>   xtse=$xtse_adsl
> + [ -z "${firmware}" ] && firmware=/lib/firmware/adsl-${annex}.bin
>   else
>   xtse=$xtse_vdsl
> + [ -z "${firmware}" ] && firmware=/lib/firmware/vdsl.bin
>   fi
>  
> - [ -z "${firmware}" ] && firmware=/lib/firmware/vdsl.bin
>   [ -f "${firmware}" ] || {
>   echo failed to find $firmware
>   return 1
> 

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 1/2] pinctrl/lantiq: introduce new dedicated tables

[Daniel Schwierzeck]

2015-11-17 13:48 GMT+01:00 Martin Schiller :
> This patch introduces new dedicated "pinctrl-ase", "pinctrl-danube",
> "pinctrl-xrx100" and "pinctrl-xrx200" configuration tables.
>
> Based on the newest Lantiq Hardware Description it turend out, that there are
> some differences in the GPIO alternative functions of the Danube, xRX100 and
> xRX200 families, which makes it impossible to use only one xway_mfp table.
>
> This patch is also the first step to add support for the xRX300 family.
>
> Signed-off-by: Martin Schiller 
> ---
>  .../patches-3.18/0150-lantiq-pinctrl-xway.patch| 1118 
> +++-
>  .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1118 
> +++-
>  2 files changed, 2214 insertions(+), 22 deletions(-)
>

> ++
> ++static const unsigned xrx200_pins_usif_spi[] = {GPIO11, GPIO12, GPIO38};
> ++static const unsigned xrx200_pins_usif_spi_cs0[] = {GPIO37};
> ++static const unsigned xrx200_pins_usif_spi_cs1[] = {GPIO39};
> ++static const unsigned xrx200_pins_usif_spi_cs2[] = {GPIO14};
> ++

> ++
> ++static const unsigned xrx200_pins_spi[] = {GPIO16, GPIO17, GPIO18};
> ++static const unsigned xrx200_pins_spi_cs1[] = {GPIO15};
> ++static const unsigned xrx200_pins_spi_cs2[] = {GPIO22};
> ++static const unsigned xrx200_pins_spi_cs3[] = {GPIO13};
> ++static const unsigned xrx200_pins_spi_cs4[] = {GPIO10};
> ++static const unsigned xrx200_pins_spi_cs5[] = {GPIO9};
> ++static const unsigned xrx200_pins_spi_cs6[] = {GPIO11};
> ++

while you are at it, could you also add dedicated controls for the SPI
and USIF-SPI pins for all SoC's like:

static const unsigned xrx200_pins_usif_spi_di[] = {GPIO11};
static const unsigned xrx200_pins_usif_spi_do[] = {GPIO12};
static const unsigned xrx200_pins_usif_spi_clk[] = {GPIO38};

static const unsigned xrx200_pins_spi_di[] = {GPIO16};
static const unsigned xrx200_pins_spi_do[] = {GPIO17};
static const unsigned xrx200_pins_spi_clk[] = {GPIO18};

I have SPI and USIF-SPI drivers which are mostly ready for upstream
submission and their DT bindings depend on dedicated pin controls.

Thanks,
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] uboot-lantiq: fix P-2812HNU-F1/3 package dependency

[Daniel Schwierzeck]

Am 30.01.2015 um 13:42 schrieb Ben Mulvihill:
 

 the NAND boot does not work yet. I was not able to make it work with a
 SPL only because the BootROM only reads the first page. The Lantiq UGW
 U-Boot uses a very small pre-loader which loads another pre-loader and
 fits in the first page. Thus we need to convert to SPL/TPL support
 from mainline U-Boot. But I hadn't enough time yet to work on it.
 
 I see. But is that the case with all lantiq nand boards? Do they all 
 have the same bootrom? By the looks of it they don't all have the same
 page size (HH3A has 512 byte, P-2812HNU has 2K).
 
 Having read your explanation, I guess that I was in fact replacing just
 the actual uboot part. I left the pre-boot partition intact, and I
 suppose that contains the pre-pre-loader and the pre-loader. However
 my uboot image was trying to do all the low-level initialisation, which
 had already been done. So maybe I could forget about spl, and simply use
 the factory preloaders to boot a uboot image which skips the low level
 stuff. What do you think?

yes, It's the best you can do atm. Some Arcadyan boards also do this.
Just look for the *_brn configs. The relevant U-Boot config option is
CONFIG_SKIP_LOWLEVEL_INIT.

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] uboot-lantiq: fix P-2812HNU-F1/3 package dependency

[Daniel Schwierzeck]

2015-01-27 18:41 GMT+01:00 Ben Mulvihill ben.mulvih...@gmail.com:
 Hi Antti,

 (Note that the diffs in this message are for information. They are not
 patches submitted for merging - not at this stage anyway.)

 I tried and it seems the ram version
 (openwrt-lantiq-p2812hnufx_ram-u-boot.asc) builds and boots properly.

 The openwrt-lantiq-p2812hnufx_nandspl-u-boot.img indeed does not boot
 correctly. Is anyone working on fixing it? (Apparently conversion to
 TPL is needed)

 I am working on the BT Home Hub 3A at the moment (arx100, nand-based
 board), and have also found that asc images build correctly but
 nandspl images do not.

 There seem to a number of problems. For a start some of the make
 targets seem to be missing. The following fixed that for arx100,
 and I think that a similar fix is necessary for danube and vrx200
 too.

the NAND boot does not work yet. I was not able to make it work with a
SPL only because the BootROM only reads the first page. The Lantiq UGW
U-Boot uses a very small pre-loader which loads another pre-loader and
fits in the first page. Thus we need to convert to SPL/TPL support
from mainline U-Boot. But I hadn't enough time yet to work on it.


 --- a/arch/mips/cpu/mips32/arx100/config.mk 2015-01-27 12:33:32.0 
 +0100
 +++ b/arch/mips/cpu/mips32/arx100/config.mk 2015-01-27 18:07:37.0 
 +0100
 @@ -27,4 +27,9 @@ ALL-y += $(obj)u-boot.ltq.norspl
  ALL-$(CONFIG_SPL_LZO_SUPPORT) += $(obj)u-boot.ltq.lzo.norspl
  ALL-$(CONFIG_SPL_LZMA_SUPPORT) += $(obj)u-boot.ltq.lzma.norspl
  endif
 +ifdef CONFIG_SYS_BOOT_NANDSPL
 +ALL-y += $(obj)u-boot.ltq.nandspl
 +ALL-$(CONFIG_SPL_LZO_SUPPORT) += $(obj)u-boot.ltq.lzo.nandspl
 +ALL-$(CONFIG_SPL_LZMA_SUPPORT) += $(obj)u-boot.ltq.lzma.nandspl
 +endif
  endif


 Then the ebu configuration word needs to be set in the nandspl
 image, as it is for norspl. Once again, the following fixed that
 for arx100, and I think something similar will be required for danube
 and vrx200.

actually the BootROM should correctly configure the EBU to be able to
read at least the first page from NAND flash. The XWAY_EBU_BOOTCFG is
only used for parallel NOR to setup various command timings and
delays.


 --- a/arch/mips/include/asm/arch-arx100/config.h2015-01-27 
 18:12:32.0 +0100
 +++ b/arch/mips/include/asm/arch-arx100/config.h2015-01-27 
 18:13:02.0 +0100
 @@ -174,6 +174,10 @@
  #define CONFIG_XWAY_SWAP_BYTES
  #endif

 +#if defined(CONFIG_SYS_BOOT_NAND) || defined(CONFIG_SYS_BOOT_NANDSPL)
 +#define CONFIG_SYS_XWAY_EBU_BOOTCFG0x688C688C
 +#endif
 +
  #defineCONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE

  #endif /* __ARX100_CONFIG_H__ */

 Finally the ltq-boot-image tool adds a couple of download header to the
 final image which I don't think should be there.

 Daniel, does all the above make sense?

 That said, even after making those changes my nandspl images still
 don't work.

 Ben







-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image

[Daniel Schwierzeck]

Am 22.01.2015 um 22:23 schrieb Ben Mulvihill:
 On Thu, 2015-01-22 at 10:07 +0100, John Crispin wrote:
 is this patch correct and should be merged or is it a RFC ?

 http://patchwork.ozlabs.org/patch/431024/
 
 Daniel found a mistake in the current code. I found another.
 This fixes both, so I guess it is a patch rather than an RFC.
 I understand it to be correct, but the authoritative answer as
 to whether it is indeed correct should really come from
 Daniel ;-) In any case Daniel has already committed it to
 uboot-lantiq github.
 
 Hope this is some help. Daniel?
 

I'm going to integrate that patch in the openwrt/14.04 branch. If you
have a working patch for the BT Home Hub; I'd like to integrate it too.
After that we can refresh the patches in the OpenWRT tree.

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image

[Daniel Schwierzeck]

2015-01-20 12:28 GMT+01:00 Ben Mulvihill ben.mulvih...@gmail.com:


 Some of the bitshifting in arch/mips/cpu/mips32/arx100/cgu.c is 1
 out. A patch along these lines should fix it:

yes, the code is wrong. I have prepared a patch. Thanks for fixing.

https://github.com/danielschwierzeck/u-boot-lantiq/commit/f38048eb920276d8aa48a4b0bbf653d8fd4ef66b


 --- a/arch/mips/cpu/mips32/arx100/cgu.c 2015-01-20 11:57:22.0 +0100
 +++ b/arch/mips/cpu/mips32/arx100/cgu.c 2015-01-20 12:00:15.0 +0100
 @@ -10,12 +10,17 @@
  #include asm/lantiq/clk.h
  #include asm/lantiq/io.h

 -#define CGU_SYS_DDR_SEL(1  0)
 -#define CGU_SYS_CPU_SEL(1  2)
 +#define CGU_SYS_DDR_SHIFT  0
 +#define CGU_SYS_CPU_SHIFT  2
  #define CGU_SYS_SYS_SHIFT  3
 +#define CGU_SYS_FPI_SHIFT  6
 +#define CGU_SYS_PPE_SHIFT  7
 +
 +#define CGU_SYS_DDR_MASK   (1  CGU_SYS_DDR_SHIFT)
 +#define CGU_SYS_CPU_MASK   (1  CGU_SYS_CPU_SHIFT)
  #define CGU_SYS_SYS_MASK   (0x3  CGU_SYS_SYS_SHIFT)
 -#define CGU_SYS_FPI_SEL(1  6)
 -#define CGU_SYS_PPE_SEL(1  7)
 +#define CGU_SYS_FPI_MASK   (1  CGU_SYS_FPI_SHIFT)
 +#define CGU_SYS_PPE_MASK   (1  CGU_SYS_PPE_SHIFT)

  struct ltq_cgu_regs {
 u32 rsvd0;
 @@ -68,7 +73,7 @@ unsigned long ltq_get_io_region_clock(vo
 u32 ddr_sel;
 unsigned long clk;

 -   ddr_sel = ltq_cgu_sys_readl(1, CGU_SYS_DDR_SEL);
 +   ddr_sel = ltq_cgu_sys_readl(CGU_SYS_DDR_MASK, CGU_SYS_DDR_SHIFT);

 if (ddr_sel)
 clk = ltq_get_system_clock() / 3;
 @@ -83,7 +88,7 @@ unsigned long ltq_get_cpu_clock(void)
 u32 cpu_sel;
 unsigned long clk;

 -   cpu_sel = ltq_cgu_sys_readl(1, CGU_SYS_CPU_SEL);
 +   cpu_sel = ltq_cgu_sys_readl(CGU_SYS_CPU_MASK, CGU_SYS_CPU_SHIFT);

 if (cpu_sel)
 clk = ltq_get_io_region_clock();
 @@ -98,7 +103,7 @@ unsigned long ltq_get_bus_clock(void)
 u32 fpi_sel;
 unsigned long clk;

 -   fpi_sel = ltq_cgu_sys_readl(1, CGU_SYS_FPI_SEL);
 +   fpi_sel = ltq_cgu_sys_readl(CGU_SYS_FPI_MASK, CGU_SYS_FPI_SHIFT);

 if (fpi_sel)
 clk = ltq_get_io_region_clock() / 2;



-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image

[Daniel Schwierzeck]

2015-01-20 15:44 GMT+01:00 Ben Mulvihill ben.mulvih...@gmail.com:
 On Tue, 2015-01-20 at 14:05 +0100, Daniel Schwierzeck wrote:
 2015-01-20 12:28 GMT+01:00 Ben Mulvihill ben.mulvih...@gmail.com:

 
  Some of the bitshifting in arch/mips/cpu/mips32/arx100/cgu.c is 1
  out. A patch along these lines should fix it:

 yes, the code is wrong. I have prepared a patch. Thanks for fixing.

 Thank you.

 The linux code in arch/mips/lantiq/xway/clk.c is wrong too I think.
 Shall I submit a patch to make the functions there return the same
 values as the uboot equivalents?

only ltq_ar9_fpi_hz() should be fixed. If bit 0 is set, than DDR/FPI
clock is 1/3 of SYS clock, otherwise 1/2


 Also, just as a matter of interest, what does CGU_SYS_PPESEL_250_MHZ
 actually do? What does PPE stand for?


it means Packet Processing Engine. It is a separate on-chip CPU for
network offloading functions which only runs with a propietary
firmware from Lantiq. On AR9 the PPE clock is fixed to 250 MHz. The HW
manual says the according bit in CGU_SYS register should be set but
maybe this could be ignored.

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image

[Daniel Schwierzeck]

Hi Ben,

2015-01-19 11:46 GMT+01:00 Ben Mulvihill ben.mulvih...@gmail.com:
 Hello,

 I am trying to build uboot-lantiq for the BT Home Hub 3A (lantiq
 ar9), and am wondering where to initialise the cgu, in the case
 of a ramboot image for uart booting. Normally the cgu is initialised
 in lowlevel_init, but that code is bypassed in ramboot images. The
 result is that the board boots with the wrong cgu settings, which
 sends the console haywire. So far I have tried two solutions:

 - putting the following lines in board_early_init_f:

   #define REG32(addr) *((volatile u32 *)(addr))
 REG32(0xbf103010) = 0x80;
 REG32(0xbf103014) = 0x01;

   This fixes the console, but breaks ethernet. I am wondering
   whether this is because by putting this code in this place, I
   am altering the cgu settings after setting up ram. Is this
   admissible?

it is insufficient if you want to change the DDR clock after the
memory is already initialized. For that you will need a sequence like
putting memory in self-refresh mode, stopping memory controller,
update clocks, restart memory controller, putting memory out of
self-refresh. That's why the cgu_init() runs before mc_init(). Thus if
the board comes up with 111/111 MHz, you cannot switch to 393/166 MHz
because that would require to change the DDR clock.


 - adding the same two register settings to the start of the
   ddr_settings file generated by lantiq_ram_init_uart.awk .
   However, the resulting image gives a download error and won't
   boot at all.

Actually this should work. Did you put the CGU register settings
before the memory controller settings?


 Any suggestions will be gratefully received!

 Ben



-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image

[Daniel Schwierzeck]

2015-01-19 15:44 GMT+01:00 Ben Mulvihill ben.mulvih...@gmail.com:
 On Mon, 2015-01-19 at 11:51 +, Conor O'Gorman wrote:
 On 19/01/15 10:46, Ben Mulvihill wrote:
  Hello,
 
  I am trying to build uboot-lantiq for the BT Home Hub 3A (lantiq
  ar9), and am wondering where to initialise the cgu, in the case
  of a ramboot image for uart booting. Normally the cgu is initialised
  in lowlevel_init, but that code is bypassed in ramboot images. The
  result is that the board boots with the wrong cgu settings, which
  sends the console haywire. So far I have tried two solutions:

 Another option is to try and not change anything. The console is already
 configured and running. The ram does need config.

 I was used to seeing the ramboot version running at half clock speed, at
 least on danube, previous to ar9.

 Conor

 Hi Conor,

 Thanks for the reply. But with the latest uboot-lantiq, not changing
 anything means that I don't get a usable console. With an older
 version I do at least get a uboot console, but no linux console when
 I boot openwrt. Correcting the cgu settings solves both problems.


could you try this?

diff --git a/arch/mips/cpu/mips32/arx100/cgu.c
b/arch/mips/cpu/mips32/arx100/cgu.c
index 6e71ee7..e0afbda 100644
--- a/arch/mips/cpu/mips32/arx100/cgu.c
+++ b/arch/mips/cpu/mips32/arx100/cgu.c
@@ -95,15 +95,5 @@ unsigned long ltq_get_cpu_clock(void)

 unsigned long ltq_get_bus_clock(void)
 {
-   u32 fpi_sel;
-   unsigned long clk;
-
-   fpi_sel = ltq_cgu_sys_readl(1, CGU_SYS_FPI_SEL);
-
-   if (fpi_sel)
-   clk = ltq_get_io_region_clock() / 2;
-   else
-   clk = ltq_get_io_region_clock();
-
-   return clk;
+   return ltq_get_io_region_clock();
 }

the UART driver calculates the baudrate from the FPI bus clock, but
FPI_SEL is not available on AR9. FPI bus clock is always the same as
DDR clock, Obviously a copypaste error from VR9 code ;)

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 1/7] [boot] uboot-lantiq: update to v2013.10

[Daniel Schwierzeck]

2014-04-15 0:38 GMT+02:00 Luka Perkov l...@openwrt.org:
 On Sun, Apr 13, 2014 at 09:43:22AM +0200, John Crispin wrote:
 On 27/10/2013 21:36, Daniel Schwierzeck wrote:
  Patches created from tree:
  g...@github.com:danielschwierzeck/u-boot-lantiq.git
  v2013.10..u-boot-lantiq-v2013.10-openwrt4
 
  Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com

 i noticed after adding that patch that tehre is a 2014.01 branch.

 i will bump the package to that branch during the week

 I have not tested the 2014.01 branch recently but the 2013.10 series did
 not boot default OpenWrt images. Antonios made a patch that fixed it and
 it is now upstreamed in u-boot.


both branches have the LZMA fix applied. Also I could boot the default
OpenWRT Lantiq kernel on an EASY50712 board with both branches.

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH, v2] lantiq: fix etop registers

[Daniel Schwierzeck]

2013/11/20 Matti Laakso malaa...@elisanet.fi:
 On 19.11.2013 21:10, John Crispin wrote:

 On 14/11/13 08:59, Matti Laakso wrote:
 At the moment the MII/RMII setting in the lantiq .dts-files has no
 effect, since wrong registers are written. Once this patch is applied,
 it is necessary to make sure that the MII/RMII setting in the .dts-file
 is correct.

 i have not merged this yet. i am wondering if we should rename th
 property in all relevant dts files and print a warning during boot if
 the real option is not set that way there is a migration path that
 wont break lots of boards for people


 That might be a good idea. For the Danube routers I was able to compile a
 list of switch chips and connection types:

 * AR8216, MII
 arv4519pw
 arv7518pw
 arv752dpw22

 * RTL8306, reversed MII
 arv752dpw
 arv452cqw
 arv4518pw

 * ADM6996, reversed MII
 arv4510pw/arv7510pw
 sx76x
 easy50712
 acmp252
 arv4520pw

 which leaves out just arv4525pw and arv7525pw. Based on this list only
 arv4519pw and arv7518pw have currently an incorrect setting in the
 .dts-file.

 But then there are the AR9-based routers which use the same driver, and
 which I'm not familiar with. Based on the new U-Boot sources at least
 p2601hnfx and h201l use reversed MII, but in the current driver all
 AR9-routers are forced to use MII regardless of .dts-file?


ignore the U-Boot sources for AR9 for now because the AR9 ethernet
support is still in development and is not working yet. But the MII
settings should be the same as on Danube boards. That depends only on
the assembled switch chip.


-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH, v2] lantiq: fix etop registers

[Daniel Schwierzeck]

2013/11/21 John Crispin j...@phrozen.org:
 On 21/11/13 10:56, Daniel Schwierzeck wrote:

 2013/11/20 Matti Laaksomalaa...@elisanet.fi:

 On 19.11.2013 21:10, John Crispin wrote:

 On 14/11/13 08:59, Matti Laakso wrote:

 At the moment the MII/RMII setting in the lantiq .dts-files has no
 effect, since wrong registers are written. Once this patch is applied,
 it is necessary to make sure that the MII/RMII setting in the .dts-file
 is correct.


 i have not merged this yet. i am wondering if we should rename th
 property in all relevant dts files and print a warning during boot if
 the real option is not set that way there is a migration path that
 wont break lots of boards for people


 That might be a good idea. For the Danube routers I was able to compile a
 list of switch chips and connection types:

 * AR8216, MII
 arv4519pw
 arv7518pw
 arv752dpw22

 * RTL8306, reversed MII
 arv752dpw
 arv452cqw
 arv4518pw

 * ADM6996, reversed MII
 arv4510pw/arv7510pw
 sx76x
 easy50712
 acmp252
 arv4520pw

 which leaves out just arv4525pw and arv7525pw. Based on this list only
 arv4519pw and arv7518pw have currently an incorrect setting in the
 .dts-file.

 But then there are the AR9-based routers which use the same driver, and
 which I'm not familiar with. Based on the new U-Boot sources at least
 p2601hnfx and h201l use reversed MII, but in the current driver all
 AR9-routers are forced to use MII regardless of .dts-file?


 ignore the U-Boot sources for AR9 for now because the AR9 ethernet
 support is still in development and is not working yet. But the MII
 settings should be the same as on Danube boards. That depends only on
 the assembled switch chip.


 Hi,

 the link between the etop and gbit switch is mii and then the gbit switch
 has 2 ports that can be R/Mii depending on how they are wired.
  ... correct me if i am wrong ...


if the external switch is a gbit one than the link is always RGMII,
otherwise MII or RMII dependent on the switch

-- 
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/7] [boot] uboot-lantiq: reuse/copy VR9 GPHY firmware blobs from target/linux/lantiq

[Daniel Schwierzeck]

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 package/boot/uboot-lantiq/Makefile | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/package/boot/uboot-lantiq/Makefile 
b/package/boot/uboot-lantiq/Makefile
index 7a66aeb..a3e9805 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -17,6 +17,8 @@ PKG_SOURCE_URL:=ftp://ftp.denx.de/pub/u-boot
 PKG_MD5SUM:=a076a044b64371edc52f7e562b13f6b2
 PKG_TARGETS:=bin
 
+FIRMWARE_LANTIQ_SOURCE:=$(TOPDIR)/target/linux/lantiq/files/firmware/lantiq
+
 include $(INCLUDE_DIR)/package.mk
 
 define uboot/Default
@@ -82,6 +84,19 @@ define BuildUBootPackage
$(call Package/uboot/template,$(1),$(TITLE))
 endef
 
+define CopyVR9Firmware
+   $(CP) $(FIRMWARE_LANTIQ_SOURCE)/vr9_phy$(1)_a$(2)x.bin \
+   
$(PKG_BUILD_DIR)/arch/mips/cpu/mips32/vrx200/fw_phy$(1)_a$(2)x.blob
+endef
+
+define Build/Prepare
+   $(call Build/Prepare/Default)
+   $(call CopyVR9Firmware,11g,1)
+   $(call CopyVR9Firmware,11g,2)
+   $(call CopyVR9Firmware,22f,1)
+   $(call CopyVR9Firmware,22f,2)
+endef
+
 define Build/Configure
$(MAKE) -C $(PKG_BUILD_DIR) $(BUILD_VARIANT)_config
 endef
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/7] [boot] uboot-lantiq: enable parallel building

[Daniel Schwierzeck]

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 package/boot/uboot-lantiq/Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/package/boot/uboot-lantiq/Makefile 
b/package/boot/uboot-lantiq/Makefile
index a3e9805..40d1ae2 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -17,6 +17,8 @@ PKG_SOURCE_URL:=ftp://ftp.denx.de/pub/u-boot
 PKG_MD5SUM:=a076a044b64371edc52f7e562b13f6b2
 PKG_TARGETS:=bin
 
+PKG_BUILD_PARALLEL:=1
+
 FIRMWARE_LANTIQ_SOURCE:=$(TOPDIR)/target/linux/lantiq/files/firmware/lantiq
 
 include $(INCLUDE_DIR)/package.mk
@@ -98,11 +100,11 @@ define Build/Prepare
 endef
 
 define Build/Configure
-   $(MAKE) -C $(PKG_BUILD_DIR) $(BUILD_VARIANT)_config
+   +$(MAKE) -C $(PKG_BUILD_DIR) $(BUILD_VARIANT)_config
 endef
 
 define Build/Compile
-   $(MAKE) -C $(PKG_BUILD_DIR) CROSS_COMPILE=$(TARGET_CROSS)
+   +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) CROSS_COMPILE=$(TARGET_CROSS)
 endef
 
 define Package/uboot/install/default
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 5/7] [boot] uboot-lantiq: add packages for Lantiq EASY80920

[Daniel Schwierzeck]

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 package/boot/uboot-lantiq/Makefile | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/package/boot/uboot-lantiq/Makefile 
b/package/boot/uboot-lantiq/Makefile
index eb13a4e..f106e1b 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -80,11 +80,36 @@ define uboot/easy50712_norspl
   IMAGE:=u-boot.ltq.lzo.norspl
 endef
 
+define uboot/easy80920_ram
+  TITLE:=U-Boot for Lantiq EASY80920 (RAM)
+  SOC:=vr9
+  DDR_SETTINGS:=board/lantiq/easy80920/ddr_settings.h
+endef
+
+define uboot/easy80920_nor
+  TITLE:=U-Boot for Lantiq EASY80920 (NOR)
+  SOC:=vr9
+endef
+
+define uboot/easy80920_norspl
+  TITLE:=U-Boot for Lantiq EASY80920 (NOR SPL)
+  SOC:=vr9
+  IMAGE:=u-boot.ltq.lzo.norspl
+endef
+
+define uboot/easy80920_sfspl
+  TITLE:=U-Boot for Lantiq EASY80920 (SPI SPL)
+  SOC:=vr9
+  IMAGE:=u-boot.ltq.lzo.sfspl
+endef
+
+
 UBOOTS:= \
arv4519pw_ram arv4519pw_nor \
arv7518pw_ram arv7518pw_nor \
gigasx76x_ram gigasx76x_nor \
-   easy50712_ram easy50712_nor easy50712_norspl
+   easy50712_ram easy50712_nor easy50712_norspl \
+   easy80920_ram easy80920_nor easy80920_norspl easy80920_sfspl
 
 define Package/uboot/template
 define Package/uboot-lantiq-$(1)
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/7] lantiq: update U-Boot package

[Daniel Schwierzeck]

This series updates the Lantiq U-Boot package to the latest 
Lantiq patches based on v2013.10. Also further boards are added.

Daniel Schwierzeck (7):
  [boot] uboot-lantiq: update to v2013.10
  [boot] uboot-lantiq: reuse/copy VR9 GPHY firmware blobs from
target/linux/lantiq
  [boot] uboot-lantiq: enable parallel building
  [boot] uboot-lantiq: add packages for Lantiq EASY50712
  [boot] uboot-lantiq: add packages for Lantiq EASY80920
  [boot] uboot-lantiq: add packages for various Arcadyan boards
  [boot] uboot-lantiq: add packages for AudioCodes MP-252

 package/boot/uboot-lantiq/Makefile |  147 +-
 package/boot/uboot-lantiq/README   |6 +
 ...of-order-calls-for-spi_claim_bus-and-spi_.patch |  175 +
 ...ntly-use-debug-for-warning-error-messages.patch |   54 +
 .../0002-sf-handle-CONFIG_MANUAL_RELOC.patch   |   46 -
 ...-factor-out-malloc-from-SPI-flash-drivers.patch |  719 --
 ...ve-malloc-of-spi_flash-to-spi_flash_probe.patch |  115 +
 ...oc-free-probe-functions-dedicated-for-SPL.patch |  131 -
 .../0004-sf-add-slim-probe-funtions-for-SPL.patch  |   87 +
 ...-factor-out-the-flash-address-calculation.patch |  107 -
 ...culatiom-of-address-bytes-completely-conf.patch |  143 +
 ...d-generic-support-for-4-byte-address-mode.patch |  161 -
 ...0006-sf-add-support-for-4-byte-addressing.patch |  169 +
 .../0007-sf-add-support-for-EN25QH256.patch|   22 +
 .../0007-sf-eon-use-16-bit-ID-for-comparison.patch |   45 -
 ...f-eon-add-support-for-4-byte-address-mode.patch |   43 -
 ...or-layout-of-S25FL256S_256K-and-S25FL512S.patch |   26 +
 ...ib-add-framework-for-ethernet-switch-driv.patch |  260 +
 .../0009-sf-eon-add-support-for-EN25QH256.patch|   21 -
 ...ib-add-driver-for-Lantiq-PSB697X-switch-f.patch |  173 +
 ...-fix-device-IDs-and-sector-architecture-f.patch |   30 -
 ...ib-add-driver-for-Lantiq-ADM6996I-switch-.patch |  169 +
 ...nsion-add-support-for-4-byte-address-mode.patch |   55 -
 ...t-switchlib-add-driver-for-Atheros-AR8216.patch |  169 +
 ...012-sf-spansion-add-support-for-S25FL512S.patch |   23 -
 ...-switchlib-add-driver-for-REALTEK-RTL8306.patch |  387 +
 ...ronix-add-support-for-4-byte-address-mode.patch |   44 -
 ...014-MIPS-add-support-for-Lantiq-XWAY-SoCs.patch | 9618 
 ...4-sf-macronix-add-support-for-MX25L25635E.patch |   21 -
 ...-add-support-for-Lantiq-XWAY-ARX100-SoC-f.patch | 1283 +++
 ...5-sf-macronix-add-support-for-MX66L51235L.patch |   21 -
 ...-add-driver-for-Lantiq-XWAY-ARX100-switch.patch |  559 ++
 ...dd-MTD-layer-driver-for-SPI-flash-devices.patch |  133 -
 .../patches/0017-sf-add-init-function.patch|   57 -
 ...ols-add-some-helper-tools-for-Lantiq-SoCs.patch |  492 +
 .../0018-MIPS-add-SPI-flash-init-hook.patch|   47 -
 .../0018-tools-lantiq-add-NAND-SPL-support.patch   |  228 +
 .../0019-Makefile-add-Lantiq-NAND-SPL-images.patch |   53 +
 ...ib-add-framework-for-ethernet-switch-driv.patch |  239 -
 .../0020-MIPS-lantiq-add-NAND-SPL-support.patch|  172 +
 ...ib-add-driver-for-Lantiq-PSB697X-switch-f.patch |  162 -
 .../0021-MIPS-vrx200-add-NAND-SPL-support.patch|   37 +
 ...ib-add-driver-for-Lantiq-ADM6996I-switch-.patch |  158 -
 ...lantiq-easy80920-add-support-for-NAND-SPL.patch |   68 +
 ...t-switchlib-add-driver-for-Atheros-AR8216.patch |  158 -
 ...023-MIPS-add-support-for-Lantiq-XWAY-SoCs.patch | 9496 ---
 ...23-MIPS-lantiq-add-default-openwrt-config.patch |   56 +
 ...00-add-option-to-boot-from-AVM-EVA-loader.patch |   33 -
 ...tiq-easy50712-add-openwrt-lantiq-common.h.patch |   31 +
 ...S-add-board-support-for-AVM-FritzBox-3370.patch |  355 -
 ...tiq-easy80920-add-openwrt-lantiq-common.h.patch |   31 +
 ...PS-add-board-support-for-Arcadyan-ARV4519.patch |  262 +
 ...-MIPS-add-board-support-for-Gigaset-SX76X.patch |  264 -
 ...PS-add-board-support-for-Arcadyan-ARV7518.patch |  114 +-
 ...PS-add-board-support-for-Arcadyan-ARV4519.patch |  248 -
 ...S-add-board-support-for-AudioCodes-MP-252.patch |  268 +
 ...S-add-board-support-for-AVM-FritzBox-3370.patch |  374 +
 ...ols-add-some-helper-tools-for-Lantiq-SoCs.patch |  361 -
 ...-MIPS-add-board-support-for-Gigaset-SX76X.patch |  267 +
 ...MIPS-add-board-support-for-ZTE-ZXHN-H367N.patch |  327 +
 ...IPS-add-board-support-for-ZTE-ZXV10-H201L.patch |  271 +
 ...S-add-board-support-for-ZyXEL-P-661HNU-Fx.patch |  324 +
 ...S-add-board-support-for-ZyXEL-P-2601HN-Fx.patch |  262 +
 ...-add-board-support-for-ZyXEL-P-2812HNU-Fx.patch |  321 +
 ...dd-board-support-for-Arcadyan-Easybox-904.patch |  297 +
 ...-add-board-support-for-Arcadyan-ARV752DPW.patch |  262 +
 ...dd-board-support-for-Arcadyan-ARV752DPW22.patch |  264 +
 ...PS-add-board-support-for-Arcadyan-ARV7510.patch |  289 +
 ...e-prepare-u-boot-lantiq-v2013.10-openwrt4.patch |   23 +
 69 files changed, 18597 insertions(+), 13236 deletions(-)
 create mode 100644 package/boot/uboot-lantiq/README
 create mode 100644 
package/boot/uboot-lantiq/patches/0001-sf-fix

[OpenWrt-Devel] [PATCH 7/7] [boot] uboot-lantiq: add packages for AudioCodes MP-252

[Daniel Schwierzeck]

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 package/boot/uboot-lantiq/Makefile | 12 
 1 file changed, 12 insertions(+)

diff --git a/package/boot/uboot-lantiq/Makefile 
b/package/boot/uboot-lantiq/Makefile
index a18c82e..af1d7ad 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -121,6 +121,17 @@ define uboot/gigasx76x_nor
   SOC:=danube
 endef
 
+define uboot/acmp252_ram
+  TITLE:=U-Boot for AudioCodes MP-252 (RAM)
+  SOC:=danube
+  DDR_SETTINGS:=board/audiocodes/acmp252/ddr_settings.h
+endef
+
+define uboot/acmp252_nor
+  TITLE:=U-Boot for AudioCodes MP-252 (NOR)
+  SOC:=danube
+endef
+
 define uboot/easy50712_ram
   TITLE:=U-Boot for Lantiq EASY50712 (RAM)
   SOC:=danube
@@ -169,6 +180,7 @@ UBOOTS:= \
arv752dpw_ram arv752dpw_nor arv752dpw_brn \
arv752dpw22_ram arv752dpw22_nor arv752dpw22_brn \
gigasx76x_ram gigasx76x_nor \
+   acmp252_ram acmp252_nor \
easy50712_ram easy50712_nor easy50712_norspl \
easy80920_ram easy80920_nor easy80920_norspl easy80920_sfspl
 
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/7] [boot] uboot-lantiq: add packages for Lantiq EASY50712

[Daniel Schwierzeck]

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 package/boot/uboot-lantiq/Makefile | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/package/boot/uboot-lantiq/Makefile 
b/package/boot/uboot-lantiq/Makefile
index 40d1ae2..eb13a4e 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -63,10 +63,28 @@ define uboot/gigasx76x_nor
   SOC:=danube
 endef
 
+define uboot/easy50712_ram
+  TITLE:=U-Boot for Lantiq EASY50712 (RAM)
+  SOC:=danube
+  DDR_SETTINGS:=board/lantiq/easy50712/ddr_settings.h
+endef
+
+define uboot/easy50712_nor
+  TITLE:=U-Boot for Lantiq EASY50712 (NOR)
+  SOC:=danube
+endef
+
+define uboot/easy50712_norspl
+  TITLE:=U-Boot for Lantiq EASY50712 (NOR SPL)
+  SOC:=danube
+  IMAGE:=u-boot.ltq.lzo.norspl
+endef
+
 UBOOTS:= \
arv4519pw_ram arv4519pw_nor \
arv7518pw_ram arv7518pw_nor \
-   gigasx76x_ram gigasx76x_nor
+   gigasx76x_ram gigasx76x_nor \
+   easy50712_ram easy50712_nor easy50712_norspl
 
 define Package/uboot/template
 define Package/uboot-lantiq-$(1)
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 6/7] [boot] uboot-lantiq: add packages for various Arcadyan boards

[Daniel Schwierzeck]

Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
 package/boot/uboot-lantiq/Makefile | 65 --
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/package/boot/uboot-lantiq/Makefile 
b/package/boot/uboot-lantiq/Makefile
index f106e1b..a18c82e 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -41,6 +41,27 @@ define uboot/arv4519pw_nor
   SOC:=danube
 endef
 
+define uboot/arv4519pw_brn
+  TITLE:=U-Boot for Arcadyan arv4519pw (BRN)
+  SOC:=danube
+endef
+
+define uboot/arv7510pw_ram
+  TITLE:=U-Boot for Arcadyan arv7510pw (RAM)
+  SOC:=danube
+  DDR_SETTINGS:=board/arcadyan/arv7510pw/ddr_settings.h
+endef
+
+define uboot/arv7510pw_nor
+  TITLE:=U-Boot for Arcadyan arv7510pw (NOR)
+  SOC:=danube
+endef
+
+define uboot/arv7510pw_brn
+  TITLE:=U-Boot for Arcadyan arv7510pw (BRN)
+  SOC:=danube
+endef
+
 define uboot/arv7518pw_ram
   TITLE:=U-Boot for Arcadyan arv7518pw (RAM)
   SOC:=danube
@@ -52,6 +73,43 @@ define uboot/arv7518pw_nor
   SOC:=danube
 endef
 
+define uboot/arv7518pw_brn
+  TITLE:=U-Boot for Arcadyan arv7518pw (BRN)
+  SOC:=danube
+endef
+
+define uboot/arv752dpw_ram
+  TITLE:=U-Boot for Arcadyan arv752dpw (RAM)
+  SOC:=danube
+  DDR_SETTINGS:=board/arcadyan/arv752dpw/ddr_settings.h
+endef
+
+define uboot/arv752dpw_nor
+  TITLE:=U-Boot for Arcadyan arv752dpw (NOR)
+  SOC:=danube
+endef
+
+define uboot/arv752dpw_brn
+  TITLE:=U-Boot for Arcadyan arv752dpw (BRN)
+  SOC:=danube
+endef
+
+define uboot/arv752dpw22_ram
+  TITLE:=U-Boot for Arcadyan arv752dpw22 (RAM)
+  SOC:=danube
+  DDR_SETTINGS:=board/arcadyan/arv752dpw22/ddr_settings.h
+endef
+
+define uboot/arv752dpw22_nor
+  TITLE:=U-Boot for Arcadyan arv752dpw22 (NOR)
+  SOC:=danube
+endef
+
+define uboot/arv752dpw22_brn
+  TITLE:=U-Boot for Arcadyan arv752dpw22 (BRN)
+  SOC:=danube
+endef
+
 define uboot/gigasx76x_ram
   TITLE:=U-Boot for Siemens Gigaset sx76x (RAM)
   SOC:=danube
@@ -105,8 +163,11 @@ endef
 
 
 UBOOTS:= \
-   arv4519pw_ram arv4519pw_nor \
-   arv7518pw_ram arv7518pw_nor \
+   arv4519pw_ram arv4519pw_nor arv4519pw_brn \
+   arv7510pw_ram arv7510pw_nor arv7510pw_brn \
+   arv7518pw_ram arv7518pw_nor arv7518pw_brn \
+   arv752dpw_ram arv752dpw_nor arv752dpw_brn \
+   arv752dpw22_ram arv752dpw22_nor arv752dpw22_brn \
gigasx76x_ram gigasx76x_nor \
easy50712_ram easy50712_nor easy50712_norspl \
easy80920_ram easy80920_nor easy80920_norspl easy80920_sfspl
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel