question on amd flash driver of redboot

Dear All,
	Hello.
	I have a question on flash_am28xxxxx.inl for redboot. 
	I am confused by the macro CYGNUM_FLASH_16AS8. It seems that if
the flash works in word mode and I want to operate it as byte, I should
NOT define the macro.
	My situation is as following:
	My flash chip is AM29LV320D. The BYTE pin is pull up to logic 1,
so it can only work in word mode. In word mode A20:A0 of the flash chip
are used as address pins while A20:A-1 in byte mode. A20:A0 are respectively
connected to the EBI address pins of CPU EBI_A21:EBI_A1. In this
situation, should I define the macro CYGNUM_FLASH_16AS8? I think I
should. Here is the code:

#ifndef CYGNUM_FLASH_16AS8
#define _16AS8 0
#else
#define _16AS8 CYGNUM_FLASH_16AS8
#endif

#if (_16AS8 == 0)
# define FLASH_Setup_Addr1              (0x555)
# define FLASH_Setup_Addr2              (0x2AA)
......
#else
# define FLASH_Setup_Addr1              (0xAAA)
# define FLASH_Setup_Addr2              (0x555)
......
	If I want to write a command to the chip address 0x555(A20:A0),
I would tell CPU to write the command to 0xAAA(EBI_A21:EBI_A0). Because

Re: 16bit RAM

Hi Sven,
> again a problem using 16bit RAM.
> The RAM is connected to an ARM7 (AT91R40008) and is working.
> The RAM is addressed as a 16bit memory without byte select lines (the
> flash is connected the same way). I can read and write but if I do a
> strcpy(a,"/dev/ser0");
> the string in "a" is "/dev/ser".
did you try stepping through above strcpy call? that might help you further.
my guess is if you try strcpy(a,"/dev/ser00"); (for that matter any even length 
string) you are likely to get what you expect, assuming buffer pointed by a is 
big enough.

> The next thing is reading from the serial port. With another board I get
> one byte by 
> 		int read ;
> 		len = 1 ;
> 		cyg_io_read(handleComPort, &read, &len);
> 	and e.g. read = 0x24 ("$").
> 
> With the new board I get
> 		read = 0x2424 ("$$").
I have one small doubt here, say if two characters were read, is $$ , what you 
expect? what is the outcome of cyg_io_read call, when len=1/2/3/4 and what you 
expect in each case?

--

-- 
regards
sandeep
--------------------------------------------------------------------------
Graduate life: It's not just a job.  It's an indenture.

Re: 16bit RAM

Sven Rehfuss <sven.rehfuss <at> b2motion.de> writes:

> Hello,
> again a problem using 16bit RAM.
> The RAM is connected to an ARM7 (AT91R40008) and is working.
> The RAM is addressed as a 16bit memory without byte select lines (the
> flash is connected the same way). I can read and write but if I do a
> strcpy(a,"/dev/ser0");
> the string in "a" is "/dev/ser".
> The next thing is reading from the serial port. With another board I get
> one byte by 
> 		int read ;
> 		len = 1 ;
> 		cyg_io_read(handleComPort, &read, &len);
> 	and e.g. read = 0x24 ("$").
> 
> With the new board I get
> 		read = 0x2424 ("$$").
> How can I tell eCos that the memory is a 16bit RAM (e.g. a char maybe
> 16bit wide)?

The last thing you want to do is to start messing about with the C
compiler to fix this. You need to take a look at how the memory
controller is being set up and maybe change it to match the memory you
have attached. Clearly you cannot change the hardware under the feet
of the code and expect it to still work. You will find the MEMC setup
in hal_platform_setup.h.

--

-- 
Nick Garnett                    eCos Kernel Architect

Reboot FLASH driver for x86-based PC104

I want to install RedBoot on i386-based PC104 board with FLASH disk
(DiskOnCheap) as a primary boot device. Startup type of RedBoot will be
ROMRAM. In documentation I have found that for x86 platform RedBoot does not
support any FLASH commands (RedBoot user guide.pdf, p. 134). Does it means
that I can not access FLASH drive from RedBoot and use, for example, FIS
file system?

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: how to correct the compile error "cannot find -lg"

>hi,
   on cygwin,when I compiled the file hello.c like the way:  

 $ arm-elf-gcc -g /h/hello/hello.c

 I got the following errors:
/ecos/gnutools/arm-elf/bin/../lib/gcc-lib/arm-elf/3.2.1/../../../../arm-elf/bin/ld: cannot
find -lg
collect2: ld returned 1 exit status

  please tell me how to correct the errors,any suggestions will be appreciated!
  best regards
  crocodilian
----------------------------------------------
[¿ì¸Ð˲¼ä]²»Í¬µÄÄê´ú¡°Ç××족µÄ²»Í¬½Ð·¨ 
http://free.21cn.com/forum/threadmode1.jsp?forum_id=624&thread_id=304315 
Òƶ¯¿¨À²ok£¬¶À¼ÒÊÔ³ª 
http://mms.21cn.com/ring/ring.jsp 
»ªÄϵÚÒ»ÈËÔìÃÀÄÐÏòÖйúµÚÒ»ÈËÔìÃÀÅ®Çó»é 
http://news.21cn.com/social/ 
21CNÉÌÎñÓÊÏäÎåÒ»8ÕÛÓŻݣ¬·áºñ½±Æ·µÈÄãÄà 
http://mail.21cn.com/huodong/0405/business/detail.html 
ÆóÒµÓÊÏäÏÄÈÕ´óÓŻݣ¬ÊÖ»ú¡¢MP3¼´Ê±ËÍ 
http://mail.21cn.com/huodong/0405/corpmail/ 

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

