NEC V25 hangs on IN/OUT instructions in ATA CF driver

[swausd]

Hi @ghaerr,

I modified my NEC V25 system and now I can use it as CPU card on a passive ISA backplane using only 8 Bit slots. Works fine with a NE200 NIC in 8 bit mode. I added this XT-IDE Rev. 4 card from a german ebay site:

https://www.ebay.com/itm/226138176425?_skw=xt-ide&itmmeta=01KEYMPV9NCA5FDF0Z8E51Z8XW&hash=item34a6e2bba9:g:j7cAAOSwqHFmPTAL

The card has no dip-switches, but solder points on the back where options can be configured by cutting traces or adding solder. I only did one change from standard configuration to disabled the flash, because it would be in conflict with my memory map and it is not used anyways.

The card is used with an IDE to CF adapter and I am using an old 64MB Sandisk CF. This config works OK in another environment in 8 bit mode.

To escape IO address conflicts the NIC is configured to IO 0x200 and the XT-IDE is in standard config IO 0x300. I configure the ATA driver to

ata_mode = MODE_XTIDEv2;
xfer_mode = XFER_8_XTCF;

and on first sight it seems to work. I can copy and read files but sometimes the system hangs. This can be reproduced doing this with the current ELKS:

ELKS Setup INT f002 START
16K ext buffers, 8K cache, 1 req hdrs
eth: ne0 at 200, irq 2, (ne1k) MAC 00:4f:4c:02:4f:6b, flags 0x80
ssd: 2013265920K disk
cfa: 8-bit xfer on
cfa:   61M CHS 490, 8,32 62720K VER 0/576 xtide=2,1
cfb: ATA at 300/307 xtide=2,1 not found (-22)
cfa:(0,125440) cfa1:(1,125439) 
NECV25 machine, cpu 3, syscaps 0, 512K base ram, 16 tasks, 64 files, 96 inodes
ELKS 0.9.0-dev (51504 text, 0 ftext, 4768 data, 4816 bss, 55950 heap)
Kernel text e062 data 80 end 1080 top 8000 446+0+0K free
VFS: Mounted root device /dev/rom (0600) romfs filesystem.
Running /etc/rc.sys script
Wed Jan 14 16:59:02 2026

ELKS 0.9.0-dev

[0.68 secs] login: root
# mkfs /dev/cfa 16384
5461 inodes
16384 blocks
Firstdatazone=176 (176)
Zonesize=1024
Maxsize=16777216

# ls -lR /mnt

/mnt:
dr-xr-xr-x  1 root     root            9  Jan  1  1970 cf
dr-xr-xr-x  1 root     root            9  Jan  1  1970 sd

/mnt/sd:

/mnt/cf:
# mount -t minix /dev/cfa /mnt/cf
# ls -lR /mnt

/mnt:
drwxr-xr-x  2 root     root           32  Jan 14 16:59 cf
dr-xr-xr-x  1 root     root            9  Jan  1  1970 sd

/mnt/sd:

/mnt/cf:
# sync
# mkdir /mnt/cf/bin
# ls -lR /mnt

/mnt:
drwxr-xr-x  3 root     root           48  Jan 14 17:00 cf
dr-xr-xr-x  1 root     root            9  Jan  1  1970 sd

/mnt/sd:

/mnt/cf:
drwxr-xr-x  2 root     root           32  Jan 14 17:00 bin

/mnt/cf/bin:
# sync

System hangs on the last sync. Tried another CF card, same result.

Doing the same with my SD-card setup works as expected. Any hints where to look to get this solved is much appreciated.

[ghaerr]

Hello @swausd,

Nice to see you playing with more hardware on ELKS!

My first thoughts on your problem are that it could be that CF writes aren't working at all, but the issue only shows up the first time you force a write with sync. Or the problem could have to do with multiple sector writes, but probably not. You can possibly test this theory further by running sync immediately after every command, including the mkfs.

Secondly, the ATA driver make some very tricky assumptions with regards to the supported XT IDE types, and just setting the XFER_8_XTCF doesn't just set 8-bit transfer mode, but also plays with the register address array. For instance:

/* convert register number to command block port address */
static int ATPROC BASE(int reg)
{
    if (ata_mode >= MODE_XTCF)          /* XTCF uses SHL 1 register file */
        reg <<= 1;
    else if (ata_mode == MODE_XTIDEv2)  /* XTIDEv2 uses a3/a0 swapped register file */
        reg = xlate_XTIDEv2[reg];
    return ata_base_port + reg;
}

At this point, I would consider adding printk's in the routines, such as write_ioport etc, to make sure that the port is as you think it should be. Also you might want to add printk debug to ata_wait to ensure the system isn't buzz-looping on a non-ready signal for some reason.

There is always the possibility that the current ATA CF driver doesn't quite work with your specific card and might not be handled. I had to guess for most of the driver and was only able to test on various emulators that supported the various XT IDE card types, and some hardware testing was done on real hardware by @toncho11 which confirmed it working.

Note that XT IDE v2 actually swaps a3/a0 address lines for speed. The reason for that can be explained if needed. I would advise serious study of ata.c to see how it complies with your card, and experimenting further with ideas from above from there, for now.

Thank you!

[swausd]

@ghaerr thanks for your quick support! I will look into this tomorrow and will report.

[toncho11]

Check here: https://github.com/ghaerr/elks/wiki/Configuring-XTIDE-or-Direct-ATA-drive-access

[swausd]

Thanks for the hint, @toncho11! Did not not notice this page until now.

[swausd]

The malfunction looks like a software or timing problem. I added a printk() in the function
static int ATPROC ata_cmd()
in ata.c and doing

mkfs /dev/cfa 16384
mount -t minix /dev/cfa /mnt/cf
mkdir /mnt/cf/bin
sync

for testing just after booting. If the printk() is in front of ata_select() like this

printk("ata_cmd drv: %x, cmd: %x\n", drive, cmd);
error = ata_select(drive, cmd, sector);

the sync runs OK. If the printk() is behind like this

error = ata_select(drive, cmd, sector);
printk("ata_cmd drv: %x, cmd: %x\n", drive, cmd);

they sync hangs without any output from ata_cmd().

When I only add a printk() in ata_select() the system seems to hang in ata_wait().
Adding printk into ata_wait() it looks like the system hangs in
status = INB(ATA_REG_STATUS);
But that is only a red herring. If the ata_wait() is eliminated from ata_select() the systems seams to hang in
OUTB(select, ATA_REG_SELECT);
So the error behaves like Schrödingers Cat - looking at it moves it.

Any suggestions where to look next?

[ghaerr]

Remind me, is your system running with a an IRQ 0 hardware timer? The ATA CF driver requires a working jiffies timer. In any case, it appears that the issue here may be timing related instead of XT IDE-specific issues like XT IDE v1 vs v2, etc.

There have been some bigger changes made recently with regards to kernel startup, interrupt handling, etc. These may be contributing to more specific issues with correctly-functioning jiffies timers on your system. To debug that, i would suggest recoding ata_wait to use a buzz-loop on ATA_STATUS_BSY rathe than the jiffies variable and see how that affects things. Just loop forever waiting for not busy. The delay_10ms function may need to be changed too.

the systems seams to hang in
OUTB(select, ATA_REG_SELECT);

In the cases above where your printk allowed the sync to "proceed", did you check that the CF card actually got written? It may be that nothing is happening and we're just sending data to the wrong ports, which is hanging the system. The system should never hang on an OUTB.

[swausd]

I am rather shure that the error is not XT IDE v1 vs v2 related as if I do a printk() like

printk("ata_cmd drv: %x, cmd: %x\n", drive, cmd);
error = ata_select(drive, cmd, sector);

in static int ATPROC ata_cmd() the system seems to work OK. I can copy the /bin directory from my romfs to the CF card and then start programs from there. No hangups.

I do have a hardware timer and it looks like it is working OK:

And I don't think the system is hanging on INB() or OUTB() - it just looks like this using printk() function calls in front and behind.

Strange...

[ghaerr]

It would seem that ata_select needs more time in order to work, since the system works with printk before it. I still suggest rewriting ata_wait without jiffies until not ATA_STATUS_BSY to eliminate this potential variable. Printk is very slow and takes a lot of time.

[swausd]

Thank you @ghaerr for your support!

I modified to this:

static int ATPROC ata_wait(unsigned int ticks)
{
//    jiff_t timeout = jiffies() + ticks + 1;
    unsigned char status;
    int time_out = 1000;

    do
    {
        status = INB(ATA_REG_STATUS);

        // are we done?

        if ((status & ATA_STATUS_BSY) == 0)
            return 0;
printk("BSY-waiting\n");
    } while (time_out--);
//    } while (!time_after(jiffies(), timeout));
printk("BSY-Timeout\n");

    return -ENXIO;
}

and get this

# mkfs /dev/cfa 16384
5461 inodes
16384 blocks
Firstdatazone=176 (176)
Zonesize=1024
Maxsize=16777216

BSY-waiting
BSY-waiting
...
BSY-waiting
BSY-waiting
BSY-waiting
# mount -t minix /dev/cfa /mnt/cf
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
# mkdir /mnt/cf/bin
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
BSY-waiting
# sync

No output on sync and system is hanging.

[swausd]

Added an additional printk() on ata_wait entry and the output looks like this

...
BSY-waiting
in ata_wait
in ata_wait
in ata_wait
BSY-waiting
# mount -t minix /dev/cfa /mnt/cf
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
BSY-waiting
in ata_wait
in ata_wait
in ata_wait
BSY-waiting
# mkdir /mnt/cf/bin
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
in ata_wait
# sync
in ata_wait

[ghaerr]

Well, you're getting somewhere... add printk in ata_wait exit also, as well as in fs/buffers.c::sync_buffers() to find out what's happening. Not sure yet, sounds like you could have a hardware problem with the XT IDE card I/O, or perhaps a busy loop in sync_buffers()? Not sure yet.

[swausd]

I don't think its a hardware problem. XT-IDE is a trivial IO-port circuit.

In my posting above there is a printk("BSY-Timeout\n"); on exit already. This is never reached.

I try to simplify the ata_wait(() and report when finished.

[ghaerr]

In my posting above there is a printk("BSY-Timeout\n"); on exit already. This is never reached.

That's right. Instead, ata_wait is exiting on ATA_STATUS_BSY == 0. So the hang may be in other places.

[swausd]

I changed ata_wait to this (removing the XT-IDE port address translation and going direct for the assembler inb opcode)

static int ATPROC ata_wait(unsigned int ticks)
{
    unsigned char status;
    
    printk("in ata_wait\n");

    do
    {
        printk("in ata_wait  1\n");

        __extension__ ({      \
            asm volatile ("inb %%dx,%%al"   \
                          :"=Ral" (status)  \
                          :"d" (0x3e));     \
        });
        
        printk("in ata_wait  2\n");

        if ((status & ATA_STATUS_BSY) == 0)
            return 0;
        
        printk("BSY-waiting\n");
    } while (1);

printk("BSY-Timeout\n");

    return -ENXIO;
}

Output is now

# sync
in ata_wait
in ata_wait  1

It looks like the system is hanging on the inb dx, al ??? I don't think so.
I will try to get some insight on the hardware level. This will take some time...

[swausd]

Hi @ghaerr,

I found the cause of my system hanging. And it is indeed while performing an IO statement (in / out). It is a specific NEC "problem".

Background
In the NEC V25 the integrated peripherals are memory mapped. NEC added an emulation mode to transfer 8088 IO-statements to memory mapped IO. With this emulation activated, every in / out statements results in an IBRK-interrupt. This vector is not initialized in my system, so my ELKS system hangs, when the emulation is activated.

Problem
The emulation should not be activated! To activate IO emulation mode, the IBRK bit, bit 1 in the processor status word, has to be set to 0. This bit is not defined in 8088/8086 and is initialized to 1. Somehow ELKS sets this bit to 0 - intentionally or by stack- or memory-corruption?

Running my test szenario

mkfs /dev/cfa 16384
mount -t minix /dev/cfa /mnt/cf
mkdir /mnt/cf/bin
sync

this IBRK bit is set only just before the system calls sys_sync in buffer.c after doing sync in the shell. I traced this using this small probe sequence:

int sys_sync(void)
{
unsigned int psw;

__extension__ ({               \
    asm volatile (             \
        "pushf              \n"\
        "cli                \n"\
        "pop    %%ax        \n"\
        "push   %%ax        \n"\
        "popf               \n"\
        : "=a"(psw)            \
        :                      \
        : );                   \
});
if (!(psw & 0x02)) printk("sys_sync:%0x\n", psw);

    fsync_dev(0);
    return 0;
}

But my knowledge of ELKS is not good enough to find the real cause deeper in the system.
Any suggestions, where to look?