Click here to go to the forum index Click here for the home page
 
Author Message

<  TAP and patch development  ~  linux

Page 21 of 23
Goto page Previous  1, 2, 3 ... 20, 21, 22, 23  Next
DeadBeef
Posted: Fri Apr 11, 2008 7:17 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
tom3q wrote:
Kaon's straps:
Code:
NEC EMMA2 Version 4.1.0.3.0
Strap settings 0x00002d33 0x0020014b 0x00002d33 0x0020014f

Bit 21 (bitmask 0x200000) means that the IDE controller is using SEP2 mode.

I think that the IDE problem on Toppies is related to MPX mode, but i still don't know what exactly it is. There must be some additional initialization steps needed for MPX mode.
I am going to try SEP2 mode if it possible to enforce it by software means (BHIF_STRAP_WRITE_2).
View user's profile Send private message
tom3q
Posted: Fri Apr 11, 2008 7:23 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
I think that these two modes may be related to the method of connecting the IRQ signal. MPX uses a GPIO and SEP2 an integrated interrupt pin(?). So if it's possible to change the mode in software, probably the IRQ number will be changed to 13.
View user's profile Send private message
newsy13
Posted: Fri Apr 11, 2008 9:51 pm Reply with quote
Joined: 10 Apr 2008 Posts: 3
mpx means multiplexed mode. Pins are shared with rom bus and gio. Thats all i found.

the Strap2 settings can be changed with the write register, but some might depend on the hardware design.
View user's profile Send private message
tom3q
Posted: Fri Apr 11, 2008 9:58 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
newsy13 wrote:
mpx means multiplexed mode. Pins are shared with rom bus and gio. Thats all i found.

the Strap2 settings can be changed with the write register, but some might depend on the hardware design.


Wow, where did you find that? Do you have some documentation?
View user's profile Send private message
newsy13
Posted: Fri Apr 11, 2008 10:09 pm Reply with quote
Joined: 10 Apr 2008 Posts: 3
tom3q wrote:
newsy13 wrote:
mpx means multiplexed mode. Pins are shared with rom bus and gio. Thats all i found.

the Strap2 settings can be changed with the write register, but some might depend on the hardware design.


Wow, where did you find that? Do you have some documentation?


sorry, no. It was an old post about the linuxtv. Some hardware does not support the pvr-ide image. some have problems with usb interface. some can not share both usb and ide. the 2.2E Board revision is known to work. It uses atasep2
View user's profile Send private message
DeadBeef
Posted: Fri Apr 11, 2008 10:57 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
I have tried a couple of values in the strap2 register - to no avail. The IDE interface/interrupt disappears as soon as any of the bits 0x20005 is set. I have also tried to change the IRQ source - no reaction.

Another thing I've forgotten to test before was the byte order when reading user data from disk in DMA mode. The data read in DMA mode is all in the wrong byte order: 3 2 1 0 7 6 5 4 ....
View user's profile Send private message
bdb
Posted: Fri Apr 11, 2008 11:32 pm Reply with quote
Frequent contributor Joined: 18 Oct 2005 Posts: 499
I finally found a little time to resurrect my linux setup ...
I tried building/running your kernel
get the same results as deadbeef

1.
initially hangs after:
Code:
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx


2.
add the interrupt clear:
Code:
    *(volatile unsigned char *)0xb0012d5b = 2; // Disable IDE interrupt.

then it runs to:
Code:
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: DW CDW2300BJ0-K0AF 0, ATA DISK drive
ide0 at 0x2d22-0x2d29,0x2d5b on irq 115
hda: attached ide-disk driver.
hda: 0 sectors (0 MB) w/32KiB Cache, CHS=65343/0/0
hda: INVALID GEOMETRY: 0 PHYSICAL HEADS?
emma_ide_init_hwif: Configuring HWIF 0
emma_ide_hw_setup: Running in MPX mode

