Re: AT91 IDE module

Re: AT91 IDE module

[Stanislaw Gruszka]

Hi

(cc linux-ide)

On Tue, Nov 23, 2010 at 10:56:08AM +0100, Radovan Vápeník wrote:
> Hello Stanislaw,
> i am working on custom board with AT91SAM9263, i am trying to start
> communication with CompactFlash throught your kernel driver (true
> ide mode). I have problem to connect CF to file to /dev directory.
> After module load kernel prints message "ide0 at
> 0xc4866000-0xc4866007,0xc486e006 on irq 132" without some
> identification in /dev/(hda). Can you help me, what can be wrong?
> Wires connections betweent processor and CF should be ok.
> 
> I have these options in kernel:
> CONFIG_IDE
> CONFIG_IDE_GD
> CONFIG_IDE_GD_ATA
> CONFIG_IDE_TASK_IOCTL
> CONFIG_IDE_PROC_FS
> CONFIG_BLK_DEV_PLATFORM
> CONFIG_BLK_DEV_IDE_AT91

CONFIG_IDE_TIMINGS is also needed, but this should be selected if 
CONFIG_BLK_DEV_IDE_AT91 was chosen.

If there is no info in /proc/partitions, then disc was not detected.
It's hard to tell why without more verbose messages. Add
"EXTRA_CFLAGS += -DDEBUG" to drivers/ide/Makefile and provide full
dmesg output.

Stanislaw

Re: AT91 IDE module

[Radovan Vápeník]

Stanislaw Gruszka napsal(a):
> Hi
>
> (cc linux-ide)
>
> On Tue, Nov 23, 2010 at 10:56:08AM +0100, Radovan Vápeník wrote:
>   
>> Hello Stanislaw,
>> i am working on custom board with AT91SAM9263, i am trying to start
>> communication with CompactFlash throught your kernel driver (true
>> ide mode). I have problem to connect CF to file to /dev directory.
>> After module load kernel prints message "ide0 at
>> 0xc4866000-0xc4866007,0xc486e006 on irq 132" without some
>> identification in /dev/(hda). Can you help me, what can be wrong?
>> Wires connections betweent processor and CF should be ok.
>>
>> I have these options in kernel:
>> CONFIG_IDE
>> CONFIG_IDE_GD
>> CONFIG_IDE_GD_ATA
>> CONFIG_IDE_TASK_IOCTL
>> CONFIG_IDE_PROC_FS
>> CONFIG_BLK_DEV_PLATFORM
>> CONFIG_BLK_DEV_IDE_AT91
>>     
>
> CONFIG_IDE_TIMINGS is also needed, but this should be selected if 
> CONFIG_BLK_DEV_IDE_AT91 was chosen.
>
> If there is no info in /proc/partitions, then disc was not detected.
> It's hard to tell why without more verbose messages. Add
> "EXTRA_CFLAGS += -DDEBUG" to drivers/ide/Makefile and provide full
> dmesg output.
>
> Stanislaw
>
>   
Hello,
i have only mtdblock0 in /proc/partitions (it is NAND), about CF is 
nothing. There is my dmesg output, the important is on end of list.

Linux version 2.6.30 (root@black) (gcc version 4.3.3 (GCC) ) #55 Wed Nov 
24 09:06:41 CET 2010
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9263-EK
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat c02f1b00, node_mem_map c0309000
  Normal zone: 128 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 16256 pages, LIFO batch:3
