headers
Wolfgang Denk | 1 May 2005 16:04
Picon
Picon
Favicon

Re: wlan driver

Hi Dan,

in message <c48defeba68ed687d83d7baa28cf738e <at> embeddededge.com> you wrote:
> 
> Has anyone worked on a 802.11 wireless driver for u-boot?

Probably. Craig A. Vanderborgh  reported  in  January  (12  Jan  2005
17:31:01  -0500)  that he was going to work on Cisco/Aironet wireless
drivers, but I haven't heard anything from him since.

> I'm faced with a board that has mini-PCI, adapters aren't
> working for standard cards, and it looks like the only
> solution may be a 3.3V wireless LAN card.

Be careful. Chose a card for which you can get at  least  full  Linux
source code. There are still cards with binary-only HAL modules which
are more or less useless to try.

> Thanks for any suggestions (I suspect Wolfgang will
> respond with a URL to an archive I couldn't find) :-)

Sorry, I'm afraid I'm not much of help here.

Best regards,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hinko Kocevar | 1 May 2005 17:44
Picon

register init

Hello  <at> LL,

i've ported u-boot to trizeps2 cpu module. It can boot and use tftp when 
running under BDI debugger, so I guess basic parts are ported fine. When I try 
to run board standalone it kind of hangs there... no output on serial console.

After few days of debugging I established that lowlevel_init() won't set the 
GAFR0_x register(s) to defined value set in u-boot board config. Under BDI I 
can see that at this point PC jumps to some random address - or throws an 
exception that BDI intercepts, if I set 'VECTOR CATCH 0xde' directive in BDI 
config.

After exception caught by the BDI I can set PC back few instrucions and board 
would boot, console lives!

I've added few nop instructions* after ldr and str invocations that are setting 
GAFRx registers, but that just delays the data abort seen before (eg. it would 
happen when setting MSCx registers).

* As xscale manual suggests for imprecise data aborts.

Further, it is not always the same exception that occurs, it is data abort, 
undefined instruction, and sometimes prefetch aborts are seen also.

And more, when the board boots by itself, which happens once in a while, I can 
see it is looping inside serial - getc() code waiting for input. But there is 
nothing shown on terminal and nothing can be input, since GAFR1_L is not setup 
to provide FFUART function.

I've attached objdump and BDI output while single-stepping around critical section.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wayne Lee | 2 May 2005 09:21
Picon

still got "*** Warning - bad CRC, using default environment" after saveenv is sucessfully done


Hi, u-boot users,

I have written hardware-dependent flash functions for my EVB u-boot support.
Hence, "saveenv" works and I can see the env data in the configured env
sector by "md" command.

However, I still get the warning messages, "*** Warning - bad CRC, using
default environment", after press reset button.

Should any CONFIG/CFG need to be added in board configuration file?

I use u-boot 1.1.2 and the followings are part of board configurations.

/*-----------------------------------------------------------------------
 * Physical Memory Map
 */
#define CONFIG_NR_DRAM_BANKS	1	   /* we have 1 bank of DRAM */
#define PHYS_SDRAM_1		0x00000000 /* SDRAM Bank #1 */
#define PHYS_SDRAM_1_SIZE	0x04000000 /* 64 MB */
#define PHYS_FLASH_1		0xFF800000 /* Flash Bank #1 */
#define CFG_FLASH_BASE		PHYS_FLASH_1

/*-----------------------------------------------------------------------
 * FLASH and environment organization
 */
#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks */
#define PHYS_FLASH_SIZE	0x00400000	/* 4MB */
#define CFG_MAX_FLASH_SECT	(71)	/* max number of sectors on one chip
*/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steven Scholz | 2 May 2005 09:34
Picon
Favicon

Re: [PATCH 4/4] add csb637 (at91rm9200) support

Anders,

> this patch switches the at91rm9200 to synchronous clock mode after
> initialization (it would otherwise stay in FastBus mode which is
> the _slowest_ clock mode).

But I thought FastBus mode is the prefered setting for ARM cpus.

--
Steven

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 1 comment |
headers
Wolfgang Denk | 2 May 2005 10:37
Picon
Picon
Favicon

Re: still got "*** Warning - bad CRC, using default environment" after saveenv is sucessfully done

In message <200505020725.j427P98R014633 <at> ismp.csie.ncku.edu.tw> you wrote:
> 
> I have written hardware-dependent flash functions for my EVB u-boot support.
> Hence, "saveenv" works and I can see the env data in the configured env
> sector by "md" command.
> 
> However, I still get the warning messages, "*** Warning - bad CRC, using
> default environment", after press reset button.

This means that U-Boot does not find a valid environment in flash.

> Should any CONFIG/CFG need to be added in board configuration file?

Added or fixed - how should we know? We don't know your hardware...

> I use u-boot 1.1.2 and the followings are part of board configurations.
> 
> /*-----------------------------------------------------------------------
>  * Physical Memory Map
>  */
> #define CONFIG_NR_DRAM_BANKS	1	   /* we have 1 bank of DRAM */
> #define PHYS_SDRAM_1		0x00000000 /* SDRAM Bank #1 */
> #define PHYS_SDRAM_1_SIZE	0x04000000 /* 64 MB */

You shouldn't do that., You should use auto-sizing instead.

> #define CFG_ENV_IS_IN_FLASH	1
> #define CFG_ENV_SIZE		0x2000	/* Total Size of Environment Sector
> */
> #define CFG_ENV_SECT_SIZE	0x2000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anders Larsen | 2 May 2005 10:55
Picon

Re: [PATCH 4/4] add csb637 (at91rm9200) support

Steven Scholz <steven.scholz <at> imc-berlin.de> schreibt:
>> this patch switches the at91rm9200 to synchronous clock mode after
>> initialization (it would otherwise stay in FastBus mode which is
>> the _slowest_ clock mode).
>
>But I thought FastBus mode is the prefered setting for ARM cpus.

Hi Steven,

FastBus is the default after reset but is not intended for normal
operation.

Quote from the ARM920T Technical Reference Manual (ARM DDI 0151C):
"On reset, the ARM920T is put into FastBus mode and operates using BCLK.
 A typical use for FastBus mode is to execute startup code while
 configuring a PLL under software control to produce FCLK at a higher
 frequency. When the PLL has stabilized and locked, you can switch the
 ARM920T to synchronous or asynchronous clocking using FCLK for normal
 operation."

Cheers
 Anders

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 0 comments |
headers
Martin Krause | 2 May 2005 11:28
Picon

AW: [PATCH 4/4] add csb637 (at91rm9200) support

Hi Anders,

u-boot-users-admin <at> lists.sourceforge.net wrote on :
> this patch switches the at91rm9200 to synchronous clock mode after
> initialization (it would otherwise stay in FastBus mode which is the
> _slowest_ clock mode). This lets the core run at full speed when not
> doing bus accesses, increasing overall performance by a factor of
> four. 
> 
> Changelog:
>   * patch by Anders Larsen, 2004-04-29
>     set the at91rm9200 clock to synchronous mode
> 
> Cheers
>  Anders

I've tested your patch on the cmc_pu2 board. Boot time is reduced
from about 32 s to 26 s with your patch (measured from starting power
supply to a specific status message of our linux application). This is
great! 

I wonder if there are some pitfalls doing this on the AT91RM9200 cpu? 
As I understand the ARM920T Technical Reference Manual the clocking 
modes are a feature of the ARM920T core and not affected by the 
surrounding on-chip peripherals added by Atmel. So it should work for 
all cpu's with ARM920T core without problems?

I've also done an nbench benchmark under linux running in synchronous
clock mode. But the results are the same as in fast bus clock mode. 
Strange. I've no idea why.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anders Larsen | 2 May 2005 14:12
Picon

Re: AW: [PATCH 4/4] add csb637 (at91rm9200) support

"Martin Krause" <Martin.Krause <at> tqs.de> schreibt:
>I wonder if there are some pitfalls doing this on the AT91RM9200 cpu? 
>As I understand the ARM920T Technical Reference Manual the clocking 
>modes are a feature of the ARM920T core and not affected by the 
>surrounding on-chip peripherals added by Atmel. So it should work for 
>all cpu's with ARM920T core without problems?

Hi Martin,

there might be some boards with ARM920T cpu who can't use synchronous
clock mode due to clock restrictions (see the TRM), but I really
can't tell.
>
>I've also done an nbench benchmark under linux running in synchronous
>clock mode. But the results are the same as in fast bus clock mode. 
>Strange. I've no idea why.

Perhaps your Linux switches clock mode itself? (the at91rm9200 patch
from maxim.org.za does _not_, however)
What does /proc/cpuinfo say about this?
With my patch I get:
# grep -i bogomips /proc/cpuinfo
BogoMIPS        : 91.95
and without it I get appr. 28.
I get the same speed improvement (x4) using an RSA encryption benchmark.

For reference here's the output from nbench 2.2.2 on my csb637 board:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wayne Lee | 2 May 2005 16:25
Picon

RE: still got "*** Warning - bad CRC, using default environment" after saveenv is sucessfully done


My SoC flash memory logic is poor. (poor hardware)
It only supports 32bit read. That is, 16-bit read and 8-bit read returns
wrong values.
(I wrote a simple bootloader to copy u-boot to RAM for execution at first.)
I found that some hardware-independent fuctions read flash via 8-bit access.
(for example, crc32() and env_relocate_spec()).

Hence, even I really upgrade the environment into dedicated flash sector,
u-boot shows the warning message while booting.

It seems unavoidable to hardcode u-boot.  :)

