Hardware

Hi,

I'm trying to get m0n0wall working on a Neoware Eon Preferred 4000 (Geode Processor).  I've tried both generic-pc-1.233.img and generic-pc-1.3b11.img, both fail at the same point.

To install the image, I followed the instructions listed on this site.

http://www.monkeysushi.net/writing/other/HOWTO%20Neoware%20m0n0wall.html

I did have to slightly modify things, however I  was able to wget the file and and use dd to write it to the DiskOnModule.


FreeBSD starts to boot ok, it fails at this point

md0: Preloaded image </mfsroot> 15728640 bytes at 0xc0a60160
Trying to mount root from ufs://dev/md0
kern.coredump: 1 -> 0

*********************************************
* FATAL ERROR
* The device that contains the configuration file (config.xml) could not be
* found. m0n0wall cannot continue booting.
*********************************************

Any ideas what is causing the coredump?

Your disk-on-module / disk-on-chip requires the TrueFFS driver, which is not a standard part of m0n0wall.  Therefore, as soon as the BIOS transfers control to the kernel, the disk it booted from is no longer readable.

Could you open up your EON and check to see whether it has a 32-pin DIP disk-on-chip, or the IDE disk-on-module package?  I believe all the devices that plug into the IDE connector will work with m0n0wall (that is at least the case with the 8 or so EONs I have), but clearly I need to draw more attention to that in my tutorial - it's an important prerequisite to getting it to work.

You may be able to boot from something other than the DOC chip (my disk-on-chip EONs refuse to boot from any other source) and then reflash the chip with a kernel with the appropriate module loaded.  If you do get this to work, could you send me a copy of the kernel?

Thanks, and good luck!

Thanks for the reply.

I managed to get the EON to boot by removing the DOM and using a CD drive.

The model of the EON I'm using is BA-EON4000T-36A (64M SO-DIMM, 64M DOM and 1 PCI slot). The other EON's I have are BA-EON4000T-26, these have (64M SO-DIMM, 32M DOM or 1 PCI or ISA slot).

The DiskOnModule is made by PQI (Power Quotient International), 64MB Industrial. It is 40pin and plugs into the IDE connector.

I tried connecting the DOM into a few normal PC's, none of them recognise the DOM. They wouldn't boot and didn't detect the DOM from the BIOS.

I've ordered some IDE to Compact Flash adaptors. If I can't get the DOM to work I will use a CF card.

I'm using 40 pin IDE 16MB PQI DOMs here with m0n0wall. No problems. Are you sure the DOM hasn't been damaged somehow? Linux and Windows 2K/XP all read/write mine fine.

Hi,

The 64Meg DOM was working with neoware before I changed it to m0n0wall. I have used the method described on the earlier website to change the firmware on the 64Meg DOM a few times.  DD successfully writes the image ok.

I have a few other EON units which have 32meg DOM in them. I'll put them into a PC and see if they are recognised/work.

Regards

Colin

I had smaller ones (8 or 16MB) too.  It's possible Neoware had something changed in later models.

You indicated that you had DOMs with Neoware's software (presumably NeoLinux) on them still.  Could you boot one of those up and watch the bootup messages / poke around in the shell to look for the TrueFFS driver?  If it's running, that's a pretty good indication that you've found the problem with m0n0.

I have the same unit with the same problem. Using a DOM connected to the Prim. IDE port. Tried writing the .img under Linux or Windows. LBA turned off or on. Move the DOM to a different system. Boots fine.

How to enable TrueFFS?

Finally gave up and now using Lex Thin-800E box with 860T motherboard, VIA C3 800 cpu.

Free stuff from work is nice. 

Received the IDE -> CF adaptors.

I used physdiskwrite-0.5.1 to load 1.3b11 onto the 64M CF. To my horror, Monowall stopped at the same point as with the DOM.

I then loaded 1.233, this boots and works.

Loaded 1.3b10, it fails at the same point as 1.3b11.

Loaded 1.3b9, it works correctly.

From my earlier post, using the same hardware, 1.3b11 boots and works correctly if I use a CDROM.

Any ideas what is causing the problem with 1.3b10/11?

I can confirm this. I also have an EON 4000S and the DOM worked fine with 1.22. Then I did an upgrade to 1.3b7 which worked as well, but 1.3b11 broke it. This happened on two identical DOM Modules. I'll now try a different DOM and also a CF-Card adaptor. This didn't help as well; http://m0n0.ch/wall/list/showmsg.php?id=162/15

I cannot attest to whether this is relative but I am using an ide to cf adapter in a couple of poweredge 350's...worked fine with the 1.2b3 I think it was...then for whatever reason one day, I figured I would upgrade to I think it was 1.3b7...no issues there, but shortly after I started getting oddball reboots....on both boxes at two different locations, one at home and one at work...for a while, the one at home was rebooting every 1-2 days, the one at work maybe once a week..I figured at this point, what the hay, I will downgrade it to the 1.233...still have reboot issues, just not as often...currently the one at home has been going for 17 days and the one at work has been running for 5 days....

maybe no correlation to this issue at all, but the conversation reminded me of my situation a little....

I think I found the line during the boot process may describing this failure:

device_attach: ata0 attach returned 6

[Can anyone who can read their DOM in a PC confirm whether they are using a power cable with their DOM?]

I've been trying to workout why none of my DOM's are recognised in anything else, they only seems to work with a EON unit.

I found this (Taken from http://www.ravirajtech.com/diskonmodule.html)

2. How is power supplied to DOM?

DOM comes with connector cable which allow you to connect DOM to 4 PINs SMPS connector. hence you can supply power to DOM exactly the way power is supplied to computer HDD. This is required only in case of 40 pins DOM.

The DOM units I have don't have any external power cables. I'm starting to think the EON is power the DOM using a spare pin. The PC IDE doesn't have power available on the spare pin.

Can anyone who can read their DOM in a PC confirm whether they are using a power cable with their DOM?


This lists the different DOM modules, all of mine are FDxxx-019PR,  these don't have the power cable. Whereas FDxxx-019P have an additional power cable.

http://www.ravirajtech.com/pdfs/DiskOnModule.pdf

Regards

Colin

I am using PQI DiskOnModule 16MB 40 pin units, P/N FD016-019P. They have a separate power cable, four wires. It plugs into a tiny socket on the top of the DOM. The other end has two of the standard 4 pin molex floppy drive power cable connectors.

Although I don't have any, my understanding of the 44 pin DOMs is that the extra four pins (compared to 40 pin units) on the IDE interface connector are for the power connections.

Hi,

My PQI DOM units are FD064-019PR.

I made a cable and conneted 5V to the spare pin on the master/slave connector connector. The unit is now recognised in my PC


You can use the master/slave link to make the cable.

1) Carefully lift one of the plastic locking tab so you can remove the outer most pin from the connector.
2) Put the pin into the spare hole - inner most position.
3) Cut the linking wire
4) Connect the wire from the inner position to 5V
5) Connect the other wire (middle pin) to Ground.
6) Take the cover off the DOM, itt is held on by the clips on the sides.
7) On the PCB, carefully link the outer 2 pins using a soldering iron.

This will result in the DOM being permanently a master unit.

If anyone wants to see a photo, email vk2kcm @ gmail dot com and I will send you one.

Regards

Colin

Hi Colin.

After some tests I assumed the 1.3b13 simply don't work.
The hardware I used was a thin client Visara 1883 (Geode 233MHz) with 64Mb RAM and a DOM (disk on module) IDE 64Mb.
I confirm DOM 44pin require 5v power supply.
Every time I used Physdiskwrite 0.5.1 to flash the image to the DOM.

Well, I started with 1.233 (put the DOM into PC, flash mono image, put into the thin client and boot the firewall) an all came right; the monowall boots an came up normally.
Ok, then the next step was to upgrade (via Web GUI) to version 1.3.b7 as suggested; aslo this version boots and run normally.
Last I applied (always using Web GUI) the 1.3b13 firmware obtaining your same error.
The same happens if you want install 1.3b13 firmware directly without follow the three steps 1.233 > 1.3b7 > 1.3b13.

Starting 1.3b13 from an IDE CD boots fine.

The last chance is try to start flashing on the DOM the 1.233 and then apply via web GUI all the beta upgrades step by step up tp 1.3b13...