Clocks: CPU 198 MHz, master 99 MHz, main 18.432 MHz
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: console=ttyS0,115200 root=/dev/nfs 
nfsroot=192.168.0.126:/home/kremilek/ARM/angstrom/base_image/ 
ip=192.168.0.200:192.168.0.126::255.255.255.0::eth0:off
NR_IRQS:192
AT91: 160 gpio irqs in 5 banks
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x30
console [ttyS0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 61792KB available (2652K code, 222K data, 112K init, 0K highmem)
Calibrating delay loop... 99.12 BogoMIPS (lpj=495616)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 296 bytes
NET: Registered protocol family 16
tcb_clksrc: tc0 at 12.916 MHz
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
NetWinder Floating Point Emulator V0.97 (double precision)
squashfs: version 4.0 (2009/01/31) Phillip Lougher
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 120
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
atmel_lcdfb atmel_lcdfb.0: 300KiB frame buffer at 23980000 (mapped at 
ffc00000)
Console: switching to colour frame buffer device 80x30
atmel_lcdfb atmel_lcdfb.0: fb0: Atmel LCDC at 0x00700000 (mapped at 
c485c000), irq 26
atmel_usart.0: ttyS0 at MMIO 0xfeffee00 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfff8c000 (irq = 7) is a ATMEL_SERIAL
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffbc000 irq 21 (00:00:45:58:14:11)
eth0: attached PHY driver [Davicom DM9161A] 
(mii_bus:phy_addr=ffffffff:00, irq=-1)
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 
3,3V 8-bit)
AT91 NAND: 8-bit, Software ECC
Scanning device for bad blocks
Bad eraseblock 1024 at 0x000008000000
Bad eraseblock 1025 at 0x000008020000
Creating 2 MTD partitions on "atmel_nand":
0x000000000000-0x000004000000 : "Partition 1"
0x000004000000-0x000010000000 : "Partition 2"
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 29, io mem 0x00a00000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
udc: at91_udc version 3 May 2006
mice: PS/2 mouse device common for all mice
input: gpio-keys as /class/input/input0
Registered led device: ds1
Registered led device: ds2
Registered led device: ds3
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
usb 1-2: new full speed USB device using at91_ohci and address 2
usb 1-2: configuration #1 chosen from 1 choice
IP-Config: Complete:
     device=eth0, addr=192.168.0.200, mask=255.255.255.0, 
gw=255.255.255.255,
     host=192.168.0.200, domain=, nis-domain=(none),
     bootserver=192.168.0.126, rootserver=192.168.0.126, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.126
eth0: link up (100/Full)
Looking up port of RPC 100005/1 on 192.168.0.126
VFS: Mounted root (nfs filesystem) on device 0:11.
Freeing init memory: 112K
udevd version 124 started
at91_ide_probe chipselect 4 irq 132 res 50000000
apply_timings t0=600 t1=70 t2=290 t6z=30
apply_timings mck_hz=99328000
apply_timings cycle=60 setup=7 pulse=29 data_float=3
Probing IDE interface ide0...
probing for hda: present=0, media=32, probetype=ATA
probing for hda: present=0, media=32, probetype=ATAPI
probing for hdb: present=0, media=32, probetype=ATA
probing for hdb: present=0, media=32, probetype=ATAPI
ide0 at 0xc4866000-0xc4866007,0xc486e006 on irq 132

Radovan

Re: AT91 IDE module

[Stanislaw Gruszka]

On Wed, Nov 24, 2010 at 10:36:37AM +0100, Radovan Vápeník wrote:
> at91_ide_probe chipselect 4 irq 132 res 50000000
> apply_timings t0=600 t1=70 t2=290 t6z=30
> apply_timings mck_hz=99328000
> apply_timings cycle=60 setup=7 pulse=29 data_float=3
> Probing IDE interface ide0...
> probing for hda: present=0, media=32, probetype=ATA
> probing for hda: present=0, media=32, probetype=ATAPI
> probing for hdb: present=0, media=32, probetype=ATA
> probing for hdb: present=0, media=32, probetype=ATAPI
> ide0 at 0xc4866000-0xc4866007,0xc486e006 on irq 132

We do not detect any IDE device, registers do not contain status/data
that IDE layer expect. As far only two possible reasons of that
problem come in mind:
- board specific code does not reset CF device (with proper
  reset duration?). This is expected, there is rst_pin in
  struct at91_cf_data but driver does not use it
- CF 9 pin (ATA SEL) is not grounded or set to 0 if connected
  to controller (also in board specific initialization code)

