Skip to contentSkip to conversation

DoC2000 288MiB / grub clobbered after partitioning

DISCUSSION R/db 2 participants 2 messages Dec 3, 2002 – Dec 5, 2002 Memory technology devices (MTD)

lore
Share & tools
lore

R/db

author
#0 lore raw

Thanks everyone for all the good stuff.
Mark (Meade), could you add a note into
your howto about dropping the right-most
zero when feeding the win: param to dformat?
(It was confusing to me, especially after
reading the M-Sys documentation)

Just a quick mention of what I'm encountering.
I'm still working at it and gathering info but
thought I'd throw this out in case someone else
has any ideas and because I'm pretty certain
so far of what is happening ( = many attempts
all starting from scratch/known pieces yielding
the same results). Short form: partitioning
the nftla clobbers grub.

Basics are Mark Meade's 10 Oct 2002 ss 1:
build grub accordingly
dformat /WIN:D000 /BDKF0:GRUB_F~1 shutdown the machine
power up machine
tell bios to netboot
see grub> (most everything prior scrolled
into the bitbucket)
shutdown the machine
power up machine
tell bios to boot from hda1
boot linux
Cool so far. At this point though I can't find
a partion table for /dev/nftla (hence can't mount /dev/nftla1). So I run fdisk (see below), it sez its going to make a new partition table (cool) then I make some partitions/write them to the DoC, mke2fs them, mount them, copy files to them, unmount, mount again, reboot, whatever.

Partitions are still there, fdisk has a quirk
where it will report the proper partitions and
if I don't spec the dev (nftla) it reports all
the partions on all devices (normal) and the
message that the nftla doesn't have a valid
table (still prints those partitions). Data is
still valid within those partitions.

GRUB at this point is hosed. Rebooting (selecting netboot in bios), the DoC grabs control then the machine reboots, ad infinitum.

Whatever. I'm still gathering info.

specifics, if you're still reading:
DoC2000/288MiB
kernel 2.4.19+usagi(IPv6)+kerneli(crypto)+mtd(cvs,
various dates (recent))
M-Sys Utils 5.1.4 (tffs_5.1.4_DOS_TOOLS.zip,late Nov 2002) GRUB from cvs (29 Nov 2002 + other recent ones)+patch
from Mark Meade's 9 Oct 2002 email on the mtd list.
SBC: MyComp.tw TH-512, Transmeta Crusoe TM5400/600MHz,
~388Megs RAM, VIA 686A/B chipset

syslog says:
DiskOnChip 2000 found at address 0xD0000
Flash chip found: Manufacturer ID: EC, Chip ID: 75 (Samsung KM29U256T)
9 flash chips found. Total DiskOnChip size: 288 MiB
NFTL: UnitSizeFactor 0x00 detected. This violates the spec but we think we know what it means...
nftla: nftla1 nftla2
Ignoring DiskOnChip 2000 at 0xD2000 - already configured
Ignoring DiskOnChip 2000 at 0xD4000 - already configured
Ignoring DiskOnChip 2000 at 0xD6000 - already configured

Cannot calculate an NFTL geometry to match size of 0x8d040 Using C:1002 H:16 S:36 (== 0x8ce80 sects)

fdisk -l /dev/nftla says
Disk /dev/nftla: 16 heads, 36 sectors, 1002 cylinders Units = cylinders of 576 * 512 bytes

     Device Boot    Start       End    Blocks   Id  System
/dev/nftla1             1       171     49230   83  Linux
/dev/nftla2           172      1002    239328   83  Linux

(partition two was just a place-holder and will get rm'd then three more partitions will take its place)

Interestingly, fdisk -l without specifiying the device gives all the normal info PLUS the message:
Disk /dev/nftla doesn't contain a valid partition table

#1 lore raw
Quoted 6 lines · R/db

Thanks everyone for all the good stuff.
Mark (Meade), could you add a note into
your howto about dropping the right-most
zero when feeding the win: param to dformat?
(It was confusing to me, especially after
reading the M-Sys documentation)

Sure. I'm in the process of updating it now.

Quoted 2 lines

Cannot calculate an NFTL geometry to match size of 0x8d040 Using C:1002 H:16 S:36 (== 0x8ce80 sects)

Have you had any more luck with your geometry problem? I've seen this before, but I wasn't able to figure out exactly what was going on. I haven't seen it lately with my 32MB DoC 2000.

Does it happen if you don't install Grub? Just use DFORMAT without the BDKF option. fdisk should show the one FAT partition created by dformat.

Maybe specifying some extra room for Grub (/BDKL0:<size> option to DFORMAT)
might help -- make the total size divisible by 8k or 16k? I'm not sure
about this, it's just a guess.

Let me know if you do get to the bottom of this, and I'll update the instructions accordingly.