Re: [U-Boot] [UBOOT] AVR32-UC3 (EVK1100) status
Hi,
I would recomend you to take a look at the comments posted on the mailinglist
earlier:
http://lists.denx.de/pipermail/u-boot/2009-January/thread.html#45925
As one of the developers which were workuing on this earlier I would say that
it is a good starting point for developing u-boot. If I remember correct, most
of the issues was due to an bug in the board we used. (We had to add a fat
load of external SRAM since code execution from SDRAM was unrelaiable,
and the CPU had to be underclocked.)
Also noted that I am not engaged in this project any more. We did this as a
student project, and delivered our result to Haavard Skinnemoen (@atmel),
which probably is the maintainer of this code now.
Best point to start is, i guess, to download the code, check that is compiles.
Then you can add a copy of the board config and customize this for this board.
regards
On Sat, Jan 30, 2010 at 4:43 PM, Tobias Frost wrote:
>
> I received a new toy, one Atmel EVK 1105 evaluation board.
> (MCU: AVR32, AT32 UC3A 0512).
>
> The board is quite similar to the EVK 1100. Checking the schematic, the
> changes are indeed minor, (like channel for SPI1 instead of SPI0 for
> Flash memory)
>
> As I saw on the list that there were some patches to support the 1100,
> it seems feasible for me also to add support for the 1105.
>
> So the first question is: How stable / good is the support of the
> EVK1100? I read on the avr32linux wiki that there are some issues
> ("commments needs to be adressed") but I found no details.
> So, does it make sense to use this as a starting point?
>
> I'm new to uboot development, so maybe you also have some pointers to
> get started.
>
> Thanks!
>
> Tobi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 9/9] AVR32: Board support for ATEVK1100
On Mon, Jan 26, 2009 at 8:50 PM, Wolfgang Denk wrote: > Dear ?ISO-8859-1?Q?Gunnar_Rangøy?, > > In message you > wrote: > ... >> >> +#undef CONFIG_CMD_AUTOSCRIPT >> > >> > Is there a specific reason for not allowing to use shell scripts? > ... >> No, not really. We did this because this was done in other AVR32 boards >> we used as references. > > Then pleasse don't - let's overcome the bad examples. > OK, this is fixed. Regards Gunnar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] AVR32: CPU support for AT32UC3A0xxx CPUs
On Fri, Jan 23, 2009 at 5:00 PM, Wolfgang Denk wrote:
> Dear Gunnar Rangoy,
>
> In message
>
> you wrote:
>> This patch adds support for the AT32UC3A0xxx chips.
> ...
>> +++ b/cpu/at32uc/at32uc3a0xxx/portmux.c
>> @@ -0,0 +1,154 @@
> ...
>> + portmux_select_peripheral(PORTMUX_PORT(0),
>> + 0x0003C000 |
>> + 0x1E00, PORTMUX_FUNC_C, 0);
>> + portmux_select_peripheral(PORTMUX_PORT(1),
>> + 0x0010 |
>> + 0x7C00 |
>> + 0x0003 |
>> + 0xE000, PORTMUX_FUNC_C, 0);
>> + portmux_select_peripheral(PORTMUX_PORT(2),
>> + 0xFFC0, PORTMUX_FUNC_A, 0);
>> + portmux_select_peripheral(PORTMUX_PORT(3),
>> + 0x3FFF, PORTMUX_FUNC_A, 0);
>> +}
>
> It would be nice if you used readable names instead of all these
> magic hardcoded constants.
Each bit in the masks represents a single pin on the microcontroller.
The readable names would therefore become something like:
#define EBI_PINS_PORT0 (0x0003C000 | 0x1E00)
#define EBI_PINS_PORT1 (0x0010 | 0x7C00 | ...)
I'm not certain that that would make it much more readable. The
bitmasks are more or less based on reading the datasheet and counting
which pins are used.
Maybe adding a comment before the code would be just as useful?
>> +++ b/cpu/at32uc/at32uc3a0xxx/sm.h
>> @@ -0,0 +1,247 @@
>> +/*
>> + * Register definitions for System Manager
>> + */
>> +#ifndef __CPU_AT32UC_SM_H__
>> +#define __CPU_AT32UC_SM_H__
>> +
>> +/* SM register offsets */
>> +/* PM starts at 0x0C00 */
>> +#define SM_PM_REGS_OFFSET0x0c00
>> +#define SM_PM_MCCTRL (SM_PM_REGS_OFFSET + 0x)
>> +#define SM_PM_CKSEL (SM_PM_REGS_OFFSET + 0x0004)
>> +#define SM_PM_CPU_MASK (SM_PM_REGS_OFFSET +
>> 0x0008)
>> +#define SM_PM_HSB_MASK (SM_PM_REGS_OFFSET +
>> 0x000c)
>> +#define SM_PM_PBA_MASK (SM_PM_REGS_OFFSET +
>> 0x0010)
>> +#define SM_PM_PBB_MASK (SM_PM_REGS_OFFSET +
>> 0x0014)
>> +#define SM_PM_PLL0 (SM_PM_REGS_OFFSET + 0x0020)
>> +#define SM_PM_PLL1 (SM_PM_REGS_OFFSET + 0x0024)
>> +#define SM_PM_OSCCTRL0 (SM_PM_REGS_OFFSET +
>> 0x0028)
> ...
>
> Instead of using offsets everywhere I would appreciate if the code
> could be changed to use C structs instead (like we do in PPC land).
It was done like this because it was done in the existing AVR32 code
which we based our work on. Since we used parts of that code, it made
most sense to use the same coding style.
We can change it if you think it is necessary.
>
>> +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
>> +{
>> + /* This will reset the CPU core, caches, MMU and all internal busses */
>> + __builtin_mtdr(8, 1 << 13); /* set DC:DBE */
>> + __builtin_mtdr(8, 1 << 30); /* set DC:RES */
>> +
>> + /* Flush the pipeline before we declare it a failure */
>> + asm volatile("sub pc, pc, -4");
>> +
>> + return -1;
>> +}
>
> I read this as if you just reset the CPU "internal" stuff. Sorry for
> asking stupid questions, I don't know this architecture at all, but:
> Will external chips be reset this way, too? Or how do you make sure
> that external peripherals get properly reset?
As most of the needed functionality is embedded in the microcontroller,
there are very few external peripherals used by U-Boot. Apart from
external memory, and oscillator, and level-shifters for the serial-port,
there is only the ethernet PHY, and that one shouldn't need a reset.
Gunnar Rangøy,
99360699
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 9/9] AVR32: Board support for ATEVK1100
On Fri, Jan 23, 2009 at 4:37 PM, Wolfgang Denk wrote: > Dear Gunnar Rangoy, > > In message > <7d98d3ebed68dfca910943a360d0b8aaa28d9c17.1232710611.git.gun...@rangoy.com> > you wrote: >> This patch adds support for the ATEVK1100 evaluation kit, which contains >> an AT32UC3A0512ES chip. > ... > > ... >> --- /dev/null >> +++ b/board/atmel/atevk1100/atevk1100.c > ... >> + /* >> + .ncs_wr_pulse = 1, >> + .ncs_rd_pulse = 1, >> + .nwe_pulse = 1, >> + .nrd_pulse = 1, >> + .nwe_cycle = 2, >> + .nrd_cycle = 2, >> + */ > > All this is dead code. Please remove. Will do that. > ... >> +/* >> + * Command line configuration. >> + */ >> +#include >> + >> +#define CONFIG_CMD_ASKENV >> +#define CONFIG_CMD_DHCP >> + >> +#undef CONFIG_CMD_AUTOSCRIPT > > Is there a specific reason for not allowing to use shell scripts? > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > I'm a programmer: I don't buy software, I write it. > -- Tom Christiansen > No, not really. We did this because this was done in other AVR32 boards we used as references. -- Gunnar Rangøy, 99360699 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] AVR32: macb - Disable 100mbps if clock is slow
On Fri, Jan 23, 2009 at 4:38 PM, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 12:56 Fri 23 Jan , Gunnar Rangoy wrote:
>> From: Olav Morken
>>
>> For 100mbps operation, the ethernet controller requires a 25 MHz clock
>> in MII mode, and a 50 MHz clock in RMII mode. If the clock is slower,
>> disable 100 Mbps mode.
>>
>> Signed-off-by: Gunnar Rangoy
>> Signed-off-by: Paul Driveklepp
>> Signed-off-by: Olav Morken
>> ---
>> drivers/net/macb.c | 12 +++-
>> 1 files changed, 11 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> index 08bebf7..d47a052 100644
>> --- a/drivers/net/macb.c
>> +++ b/drivers/net/macb.c
>> @@ -297,7 +297,17 @@ static void macb_phy_reset(struct macb_device *macb)
>> int i;
>> u16 status, adv;
>>
>> - adv = ADVERTISE_CSMA | ADVERTISE_ALL;
>> + adv = ADVERTISE_CSMA | ADVERTISE_ALL ;
> ??
Oops... Will fix this.
>> +
>> +#ifdef CONFIG_MACB_FORCE10M
>> + printf("%s: 100Mbps is not supported on this board - forcing
>> 10Mbps.\n",
>> +netdev->name);
>> +
>> + adv &= ~ADVERTISE_100FULL;
>> + adv &= ~ADVERTISE_100HALF;
>> + adv &= ~ADVERTISE_100BASE4;
>> +#endif
>not a fan
>could you be more specific about the problem?
>
> Best Regards,
> J.
>
On the EVK1100 board, the CPU (UC3A0512) is connected to the PHY via an
RMII bus. This requires the CPU clock to be at least 50 MHz.
Unfortunately, the chip on current EVK1100 boards may be unable to run
at more than 50 MHz, and with the oscillator on the board, the closest
frequency we can generate is 48 MHz.
This patch makes it possible to limit the macb to 10 MBit for this
case. We are open for suggestions for other solutions.
--
Gunnar Rangøy,
99360699
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