To debug problem further, you can add your own code at the end of
at91_ide_probe(), which read/write IDE register to see if device
react properly and give some sensible status values.

Stanislaw

Re: AT91 IDE module

[Radovan Vapeník]

Cituji Stanislaw Gruszka <stf_xl@wp.pl>:

> On Wed, Nov 24, 2010 at 10:36:37AM +0100, Radovan Vápeník wrote:
>> at91_ide_probe chipselect 4 irq 132 res 50000000
>> apply_timings t0=600 t1=70 t2=290 t6z=30
>> apply_timings mck_hz=99328000
>> apply_timings cycle=60 setup=7 pulse=29 data_float=3
>> Probing IDE interface ide0...
>> probing for hda: present=0, media=32, probetype=ATA
>> probing for hda: present=0, media=32, probetype=ATAPI
>> probing for hdb: present=0, media=32, probetype=ATA
>> probing for hdb: present=0, media=32, probetype=ATAPI
>> ide0 at 0xc4866000-0xc4866007,0xc486e006 on irq 132
>
> We do not detect any IDE device, registers do not contain status/data
> that IDE layer expect. As far only two possible reasons of that
> problem come in mind:
> - board specific code does not reset CF device (with proper
>   reset duration?). This is expected, there is rst_pin in
>   struct at91_cf_data but driver does not use it
> - CF 9 pin (ATA SEL) is not grounded or set to 0 if connected
>   to controller (also in board specific initialization code)
>
> To debug problem further, you can add your own code at the end of
> at91_ide_probe(), which read/write IDE register to see if device
> react properly and give some sensible status values.
>
> Stanislaw
>

Seems problem is really on reset pin, i have analysed using  
oscilloscope and on reset pin is still in logical "1", without change  
during module loading. I will try to find out why is this happening.

Radovan


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: AT91 IDE module

[Stanislaw Gruszka]

On Thu, Nov 25, 2010 at 09:53:19PM +0100, Radovan Vapeník wrote:
> >We do not detect any IDE device, registers do not contain status/data
> >that IDE layer expect. As far only two possible reasons of that
> >problem come in mind:
> >- board specific code does not reset CF device (with proper
> >  reset duration?). This is expected, there is rst_pin in
> >  struct at91_cf_data but driver does not use it
> >- CF 9 pin (ATA SEL) is not grounded or set to 0 if connected
> >  to controller (also in board specific initialization code)
> >
> >To debug problem further, you can add your own code at the end of
> >at91_ide_probe(), which read/write IDE register to see if device
> >react properly and give some sensible status values.
> >
> >Stanislaw
> >
> 
> Seems problem is really on reset pin, i have analysed using
> oscilloscope and on reset pin is still in logical "1", without
> change during module loading. I will try to find out why is this
> happening.

I was unclear. Driver does not change reset pin. Reset need to be
done in board initialization code. You have to add something like that

#define RST_PIN AT91_PIN_PC5
at91_set_gpio_output(RST_PIN, 1);
at91_set_gpio_value(RST_PIN,0);
mdelay(2);
at91_set_gpio_value(RST_PIN,1);

in your arch/arm/mach-at91/board-NAME.c (I'm not sure if 2ms is
correct IDE reset duration).

Stanislaw

Re: AT91 IDE module

[Radovan Vápeník]

Stanislaw Gruszka napsal(a):
> On Thu, Nov 25, 2010 at 09:53:19PM +0100, Radovan Vapeník wrote:
>   
>>> We do not detect any IDE device, registers do not contain status/data
>>> that IDE layer expect. As far only two possible reasons of that
>>> problem come in mind:
>>> - board specific code does not reset CF device (with proper
>>>  reset duration?). This is expected, there is rst_pin in
>>>  struct at91_cf_data but driver does not use it
>>> - CF 9 pin (ATA SEL) is not grounded or set to 0 if connected
>>>  to controller (also in board specific initialization code)
>>>
>>> To debug problem further, you can add your own code at the end of
>>> at91_ide_probe(), which read/write IDE register to see if device
>>> react properly and give some sensible status values.
>>>
>>> Stanislaw
>>>
>>>       
>> Seems problem is really on reset pin, i have analysed using
>> oscilloscope and on reset pin is still in logical "1", without
>> change during module loading. I will try to find out why is this
>> happening.
>>     
>
> I was unclear. Driver does not change reset pin. Reset need to be
> done in board initialization code. You have to add something like that
>
> #define RST_PIN AT91_PIN_PC5
> at91_set_gpio_output(RST_PIN, 1);
> at91_set_gpio_value(RST_PIN,0);
> mdelay(2);
> at91_set_gpio_value(RST_PIN,1);
>
> in your arch/arm/mach-at91/board-NAME.c (I'm not sure if 2ms is
> correct IDE reset duration).
>
> Stanislaw
>
>   

On the data bus is something strange - I have scanned data bus using 
oscilloscope at the moment, when processor send CS signal to 
CompactFlash. The  screenshot from oscilloscope is here - 
http://www.vapenik.com/files/cf_init.png. The yellow color is CFCS0, 
blue is one data pin on the data bus. The red arrow shows the possible 
problem - there is transient. And in 4. quadrant is some transient too, 
question is why it happens (but pc is working correctly, i boot linux 
without problem). This is on EBI0, there is connected NAND Flash + 2x 
SDRAM and Compact Flash. When I measured EBI0, the strange  timing with 
transient is only on low 16 bits of EBI0 
(http://www.vapenik.com/files/data-0-15.png , one random wire on data 
bus EBI0, low 16bits), high 16 bits are ok 
(http://www.vapenik.com/files/data-16-31.png , one random wire on EBI0, 
high 16 bits). But almost this same happens on Evaluation Board from 
Atmel, so I really don't know where is problem.

Radovan

Re: AT91 IDE module

[Radovan Vápeník]

Stanislaw Gruszka napsal(a):
> On Thu, Nov 25, 2010 at 09:53:19PM +0100, Radovan Vapeník wrote:
>   
>>> We do not detect any IDE device, registers do not contain status/data
>>> that IDE layer expect. As far only two possible reasons of that
>>> problem come in mind:
>>> - board specific code does not reset CF device (with proper
>>>  reset duration?). This is expected, there is rst_pin in
>>>  struct at91_cf_data but driver does not use it
>>> - CF 9 pin (ATA SEL) is not grounded or set to 0 if connected
>>>  to controller (also in board specific initialization code)
>>>
>>> To debug problem further, you can add your own code at the end of
>>> at91_ide_probe(), which read/write IDE register to see if device
>>> react properly and give some sensible status values.
>>>
>>> Stanislaw
>>>
>>>       
>> Seems problem is really on reset pin, i have analysed using
>> oscilloscope and on reset pin is still in logical "1", without
>> change during module loading. I will try to find out why is this
>> happening.
>>     
>
> I was unclear. Driver does not change reset pin. Reset need to be
> done in board initialization code. You have to add something like that
>
> #define RST_PIN AT91_PIN_PC5
> at91_set_gpio_output(RST_PIN, 1);
> at91_set_gpio_value(RST_PIN,0);
> mdelay(2);
> at91_set_gpio_value(RST_PIN,1);
>
> in your arch/arm/mach-at91/board-NAME.c (I'm not sure if 2ms is
> correct IDE reset duration).
>
> Stanislaw
>
>   
I found out the reason of transients - it is caused by enabled pull-up 
resistor on lower 16 bits on EBI0 - bit EBI0_DBPUC shoul be set to "1", 
normally is set to "0". But the CF still no working, problem is is 
elsewhere.

Radovan

Re: AT91 IDE module

[Radovan Vápeník]