but, it has got then endianness of the identify command wrong
this is because emma_ide_init_hwif() has not yet been called

3.
fix this, now I get to:
Code:
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
init_hwif_data(index=0)
init_hwif_data(index=0)
hda: WDC WD3200JB-00KFA0, ATA DISK drive
ide0 at 0x2d22-0x2d29,0x2d5b on irq 115
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 625142448 sectors (320073 MB) w/8192KiB Cache, CHS=38913/255/63
Partition check:
 /dev/ide/host0/bus0/target0/lun0: unknown partition table
emma_ide_init_hwif: Configuring HWIF 0
emma_ide_hw_setup: Running in MPX mode
init_hwif_data(index=0)

- the identify is now working; it has found a disk,although it is formatted in toppy speak ...
- it is running in mpx mode
- tried various combinations of the mpx/sep2 bit of code, no difference
- tried lots of random things; no progress

4.
with lots more debug prints, I get to:
Code:
emma_ide_init_hwif: Configuring HWIF 0
emma_ide_hw_setup: Running in MPX mode
ide_setup_ports()-call
ide_setup_ports()-done
ide_register_hw()-call
  ide_register_hw()
    init_hwif_data(index=0)
      initializing=0
    init_hwif_data()-end
    initializing=0
    ide_probe_module(1)
      ide_probe=80cd3bcc
      ide_probe->init()
        ideprobe_init()
        probe_hwif()
          irqd=73, disable_irq()
          local_irq_set(80d04bb8)
          ide_probe_for_drive()
            do_probe()
              probing for hda: present=0, media=32, probetype=ATA
              emma_ide_selectproc()
                emma_ide_selectproc: drive capabilities = 0x00
              try_to_identify(cmd=ec)
                actual_try_to_identify()
                  a.50ms
                  use non-intrusive polling
                  cmd=ec [WIN_IDENTIFY]
                  ask drive for ID
                  timeout=6


it appears to be hanging after the IDE_COMMAND_REG write in
ide-probe.c
actual_try_to_identify()
Code:

        ...
      hwif->OUTB(cmd, IDE_COMMAND_REG);
   }
   timeout = ((cmd == WIN_IDENTIFY) ? WAIT_WORSTCASE : WAIT_PIDENTIFY) / 2;
printk("timeout=%x, jiffies=%x\n", timeout, jiffies);
   timeout += jiffies;
