ipod 5.5 rockbox bootloader screen

[makeprop]

hi all,

So I have a 5.5G here (V9M) with a 128gb FC1307A CF adaptor and cheapo adaptor to ZIF.
I manually restored it because iTunes wouldn't detect it nor gtkpod, but windows/linux detect it as a drive fine and show the folders and everything as well as read the partitions fine. When I restored it manually it boots and loads the iPod firmware fine.
The serial number matches the plate on the back
When I installed rockbox it went fine, except the very first install crashed when the install progres bar reached 100% from an error on no themes selected, but other subsequent attempts (of reformatting, started the iPod again and installing the bootloader) completed fine. A manual installation of the bootloader was also attempted but the same screen upon the first boot popped up.
I also tried the daily and developmental build.


It says:

Code: [Select]

Rockbox boot loader:
Version v4.0
IPOD Version: 0x000B0011
FC-1307 SD to CF Adaptor V1.3
No Partition Found
Insert USB cable or
etc etc
I tried also using the Tarkan iFlash adaptor thinking maybe it was my adaptor but this made no difference.
I will try again tomorrow with another CF adaptor. (both of these adpators worked on a mini 1G and a 4g as I noted in another post).

One thing i might try are different firmware versions - is this something that is worthwhile do you all think?
I will also attempt this on a known working original HDD. The ZIF hdd that was in here was dead.

[makeprop]

ok I removed the adaptor and moved it to another iPod 5.5 that is also a V9M that was booting fine on a (now dead) HDD rockbox, and it is giving me the same error.

So I'm not sure where to look here really.

[makeprop]

Ok looks like the iTunes thing was just rubbish apple software - i reverted back to 12.10.11 and uninstalled/cleared all itunes folders and now iTunes can read the iPod.
I suspect windows might have done some blockage on the software because its multiple attempts to read dead and slow drives might have set w10 to do some optimising?

Anyway at least I'm down to a narrower problem of rockbox on the 5G vids.

[makeprop]

I'm so sorry for wasting space on this forum - I just realised now the 2048 vs 512 byte sectorsn differnce when moving to the 5.5Gs. Will give that a crack now and see how I go.

[makeprop]

Ok so in working through: https://www.rockbox.org/wiki/IpodManualRestore.html
I'm running into system issues of not being able to use mformat properly. (it keeps complaining about argsize > 6)
And when using mkfs.vfat forcing it to set 2048 byte sector size it doesn't like being rockboxed (i run into the same error as above). Currently trying to get a newfs_msdos iteration working.

[makeprop]

So here's an update:
I tried a combination of CF adaptors with SD cards and here's what I found,
the method I used to restore was as per my previous pages:
1. partition using fdisk
2. format using mkfs.vfat -F 32

1. "Extreme CF Adaptor" (Type 2) With SJCAM 128gb uSD: Rockbox stuck at bootloader screen
2. "Extreme CF Adaptor" (Type 2) with Fanxiang 128gb SD: Rockbox stuck at bootloader screen
3. "Extreme CF Adaptor" (Type 2) with Sandisk 64gb Ultra uSD (old card from an old phone): Rockbox boots
4. "Extreme CF Adaptor" (Type 2) with Kingston Canvas Selcet Plus 256gb uSD (old card from an old phone): Rockbox boots

1. "Kak UDMA type 1 CF Adaptor" (Type 1) With SJCAM 128gb uSD: Rockbox stuck at bootloader screen
2. "Kak UDMA type 1 CF Adaptor" (Type 1) with Fanxiang 128gb SD: Rockbox stuck at bootloader screen
3. "Kak UDMA type 1 CF Adaptor" (Type 1) with Sandisk 64gb Ultra uSD (old card from an old phone): Rockbox boots
4. "Kak UDMA type 1 CF Adaptor" (Type 1) with Kingston Canvas Selcet Plus 256gb uSD (old card from an old phone): Rockbox boots

So the pattern here follows the SD/uSD cards in question. If I get the time I'll have a look at the mbrs and see if anything funny comes of them but I think we can safely say the factor here really is not the CF to ZIF adaptor, not the CF to SD adaptor, but the SD itself.

Whether or not I will be able to get those other SDs working is another question. I've tried forcing to format them to 512 byte-sectors but when interfaced via the Ipod it forces me to format them to 2048 bytes.
Some notes and observations:
1. When reading the fdisk output from the card directly it reports a byte-sector size of 512, but when reading it via an iPod fdisk records it as 2048 bytes
2. When using fdisk to setup the partitions, if it's via the ipod the start byte sector it suggests is 512, but if doing it directly via SD/CF the start byte sector is 2048 - which is very counter intuitive but might give a clue I haven't yet compared different SD cards to see if there's a pattern here, this is just for the fanxiang brand for now.
3. This is more a question than an observation: if i set up a CF 'offline' that is outside an ipod to have sda1 with the firmware written in and sda2 with the fat32 formatted partition and then throw it in the ipod it doesn't restore it as it would if the ipod is on so i'm guessing there's some other process running that might prevent the ipod from being 'flashed' offline.

I'm now trying to dd the working sandisk uSD over to a non working SJCAM uSD to see if that makes anything - i doubt it will but it'll be my first step into trying to map the differences across SDs.
A lot of my work here is really to try dispell the mysticism around so much of this. Behind the information online on reddit versus elsewhere.

[makeprop]

ok i dd'ed the 64gb sandisk to the 128 failing sjcam SD card - threw it in teh 5.5G and rockbox boots!

here's an fdisk dump as it's being read via the ipod through linux.

Code: [Select]

Disk /dev/sdb: 116.48 GiB, 125069950976 bytes, 61069312 sectors
Disk model: SD to CF Adapter
Units: sectors of 1 * 2048 = 2048 bytes
Sector size (logical/physical): 2048 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disklabel type: dos
Disk identifier: 0x63e0d1fd

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *      512    26111    25600   50M  0 Empty
/dev/sdb2       26112 31183871 31157760 59.4G  b W95 FAT32

A curious thing I noticed when I first put one of the non working cards on this distro it's dump on an fdisk was:

Code: [Select]

Disk /dev/sdb: 116.08 GiB, 124644229120 bytes, 60861440 sectors
Disk model: iPod           
Units: sectors of 1 * 2048 = 2048 bytes
Sector size (logical/physical): 2048 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disklabel type: dos
Disk identifier: 0x8817a9c6

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sdb1  *      2048    104447    102400   200M  0 Empty
/dev/sdb2       104448 243445759 243341312 464.1G  b W95 FAT32

Then after going through a normal procedure where I set it up via fdisk it goes back to being read as its normal size (128gb)

Code: [Select]

Disk /dev/sdb: 116.08 GiB, 124644229120 bytes, 60861440 sectors
Disk model: iPod           
Units: sectors of 1 * 2048 = 2048 bytes
Sector size (logical/physical): 2048 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disklabel type: dos
Disk identifier: 0x0f150533

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *      512    26111    25600   50M  0 Empty
/dev/sdb2       26112 60861439 60835328  116G  b W95 FAT32


You'll notice that the byte sector has NOT changed in either dump - yet fdisk read it the first time as a 512gb disk. In anycase, this suggests that  this is not an issue of SD card compatibility and one of configuration and how the SD card/various layers between it and the user configuring the card. That said I better actually test this boot and ensure that the data integrity remains on this particular SD.
** Update

Looks like I spoke too soon - i can copy files over but something is messing up majorly the file copy regularly crashes out and is unable to get passed a few tens of mb before windows gives up and tries again. Anyway we're somewhere at least!

[makeprop]

ok so I followed the guide in https://www.ott.net/mach/rockbox-on-ipod-video-without-itunes/ which looks like where the sticky came from.

Apologies for causing a such a fuss. 

Thank you all so much for everything as usual.

[Bilgus]

No worries keep up the good work!