Stanislaw Gruszka napsal(a):
> On Thu, Nov 25, 2010 at 09:53:19PM +0100, Radovan Vapeník wrote:
>   
>>> We do not detect any IDE device, registers do not contain status/data
>>> that IDE layer expect. As far only two possible reasons of that
>>> problem come in mind:
>>> - board specific code does not reset CF device (with proper
>>>  reset duration?). This is expected, there is rst_pin in
>>>  struct at91_cf_data but driver does not use it
>>> - CF 9 pin (ATA SEL) is not grounded or set to 0 if connected
>>>  to controller (also in board specific initialization code)
>>>
>>> To debug problem further, you can add your own code at the end of
>>> at91_ide_probe(), which read/write IDE register to see if device
>>> react properly and give some sensible status values.
>>>
>>> Stanislaw
>>>
>>>       
>> Seems problem is really on reset pin, i have analysed using
>> oscilloscope and on reset pin is still in logical "1", without
>> change during module loading. I will try to find out why is this
>> happening.
>>     
>
> I was unclear. Driver does not change reset pin. Reset need to be
> done in board initialization code. You have to add something like that
>
> #define RST_PIN AT91_PIN_PC5
> at91_set_gpio_output(RST_PIN, 1);
> at91_set_gpio_value(RST_PIN,0);
> mdelay(2);
> at91_set_gpio_value(RST_PIN,1);
>
> in your arch/arm/mach-at91/board-NAME.c (I'm not sure if 2ms is
> correct IDE reset duration).
>
> Stanislaw
>
>   
I found out the reason of transients - it is caused by enabled pull-up
resistor on lower 16 bits on EBI0 - bit EBI0_DBPUC shoul be set to "1",
normally is set to "0". But the CF still no working, problem is is
elsewhere.

Radovan

I had mistake in schematic - after repair I get some new debug messages 
- is possible to tell, what can be wrong? Thanks for advice

at91_ide_probe chipselect 4 irq 132 res 50000000
apply_timings t0=600 t1=70 t2=290 t6z=30
apply_timings mck_hz=99328000
apply_timings cycle=60 setup=7 pulse=29 data_float=3
Probing IDE interface ide0...
probing for hda: present=0, media=32, probetype=ATA
probing for hda: present=0, media=32, probetype=ATAPI
hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x00)
hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x1e)
probing for hdb: present=0, media=32, probetype=ATA
probing for hdb: present=0, media=32, probetype=ATAPI
hdb: probing with STATUS(0xa0) instead of ALTSTATUS(0x1e)
hdb: probing with STATUS(0xa0) instead of ALTSTATUS(0x1e)
ide0 at 0xc4866000-0xc4866007,0xc486e006 on irq 132

Radovan

Re: AT91 IDE module

[Stanislaw Gruszka]

On Thu, Dec 02, 2010 at 05:10:21PM +0100, Radovan Vápeník wrote:
> I had mistake in schematic - after repair I get some new debug
> messages - is possible to tell, what can be wrong? Thanks for advice

Unfortunately I don't know where the problem can be.

> at91_ide_probe chipselect 4 irq 132 res 50000000
> apply_timings t0=600 t1=70 t2=290 t6z=30
> apply_timings mck_hz=99328000
> apply_timings cycle=60 setup=7 pulse=29 data_float=3
> Probing IDE interface ide0...
> probing for hda: present=0, media=32, probetype=ATA
> probing for hda: present=0, media=32, probetype=ATAPI
> hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x00)

Strange that here alt status is 0x00 and in other places it is 0x1e.
Also all bits in alt status except second one should be the same as in
status register. First version of driver had bug where address of alt
status was wrong, but that was fixed before driver was merged into
the kernel.

> hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x1e)
> probing for hdb: present=0, media=32, probetype=ATA
> probing for hdb: present=0, media=32, probetype=ATAPI
> hdb: probing with STATUS(0xa0) instead of ALTSTATUS(0x1e)
> hdb: probing with STATUS(0xa0) instead of ALTSTATUS(0x1e)

Status 0xa0 shows that BUSY bit is set, that definitely is wrong too.

Stanislaw