printk("timeout=%x\n", timeout);
   do {
printk("time_after(%x, %x)\n", jiffies, timeout);
      if (time_after(jiffies, timeout)) {
         /* drive timed-out */

maybe , interrupts are disabled/jammed at this point...
but ... this is the second time this code has been called; the first time (during the original identify) worked fine!

any ideas?

-- my notes show that the toppy firmware does not do the
EMMA_BHIF_STRAP_WRITE_2 |= 0x00200000, i.e. uses the gpio pin for the irq
-- i also have:
//EMMA_ZPIO_PORT_DATA_0, d22 - ide is used by topfield, what for???


bdb
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 9:58 am Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
There may be a problem with GPIO IRQ handling. arch/mips/emma/irq-emma.c contains some related code, but it seems unreliable to me:
Code:
static void emma_irq_ack(unsigned int irq)
{
        const unsigned int bit = 1 << ((irq - EMMA_IRQ_BASE) % 32);

        emma_irq_disable(irq);

        // Clear ZPIO interrupt status.
        if(irq < EMMA_DMA_IRQ_BASE) {
        if(irq >= EMMA_ZPIO_1_IRQ_BASE)
                *EMMA_ZPIO_INT_STATUS_1 |= bit;
        else if(irq >= EMMA_ZPIO_0_IRQ_BASE)
                *EMMA_ZPIO_INT_STATUS_0 |= bit;
        }
}
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 12:35 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
tom3q wrote:
There may be a problem with GPIO IRQ handling. arch/mips/emma/irq-emma.c contains some related code, but it seems unreliable to me:
Why do you think it is unreliable?

I found a way to run your kernel. The required changes are as follows:

  • comment out *EMMA_ATA_IDE_CONTROL32 = 0x00000000; in emma_ide_hw_setup() because it causes the Toppy to freeze
  • an early IDE initialization is absolutely not necessary, by default no IDE is detected, the EMMA-related initialization is performed via emma_ide_init_module(), so comment out ide_ops = &emma_ide_ops; in setup.c
  • add hwif->hold = 1; at the end of emma_ide_init_hwif(), it makes EMMA-specific IO operations persistent (otherwise they might be overwritten by ide_register_hw())

Running "dd if=/dev/hda of=/dev/null count =10000" in PIO mode causes a freeze instead of a crash. However, the reason for that is a much slower implementation of emma_ide_insw() calling emma_ide_inw() for every word to read. It is 3 times slower than without function call. Once emma_ide_insw() is made faster the kernel crashes on dd operation just like with my version of IDE driver or when using DMA. However, when running the following script the kernel does not crash unless the block count is increased:
Code:
while [ 1 ]
do
  dd if=/dev/hda of=/dev/null count =2000
done


My modifications in the emma-ide.c:
Code:
/* EMMA IDE driver routines */
void emma_ide_hw_setup(void)
{
        u32 temp;

        if(!emma_ide_sep2) {
                printk(KERN_INFO "emma_ide_hw_setup: Running in MPX mode\n");
                *EMMA_BHIF_STRAP_WRITE_2 &= ~((1<<1) | (1<<6));
                *EMMA_ZPIO_PORT_DIRECTION_0 |= 1<<10;
                *EMMA_ZPIO_PORT_DATA_0 |= 1<<10;
                temp = *EMMA_BHIF_STRAP_WRITE_2;
                temp &= ~((1<<19)|(1<<21)|(1<<27));
                temp |= 1<<7;
                *EMMA_BHIF_STRAP_WRITE_2 = temp;
        } else {
                printk(KERN_INFO "emma_ide_hw_setup: Running in SEP2 mode\n");
        }

        ide_ops = &emma_ide_ops;
        *EMMA_BHIF_CLK_MSK |= EMMA_BHIF_CLK_MSK_ATA_ICLK | EMMA_BHIF_CLK_MSK_ATA_I2CLK;
        *EMMA_BHIF_CLK_SEL_1 |= EMMA_BHIF_CLK_SEL_1_ATA_ICLK;
        *EMMA_BHIF_CLK_SEL_1 &= ~EMMA_BHIF_CLK_SEL_1_ATA_I2CLK;
        *EMMA_BHIF_CLK_MSK &= ~(EMMA_BHIF_CLK_MSK_ATA_ICLK | EMMA_BHIF_CLK_MSK_ATA_I2CLK);

        *EMMA_ATA_SOFT_RESET = EMMA_ATA_SOFT_RESET_RESET;
        udelay(1);
        *EMMA_ATA_SOFT_RESET = EMMA_ATA_SOFT_RESET_END_RESET;
        udelay(2);

        *EMMA_ATA_INT_CTRL = EMMA_ATA_INT_CTRL_INT_ENABLE;
        //*EMMA_ATA_IDE_CONTROL32 = 0x00000000;

}

void emma_ide_init_hwif(void)
{
        ide_hwif_t * hwif = &ide_hwifs[EMMA_IDE_HWIF_TO_TAKE_OVER];
#ifdef EMMA_IDE_DEBUG
        printk("emma_ide_init_hwif\n");
#endif
        printk("emma_ide_init_hwif: Configuring HWIF %u\n", EMMA_IDE_HWIF_TO_TAKE_OVER);

/* Setting up IO ports */
        ide_setup_ports(&hwif->hw, 0, &emma_ide_offsets[0], 0, 0, NULL, NEC_HD_IRQ);

/* Setting up IO operations */
        hwif->OUTB = &emma_ide_outb;
        hwif->OUTBSYNC = &emma_ide_outbsync;
        hwif->OUTW = &emma_ide_outw;
        hwif->OUTL = &emma_ide_outl;
        hwif->OUTSW = &emma_ide_outsw;
        hwif->OUTSL = &emma_ide_outsl;
        hwif->INB = &emma_ide_inb;
        hwif->INW = &emma_ide_inw;
        hwif->INL = &emma_ide_inl;
        hwif->INSW = &emma_ide_insw;
        hwif->INSL = &emma_ide_insl;

/* HWIF setup */
        hwif->tuneproc = &emma_ide_tuneproc;
        hwif->selectproc = &emma_ide_selectproc;
        hwif->hold = 1;
}
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 12:45 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
DeadBeef wrote:
Why do you think it is unreliable?


The |= operation gets the value of EMMA_ZPIO_INT_STATUS_X, ORs it with the irq bit and writes that to the register. Shouldn't it just write the single bit to the register?

About hanging/crashing while bigger transfers, are you sure that Linux is actually using my I/O routines? Have you removed the calls to emma_ide_wait_for_device()?
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 1:13 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
tom3q wrote:

The |= operation gets the value of EMMA_ZPIO_INT_STATUS_X, ORs it with the irq bit and writes that to the register. Shouldn't it just write the single bit to the register?
They probably attempt to acknowledge the specified IRQ plus all bits set in the register. In the worst case some interrupts might be lost if it is "unreliable" as you say.
tom3q wrote:
About hanging/crashing while bigger transfers, are you sure that Linux is actually using my I/O routines?
Yes, I am sure (I had debug output before). As stated above the kernel crashes on big transfers even in DMA mode.
tom3q wrote:
Have you removed the calls to emma_ide_wait_for_device()?
No, I haven't. Otherwise the IDE interface becomes unstable.

I am still worried about the endianess of the DMA transfers. Your DMA code writes 0x01 into the EMMA_ATA_DMA_CONTROL register. I tried writing 0x101 like the Toppy firmware does. But I still get the same wrong byte order.
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 1:19 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
DeadBeef wrote:
I am still worried about the endianess of the DMA transfers. Your DMA code writes 0x01 into the EMMA_ATA_DMA_CONTROL register. I tried writing 0x101 like the Toppy firmware does. But I still get the same wrong byte order.


0x01 is EMMA_ATA_DMA_CONTROL_START and 0x100 is EMMA_ATA_DMA_ULTRA_DMA_4. So Toppy just uses UDMA 4. I don't know what endianess problems have you got... Maybe you have hda=bswap in the command line? There is no data corruption when using DMA so it seems that the endianess must be correct.
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 1:27 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
tom3q wrote:
Maybe you have hda=bswap in the command line? There is no data corruption when using DMA so it seems that the endianess must be correct.
I am not saying that the data is corrupted. It is just read with the wrong byte order. CPU does not perform any byte swapping (I checked on completion of DMA). For example, the Toppy firmware stored the following data bytes using DMA:
Code:
0 1 2 3   4 5 6 7   8 9 10 11 ...

Linux reads this data as follows:
Code:
3 2 1 0   7 6 5 4   11 10 9 8 ...
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 1:47 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
Maybe the Toppy firmware stores the data in wrong byte order? Is it correct when reading in PIO mode?
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 2:02 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
tom3q wrote:
Maybe the Toppy firmware stores the data in wrong byte order?
I don't see how it should be possible. The Toppy is configured for big endian. For performance reasons the firmware does not changes byte order of received DVB data. So the data must have been stored in big endian.
tom3q wrote:
Is it correct when reading in PIO mode?
Reading in PIO mode also returns wrong byte order because the byte order is changed in emma_ide_inw().
View user's profile Send private message

Display posts from previous:  

All times are GMT + 1 Hour
Page 21 of 23
Goto page Previous  1, 2, 3 ... 20, 21, 22, 23  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum