Installing rockbox on HiFiMAN HM-603 Slim - boot hangs

[Infine]

I'm installing rockbox on the HM-603 Slim 4GB player as per the wiki page http://www.rockbox.org/wiki/HifimanPort

Ater rebooting I get a fast rockbox splash followed by the loading screen with
Loading rockbox.rkw
Loading OK
and then nothing - blank white screen. Device apparently hangs - only reset button works.

I can still boot it into the original firmware by pressing any button with the power switch which gets me to
Loading BASE.RKW
Loading OK
Executing
And then the default firmware interface.

I can still rollback to the original firmware, I can still use the original firmware with the rockbox bootloader, but the rockbox itself hangs at boot.

I used both manual and mkrk methods to no avail.
SD card is 32GB formatted using mkfs.vfat on device (that is, without a partition table) and is otherwise visible to the player.

Also during firmware upgrade (both installing rockbox and rolling back to OF) it says it's upgrading HM-801 (probably just a generic message? image file is HM-603.IMG).

What am I doing wrong?

UPDATE:

I got a hold on another (16GB) SD card from a camera and tried booting from it.
This time I managed to see Executing, and the screen did not refresh and go white, but it still hung.

I repartitioned the new SD card making a 8GB fat32 partition, and this time the screen goes white, but pressing any button shuts down the player.

I've also tried cloning git version and building with various developer options (small c build, logf build), but it's the same. Apart from the logf build - it shuts down immediately without interaction.
Though I didn't try to build a bootloader, because I'm afraid to brick the device.

EDIT:

It sometimes goes blank white and sometimes gets stuck at executing with the same configuration.

[Infine]

Okay, update.

I took a peek inside and found a single Hynix H57V2562GTR-60C memory chip for RAM which is different from photos of various HM-60x boards I've found in google.

I think datasheet says it's supposed to be 256Mb (which should be 32MB?), but I'm not sure if I'm understanding the datasheet correctly.
Regardless, changing the configure script to 32MB target RAM produced nothing, BUT.

I was able to successfully build and run a 4MB build.

2MB is too low to build, 8MB is white screen, but 4MB build consistently boots, navigates and plays. I'm a bit confused.

[wodz]

That pretty much looks like dram controller misconfiguration which is odd considering that we relay on init performed by original first stage bootloader and don't touch it. There are two things you can try (depending how skilled you are):
1) Build hwstub for rk27xx (utils/hwstub/stub/rk27xx), convert binary to rkw format (according to convert_to_rkw.txt) and copy it as rockbox.rkw (this will preserve possibility to boot original firmware). Then you can boot this debug stub and poke ram and ram config with help of PC side utilities (/utils/hwstub/tools/hwstub_shell and /utils/regtools/qeditor). This may give a clue whats wrong.
2) Disassemble BASE.RKW to see if it performs dram controller init (previous versions didn't do that)

You can try to catch me on IRC if you need assistance.

[Infine]

That pretty much looks like dram controller misconfiguration which is odd considering that we relay on init performed by original first stage bootloader and don't touch it. There are two things you can try (depending how skilled you are):
1) Build hwstub for rk27xx (utils/hwstub/stub/rk27xx), convert binary to rkw format (according to convert_to_rkw.txt) and copy it as rockbox.rkw (this will preserve possibility to boot original firmware). Then you can boot this debug stub and poke ram and ram config with help of PC side utilities (/utils/hwstub/tools/hwstub_shell and /utils/regtools/qeditor). This may give a clue whats wrong.
2) Disassemble BASE.RKW to see if it performs dram controller init (previous versions didn't do that)

You can try to catch me on IRC if you need assistance.

Considering the second approach on the first glance requires experience with disassembling stuff, knowledge of ARM assembler and possibly an rk2706 datasheet, I'm probably better off with the first one (I assume it's a low-level shell over USB?). Not to mention, the firmware I've tried it with is .06 version which is out there since forever (circa 2012?) and apparently fits non-slim 603 version just fine.

Will try the next week.

[wodz]

Yes disassembling BASE.RKW requires knowledge about format itself and, arm assembler and rk27xx memory map. Could you provide me the link to this firmware archive (or provide me BASE.RKW)? I may take a look, I've dissasembled a few base images for rk27xx hardware so it should be pretty easy to spot the difference.

hwstub is to tier thing. It is small firmware running on device which sole purpose is to communicate over usb with dedicated shell (hwstub_shell). It allows to read and write arbitrary memory location on device.

[Infine]

Firmware was taken from the rockbox wiki page for hifiman port: http://down.hifiman.cn/HM-603_SFW_HCZ_V0.06_20120618.zip
There's a newer version: http://down.hifiman.cn/HM-603_SFW_HCZ_V0.07_20130109_.rar, but the one above works fine.

I assume one could pick up knowledge about rkw format from the rkw-loader code, and memory map from the rk27xx header(?), but I've got no idea where to look for the DRAM init in the code and how it should look apart from probably being somewhere in the beginning.

PS: I've found something rk2706 SDKish on some chinese forum ('ish because I obviously don't know chinese). It has some sources for something something including hw_memmap.h for that matter.

[wodz]

Quick look at V0.06 and V0.07 shows no difference in DRAM init routine. I don't have the hardware so I can only guide you where to look.

[mortalis]

we relay on init performed by original first stage bootloader and don't touch it.

That's not quite true,  we tweak sdram settings in sytem_init() a little bit:

void system_init(void)
{
....
#ifndef BOOTLOADER
    /* SDRAM tweaks */
    MCSDR_MODE = (2<<4)|3;         /* CAS=2, burst=8 */
    MCSDR_T_REF = (125*100) >> 3;  /* 125/8 = 15.625 autorefresh interval */
    MCSDR_T_RFC = (64*100) / 1000; /* autorefresh period */
    MCSDR_T_RP = 1;                /* precharge period */
    MCSDR_T_RCD = 1;               /* active to RD/WR delay */

Although these tweaks looks correct, I think it worth to try without these lines.