@KdL: I got a working SD card img that was created on a Windows machine using your 'sdcreate.cmd' script.
I have seen that:
1- It has a 'W95 FAT16 (LBA)' partition.
2- This partition has a VFAT filesystem.
As simple as that.
So the core is doing what it's supposed to but, but damn Windows 'format fs=fat' is doing something different to the partition than GNU/Linux 'mkfs.vfat -F 16' is doing.
So, WHAT is the difference bewteen doing 'format fs=fat' on Windows and doing 'mkfs.vfat -F 16' on GNU/Linux?? Do you guys PLEASE know??
@KdL: Does the core expect something special that could be done only by Windows 'format fs=fat' command but not by GNU/Linux 'mkfs.vfat -F 16'?? Any kind of signature, etc??
@KdL: I got a working SD card img that was created on a Windows machine using your 'sdcreate.cmd' script.
I have seen that:
1- It has a 'W95 FAT16 (LBA)' partition.
2- This partition has a VFAT filesystem.
As simple as that.
So the core is doing what it's supposed to but, but damn Windows 'format fs=fat' is doing something different to the partition than GNU/Linux 'mkfs.vfat -F 16' is doing.
So, WHAT is the difference bewteen doing 'format fs=fat' on Windows and doing 'mkfs.vfat -F 16' on GNU/Linux?? Do you guys PLEASE know??
@KdL: Does the core expect something special that could be done only by Windows 'format fs=fat' command but not by GNU/Linux 'mkfs.vfat -F 16'?? Any kind of signature, etc??
The code of IPL-ROM requires:
- 'FAT' marker;
- MBR to find the primary partition;
- proper SDBIOS with 'AB' marker (as 1st file).
; search 'FAT' checksum ld hl, $C000 ; buffer ld bc, $0080 loop_f: ld a, 'F' ; 'F' cpir or a jr nz, exit_fat test_fat: add a, (hl) ; 'A' inc hl add a, (hl) ; 'T' sub 'F' + 'A' + 'T' dec hl jr nz, loop_f ; yes marker 'FAT' ld c, b ; ld c, $00 ld e, c ; ld de, $0000 ld d, c scf ; no 'FAT' exit_fat: jr c, find_ab ; CY = 1 => yes 'FAT' ;---------------------------------------- ; test MBR, search partition ld b, $04 ; partitions to find ld hl, $C000 + $01C6 ; sector offset find_part: push hl ld e, (hl) inc hl ld d, (hl) inc hl ld c, (hl) ld a, c or d or e pop hl jr nz,exit_mbr ; yes partition ld de, $0010 add hl, de djnz find_part ; no partition scf ; CY = 1 error ;---------------------------------------- exit_mbr: jr c, load_epcs ; no partition ; yes partition push de push bc ld b, $01 ; 1 sector ld hl, $C000 ; DAT buffer call read_sd ; PBR read pop bc pop de jr nc, find_ab ; CY = 1 => error
@KdL: I don't see anything that shouldn't work when preparing the card on GNU/Linux.
Do you use GNU/Linux or could you try to get an SD prepared on that system, please?
@gaula82: check the id of the partition that you created with fdisk -l. (https://www.win.tue.nl/~aeb/partitions/partition_types-1.html), is it 06? And is it 0e for the image file created from Windows?
@sdsnatcher73: According to fdisk, the working SD image's FAT16 partition is 'e', which equals to W95 FAT16 (LBA). This img was created on a Windows computer, and is the one whose creation process I am trying to replicate on GNU/Linux.
So on my experiments I always create partition types with the exact same ID, 'e'. I think this is alright.
On today's experiments, I have found that if I take an SD which works (I mean: an SD where I just dumped the working image using dd) and delete every file on it, and then I copy OCM-BIOS.DAT to the card again, it stops working. In other words, re-copying OCM-BIOS.DAT from Linux "breaks" something, so it's not the partition type or filesystem, it seems. OCM-BIOS.DAT is still the first file on disk after I re-copy it, because it's in fact the only file on disk.
This is crazy...
Maybe Linux has different rules for long file name creation. If it creates a vFAT long file name for OCM-BIOS.DAT (maybe because it thinks the - is not allowed in original FAT) that may screw things up. You could dd the block device to an image again and have a look at the actual FAT entry. If there is a LFN the FAT will have an 8.3 entry like OCM-BI~1.DAT...
@sdsnatcher73: I have imaged a non-working setup (where I had simply copied OCM-BIOS.DAT to the card using Linux 'cp' command), then mounted it on dosbox using imgmount, and copied OCM-BIOS.DAT to it, then dumped the image again to SD. Then it works. So Linux 'cp' seems to the the "problem"!
This card was all setup from Linux (partition table creation, partition creation, partition filesystem setup) and simply copying the file from DOS instead of Linux made it work.
I have hex-edited both a working and a non-working image (on the working one I had copied OCM-BIOS.DAT using the copy command on dosbox, and on the non-working image I had copied OCM-BIOS.DAT using cp from Linux), and it seems both have a FAT entry called "OCM-BIOSDAT". Same name in both cases.
So I believe it's about how sectors are writen by DOS's copy and how they are writen by Linux's cp.
But what the different actually is, or HOW to replicate DOS's copy behaviour on Linux, I don't know yet.
Any ideas?
Can you try a fsck on the non-working setup? I'd like to know if it says that the "dirty" bit is set.
All does seem a bit weird, FAT seems correct in both cases! You could try mcopy from mtools, not sure if that works on sd cards (it’s main purpose is for floppy disks), but worth a try I guess...
@Pentarou, this is what fsck has to say:
manuel@vader:~$ sudo fsck.fat /dev/sdb1 fsck.fat 4.1 (2017-01-24) /dev/sdb1: 1 files, 32/61870 clusters
@sdsnatcher73: I tried mcopy and it does not work either. This needs KdL to test himself and see why the bootloader does not read the file when copied from a non-Windows system.