Thanks.
Wayne

-----Original Message-----
From: wd <at> denx.de [mailto:wd <at> denx.de] 
Sent: Monday, May 02, 2005 4:38 PM
To: Wayne Lee
Cc: u-boot-users <at> lists.sourceforge.net
Subject: Re: [U-Boot-Users] still got "*** Warning - bad CRC, using default
environment" after saveenv is sucessfully done 

In message <200505020725.j427P98R014633 <at> ismp.csie.ncku.edu.tw> you wrote:
> 
> I have written hardware-dependent flash functions for my EVB u-boot
support.
> Hence, "saveenv" works and I can see the env data in the configured env
> sector by "md" command.
(Continue reading)

Permalink | Reply | 0 comments |
headers
NZG | 2 May 2005 17:02
Favicon

Re: still got "*** Warning - bad CRC, using default environment" after saveenv is sucessfully done

I was having this same problem, and it turned out I was writing the 
enviornment over the top of some of my u-boot code.

I'd make sure CFG_ENV_OFFSET is set to an empty area.

NZG.
On Monday 02 May 2005 02:21, Wayne Lee wrote:
> Hi, u-boot users,
>
> I have written hardware-dependent flash functions for my EVB u-boot
> support. Hence, "saveenv" works and I can see the env data in the
> configured env sector by "md" command.
>
> However, I still get the warning messages, "*** Warning - bad CRC, using
> default environment", after press reset button.
>
> Should any CONFIG/CFG need to be added in board configuration file?
>
> I use u-boot 1.1.2 and the followings are part of board configurations.
>
> /*-----------------------------------------------------------------------
>  * Physical Memory Map
>  */
> #define CONFIG_NR_DRAM_BANKS	1	   /* we have 1 bank of DRAM */
> #define PHYS_SDRAM_1		0x00000000 /* SDRAM Bank #1 */
> #define PHYS_SDRAM_1_SIZE	0x04000000 /* 64 MB */
> #define PHYS_FLASH_1		0xFF800000 /* Flash Bank #1 */
> #define CFG_FLASH_BASE		PHYS_FLASH_1
>
> /*-----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane