IRQ setting in config? (Enhancement)

[Mellvik]

Somewhere down the line ELKS needs a simplified way to set irq# for peripheral interfaces. My encounter with NE2k a couple of years back was interesting, but not something a regular user would be able to understand - 3 changes i 2 files, and a combination of numbers and bits (mask).

[jbruchon]

We would probably benefit by having something like sysfs on Linux which makes stuff like this not only easy to change after building and booting, but also scriptable.

[pawosm-arm]

I've encountered the same problem with the ne2k card clone I have. I always need to edit ELKS sources to build the kernel for the XT-Turbo machine equipped with that ISA8 card. And it's not only IRQs. I/O ports and I/O mem also need to be changed. Definitely, ability to set it up in menuconfig would be beneficial.

@Mellvik was your encounter successful? What numbers and bits did you change?

[Mellvik]

@pawosm-arm, Yes, it was successful, and not all that complicated (I got help from the people on the list), but to a 'regular' (non technical) user, it would presumably be really hard.

In my case, I needed IRQ 11, here it is:

https://github.com/Mellvik/elks/commit/209a0eb0606ecf3340db49d4bfe0422be44d6d17

-Mellvik

29. feb. 2020 kl. 22:26 skrev pawosm-arm notifications@github.com:

 I've encountered the same problem with the ne2k card clone I have. I always need to edit ELKS sources to build the kernel for the XT-Turbo machine equipped with that ISA8 card. And it's not only IRQs. I/O ports and I/O mem also need to be changed. Definitely, ability to set it up in menuconfig would be beneficial.

@Mellvik was your encounter successful? What numbers and bits did you change?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pawosm-arm]

In my case, I needed IRQ 11, here it is:

Ah, so you have 286 AT machine, so it's easier. It is much harder on XT where there's only one 8259 significantly limiting the number of available IRQs. In my case, I was left with only IRQ2 free for the network card. Similar problem with I/O ports. The only way to set IRQ, I/O ports and I/O mem not colliding with the other ISA8 cards (e.g. I could not let it use I/O base 300h as it was already taken by the XT-IDE controller) was to run DOS program that configures settings held in the card's EEPROM.

What I eventually came up with was: IRQ 2 I/O base 240h

...and my patch was slightly longer:

diff --git a/elks/arch/i86/drivers/net/eth-main.c b/elks/arch/i86/drivers/net/eth-main.c
index 99b20971..00a95385 100644
--- a/elks/arch/i86/drivers/net/eth-main.c
+++ b/elks/arch/i86/drivers/net/eth-main.c
@@ -21,7 +21,7 @@

 static byte_t eth_inuse = 0;

-static byte_t mac_addr [6] = {0x52, 0x54, 0x00, 0x12, 0x34, 0x56};  // QEMU default
+static byte_t mac_addr [6] = {0x00, 0x00, 0xc0, 0x16, 0x8f, 0x43};  // WDC

 static byte_t recv_buf [MAX_PACKET_ETH];
 static byte_t send_buf [MAX_PACKET_ETH];
@@ -292,14 +292,14 @@ void eth_drv_init ()
                err = ne2k_probe ();
                if (err)
                        {
-                       printk ("[ne2k] not detected @ IO 300h\n");
+                       printk ("[ne2k] not detected @ IO 240h\n");
                        break;
                        }

                err = request_irq (NE2K_IRQ, ne2k_int, NULL);
                if (err)
                        {
-                       printk ("[ne2k] IRQ 9 request error: %i\n", err);
+                       printk ("[ne2k] IRQ 2 request error: %i\n", err);
                        break;
                        }

diff --git a/elks/arch/i86/drivers/net/ne2k-low.s b/elks/arch/i86/drivers/net/ne2k-low.s
index 1733f709..72a90474 100644
--- a/elks/arch/i86/drivers/net/ne2k-low.s
+++ b/elks/arch/i86/drivers/net/ne2k-low.s
@@ -7,7 +7,7 @@

 ; On Advantech SNMP-1000 SBC, the ethernet interrupt is INT0 (0Ch)

-int_vect    EQU $0C
+int_vect    EQU $60

        .TEXT
diff --git a/elks/arch/i86/drivers/net/ne2k-mac.s b/elks/arch/i86/drivers/net/ne2k-mac.s
index e5e2884c..9c46478e 100644
--- a/elks/arch/i86/drivers/net/ne2k-mac.s
+++ b/elks/arch/i86/drivers/net/ne2k-mac.s
@@ -6,42 +6,42 @@

 // TODO: move definitions to ne2k-defs.s

-// I/O base @ 300h
+// I/O base @ 240h

-io_ne2k_command    = 0x0300
+io_ne2k_command    = 0x0240

-io_ne2k_rx_first   = 0x0301  // page 0
-io_ne2k_rx_last    = 0x0302  // page 0
-io_ne2k_rx_get     = 0x0303  // page 0
+io_ne2k_rx_first   = 0x0241  // page 0
+io_ne2k_rx_last    = 0x0242  // page 0
+io_ne2k_rx_get     = 0x0243  // page 0

 // This is not a true NE2K register
-//io_ne2k_rx_put1    = 0x0306  // page 0 - read
+//io_ne2k_rx_put1    = 0x0246  // page 0 - read

-io_ne2k_tx_start   = 0x0304  // page 0 - write
-io_ne2k_tx_len1    = 0x0305  // page 0 - write
-io_ne2k_tx_len2    = 0x0306  // page 0 - write
+io_ne2k_tx_start   = 0x0244  // page 0 - write
+io_ne2k_tx_len1    = 0x0245  // page 0 - write
+io_ne2k_tx_len2    = 0x0246  // page 0 - write

-io_ne2k_int_stat   = 0x0307  // page 0
+io_ne2k_int_stat   = 0x0247  // page 0

-io_ne2k_dma_addr1  = 0x0308  // page 0
-io_ne2k_dma_addr2  = 0x0309  // page 0
-io_ne2k_dma_len1   = 0x030A  // page 0 - write
-io_ne2k_dma_len2   = 0x030B  // page 0 - write
+io_ne2k_dma_addr1  = 0x0248  // page 0
+io_ne2k_dma_addr2  = 0x0249  // page 0
+io_ne2k_dma_len1   = 0x024A  // page 0 - write
+io_ne2k_dma_len2   = 0x024B  // page 0 - write

-io_ne2k_rx_stat    = 0x030C  // page 0 - read
+io_ne2k_rx_stat    = 0x024C  // page 0 - read

-io_ne2k_rx_conf    = 0x030C  // page 0 - write
-io_ne2k_tx_conf    = 0x030D  // page 0 - write
-io_ne2k_data_conf  = 0x030E  // page 0 - write
-io_ne2k_int_mask   = 0x030F  // page 0 - write
+io_ne2k_rx_conf    = 0x024C  // page 0 - write
+io_ne2k_tx_conf    = 0x024D  // page 0 - write
+io_ne2k_data_conf  = 0x024E  // page 0 - write
+io_ne2k_int_mask   = 0x024F  // page 0 - write

-io_ne2k_unicast    = 0x0301  // page 1 - 6 bytes
-io_ne2k_rx_put     = 0x0307  // page 1
-io_ne2k_multicast  = 0x0308  // page 1 - 8 bytes
+io_ne2k_unicast    = 0x0241  // page 1 - 6 bytes
+io_ne2k_rx_put     = 0x0247  // page 1
+io_ne2k_multicast  = 0x0248  // page 1 - 8 bytes

-io_ne2k_data_io    = 0x0310  // 2 bytes
+io_ne2k_data_io    = 0x0250  // 2 bytes

-io_ne2k_reset      = 0x031F
+io_ne2k_reset      = 0x025F

 // Ring segmentation
diff --git a/elks/arch/i86/drivers/net/ne2k-phy.s b/elks/arch/i86/drivers/net/ne2k-phy.s
index acbd673f..3b55b70c 100644
--- a/elks/arch/i86/drivers/net/ne2k-phy.s
+++ b/elks/arch/i86/drivers/net/ne2k-phy.s
@@ -5,10 +5,10 @@

 ; TODO: move definitions to ne2k.h

-; I/O base @ 300h
+; I/O base @ 240h

-io_ne2k_mdio     EQU $314
-io_ne2k_gpio     EQU $317
+io_ne2k_mdio     EQU $254
+io_ne2k_gpio     EQU $257

 ; MDIO register

diff --git a/elks/arch/i86/drivers/net/ne2k.h b/elks/arch/i86/drivers/net/ne2k.h
index 98e64b8f..cc97aaaa 100644
--- a/elks/arch/i86/drivers/net/ne2k.h
+++ b/elks/arch/i86/drivers/net/ne2k.h
@@ -4,7 +4,7 @@

 // Default in QEMU

-#define NE2K_IRQ 9
+#define NE2K_IRQ 2

 // NE2K status
diff --git a/elks/arch/i86/kernel/irqtab.S b/elks/arch/i86/kernel/irqtab.S
index 32e8c8e1..24479683 100644
--- a/elks/arch/i86/kernel/irqtab.S
+++ b/elks/arch/i86/kernel/irqtab.S
@@ -43,7 +43,7 @@ ds_kernel:
 #define MFD 0
 #endif
 #ifdef CONFIG_ETH_NE2K
-#define METH 0x200
+#define METH 0x4
 #else
 #define METH 0
 #endif
@@ -115,8 +115,8 @@ _irq1:                      // Keyboard
        call    _irqit
        .byte   1
 #endif
-#if 0
-_irq2:                 // Cascade
+#ifdef CONFIG_ETH_NE2K
+_irq2:                 // Network device
        call    _irqit
        .byte   2
 #endif
@@ -149,8 +149,8 @@ _irq8:                      // RTC
        call    _irqit
        .byte   8
 #endif
-#ifdef CONFIG_ETH_NE2K
-_irq9:                 // Ethernet device
+#if 0
+_irq9:
        call    _irqit
        .byte   9
 #endif

Unfortunately, it didn't work for me. And currently, I won't be able to follow this up until April.

[Mellvik]

Hi @pawosm-arm, While I cannot help you debug the code, your message is a pertinent reminder that there is more than the IRQ-config that needs work. Lifting the base I/O address of the interface out from the 'hardcoded at driver' level is just as important.

--Mellvik

29. feb. 2020 kl. 23:01 skrev pawosm-arm notifications@github.com:

 In my case, I needed IRQ 11, here it is:

Ah, so you have 286 AT machine, so it's easier. It is much harder on XT where there's only one 8259 significantly limiting the number of available IRQs. In my case, I was left with only IRQ2 free for the network card. Similar problem with I/O ports. The only way to set IRQ, I/O ports and I/O mem not colliding with the other ISA8 cards (e.g. I could not let it use I/O base 300h as it was already taken by the XT-IDE controller) was to run DOS program that configures settings held in the card's EEPROM.

What I eventually came up with was: IRQ 2 I/O base 240h

...and my patch was slightly longer:

diff --git a/elks/arch/i86/drivers/net/eth-main.c b/elks/arch/i86/drivers/net/eth-main.c index 99b20971..00a95385 100644 --- a/elks/arch/i86/drivers/net/eth-main.c +++ b/elks/arch/i86/drivers/net/eth-main.c @@ -21,7 +21,7 @@

static byte_t eth_inuse = 0;

-static byte_t mac_addr [6] = {0x52, 0x54, 0x00, 0x12, 0x34, 0x56}; // QEMU default +static byte_t mac_addr [6] = {0x00, 0x00, 0xc0, 0x16, 0x8f, 0x43}; // WDC

static byte_t recv_buf [MAX_PACKET_ETH]; static byte_t send_buf [MAX_PACKET_ETH]; @@ -292,14 +292,14 @@ void eth_drv_init () err = ne2k_probe (); if (err) {

• printk ("[ne2k] not detected @ IO 300h\n");

• printk ("[ne2k] not detected @ IO 240h\n"); break; }

          err = request_irq (NE2K_IRQ, ne2k_int, NULL);
          if (err)
                  {

• printk ("[ne2k] IRQ 9 request error: %i\n", err);
• printk ("[ne2k] IRQ 2 request error: %i\n", err); break; }

diff --git a/elks/arch/i86/drivers/net/ne2k-low.s b/elks/arch/i86/drivers/net/ne2k-low.s index 1733f709..72a90474 100644 --- a/elks/arch/i86/drivers/net/ne2k-low.s +++ b/elks/arch/i86/drivers/net/ne2k-low.s @@ -7,7 +7,7 @@

; On Advantech SNMP-1000 SBC, the ethernet interrupt is INT0 (0Ch)

-int_vect EQU $0C +int_vect EQU $60

    .TEXT

diff --git a/elks/arch/i86/drivers/net/ne2k-mac.s b/elks/arch/i86/drivers/net/ne2k-mac.s index e5e2884c..9c46478e 100644 --- a/elks/arch/i86/drivers/net/ne2k-mac.s +++ b/elks/arch/i86/drivers/net/ne2k-mac.s @@ -6,42 +6,42 @@

// TODO: move definitions to ne2k-defs.s

-// I/O base @ 300h +// I/O base @ 240h

-io_ne2k_command = 0x0300 +io_ne2k_command = 0x0240

-io_ne2k_rx_first = 0x0301 // page 0 -io_ne2k_rx_last = 0x0302 // page 0 -io_ne2k_rx_get = 0x0303 // page 0 +io_ne2k_rx_first = 0x0241 // page 0 +io_ne2k_rx_last = 0x0242 // page 0 +io_ne2k_rx_get = 0x0243 // page 0

// This is not a true NE2K register -//io_ne2k_rx_put1 = 0x0306 // page 0 - read +//io_ne2k_rx_put1 = 0x0246 // page 0 - read

-io_ne2k_tx_start = 0x0304 // page 0 - write -io_ne2k_tx_len1 = 0x0305 // page 0 - write -io_ne2k_tx_len2 = 0x0306 // page 0 - write +io_ne2k_tx_start = 0x0244 // page 0 - write +io_ne2k_tx_len1 = 0x0245 // page 0 - write +io_ne2k_tx_len2 = 0x0246 // page 0 - write

-io_ne2k_int_stat = 0x0307 // page 0 +io_ne2k_int_stat = 0x0247 // page 0

-io_ne2k_dma_addr1 = 0x0308 // page 0 -io_ne2k_dma_addr2 = 0x0309 // page 0 -io_ne2k_dma_len1 = 0x030A // page 0 - write -io_ne2k_dma_len2 = 0x030B // page 0 - write +io_ne2k_dma_addr1 = 0x0248 // page 0 +io_ne2k_dma_addr2 = 0x0249 // page 0 +io_ne2k_dma_len1 = 0x024A // page 0 - write +io_ne2k_dma_len2 = 0x024B // page 0 - write

-io_ne2k_rx_stat = 0x030C // page 0 - read +io_ne2k_rx_stat = 0x024C // page 0 - read

-io_ne2k_rx_conf = 0x030C // page 0 - write -io_ne2k_tx_conf = 0x030D // page 0 - write -io_ne2k_data_conf = 0x030E // page 0 - write -io_ne2k_int_mask = 0x030F // page 0 - write +io_ne2k_rx_conf = 0x024C // page 0 - write +io_ne2k_tx_conf = 0x024D // page 0 - write +io_ne2k_data_conf = 0x024E // page 0 - write +io_ne2k_int_mask = 0x024F // page 0 - write

-io_ne2k_unicast = 0x0301 // page 1 - 6 bytes -io_ne2k_rx_put = 0x0307 // page 1 -io_ne2k_multicast = 0x0308 // page 1 - 8 bytes +io_ne2k_unicast = 0x0241 // page 1 - 6 bytes +io_ne2k_rx_put = 0x0247 // page 1 +io_ne2k_multicast = 0x0248 // page 1 - 8 bytes

-io_ne2k_data_io = 0x0310 // 2 bytes +io_ne2k_data_io = 0x0250 // 2 bytes

-io_ne2k_reset = 0x031F +io_ne2k_reset = 0x025F

// Ring segmentation diff --git a/elks/arch/i86/drivers/net/ne2k-phy.s b/elks/arch/i86/drivers/net/ne2k-phy.s index acbd673f..3b55b70c 100644 --- a/elks/arch/i86/drivers/net/ne2k-phy.s +++ b/elks/arch/i86/drivers/net/ne2k-phy.s @@ -5,10 +5,10 @@

; TODO: move definitions to ne2k.h

-; I/O base @ 300h +; I/O base @ 240h

-io_ne2k_mdio EQU $314 -io_ne2k_gpio EQU $317 +io_ne2k_mdio EQU $254 +io_ne2k_gpio EQU $257

; MDIO register

diff --git a/elks/arch/i86/drivers/net/ne2k.h b/elks/arch/i86/drivers/net/ne2k.h index 98e64b8f..cc97aaaa 100644 --- a/elks/arch/i86/drivers/net/ne2k.h +++ b/elks/arch/i86/drivers/net/ne2k.h @@ -4,7 +4,7 @@

// Default in QEMU

-#define NE2K_IRQ 9 +#define NE2K_IRQ 2

// NE2K status diff --git a/elks/arch/i86/kernel/irqtab.S b/elks/arch/i86/kernel/irqtab.S index 32e8c8e1..24479683 100644 --- a/elks/arch/i86/kernel/irqtab.S +++ b/elks/arch/i86/kernel/irqtab.S @@ -43,7 +43,7 @@ ds_kernel:

define MFD 0

endif

ifdef CONFIG_ETH_NE2K

-#define METH 0x200 +#define METH 0x4

else

define METH 0

endif

@@ -115,8 +115,8 @@ _irq1: // Keyboard call _irqit .byte 1

endif

-#if 0 -_irq2: // Cascade +#ifdef CONFIG_ETH_NE2K +_irq2: // Network device call _irqit .byte 2

endif

@@ -149,8 +149,8 @@ _irq8: // RTC call _irqit .byte 8

endif

-#ifdef CONFIG_ETH_NE2K -_irq9: // Ethernet device +#if 0 +_irq9: call _irqit .byte 9

endif

Unfortunately, it didn't work for me. And currently, I won't be able to follow this up until April.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Mellvik]

From #515: I suggest leaving IRQ2 alone. Unless we're on a pre-PC/AT machine, IRQ2 is tied to the 2nd 8259 Interrupt controller, and - if I remember correctly - all attempts to use IRQ2 will be mapped to #9.

[ghaerr]

I suggest leaving IRQ2 alone. Unless we're on a pre-PC/AT machine, IRQ2 is tied to the 2nd 8259 Interrupt controller, and - if I remember correctly - all attempts to use IRQ2 will be mapped to #9.

At this point, I was thinking of updating config so that one can specify IRQ 5 somewhat as follows:

• NONE
• COM3 (default for now, then NONE after your testing)
• Experimental HW IDE hard disk
• Sound card (to be added when driver written).

Then, not changing any IRQ 2 or IRQ 9, but designing the above so that adding the ability to attache a network card to IRQ 2 or IRQ 5 may be possible... Comments?

[pawosm-arm]

Seems like we're following the fate of Linux, one system that tries to fit so many possible configurations... Eventually, Linux ended up having Device Tree compiled to binary blob read and processed at boot time.

I suggest leaving IRQ2 alone. Unless we're on a pre-PC/AT machine, IRQ2 is tied to the 2nd 8259 Interrupt controller, and - if I remember correctly - all attempts to use IRQ2 will be mapped to #9.

Indeed, these are pre-AT machines on which I'm trying to run ELKS on. Yet since PC/XT/AT machines share the same pre-plug-n-pray ISA bus with limited number of devices that could be controlled and where each device is defined by three parameters (IRQ, I/O ports, I/O mem), I opted for some kind of global devices table (in kernel's menuconfig) rather than focusing on just IRQ5 and/or IRQ2.

[ghaerr]

Seems like we're following the fate of Linux, one system that tries to fit so many possible configurations...

That's what is being requested in this issue, right?

Eventually, Linux ended up having Device Tree compiled to binary blob read and processed at boot time.

Wow, I didn't know that. What a mess.

I opted for some kind of global devices table (in kernel's menuconfig) rather than focusing on just IRQ5 and/or IRQ2.

That's not a bad idea. However, none of the ELKS device drivers are setup to use a table-driven approach without modifying all of them and other areas too. Given the current ELKS dependence on PC architecture and almost all of the devices are built into motherboards, what really would be the point? I also hesitate to make such a major modification unless all could be tested.

We have shown we need flexibility on IRQ 5. Are there other devices needing 2/9 other than a network card? This open issue may be more comprehensive than just rerouting IRQ 5, if port addresses need to be specified for other devices.

[pawosm-arm]

Wow, I didn't know that. What a mess.

Quoting elinux.org: The primary purpose of Device Tree in Linux is to provide a way to describe non-discoverable hardware. This information was previously hard coded in source code.

almost all of the devices are built into motherboards

yeah, but we're struggling here with those devices that aren't built into motherboards, rather plugged into the ISA slots.

I also hesitate to make such a major modification unless all could be tested.

That's the nightmare of every maturing OS :(

We have shown we need flexibility on IRQ 5. Are there other devices needing 2/9 other than a network card?

Actually, everything in XT that can be jumper set to use IRQ5 has an option to pick different IRQ line, including IRQ2 (maybe except Hercules Graphics Card which usually has on-board parallel port and uses IRQ5 for LPT2: and usually there's no jumper to change that). So, the network card, sound card, more serial ports, 8-bit SCSI controller, all of this stuff can be configured to use selected IRQ lines including IRQ2 or IRQ5, depending on their availability in given system.

[ghaerr]

Actually, everything in XT that can be jumper set to use IRQ5 has an option to pick different IRQ line

Well, what do we really need to do? I'm trying to sort out the difference of "what would be great" but hardly used, and what is actually needed. Granted, I would like to get "great" things done too, but do we really need to be able to reconfigure all IRQs?

[ghaerr]

Quoting elinux.org: The primary purpose of Device Tree in Linux is to provide a way to describe non-discoverable hardware. This information was previously hard coded in source code.

I suppose another approach could be to "table-drive" the ports and IRQs somehow, without having to write complicated IRQ-setting configuration files. But that could still take lots of work, integrating that in and out of .c code. What do you guys think of that approach here?

[pawosm-arm]

Currently, those 'lots of work' are shifted on potential ELKS users, e.g. it was a good guess game to find all the places that need to be amend to match I/O configuration of the network card (see earlier posts in this ticket) and I'm still not sure if I spotted all the places that needed to be spot (due to the lockdown, I can't follow the subject).

[ghaerr]

Currently, those 'lots of work' are shifted on potential ELKS users, e.g. it was a good guess game to find all the places that need to be amend to match I/O configuration of the network card

I see. Good point. I'm learning too. One idea could be to set all the ports and IRQ as #defines, and put them all into header files in elks/include/arch, at least to start. It may or may not be a good idea to cull them all into a single header file 'ports.h'?

[pawosm-arm]

It would be much better than having bare values spread across many files.

[ghaerr]

I'll take a pass at creating a 'ports.h' that has start port addresses and IRQs for all devices that use IRQs. That will help dig in to see how much of a problem this might be.

[ghaerr]

PR #561 hopefully solves most of the requests in this issue.

We need someone to test the NE2K network driver. Can this be setup on QEMU?

The NE2K 'ne2k-mac.s' file needs to be updated to get the network card base port address from ports.h and then add offsets for the remaining ports. @pawosm-arm's first patch shows the need for this.

[Mellvik]

@ghaerr,

I think one of my network (NE2K) cards can be set to IRQ9, so I can do some testing when it's ready.

—Mellvik

17. apr. 2020 kl. 17:17 skrev Gregory Haerr notifications@github.com:

PR #561 https://github.com/jbruchon/elks/pull/561 hopefully solves most of the requests in this issue.

We need someone to test the NE2K network driver. Can this be setup on QEMU?

The NE2K 'ne2k-mac.s' file needs to be updated to get the network card base port address from ports.h and then add offsets for the remaining ports. @pawosm-arm https://github.com/pawosm-arm's first patch shows the need for this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/372#issuecomment-615302882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOGC44AYQR54GD3JJILRNBXIFANCNFSM4KZZPTXA.

[ghaerr]

NE2K is ready to go now, I'm looking for instructions on how QEMU maps network access to the host. I've never setup ELKS networking nor QEMU emulating a network card, and am hoping to get a head-start from someone that's done it before. (Working away over here on macOS and no real 8086 hardware lol).

Once NE2K runs on QEMU, it can be modified for reconfiguration of base addresses, etc.

[cjsthompson]

@ghaerr , maybe you know it already and for some reason it's not suitable, but I thought I'd mention PCem, an emulator that aims at accurately emulating a good selection of early PCs from XTs to Pentiums with all kinds of then popular expansion cards (it emulates an Adlib sound card, Ne2k ISA card and more). It uses copies of the original BIOS. I played with it last month to emulate an Amstrad PC1512 (a machine I have) and I found it overall quite good albeit with a few bugs but it's still being actively maintained. PCem goes so far at trying to be accurate that they even emulate the look of of a CRT and the sound of floppy drives :) Perhaps it would be a great tool to test ELKS.

I'm going to give it a try with ELKS as soon as the new version is released as my real Amstrad PC1512's monitor (which does dual boot ELKS 0.1.x and FreeDOS from an MFM hd) is unfortunately broken at the moment.

[ghaerr]

I thought I'd mention PCem, an emulator that aims at accurately emulating a good selection of early PCs

Thanks Christoph! Is that the same as 'pce', it looked at that last year but haven't tried it with ELKS yet.

I'm going to give it a try with ELKS as soon as the new version is released

As soon as an ELKS new version is released? What are you waiting for? :) Give it a try now, and I'll follow up and use your config file to get going on my side!

That said, I would like to see an ELKS release sometime soon.

[cjsthompson]

Thanks Christoph! Is that the same as 'pce', it looked at that last year but haven't tried it with ELKS yet.

I've never heard of 'pce' but I know there are a few forks of PCem out there. There's 86Box but they've made it Windows only.

As soon as an ELKS new version is released? What are you waiting for? :) Give it a try now, and I'll follow up and use your config file to get going on my side!

I tried to make a gcc-ia16 AUR build for Arch Linux so I could use it to build ELKS a month ago or so, but the build process of binutils/gcc is such a mess that I gave up for now (I followed what the build scripts for Ubuntu are doing but for some esoteric reason it fails hard and having to debug the autotools mess gives me nightmares). Also because of a BIOS limitation the Amstrad PC 1512 can't boot from anything else than a 360k floppy drive (unless there's some BIOS add-on on an expansion card). PCem does reproduce that limitation accurately too. So I thought it would be more interesting to try things out with the 32mb hd image support you added not long ago.

However I could definitely try 0.3.0 with some other XT that PCem emulates.

[ghaerr]

the build process of binutils/gcc is such a mess that I gave up for now.

Actually, it has been made easy. Do a 'git clone' of ELKS, cd to it, then run "./build.sh". It does take a while, but there is nothing else you need to do. I recommend trying it :)

the Amstrad PC 1512 can't boot from anything else than a 360k floppy drive.

ELKS now supports building a complete set of images, including both MINIX and FAT versions of 360k images. After building ELKS, do: 'cd images; make images', and it will produce fd360-minix.bin and fd360-fat.bin for you to dd onto a floppy. You can also use menuconfig to generate the same set of disk images by setting "Build extra binary images" to Y in the "Target Image" section.

If you like, I'll post a 360k image for you here, just so you can try booting.

[cjsthompson]

Actually, it has been made easy. Do a 'git clone' of ELKS, cd to it, then run "./build.sh". It does take a while, but there is nothing else you need to do. I recommend trying it :)

I'll give it a try tomorrow.

ELKS now supports building a complete set of images, including both MINIX and FAT versions of 360k images. After building ELKS, do: 'cd images; make images', and it will produce fd360-minix.bin and fd360-fat.bin for you to dd onto a floppy. You can also use menuconfig to generate the same set of disk images by setting "Build extra binary images" to Y in the "Target Image" section.

I've been closely following all the awesome improvements to ELKS that have been made these last few months and I'm really eager to get that monitor repaired so I can upgrade ELKS on my Amstrad.

If you like, I'll post a 360k image for you here, just so you can try booting.

