eCos/RedBoot i386 problems

Hello, I´ve just started learning eCos and am using the book "Embedded Software Development with eCos" by Anthony J. Massa. I´m trying to set up a RedBoot floppy on an i386 PC target (an old p150 I had lying around). I´m working on a laptop that does not have a floppy drive, and am trying to use a floppy drive that resides on a network share. The laptop has a dual boot system with XP and Linux (SuSE 8.2). I´ve been able to mount the drive using Cygwin under XP, and also under Linux, and am able to read and write to it.

My problem is this: I have not been able to get the target to boot properly. I´ve done the eCos compile under both XP and Linux, but still get the same problems. When I attempt to install the image to the floppy as per the instructions, this is what happens:

mht@linux:~/work> dd conv=sync if=redboot_install/bin/redboot.bin of=/dev/floppy dd: opening `/dev/floppy': Is a directory

and nothing else happens. When I set the of to /dev/floppy/redboot.img, I get the success message:

linux:/home/mht/work # dd conv=sync if=redboot_install/bin/redboot.bin of=/dev/floppy/redboot.img

174+1 records in 175+0 records out

I then copied it to the HD on the computer that has the floppy, and used rawrite to install to the floppy. When I boot up, a little more than two rows of dots come on the screen, and then a blinking cursor. Nothing else happens after that...no boot message or anything else, even though I set it up in eCos to output to the monitor.

Does anyone have any possible solutions, or ideas as to what I might be doing wrong? I´d appreciate any help!

Thanks, Mike Trozzo

mht@linux:~> mount /dev/hda7 on / type reiserfs (rw) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda8 on /home type reiserfs (rw) /dev/hda1 on /windows/C type ntfs (ro,noexec,nosuid,nodev,gid=100,umask=0002,nls=iso8859-1) /dev/hda5 on /windows/D type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,iocharset=iso8859-1,code=437) shmfs on /dev/shm type shm (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) //192.168.0.1/a on /dev/floppy type smbfs (0) mht@linux:~> bash mht@linux:~> cd work mht@linux:~/work> ls redboot.ecc redboot_install untitled_build untitled_mlt redboot_build redboot_mlt untitled_install mht@linux:~/work> dd conv=sync if=redboot_install/bin/redboot.bin of=/dev/floppy dd: opening `/dev/floppy': Is a directory mht@linux:~/work> dd conv=sync if=redboot_install/bin/redboot.bin of=/dev/floppy/redboot.img dd: opening `/dev/floppy/redboot.img': Permission denied mht@linux:~/work> su Password: linux:/home/mht/work # dd conv=sync if=redboot_install/bin/redboot.bin of=/dev/floppy/redboot.img

174+1 records in 175+0 records out linux:/home/mht/work # dd conv=sync if=redboot_install/bin/redboot.bin of=/dev/floppy/redboot.bin 174+1 records in 175+0 records out linux:/home/mht/work #
Reply to
Mike Trozzo
Loading thread data ...

Mike Trozzo enlightened us with:

Ugh, that isn't going to make things easy!

Unfortunately it probably assumes there's a FAT filesystem on it.

For these purposes, only redboot.bin matters. Ignore redboot.img.

It's probably copied just as a file, not directly starting at the floppy boot sector.

rawrite should work though. If you already have a cygwin system as you seem to indicate, try copying just dd.exe and cygwin1.dll to the machine with the floppy drive, and run the dd command again. Although you probably have to use /dev/fd0 with cygwin these days I think.

Jifl

--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Reply to
Jonathan Larmour

In this case you like to overwrite the DEVICE /dev/floppy But you probably have an network mounted partition - correct? Can you get a remote shell on the computer with the floppy? Then transfer the file there and use the command.

Another approach could be to get a USB floppy - it should work...

In this case you copy the file to the floppy...

Here you have a bootable floppy! It begins to boot, but it does not boot properly - sorry I can't help you here, you need to ask someone that knows more about eCos... (or redboot)

/RogerL

--
Roger Larsson
Skellefteå
 Click to see the full signature
Reply to
Roger Larsson

Jonathan,

Thanks for helping me out. I bit the bullet and installed Cygwin on the other box. Fortunately, my wife is very understanding in these matters (it´s her computer :-). I mounted the floppy, wrote to it, and all was well.

Anyway, this brings me to the second phase of the problem, which has happened both with the rawrite images and the cygwin/dd images. I put the floppy into the drive of the target, and fire it up. All I get are 2+ rows of dots. It seems like it´s not quite completing the boot process. This has not only happened with the binaries I made with eCos, but also with the example binary that was on the CD that came with the Massa book (which I figure should work). Shouldn´t I get the boot message on the screen, since I set it to output to the monitor? I'm also connected through the serial port, but tomorrow once I pick up another cable I´ll run it through the hub so that I can try a ping. I can´t figure out what I´m missing here. Any ideas?

TIA, Mike

Reply to
Mike Trozzo

Roger,

Thanks for the advice...but I just ended up putting cygwin on the other comp and it works fine. Now all I have to do is get the floppy to boot and I´ll be happy.

Mike

Reply to
Mike Trozzo

Here´s an update: I ran the bootdisk on another computer, and after a few seconds, it booted up, and got the RedBoot welcome message. Strange. The one that didn´t work was a p150, which boots up fine with a Win98 boot floppy and also to the HD. The one that did was a 1.4 GHz PIII. Go figure.

Reply to
Mike Trozzo

Mike Trozzo enlightened us with:

Seems so. Perhaps it's to do with the ethernet support... if that computer has an Intel NIC, RedBoot may just be stuck waiting for a BOOTP response. Wait a bit longer to see what happens. Or maybe you've stumbled on some incompatibility with your particular PC - not all PCs are as compatible as you might think; especially older "big manufacturer" ones like Compaq, Dell, etc.

Either of those would explain why it did work on a different PC.

Jifl

--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Reply to
Jonathan Larmour

Make sure that the system is compiled for 386/486/Pentium -march=... Newer architectures has instructions not available on the old ones.

/RogerL

--
Roger Larsson
Skellefteå
 Click to see the full signature
Reply to
Roger Larsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.