boot image problem

Hi,

I’m trying to load a boot image on a compact flash card and I’m having a few difficulties. Here’s what I think makes the most sense (I’ve tried variations on these with little success):

fdisk hd1 delete -a
fdisk hd1 add -b -t77

fdisk hd1 show
(this results in the first partition being 54Mb even though the disk is 64Mb, this big a difference seems odd to me)

dinit -h hd1t79
It asks if the file will be lost, yes
states that the loader used is: /bunch_of_dirs/ipl-diskpc2-flop
(is this the best loader??)

mount hd1t79 /fs/cf
cp boot_image.ifs /fs/cf/.boot

When I boot this, the cursor just ends up blinking forever

However if I don’t create a partition using fdisk and use the dinit command as: dinit -h -hd1

When I boot this up, it gets a disk error: Hit Esc for .altbootD

I’ve also tried including the boot image in the dinit command with no luck.

Any suggestions would be greatly appreciated

‘fdisk add -s1 -t77’ should be: ‘fdisk add -s1 -t79’ to match the rest of what you wrote. Second, the CF might have a bad geometry so that is is not able to boot. Format the CF card using Windows and the CFPREP utility that comes with a lot of USB card readers. Then, redo your CF card.

Freddy

Yeah, the problem will be a mismatch between the CHS totals of what devb-eide thinks when you are placing the partition and image and what the BIOS thinks the CHS totals are. For some reason LBA is not used or the views of LBA are not consistant.

One sign, but not a garrantee, of this happening is the following being displayed when giving the command similar to “fdisk /dev/hd0 info” …

Warning: total sectors field does not agree with
cylinderssectors/trackheads!! (78165360 vs 78156225)

Ok, after reading the previos discussion (openqnx.com/PNphpBB2-viewtopic-t2882-.html) I think I’m starting to understand what’s going on.

I am getting the warning message mentioned above on fdisk /dev/hd1 info

From what I gather the problem is that the BIOS on the boot machine is recognizing a different number of CHS than devb-eide. Is this because devb-eide defaults to LBA mode and the BIOS does not. Is this a problem with the card or the computers reading the card?? FYI: I used 6.2.1 images on it fine, but now with 6.3 there’s issues.

My usb reader didn’t come with a copy of CFPREP (calling the manufacturer, SanDisk, didn’t help as it appears to be only available through OEM support - is CFPREP specific to each CF reader manufacturer). What exactly does CFPREP do, and will it fix the problem?

Thanks for your help,

I’ve given up trying to understand what devb-eide is doing to guess the geometry, I figgure the best idea is to let BIOS have it’s way and adapt devb-eide to suit. Which luckly can be easily done. Kudos to QSS for making that possible.

To start over, I suggest erasing the partition table with dd and then running windoze fdisk over it to create a single DOS partition. Then back in QNX devb-eide will find a happy partition table and use that for it’s CHS totals. Note down the totals and also where the partition has been placed in terms of start and end CHS values. Then delete the DOS partition and add a QNX one. This should have the same start and end values. If not, then starting devb-eide with the “disk translation=HEAD:SECTOR” option that matches what BIOS lists will get it straight. Hopefully this bit won’t be needed.

From there you should be away flying … :>

Well I couldn’t find a copy of windows fdisk for XP so I used the disk management tool to add a FAT partition and that really messed things up. Here’s the fdisk info output:

Physical disk characteristics: (hd1)
Disk type : Direct Access (0)
Cylinders : 7
Heads : 255
Sectors/Track : 63
Total Sectors : 125440

Warning: total sectors field does not agree with
cylinderssectors/trackheads!! (125440 vs 112455)

Partition table information:
0: (114) beg(h=116,s=104,c=101) end(h=32,s=109,c=101) off=778135908, size=1141509631
1: (101) beg(h=115,s=107,c=32) end(h=114,s=114,c=111) off=168689522, size=1936028240
2: (121) beg(h=32,s=97,c=110) end(h=32,s=107,c=101) off=1869881465, size=1936028192
3: (13) beg(h=97,s=114,c=116) end(h=10,s=0,c=0) off=0, size=3637226496
signature1=0x55, signature2=0xAA

Anyways, I tried to match the qnx partitions up, but you’ll notice the beg cylinders are after the end cylinders for each partition, and fdisk didn’t want to let me do this. When I got the boot image on loading it on the target computer it just displayed semicolon’s (does this mean something specific).

I tried the command:
devb-eide name=/dev/hd1 disk translation=8:32
and it still gives me the sectors warning. Is this the correct command?

Will a new card fix the problem, as I’m at that “who cares about $50 if I can stop wasting my time” - don’t worry, I’m still far from flying

Just out of curiosity, what kind of CF reader do you notice these problems with - I am using a SanDisk ImageMate CF.

Thanks for your help,

I’ve only used my laptop for experimenting so don’t have any readers. It doesn’t support booting from the PCMCIA slot so I can’t experiment in that area.

I didn’t know Windoze fdisk was no longer as I’ve never really used any NT based setups.

I guess I’m starting to get an understanding of the reallity of trying to make a disc portable in the PC world - it’s not possible without hassles, like most of the rest of the PC.

Okay, you have listed 8:32 for the Heads and Sectors totals, those values should be the same as what the target BIOS views the CF card as. Once you get the CHS totals matching then erase the partition table again and use QNX’s fdisk to create the the partitions from scratch again. Everytime you start devb-eide for this card, on all equipment including in the boot image, from now on will need the same translation specified.

And yep that command looked correct except I also had to specify the ioport and irq because they are not at the typical locations on me laptop.

Well, I got a hold of another CF card (Canon) and everything worked the first time with no problems, so thats about it.

Does anyone out there from QSSL know anything about this problem??

Thanks for the help

dang, I wanted to see that work.

What brand CF card was the old one?

SanDisk Industrial Grade 64MB (SDCFB-64-101-80)

I had the exact same problem of you getting Hit Esc for .altbootD at startup and using a Sandisk flash. But I have solve the problem using the dloader application, once you have made your dinit, just type dloader /dev/hdx pc1 and then after dloader /dev/hdxtyy pc2 . Then you can copy your .ifs over your .boot and that’s all. Just try to boot with it and see if it works, it works for me at least.

I ran into ths same problem with a SanDisk SDCFBI-64-101-00 using the PCCARD slot on my laptop.
In QNX 6.3 the CHS (Cylinder Head Sector) shows up as 7:255:63.
On my target device it is detected as CHS=490:8:32.

My solution was to specify the CHS when starting devb-eide.
$ devb-eide eide ioport=0x300,irq=3,geometry=8:490:32 disk translate=8:32

See the help for devb-eide for details.

After I did that, I followed the instructions given by fmartens in openqnx.com/PNphpBB2-viewtopic-t2882-.html

Worked like a charm.

Hope the following information is helpful to those of you who have problems with CF cards.

Another help : becom.sk/index.php?option=co … view&id=57

dloader /dev/hd0 /boot/sys/ipl-diskpc1

dloader /dev/hd0t79 /boot/sys/ipl-diskpc2

!?

ipl-diskpc1 comes from where? diskpc2 comes from where?

I JUST hit this problem and it is driving me insane. I have to deliver product and half my CF disks are useless. The other half work perfectly. Identical program loads. Identical images. CHS doesn’t work, devb-eide won’t mount anything with 16 heads. Tested the SAME command with 8 head geometry and everything was fine.

I am going to try the dloader method now.

I ship in 4 days.

respectfully
BJ

OK… those are the loaders that come with the OS.

In 6.3.0 I am seeing no ability to initialize ‘boot t79’ in the fdisk command.

devb-eide has two different ways of dealing with “old” and "new " disks. There’s an int13 switch “-8” (which is suggestive) and there’s a -O switch which does something with an “old” fixed offset loader.

There are also ipl-diskpc1-flop and diskpc2-flop variants that give us access to sub 8 GB partitions.

It seems to me that some combination of this stuff should work. How quickly I can test the permutations and get through this issue is the question.

One question that is still bothering me. If I run dinit, does it put a loader on automatically if I don’t specify one, or does it leave the one that was installed by fdisk?

I note that the failures are occuring after the image is loaded and the devb-eide is being called to mount the disk. This may be somewhat different from the previous issues. The startup script is being run from the image… but the disk is unmountable. !?

respectfully
BJ

Arrgghhh! Now we see that if we use the ipl-diskpc1-flop and ipl-diskpc2-flop we are forever prevented from using the ipl-diskpc on that disk, at least as far as QNX is concerned.

It also appears as though part of the problem is in devb-umass, as the usb driver seems to be fairly arbitrary about what CHS values it applies to the disks it mounts.

Which leads me to wonder if perhaps this is entirely an issue in this driver.

Grumble

Nope - Looks like its devb-eide that has the issue. The USB driver is able to access any flavor of CF disk, the eide driver is apparently incompetent when the CHS is reported as 63 sectors per track.

I am going to send one of these CF disks upwards to QNX and ask them to explain how it can be formatted in a USB mass storage device to boot in an eide system properly. Whatever the blazes it is doing, it is NOT mounting the disk. Nor do any optional switches seem to have the slightest effect on it except occasionally to make it even worse.

BJ