Re: [PATCH v4 1/4] bootstd: Enable BOOTSTD_DEFAULTS by default
Hi Simon, On 29/03/2023 at 09:16, Simon Glass wrote: This is needed to enable the boot command used to start standard boot. Enable it by default. This brings in quite a few features, mostly in common with DISTRO_DEFAULTS Disable this option for boards which don't have enough space. What is the identified minimal space for benefiting from this feature? Disable CONFIG_ENV_VARS_UBOOT_CONFIG for some Xilinx boards which have a very small environment. Disable BOOTSTD_DEFAULTS for smartweb since it is too close to its limit. I see that a few Microchip boards are in this case too and even if sama5d27 som1 ek might be impacted, I would like to double check for the other sama5d2 boards. [..] Best regards, Nicolas -- Nicolas Ferre
Re: [U-Boot] [PATCH] net: macb: Clean 64b dma addresses if they are not detected
Michal, On 20/09/2018 at 08:23, Michal Simek wrote: On 19.9.2018 20:08, Edgar E. Iglesias wrote: On Wed, Sep 19, 2018 at 06:08:18PM +0200, Michal Simek wrote: Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B is not detected on 64bit system. The issue was observed when bootloader(u-boot) does not check macb feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support by default. Then macb driver is reading DMACFG register back and only adding 64bit dma configuration but not cleaning it out. This is also align with other features which are also cleared if they are not present. Hi Michal, Signed-off-by: Michal Simek --- drivers/net/ethernet/cadence/macb_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 16e4ef7d7185..79707dff3f13 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -2163,6 +2163,8 @@ static void macb_configure_dma(struct macb *bp) #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT if (bp->hw_dma_cap & HW_DMA_CAP_64B) dmacfg |= GEM_BIT(ADDR64); + else + dmacfg &= ~GEM_BIT(ADDR64); #endif I think you might want to do this clearing outside of the #ifdef. If CONFIG_ARCH_DMA_ADDR_T_64BIT is not defined, we'd want to make sure the ADDR64 is cleared. E.g something like: dmacfg &= ~GEM_BIT(ADDR64); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT if (bp->hw_dma_cap & HW_DMA_CAP_64B) dmacfg |= GEM_BIT(ADDR64); #endif Same thing for the USE_HWSTAMP/PTP flags below. Origin patch, which introduce this read with mask, macfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L); was done in 2011 and from that time this function was extended a little bit. I am even not quite sure if make sense to read this reg and apply setting on the top of it. Nicolas: Isn't it better simply compose that reg from scratch? I have several arguments against composing this register from scratch: 1/ the reset value of this register is non-null for both of our platforms and it could be meaningful to keep some of these values. 2/ one bitfield could use different values between Zynq and AT91: RXBMS (1kB to 8kB for Zynq and 512 to 4KB for AT91), with same encoding. 3/ and well, this is the type of register with multiple bits that are marked as "reserved" and that experience tells that they might be connected to something... So, I'm all for correcting the code like what Edgar suggests. Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot
On 01/03/2018 at 20:55, Mariano Coromac wrote: I found the problem. In my header file I was reading from eMMC device 1. Not 0. That's why the operations with mmc worked in command line but did not on startup. Please correct me if I'm mistaken but I have a couple questions. 1) Do I need a partition in my eMMC in order to boot the Linux kernel? When I run "mmc part" it shows no partition at all. 2) When U-Boot finishes compiling it generates a .dtb with the name of my custom board. I need to write this file (alongside zImage) inside my eMMC for my Linux Kernel to boot right? Actually no: the .dtb from U-Boot is for U-Boot to use. For loading the Linux kernel, you must use the .dtb that is produced by the compilation of the kernel (in arch/arm/boot/dts/) When I try to boot the kernel it hangs in here: => boot reading p_a5_tab_reva.dtb 13699 bytes read in 18 ms (743.2 KiB/s) reading zImage 3749624 bytes read in 298 ms (12 MiB/s) ## Flattened Device Tree blob at 2100 Booting using the fdt blob at 0x2100 Loading Device Tree to 27b7d000, end 27b83582 ... OK Starting kernel ... What do you think of this? Perhaps is regarding the kernel itself or maybe is a UBoot configuration? -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot
On 12/02/2018 at 18:13, Mariano Coromac wrote: > With that one there is none, I had problems with the other one. I don't understand this sentence. > Right now I just want to know how the CONIG parameters like this one: > CONFIG_8xx_CONS_SMC1= I don't see such parameter in a sama5d2 xplained .config. For a sama5d2 xplained board, you can refer to these files for configuration: include/configs/at91-sama5_common.h include/configs/sama5d2_xplained.h configs/sama5d2_xplained_spiflash_defconfig and other defconfigs and you can follow the initialization phase from: board/atmel/sama5d2_xplained/sama5d2_xplained.c Device tree files are also important: arch/arm/dts/at91-sama5d2_xplained.dts > Apply to my SAMA5D2. I already have my debug uart working but not the > monitor console. Therefore I can't even print 'help'. > Also, I'm still having trouble with the drivers as you can see above. On the u-boot-2017.03-at91 branch of our vendor tree, you have an example of moving the console from one USART to the other with this commit: 74f976f8d1fe714b5b28d450e7213657ca8dd71e (board: atmel: sama5d2_ptc_ek: use uart0 as console output) Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot
On 12/02/2018 at 17:28, Mariano Coromac wrote: > Sorry, I tried to switch to the upstream repo but it gave some compiling > errors. > I am using the 409952795f8a28d3c266b2b8b2b9eccf46347601 commit from > git://github.com/linux4sam/u-boot-at91.git > <http://github.com/linux4sam/u-boot-at91.git> Can you tell us what is the compiling error that you are experiencing? Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: macb: Not all the GEM are gigabit capable
Le 16/12/2015 11:27, Gregory CLEMENT a écrit :
> During the initialization of PHY the gigabit bit capable is set if the
> controller is a GEM. However, for sama5d2 and sama5d4, the GEM is
> configured to support only 10/100.
>
> Improperly setting the GBE capability leads to an unresponsive MAC
> controller. This patch fix this behavior allowing to use the gmac with
> these SoCs.
>
> Suggested-by: Nicolas Ferre <nicolas.fe...@atmel.com>
> Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
>
> fix gem
> ---
> drivers/net/macb.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index a5c1880..ab38f48 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -109,6 +109,15 @@ static int macb_is_gem(struct macb_device *macb)
> return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) == 0x2;
> }
>
> +static int gem_is_gigabit_capable(struct macb_device *macb)
> +{
> + /*
> + * The GEM controllers embeded in SAMA5D2 and SAMA5D4 are
> + * configured to support only 10/100.
> + */
> + return macb_is_gem(macb) && !cpu_is_sama5d2() && !cpu_is_sama5d2();
Typo here: sama5d2 twice!
;-)
> +}
> +
> static void macb_mdio_write(struct macb_device *macb, u8 reg, u16 value)
> {
> unsigned long netctl;
> @@ -480,8 +489,8 @@ static int macb_phy_init(struct macb_device *macb)
> return 0;
> }
>
> - /* First check for GMAC */
> - if (macb_is_gem(macb)) {
> + /* First check for GMAC and that it is GiB capable */
> + if (gem_is_gigabit_capable(macb))
> lpa = macb_mdio_read(macb, MII_STAT1000);
>
> if (lpa & (LPA_1000FULL | LPA_1000HALF)) {
>
--
Nicolas Ferre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: macb: Not all the GEM are gigabit capable
Le 16/12/2015 14:50, Gregory CLEMENT a écrit :
> During the initialization of PHY the gigabit bit capable is set if the
> controller is a GEM. However, for sama5d2 and sama5d4, the GEM is
> configured to support only 10/100.
>
> Improperly setting the GBE capability leads to an unresponsive MAC
> controller. This patch fixes this behavior allowing using the gmac with
> these SoCs.
>
> Suggested-by: Nicolas Ferre <nicolas.fe...@atmel.com>
> Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.fe...@atmel.com>
Thanks,
> ---
> Hi,
>
> in this v3, I fixed the sama5d2 typo and the missing brace.
>
> I also took care of the cpu_is_* symbols which may not be defined
> depending of the choice of the SoC.
>
> Gregory
>
> drivers/net/macb.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index a5c1880..e801313 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -109,6 +109,23 @@ static int macb_is_gem(struct macb_device *macb)
> return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) == 0x2;
> }
>
> +#ifndef cpu_is_sama5d2
> +#define cpu_is_sama5d2() 0
> +#endif
> +
> +#ifndef cpu_is_sama5d4
> +#define cpu_is_sama5d4() 0
> +#endif
> +
> +static int gem_is_gigabit_capable(struct macb_device *macb)
> +{
> + /*
> + * The GEM controllers embeded in SAMA5D2 and SAMA5D4 are
> + * configured to support only 10/100.
> + */
> + return macb_is_gem(macb) && !cpu_is_sama5d2() && !cpu_is_sama5d4();
> +}
> +
> static void macb_mdio_write(struct macb_device *macb, u8 reg, u16 value)
> {
> unsigned long netctl;
> @@ -480,8 +497,8 @@ static int macb_phy_init(struct macb_device *macb)
> return 0;
> }
>
> - /* First check for GMAC */
> - if (macb_is_gem(macb)) {
> + /* First check for GMAC and that it is GiB capable */
> + if (gem_is_gigabit_capable(macb)){
> lpa = macb_mdio_read(macb, MII_STAT1000);
>
> if (lpa & (LPA_1000FULL | LPA_1000HALF)) {
>
--
Nicolas Ferre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: Add Support for the VInCo platform
Le 16/12/2015 14:53, Gregory CLEMENT a écrit :
> The Versatile Industrial Communication platform is a community oriented
> board from Landis + Gyr. It comes with:
> - an RS-485 port
> - 2 Ethernet ports
> - a wireless M-BUS
> - a 4G modem
> - a 4MB SPI flash
> - a 4GB eMMC
>
> Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
It seems okay to me:
Acked-by: Nicolas Ferre <nicolas.fe...@atmel.com>
Thanks,
> ---
> arch/arm/mach-at91/Kconfig | 6 ++
> board/l+g/vinco/Kconfig| 12 +++
> board/l+g/vinco/Makefile | 1 +
> board/l+g/vinco/vinco.c| 212
> +
> configs/vinco_defconfig| 13 +++
> include/configs/vinco.h| 172
> 6 files changed, 416 insertions(+)
> create mode 100644 board/l+g/vinco/Kconfig
> create mode 100644 board/l+g/vinco/Makefile
> create mode 100644 board/l+g/vinco/vinco.c
> create mode 100644 configs/vinco_defconfig
> create mode 100644 include/configs/vinco.h
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index c333647..3dfbb5f 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -114,6 +114,11 @@ config TARGET_SMARTWEB
> select CPU_ARM926EJS
> select SUPPORT_SPL
>
> +config TARGET_VINCO
> + bool "Support VINCO"
> + select CPU_V7
> + select SUPPORT_SPL
> +
> endchoice
>
> config SYS_SOC
> @@ -136,6 +141,7 @@ source "board/bluewater/snapper9260/Kconfig"
> source "board/calao/usb_a9263/Kconfig"
> source "board/egnite/ethernut5/Kconfig"
> source "board/esd/meesc/Kconfig"
> +source "board/l+g/vinco/Kconfig"
> source "board/mini-box/picosam9g45/Kconfig"
> source "board/ronetix/pm9261/Kconfig"
> source "board/ronetix/pm9263/Kconfig"
> diff --git a/board/l+g/vinco/Kconfig b/board/l+g/vinco/Kconfig
> new file mode 100644
> index 000..229b5ea
> --- /dev/null
> +++ b/board/l+g/vinco/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_VINCO
> +
> +config SYS_BOARD
> + default "vinco"
> +
> +config SYS_VENDOR
> + default "l+g"
> +
> +config SYS_CONFIG_NAME
> + default "vinco"
> +
> +endif
> diff --git a/board/l+g/vinco/Makefile b/board/l+g/vinco/Makefile
> new file mode 100644
> index 000..a2b8a2b
> --- /dev/null
> +++ b/board/l+g/vinco/Makefile
> @@ -0,0 +1 @@
> +obj-y += vinco.o
> diff --git a/board/l+g/vinco/vinco.c b/board/l+g/vinco/vinco.c
> new file mode 100644
> index 000..3d7af09
> --- /dev/null
> +++ b/board/l+g/vinco/vinco.c
> @@ -0,0 +1,212 @@
> +/*
> + * Board file for the VInCo platform
> + * Based on the the SAMA5-EK board file
> + * Configuration settings for the VInCo platform.
> + * Copyright (C) 2014 Atmel
> + * Bo Shen <voice.s...@atmel.com>
> + * Copyright (C) 2015 Free Electrons
> + * Gregory CLEMENT <gregory.clem...@free-electrons.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#ifdef CONFIG_ATMEL_SPI
> +int spi_cs_is_valid(unsigned int bus, unsigned int cs)
> +{
> + return bus == 0 && cs == 0;
> +}
> +
> +void spi_cs_activate(struct spi_slave *slave)
> +{
> + at91_set_pio_output(AT91_PIO_PORTC, 3, 0);
> +}
> +
> +void spi_cs_deactivate(struct spi_slave *slave)
> +{
> + at91_set_pio_output(AT91_PIO_PORTC, 3, 1);
> +}
> +
> +static void vinco_spi0_hw_init(void)
> +{
> + at91_set_a_periph(AT91_PIO_PORTC, 0, 0);/* SPI0_MISO */
> + at91_set_a_periph(AT91_PIO_PORTC, 1, 0);/* SPI0_MOSI */
> + at91_set_a_periph(AT91_PIO_PORTC, 2, 0);/* SPI0_SPCK */
> +
> + at91_set_pio_output(AT91_PIO_PORTC, 3, 1); /* SPI0_CS0 */
> +
> + /* Enable clock */
> + at91_periph_clk_enable(ATMEL_ID_SPI0);
> +}
> +#endif /* CONFIG_ATMEL_SPI */
> +
> +
> +#ifdef CONFIG_CMD_USB
> +static void vinco_usb_hw_init(void)
> +{
> + at91_set_pio_output(AT91_PIO_PORTE, 11, 0);
> + at91_set_pio_output(AT91_PIO_PORTE, 12, 0);
> + at91_set_pio_output(AT91_PIO_PORTE, 10, 0);
> +}
> +#endif
> +
> +
> +#ifdef CONFIG_GENERIC_ATMEL_MCI
> +void vinco_mci0_hw_init(voi
Re: [U-Boot] [PATCH] net: macb: sama5d4 is not gigabit capable
Le 15/12/2015 20:59, Joe Hershberger a écrit :
> Hi Gregory,
>
> On Mon, Dec 14, 2015 at 10:37 AM, Gregory CLEMENT
> <gregory.clem...@free-electrons.com> wrote:
>> During the initialization of PHY the gigabit bit capable is set if the
>> controller is a GEM. However, for sama5d4, the GEM is not gigabit
>> capable. Improperly setting the GBE capability leads to an unresponsive
>> MAC controller. This patch fix this behavior allowing to use the gmac
>> with the sama5d4.
>>
>> Suggested-by: Nicolas Ferre <nicolas.fe...@atmel.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
>> ---
>> drivers/net/macb.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> index a5c1880..642717d 100644
>> --- a/drivers/net/macb.c
>> +++ b/drivers/net/macb.c
>> @@ -480,8 +480,11 @@ static int macb_phy_init(struct macb_device *macb)
>> return 0;
>> }
>>
>> - /* First check for GMAC */
>> - if (macb_is_gem(macb)) {
>> + /*
>> +* First check for GMAC, but not the one on SAMA5D4 which is
>> +* not gigabit capabale
>> +*/
>> + if (macb_is_gem(macb) && ! cpu_is_sama5d4()) {
>
> Is there not some other property that can identify the lack of Gigabit
> support in the "GEM"? It would be better to not have to keep track of
> the next processor and the one after that which has the same
> situation.
Actually, sama5d2 is in the same situation already...
Bye,
>
>> lpa = macb_mdio_read(macb, MII_STAT1000);
>>
>> if (lpa & (LPA_1000FULL | LPA_1000HALF)) {
>> --
>> 2.5.0
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
--
Nicolas Ferre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: macb: sama5d4 is not gigabit capable
Le 16/12/2015 10:41, Gregory CLEMENT a écrit :
> Hi Andreas,
>
> On mer., déc. 16 2015, "Andreas Bießmann" <andreas.de...@googlemail.com>
> wrote:
>
>> Hi all,
>>
>> On 16.12.2015 10:19, Nicolas Ferre wrote:
>>> Le 15/12/2015 20:59, Joe Hershberger a écrit :
>>>> Hi Gregory,
>>>>
>>>> On Mon, Dec 14, 2015 at 10:37 AM, Gregory CLEMENT
>>>> <gregory.clem...@free-electrons.com> wrote:
>>>>> During the initialization of PHY the gigabit bit capable is set if the
>>>>> controller is a GEM. However, for sama5d4, the GEM is not gigabit
>>>>> capable. Improperly setting the GBE capability leads to an unresponsive
>>>>> MAC controller. This patch fix this behavior allowing to use the gmac
>>>>> with the sama5d4.
>>>>>
>>>>> Suggested-by: Nicolas Ferre <nicolas.fe...@atmel.com>
>>>>> Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
>>>>> ---
>>>>> drivers/net/macb.c | 7 +--
>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>>>>> index a5c1880..642717d 100644
>>>>> --- a/drivers/net/macb.c
>>>>> +++ b/drivers/net/macb.c
>>>>> @@ -480,8 +480,11 @@ static int macb_phy_init(struct macb_device *macb)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> - /* First check for GMAC */
>>>>> - if (macb_is_gem(macb)) {
>>>>> + /*
>>>>> +* First check for GMAC, but not the one on SAMA5D4 which is
>>>>> +* not gigabit capabale
>>>>> +*/
>>>>> + if (macb_is_gem(macb) && ! cpu_is_sama5d4()) {
>>>>
>>>> Is there not some other property that can identify the lack of Gigabit
>>>> support in the "GEM"? It would be better to not have to keep track of
>>>> the next processor and the one after that which has the same
>>>> situation.
>>>
>>> Actually, sama5d2 is in the same situation already...
>>
>> would it be a compromise to patch the macb_is_gem() in favor of the
>> different usages of this function?
>
> I was thinking of introducing a is_gb_capable() function.
>
>>
>> On the other hand I also wonder why the MACB IP tells it is GiB capable
>> by the IDNUM bitfield. Isn't there a possibility to fix this
>> detection?
>
> the first part of the IDNUM identify the generation of this IP and 0x1
> is MACB whereas 0x2 is GEM. As I wrote in my previous email, I _think_
> that the GEM is really GiB capabale but the SoC around do not provde the
> needed ressource for this (such as line running at GHz).
Actually, the GEM IP from Cadence can be configured to only do
10/100Mbs. So the IP ID doesn't tell that and the design configuration
registers don't seem to reflect that.
Bye,
--
Nicolas Ferre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] ARM: atmel: add sama5d4ek board support
On 16/09/2014 09:57, Bo Shen : This patch series add sama5d4ek board support which supports following features: - Boot media support: NAND flash/SD card/SPI flash - Support LCD display - Support ethernet - Support USB mass storage This patch series depends on the series [1]: ARM: atmel: use pcr to enable or disable peripheral clock. [1] http://patchwork.ozlabs.org/patch/376960/ Bo Shen (2): net: macb: enable GMAC IP without GE feature support ARM: atmel: add sama5d4ek board support Josh Wu (1): atmel_nand: if don't have gf table in rom code we will build it runtime For the whole series: Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Thanks, best regards, arch/arm/Kconfig | 4 + arch/arm/cpu/armv7/at91/timer.c | 3 +- arch/arm/include/asm/arch-at91/at91_pmc.h | 6 +- arch/arm/include/asm/arch-at91/clk.h | 29 +++ arch/arm/include/asm/arch-at91/hardware.h | 2 + arch/arm/include/asm/arch-at91/sama5d4.h | 199 ++ board/atmel/sama5d4ek/Kconfig | 18 ++ board/atmel/sama5d4ek/MAINTAINERS | 8 + board/atmel/sama5d4ek/Makefile| 15 ++ board/atmel/sama5d4ek/sama5d4ek.c | 322 ++ configs/sama5d4ek_mmc_defconfig | 3 + configs/sama5d4ek_nandflash_defconfig | 3 + configs/sama5d4ek_spiflash_defconfig | 3 + drivers/mtd/nand/atmel_nand.c | 127 +++- drivers/net/macb.c| 8 +- include/configs/sama5d4ek.h | 215 16 files changed, 959 insertions(+), 6 deletions(-) create mode 100644 arch/arm/include/asm/arch-at91/sama5d4.h create mode 100644 board/atmel/sama5d4ek/Kconfig create mode 100644 board/atmel/sama5d4ek/MAINTAINERS create mode 100644 board/atmel/sama5d4ek/Makefile create mode 100644 board/atmel/sama5d4ek/sama5d4ek.c create mode 100644 configs/sama5d4ek_mmc_defconfig create mode 100644 configs/sama5d4ek_nandflash_defconfig create mode 100644 configs/sama5d4ek_spiflash_defconfig create mode 100644 include/configs/sama5d4ek.h -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm : Atmel : add at91sam9x5ek board support
On 07/02/2012 12:02 PM, Andreas Bießmann : Dear all, On 02.07.2012 11:53, Nicolas Ferre wrote: On 07/02/2012 11:47 AM, Andreas Bießmann : On 02.07.2012 10:36, Bo Shen wrote: [..] +/* bootstrap + u-boot + env + linux in nandflash */ +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_OFFSET0xc +#define CONFIG_ENV_OFFSET_REDUND0x10 +#define CONFIG_ENV_SIZE0x2/* 1 sector = 128 kB */ +#define CONFIG_BOOTCOMMANDnand read.jffs2 \ +0x2200 0x20 0x30; \ +bootm 0x2200 Well, you read from jffs but work with ubifs later on? Is that ok? BTW: I do not know 'nand read.jffs2', does this subcommand exist really? Using the read with subfix .jffs2 it to skip the bad block. This partition is for Linux kernel. I will remove the .jffs2 to avoid confusing. Well, it is ok with me to use read.jffs2 (if it works). I just do not know about that subcommand and I can only find some references about that in two other boards. I guess these boards are just forgotten while removing the 'nand read.jffs2' command. Please check, if that command works, if yes let it as is, if not rewrite. I am in favor of using read.jffs2 because it is able to skip bad blocks. As the programming tool is also skipping bad blocks the same way, we have a configuration that is perfectly working even in case of bad block in the middle of the kernel image. So please, keep using read.jffs2 (or equivalent)! I have the same opinion here, we should skip bad blocks. But I think 'nand read.jffs2' is not available any longer. from current common/cmd_nand.c: ---8--- nand read - addr off|partition size\n nand write - addr off|partition size\n read/write 'size' bytes starting at offset 'off'\n to/from memory address 'addr', skipping bad blocks.\n nand read.raw - addr off|partition [count]\n nand write.raw - addr off|partition [count]\n Use read.raw/write.raw to avoid ECC and access the flash as-is.\n ---8--- ... skipping bad blocks So it seems that simple nand read/write is what we are looking for... in comparison with read.raw/write.raw. Fair enough: nand read/write is the way to go, now. Thanks, best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: prevent libgcc to be linked twice
On 10/18/2011 06:06 PM, Mike Frysinger : On Tuesday 18 October 2011 04:30:27 Nicolas Ferre wrote: On 10/17/2011 07:25 PM, Mike Frysinger : On Monday 17 October 2011 09:41:15 Nicolas Ferre wrote: If we define USE_PRIVATE_LIBGCC, PLATFORM_LIBS is used during link. During this last link editing, libgcc may be listed twice and fail. Prevent this using filter-out in top Makefile. could you please provide more details ? libgcc should not be listed twice. I compile current u-boot with the flowing command line: make -j5 CROSS_COMPILE=arm-linux-gnueabi- USE_PRIVATE_LIBGCC=yes at91sam9m10g45ek_nandflash the issue shows up when using the board shortcut, and only when your tree is already configured. if you use at91sam9m10g45ek_nandflash_config and then another make, it works fine. if you start from a clean tree (git clean -x -d), it works fine. Ah thanks for the information. Indeed it is a more common way of using the configuration/compilation flow... this is due to PLATFORM_LIBS appending PLATFORM_LIBGCC when the tree has been configured, then exporting PLATFORM_LIBS, then the board shortcut running $(MAKE). the exported PLATFORM_LIBS gets LIBGCC appended a second time. this issue will show up with any value that gets appended to PLATFORM_LIBS and not just libgcc. the arm code already hits this and deals with it locally. seems like we should instead unify this logic, or redo PLATFORM_LIBS so that it isn't an issue in the first place. Yes, that it a bit confusing... But with proper explanation, we can deal with this. Thanks for your help, best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: prevent libgcc to be linked twice
On 10/17/2011 07:25 PM, Mike Frysinger : On Monday 17 October 2011 09:41:15 Nicolas Ferre wrote: If we define USE_PRIVATE_LIBGCC, PLATFORM_LIBS is used during link. During this last link editing, libgcc may be listed twice and fail. Prevent this using filter-out in top Makefile. could you please provide more details ? libgcc should not be listed twice. I compile current u-boot with the flowing command line: make -j5 CROSS_COMPILE=arm-linux-gnueabi- USE_PRIVATE_LIBGCC=yes at91sam9m10g45ek_nandflash On an Ubuntu 11.10 with Linaro's cross-toolchain (targeting ARMv7). My SoC is an ARM926 so I use the USE_PRIVATE_LIBGCC=yes switch. This will prevent the build to take libgcc from my host but compile the u-boot embedded libgcc: everything is fine, good feature. But, here is the final link editing stage: UNDEF_SYM=`arm-linux-gnueabi-objdump -x board/atmel/at91sam9m10g45ek/libat91sam9m10g45ek.o api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o dri vers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/nferre/workspace/u-boot/u-boot-git arm-linux-gnueabi-ld -pie -T u-boot.lds -Bstatic -Ttext 0x73f0 $UNDEF_SYM arch/arm/cpu/arm926ejs/start.o --start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand /libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/atmel/at91sam9m10g45ek/libat91sam9m10g45ek.o --end-group /home/nferre/workspace/u-boot/u-boot-git/arch/arm/lib/eabi_compat.o /home/nferre/workspace/u-boot/u-boot-git/arch/arm/lib /libgcc.o /home/nferre/workspace/u-boot/u-boot-git/arch/arm/lib/libgcc.o -Map u-boot.map -o u-boot And you see that there is arch/arm/lib/libgcc.o included twice in object files that have to be linked together. I think that it is coming from the PLATFORM_LIBS variable so I modified like in my patch which solves the problem. Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: prevent libgcc to be linked twice
If we define USE_PRIVATE_LIBGCC, PLATFORM_LIBS is used during link. During this last link editing, libgcc may be listed twice and fail. Prevent this using filter-out in top Makefile. Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 5db2e0e..4bdfe11 100644 --- a/Makefile +++ b/Makefile @@ -311,7 +311,8 @@ endif else PLATFORM_LIBGCC = -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc endif -PLATFORM_LIBS += $(PLATFORM_LIBGCC) +PLATFORM_LIBS := $(PLATFORM_LIBGCC) \ + $(filter-out %$(PLATFORM_LIBGCC), $(PLATFORM_LIBS)) export PLATFORM_LIBS # Special flags for CPP when processing the linker script. -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add initilisation of watchdog in init_sequence
Le 30/05/2010 13:17, Tom Rix : Nicolas Ferre wrote: For platforms that implement a hardware watchdog, call its initialization routine in init_sequence. This location has been chosen to be the closest to initialization of console as some watchdog drivers are writing status messages. On the other hand, watchdog setup should be close to chip startup to be able to begin the triggering quickly. I am not opposed to putting watchdog into the init sequence. A current ARM way for initializing the watchdog is to do it in s_init. Why doesn't this work for you ? Well, I only see it done like this in some omap platforms. It does work for me because we do not always use the lowlevel_init.S file: sometimes, the low level initialization is done by a tiny first level bootloader... Reviewing other watchdog additions in the init sequences from powerpc,sh,m68k If an init is to be added, this setup should be cut-n-pasted from one of these. There should be follow-on patches to convert the ARM s_init's over to using the init sequence. I guess that as architecture implementation are different in the way of initializing watchdog, I may include this in each board file or create a common initialization for AT91 at board level... Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: atmel_usart: insert watchdog petting during putc() and tstc()
Watchdog resets were experienced during autoboot delay. Petting the watchdog
during putc() and tstc() functions solve the issue.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/serial/atmel_usart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index cad3412..fcaee5d 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -80,7 +80,8 @@ void serial_putc(char c)
if (c == '\n')
serial_putc('\r');
- while (!(usart3_readl(CSR) USART3_BIT(TXRDY))) ;
+ while (!(usart3_readl(CSR) USART3_BIT(TXRDY)))
+WATCHDOG_RESET();
usart3_writel(THR, c);
}
@@ -99,5 +100,6 @@ int serial_getc(void)
int serial_tstc(void)
{
+ WATCHDOG_RESET();
return (usart3_readl(CSR) USART3_BIT(RXRDY)) != 0;
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog petting during autoboot delay
Le 26/05/2010 20:13, Mike Frysinger :
On Wednesday 26 May 2010 06:34:49 Nicolas Ferre wrote:
--- a/common/main.c
+++ b/common/main.c
@@ -159,6 +159,7 @@ static __inline__ int abortboot(int bootdelay)
* when catch up.
*/
do {
+WATCHDOG_RESET(); /* Trigger watchdog, if needed */
if (tstc()) {
if (presskey_len presskey_max) {
presskey [presskey_len ++] = getc();
@@ -251,6 +252,7 @@ static __inline__ int abortboot(int bootdelay)
# endif
break;
}
+WATCHDOG_RESET(); /* Trigger watchdog, if needed
*/
udelay(1);
}
if your udelay() implementation isnt calling WATCHDOG_RESET(), it is broken.
yes, this is undocumented, but search the mailing archives for examples.
Yes, for sure, udelay() is calling WATCHDOG_RESET().
i believe the same goes for serial devices and their tstc() function.
True, this is where the problem resides. I will try to modify the
atmel_serial tstc() function.
Best regards,
--
Nicolas Ferre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog petting during autoboot delay
Le 26/05/2010 20:13, Mike Frysinger :
On Wednesday 26 May 2010 06:34:49 Nicolas Ferre wrote:
--- a/common/main.c
+++ b/common/main.c
@@ -159,6 +159,7 @@ static __inline__ int abortboot(int bootdelay)
* when catch up.
*/
do {
+WATCHDOG_RESET(); /* Trigger watchdog, if needed */
if (tstc()) {
if (presskey_len presskey_max) {
presskey [presskey_len ++] = getc();
@@ -251,6 +252,7 @@ static __inline__ int abortboot(int bootdelay)
# endif
break;
}
+WATCHDOG_RESET(); /* Trigger watchdog, if needed
*/
udelay(1);
}
if your udelay() implementation isnt calling WATCHDOG_RESET(), it is broken.
yes, this is undocumented, but search the mailing archives for examples.
i believe the same goes for serial devices and their tstc() function.
Well, after more checking, it seems that resetting the watchdog in tstc
function is not so common: only serial_pl01x.c is doing it. So I guess
that my first addition may be needed for other chips...
Best regards,
--
Nicolas Ferre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: add initilisation of watchdog in init_sequence
For platforms that implement a hardware watchdog, call its initialization
routine in init_sequence.
This location has been chosen to be the closest to initialization of console as
some watchdog drivers are writing status messages. On the other hand, watchdog
setup should be close to chip startup to be able to begin the triggering
quickly.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/lib/board.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index f5660a9..569009e 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -70,6 +70,10 @@ extern int AT91F_DataflashInit(void);
extern void dataflash_print_info(void);
#endif
+#ifdef CONFIG_HW_WATCHDOG
+extern void hw_watchdog_init(void);
+#endif
+
#ifndef CONFIG_IDENT_STRING
#define CONFIG_IDENT_STRING
#endif
@@ -251,6 +255,9 @@ init_fnc_t *init_sequence[] = {
serial_init,/* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
+#if defined(CONFIG_HW_WATCHDOG)
+ hw_watchdog_init, /* watchdog setup */
+#endif
#if defined(CONFIG_DISPLAY_CPUINFO)
print_cpuinfo, /* display cpu info (and speed) */
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] watchdog petting during autoboot delay
Watchdog resets were experienced during autoboot delay. Petting the watchdog
during abortboot() function solve the issue.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
common/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index f7e7c1c..ea040aa 100644
--- a/common/main.c
+++ b/common/main.c
@@ -159,6 +159,7 @@ static __inline__ int abortboot(int bootdelay)
* when catch up.
*/
do {
+ WATCHDOG_RESET(); /* Trigger watchdog, if needed */
if (tstc()) {
if (presskey_len presskey_max) {
presskey [presskey_len ++] = getc();
@@ -251,6 +252,7 @@ static __inline__ int abortboot(int bootdelay)
# endif
break;
}
+ WATCHDOG_RESET(); /* Trigger watchdog, if needed
*/
udelay(1);
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Network AT91 AVR32: generic way of addressing USRIO register layout
The MACB IP used by AVR32 AT91 have two different layout for USRIO register. We have to differentiate this in the driver code. No more cpu specific #ifdefs in driver: we manage a configuration variable. Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- drivers/net/macb.c |6 ++ drivers/net/macb.h |7 +++ 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 6de0a04..1023315 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -446,15 +446,13 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) /* choose RMII or MII mode. This depends on the board */ #ifdef CONFIG_RMII -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) +#if defined(CONFIG_MACB_USRIO_CFG1) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); #endif #else -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) +#if defined(CONFIG_MACB_USRIO_CFG1) macb_writel(macb, USRIO, MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, MACB_BIT(MII)); diff --git a/drivers/net/macb.h b/drivers/net/macb.h index f92a20c..349499c 100644 --- a/drivers/net/macb.h +++ b/drivers/net/macb.h @@ -212,6 +212,13 @@ #define MACB_SOF_OFFSET30 #define MACB_SOF_SIZE 2 +/* MACB IP used by AVR32 AT91 have two + * different layout for USRIO register. */ +#if !defined(CONFIG_AVR32) +/* Use AT91 USRIO layout */ +#define CONFIG_MACB_USRIO_CFG1 1 +#endif + /* Bitfields in USRIO */ #define MACB_MII_OFFSET0 #define MACB_MII_SIZE 1 -- 1.5.3.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC.
Ben, Ben Warren : Hi Nicolas, Nicolas Ferre wrote: snip diff --git a/drivers/net/macb.c b/drivers/net/macb.c index af0409b..6de0a04 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -447,14 +447,14 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) /* choose RMII or MII mode. This depends on the board */ #ifdef CONFIG_RMII #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); #endif #else #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, MACB_BIT(MII)); Please find a more generic way of doing this. There should be no board/cpu specific #ifdefs in common drivers. While you're at it, fix up the existing ones. Tell me if a configuration variable that I setup in the macb.h file depending on CPU is acceptable ? Here is the snippet : in drivers/net/macb.h +/* MACB IP used by AVR32 AT91 have two + * different layout for USRIO register. */ +#if !defined(CONFIG_AVR32) +/* Use AT91 USRIO layout */ +#define CONFIG_MACB_USRIO_CFG1 1 +#endif And then I use CONFIG_MACB_USRIO_CFG1 in macb.c This will prevent me from setting this variable in every CPU config file... Bye, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: NAND OOB and ECC in U-Boot vs Linux
Jesus Alvarez jalvarez at micromint.com writes: The AT91 Linux kernel patches for versions 2.6.27 or later use a separate atmel_nand.c driver that implements some OOB and ECC options that are not exactly the same as those in the standard kernel NAND driver (nand_base.c , etc.). AT91 based boards can use the CONFIG_MTD_NAND_ATMEL option to enable the atmel_nand driver together with CONFIG_MTD_NAND_ATMEL_ECC_HW, CONFIG_MTD_NAND_ATMEL_ECC_SOFT or CONFIG_MTD_NAND_ATMEL_ECC_NONE for the desired ECC. The OOB layout used by that driver appears to be different. CONFIG_MTD_NAND_ATMEL_ECC_SOFT is fully compatible with u-boot management of NAND flash. Indeed CONFIG_MTD_NAND_ATMEL_ECC_HW uses a different layout of OOB (ecc just after data, at bad block notification location). If you use this option in Linux, you will have to make sure that u-boot supports it. Regards, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC.
Ben Warren : Hi Nicolas, Nicolas Ferre wrote: snip diff --git a/drivers/net/macb.c b/drivers/net/macb.c index af0409b..6de0a04 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -447,14 +447,14 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) /* choose RMII or MII mode. This depends on the board */ #ifdef CONFIG_RMII #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); #endif #else #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, MACB_BIT(MII)); Please find a more generic way of doing this. There should be no board/cpu specific #ifdefs in common drivers. While you're at it, fix up the existing ones. Ben, Maybe we can separate the two topics in two separate actions. I propose that we go on with this patch for at91sam9g20 adding and, after this, we can concentrate on chasing #ifdefs in drivers. Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC.
AT91sam9g20 is an evolution of the at91sam9260 with a faster clock speed.
The AT91SAM9G20-EK board is an updated revision of the AT91SAM9260-EK board.
It is essentially the same, with a few minor differences.
Here is the chip page on Atmel website:
http://www.atmel.com/dyn/products/product_card.asp?part_id=4337
Signed-off-by: Justin Waters justin.wat...@timesys.com
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
MAKEALL |1 +
Makefile | 14 --
board/atmel/at91sam9260ek/at91sam9260ek.c |5 +
cpu/arm926ejs/at91/usb.c |4 ++--
doc/README.at91 |2 +-
drivers/net/macb.c|4 ++--
include/asm-arm/arch-at91/hardware.h |2 +-
include/configs/at91sam9260ek.h | 23 ++-
8 files changed, 42 insertions(+), 13 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 25d0647..7ce4b70 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -569,6 +569,7 @@ LIST_at91= \
at91rm9200dk\
at91rm9200ek\
at91sam9260ek \
+ at91sam9g20ek \
at91sam9261ek \
at91sam9263ek \
at91sam9rlek\
diff --git a/Makefile b/Makefile
index c24115d..45cb8b6 100644
--- a/Makefile
+++ b/Makefile
@@ -2648,8 +2648,18 @@ at91cap9adk_config : unconfig
at91sam9260ek_nandflash_config \
at91sam9260ek_dataflash_cs0_config \
at91sam9260ek_dataflash_cs1_config \
-at91sam9260ek_config : unconfig
- @mkdir -p $(obj)include
+at91sam9260ek_config \
+at91sam9g20ek_nandflash_config \
+at91sam9g20ek_dataflash_cs0_config \
+at91sam9g20ek_dataflash_cs1_config \
+at91sam9g20ek_config : unconfig
+ @mkdir -p $(obj)include
+ @if [ $(findstring 9g20,$@) ] ; then \
+ echo #define CONFIG_AT91SAM9G20EK 1
$(obj)include/config.h ; \
+ $(XECHO) ... 9G20 Variant ; \
+ else \
+ echo #define CONFIG_AT91SAM9260EK 1
$(obj)include/config.h ; \
+ fi;
@if [ $(findstring _nandflash,$@) ] ; then \
echo #define CONFIG_SYS_USE_NANDFLASH 1
$(obj)include/config.h ; \
$(XECHO) ... with environment variable in NAND FLASH ; \
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index ef99b8b..58599fa 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -212,8 +212,13 @@ int board_init(void)
/* Enable Ctrlc */
console_init_f();
+#ifdef CONFIG_AT91SAM9G20EK
+ /* arch number of AT91SAM9260EK-Board */
+ gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
+#else
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9260EK;
+#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/cpu/arm926ejs/at91/usb.c b/cpu/arm926ejs/at91/usb.c
index a15ab16..7c44ad0 100644
--- a/cpu/arm926ejs/at91/usb.c
+++ b/cpu/arm926ejs/at91/usb.c
@@ -33,7 +33,7 @@ int usb_cpu_init(void)
{
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
-defined(CONFIG_AT91SAM9263)
+defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20)
/* Enable PLLB */
at91_sys_write(AT91_CKGR_PLLBR, CONFIG_SYS_AT91_PLLB);
while ((at91_sys_read(AT91_PMC_SR) AT91_PMC_LOCKB) != AT91_PMC_LOCKB)
@@ -62,7 +62,7 @@ int usb_cpu_stop(void)
#endif
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
-defined(CONFIG_AT91SAM9263)
+defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20)
/* Disable PLLB */
at91_sys_write(AT91_CKGR_PLLBR, 0);
while ((at91_sys_read(AT91_PMC_SR) AT91_PMC_LOCKB) != 0)
diff --git a/doc/README.at91 b/doc/README.at91
index c666d82..f1ea8f3 100644
--- a/doc/README.at91
+++ b/doc/README.at91
@@ -4,7 +4,7 @@ http://atmel.com/dyn/products/tools.asp?family_id=605#1443
I. Board mapping boot media
--
-AT91SAM9260EK AT91SAM9XEEK
+AT91SAM9260EK, AT91SAM9G20EK AT91SAM9XEEK
--
Memory map
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index af0409b..6de0a04 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -447,14 +447,14 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
/* choose RMII or MII mode. This depends on the board */
#ifdef CONFIG_RMII
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
-defined(CONFIG_AT91SAM9263)
+defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20)
macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
#else
macb_writel(macb, USRIO, 0);
#endif
#else
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260
[U-Boot] [PATCH] at91: Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC.
AT91sam9g20 is an evolution of the at91sam9260 with a faster clock speed. Here is the chip page on Atmel website: http://www.atmel.com/dyn/products/product_card.asp?part_id=4337 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- Makefile | 17 ++ board/atmel/at91sam9g20ek/Makefile| 57 +++ board/atmel/at91sam9g20ek/at91sam9g20ek.c | 261 + board/atmel/at91sam9g20ek/config.mk |1 + board/atmel/at91sam9g20ek/led.c | 64 +++ board/atmel/at91sam9g20ek/nand.c | 78 + board/atmel/at91sam9g20ek/partition.c | 40 + cpu/arm926ejs/at91/usb.c |4 +- doc/README.at91 |2 +- drivers/net/macb.c|4 +- include/asm-arm/arch-at91/hardware.h |2 +- include/configs/at91sam9g20ek.h | 201 ++ 12 files changed, 725 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index c24115d..0cd8a93 100644 --- a/Makefile +++ b/Makefile @@ -2679,6 +2679,23 @@ at91sam9xeek_config : unconfig fi; @$(MKCONFIG) -n at91sam9xeek -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91 +at91sam9g20ek_nandflash_config \ +at91sam9g20ek_dataflash_cs0_config \ +at91sam9g20ek_dataflash_cs1_config \ +at91sam9g20ek_config : unconfig + @mkdir -p $(obj)include + @if [ $(findstring _nandflash,$@) ] ; then \ + echo #define CONFIG_SYS_USE_NANDFLASH 1 $(obj)include/config.h ; \ + $(XECHO) ... with environment variable in NAND FLASH ; \ + elif [ $(findstring dataflash_cs0,$@) ] ; then \ + echo #define CONFIG_SYS_USE_DATAFLASH_CS0 1 $(obj)include/config.h ; \ + $(XECHO) ... with environment variable in SPI DATAFLASH CS0 ; \ + else \ + echo #define CONFIG_SYS_USE_DATAFLASH_CS1 1 $(obj)include/config.h ; \ + $(XECHO) ... with environment variable in SPI DATAFLASH CS1 ; \ + fi; + @$(MKCONFIG) -a at91sam9g20ek arm arm926ejs at91sam9g20ek atmel at91 + at91sam9261ek_nandflash_config \ at91sam9261ek_dataflash_cs0_config \ at91sam9261ek_dataflash_cs3_config \ diff --git a/board/atmel/at91sam9g20ek/Makefile b/board/atmel/at91sam9g20ek/Makefile new file mode 100644 index 000..cdf5d34 --- /dev/null +++ b/board/atmel/at91sam9g20ek/Makefile @@ -0,0 +1,57 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y+= at91sam9g20ek.o +COBJS-y+= led.o +COBJS-y+= partition.o +COBJS-$(CONFIG_CMD_NAND) += nand.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/atmel/at91sam9g20ek/at91sam9g20ek.c b/board/atmel/at91sam9g20ek/at91sam9g20ek.c new file mode 100644 index 000..eee9f50 --- /dev/null +++ b/board/atmel/at91sam9g20ek/at91sam9g20ek.c @@ -0,0 +1,261 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop stelian@leadtechdesign.com + * Lead Tech Design www.leadtechdesign.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope
Re: [U-Boot] Help on getting the AT91 u-boot patch
John Parten john.parten at passivsystems.com writes: Hello Mailling List, I am trying to build U-Boot 1.3.4 from source, for the AT91SAM9260EK development board. I am following the instructions at http://www.linux4sam.org/twiki/bin/view/Linux4SAM/U-Boot I get to the point where it says take the AT91 u-boot patch set However, when I try to use ... wget http://www.linux4sam.org/twiki/pub/Linux4SAM/U-Boot/u-boot-1.3.4-exp.diff I get error 404 file not found Indeed, I changed the information included in this webpage. Also I tried ... wget http://www.linux4sam.org/pub/uboot/u-boot-1.3.4-exp/u-boot-1.3.4-exp.diff as per the table a bit further down on the page - this does not work either. This is an ftp URL : try : wget ftp://www.linux4sam.org/pub/uboot/u-boot-1.3.4-exp/u-boot-1.3.4-exp.diff As we try to integrate constantly patches in mainline, you can find most of those bits in latest u-boot revisions. Hope that it helps. Best regards, -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] at91: add at91sam9xeek board support
At91sam9xe is basically an at91sam9260 with embedded flash. We can manage it as another entry for at91sam9260 in the Makefile. Check documentation at : http://www.atmel.com/dyn/products/product_card.asp?part_id=4263 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- Patch against u-boot-at91.git V2 integrates the typo noted during the v1 review (Typo: CFG_ convert to CONFIG_SYS_) Makefile | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 623b8f7..74dfcca 100644 --- a/Makefile +++ b/Makefile @@ -2599,6 +2599,23 @@ at91sam9260ek_config : unconfig fi; @$(MKCONFIG) -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91 +at91sam9xeek_nandflash_config \ +at91sam9xeek_dataflash_cs0_config \ +at91sam9xeek_dataflash_cs1_config \ +at91sam9xeek_config: unconfig + @mkdir -p $(obj)include + @if [ $(findstring _nandflash,$@) ] ; then \ + echo #define CONFIG_SYS_USE_NANDFLASH 1 $(obj)include/config.h ; \ + $(XECHO) ... with environment variable in NAND FLASH ; \ + elif [ $(findstring dataflash_cs0,$@) ] ; then \ + echo #define CONFIG_SYS_USE_DATAFLASH_CS0 1 $(obj)include/config.h ; \ + $(XECHO) ... with environment variable in SPI DATAFLASH CS0 ; \ + else \ + echo #define CONFIG_SYS_USE_DATAFLASH_CS1 1 $(obj)include/config.h ; \ + $(XECHO) ... with environment variable in SPI DATAFLASH CS1 ; \ + fi; + @$(MKCONFIG) -n at91sam9xeek -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91sam9 + at91sam9261ek_nandflash_config \ at91sam9261ek_dataflash_cs0_config \ at91sam9261ek_dataflash_cs3_config \ -- 1.5.3.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: add at91sam9xeek board support (typo)
Typo: CFG_ convert to CONFIG_SYS_ Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- Makefile |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 7be1de2..74dfcca 100644 --- a/Makefile +++ b/Makefile @@ -2605,13 +2605,13 @@ at91sam9xeek_dataflash_cs1_config \ at91sam9xeek_config: unconfig @mkdir -p $(obj)include @if [ $(findstring _nandflash,$@) ] ; then \ - echo #define CFG_USE_NANDFLASH 1 $(obj)include/config.h ; \ + echo #define CONFIG_SYS_USE_NANDFLASH 1 $(obj)include/config.h ; \ $(XECHO) ... with environment variable in NAND FLASH ; \ elif [ $(findstring dataflash_cs0,$@) ] ; then \ - echo #define CFG_USE_DATAFLASH_CS0 1 $(obj)include/config.h ; \ + echo #define CONFIG_SYS_USE_DATAFLASH_CS0 1 $(obj)include/config.h ; \ $(XECHO) ... with environment variable in SPI DATAFLASH CS0 ; \ else \ - echo #define CFG_USE_DATAFLASH_CS1 1 $(obj)include/config.h ; \ + echo #define CONFIG_SYS_USE_DATAFLASH_CS1 1 $(obj)include/config.h ; \ $(XECHO) ... with environment variable in SPI DATAFLASH CS1 ; \ fi; @$(MKCONFIG) -n at91sam9xeek -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91sam9 -- 1.5.3.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