GDB Initialisation problem

Hi,

We build a card which looks like the Rattler card with a PPC8270.
But when we used GDB, we have to launch a NEXTI and a JUMP *0x60000 command to
begin debug with GDB at our start adress 0x60000.
If we do directly the CONTINUE command, it began at 0x15de4 instead of 0x60000.
Why GDB doesn't go automaticaly to this adress ?
Is there a file in eCos to change for this?

(gdb) target remote 192.168.1.3:9000
Remote debugging using 192.168.1.3:9000
0x0000e8b4 in ?? ()
(gdb) load hello.elf
Loading section .text, size 0x8de4 lma 0x60000
Loading section .rodata, size 0x948 lma 0x68de8
Loading section .data, size 0x574 lma 0x69730
Start address 0x60000, load size 40096                       (Here it knows that
 the program begins at 0x60000 !!!)
Transfer rate: 320768 bits in <1 sec, 507 bytes/write.
(gdb) nexti
[New Thread 1]
0x00015de4 in ?? ()      (Why is it at this adress ?)
(gdb) jump *0x60000

Thanks,

Emmanuel Coullien

--

-- 

Re: GDB Initialisation problem

On Tue, 1 Jun 2004 14:34:58 +0200
e.coullien <at> faiveley.com wrote:

> 
> 
> Hi,
> 
> We build a card which looks like the Rattler card with a PPC8270.
> But when we used GDB, we have to launch a NEXTI and a JUMP *0x60000
> command to begin debug with GDB at our start adress 0x60000.
> If we do directly the CONTINUE command, it began at 0x15de4 instead of
> 0x60000. Why GDB doesn't go automaticaly to this adress ?
> Is there a file in eCos to change for this?
> 
> 
> (gdb) target remote 192.168.1.3:9000
> Remote debugging using 192.168.1.3:9000
> 0x0000e8b4 in ?? ()
> (gdb) load hello.elf
> Loading section .text, size 0x8de4 lma 0x60000
> Loading section .rodata, size 0x948 lma 0x68de8
> Loading section .data, size 0x574 lma 0x69730
> Start address 0x60000, load size 40096                       (Here it
> knows that
>  the program begins at 0x60000 !!!)
> Transfer rate: 320768 bits in <1 sec, 507 bytes/write.
> (gdb) nexti
> [New Thread 1]
> 0x00015de4 in ?? ()      (Why is it at this adress ?)
> (gdb) jump *0x60000

Réf. : Re: [ECOS] GDB Initialisation problem

If I try a simple "continue", the program never break on my break in the main()
function.
It doesn't seem to start at the right adress (0x60000).

Emmanuel Coullien

Laurent GONZALEZ <laurent.gonzalez <at> silicomp.fr> le 01/06/2004 15:04:59

                                                           

 Pour  ecos-discuss <at> ecos.sourceware.org                    
 :                                                         

 cc :  (ccc : Emmanuel COULLIEN/Faiveley)                  

                                                           

 Objet Re: [ECOS] GDB Initialisation problem               
 :                                                         

On Tue, 1 Jun 2004 14:34:58 +0200
e.coullien <at> faiveley.com wrote:

>
>
> Hi,

Re: GDB Initialisation problem

On Tue, 1 Jun 2004 15:15:26 +0200
e.coullien <at> faiveley.com wrote:

> If I try a simple "continue", the program never break on my break in
> the main() function.

How did you set the breakpoint ? (sb. break main) What's the gdb output
of this command ?
Have you tried to load and debug your program through serial line ?

> It doesn't seem to start at the right adress (0x60000).

I don't known the memory mapping of your custom card.
Redboot tells you the memory mapping of your board when it boots of
after issuing "version" command.

regards,

-- 
GONZALEZ Laurent
Silicomp Ingénierie
Tel: 33 476 41 66 98

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Réf. : Re: [ECOS] GDB Initialisation problem

I set breackpoints through the windows interface.

Through the serial line, we had the same thing.
I mean the "CONTINUE" command doesn't work. Only the NEXTI and JUMP *0x60000
commands allow to run our aplication and stoped at the breackpoint.

Here is the card's Mapping :

RedBoot> version

RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version v2_00_lpz - built 12:13:16, Jun  1 2004

Platform: Fydji (PowerPC MPC8270)
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x00000000-0x04000000, [0x0003c580-0x03fdd000] available
FLASH: 0xff800000 - 0x00000000, 64 blocks of 0x00020000 bytes each.
RedBoot>

Thanks,

Emmanuel Coullien

Laurent GONZALEZ <laurent.gonzalez <at> silicomp.fr> le 01/06/2004 15:46:29

                                                           

 Pour  ecos-discuss <at> ecos.sourceware.org