If I run into the same gcc build problem on Arch with build.sh then that would be really nice.

[ghaerr]

I followed what the build scripts for Ubuntu are doing but for some esoteric reason it fails hard

I missed that part, so I've attached a compressed zip of the latest build's two 360k boot disks (MINIX and FAT) for you to try.
fd360.zip

it would be more interesting to try things out with the 32mb hd image

Yes, please do. I'm interested in feedback on the MBR images particularly.

[cjsthompson]

So I just gave a try to fd360-minix.bin in PCem with my 1512 profile and it works great. The only thing you need to do to use these images with PCem is change the file extension to 'img' to load them in. Everything in PCem can be set up from the GUI like VirtualBox so there's not really a big need for a config file. But there is one for each virtual PC config one might brew anyway.

I went and ls'ed and cat'ed around the file system and everything works great so far. 'reboot' works too. The system seems to run as fast as I remember MSDOS to run on a real 1512. I could be wrong but the 1512 doesn't have NEC V30 CPU, but an AMD 8086. Maybe PCem got it wrong. The serial ports are indeed two 16550A on the 1512.

Building binutils/gcc with build.sh works great as well. I was able to build a custom 32mb hd image of ELKS after fiddling a bit in menuconfig. However the geometry automatically detected by PCem for the ELKS hd image isn't supported by the MFM controller emulated by PCem that I chose. Going to try out other controllers. This is what I get so far with the hd image in PCem:

[ghaerr]

Hello @Mellvik,

In reviewing this thread, I think that PR #561 from back in April (Add customizable IRQ and I/O ports for all drivers) pretty much sets what we're going to get (at least for the next release) as far as being able to configure IRQ and port settings in ELKS. That PR allows configuring almost all hardware base addresses and IRQs from the include/arch/ports.h file and then recompiling, rather than trying to bring all of that complexity into menuconfig. The only I know missing from ports.h is the NE2K NIC base address, which is currently set in ne2k-mac.s as 'base = 0x0300'. That base address is already coded into ports.h as NE2K_PORT and can be included within ne2k-mac.s by renaming the file to ne2k-mac.S (which allows for automatic C preprocessing of assembly files), including "arch/ports.h" and then adding 'base = NE2K_PORT' in the new file. This can be done with the planned enhancements you're doing for that driver.

Please review and then close this issue if satisfied, thanks!

[Mellvik]

@ghaerr, how timely.

I was going to ask you about this. Is there anything other than changing the file name and modifying the makefile I need to be aware of?

—Mellvik

19. jul. 2020 kl. 01:43 skrev Gregory Haerr notifications@github.com:

Hello @Mellvik https://github.com/Mellvik,

In reviewing this thread, I think that PR #561 https://github.com/jbruchon/elks/pull/561 from back in April (Add customizable IRQ and I/O ports for all drivers) pretty much sets what we're going to get (at least for the next release) as far as being able to configure IRQ and port settings in ELKS. That PR allows configuring almost all hardware base addresses and IRQs from the include/arch/ports.h file and then recompiling, rather than trying to bring all of that complexity into menuconfig. The only I know missing from ports.h is the NE2K NIC base address, which is currently set in ne2k-mac.s as 'base = 0x0300'. That base address is already coded into ports.h as NE2K_PORT and can be included within ne2k-mac.s by renaming the file to ne2k-mac.S (which allows for automatic C preprocessing of assembly files), including "arch/ports.h" and then adding 'base = NE2K_PORT' in the new file. This can be done with the planned enhancements you're doing for that driver.

Please review and then close this issue if satisfied, thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/372#issuecomment-660558518, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOCDZFCYRV5IAUYCBI3R4IXQLANCNFSM4KZZPTXA.

[ghaerr]

Is there anything other than changing the file name and modifying the makefile I need to be aware of?

No, the instructions above should do it. If you run into any problems with the .S file preprocessing allowed, just look at some of the other .S files, perhaps those in arch/i86/kernel, for instance.

[ghaerr]

@Mellvik,

Now that the NE2K mac-ne2k.S driver includes ports.h, is there anything more that will be done on this issue? Please close this issue if satisfied, thank you.