S1mp3.org Forum

by **Crunchy** » Wed Oct 19, 2005 4:05 pm

Lately, we have been getting a lot of questions about decreased memory size.
(512MB -> 128MB, 256 -> 119, etc)

All we know is that it is related to a bad firmware.
So far, we have had a few recoveries due to a firmware upgrade.
before you go flashing random firmwares, and you totally kill your player, READ the original topic about this.

original memory issue topic

read it carefully, and if you decide to use the firmware mentioned there, MAKE A BACKUP! you can use wiRe's s1fwx program for that. (available on our main page)

by **ian_hawdon** » Sat Oct 22, 2005 1:26 pm

Can anyone donate their firmware to me for testing on this issue

ian <dot> hawdon <at> gmail <dot> com

Thank you

by **wladston** » Sun Oct 23, 2005 10:15 am

Daemon,

Thats very interesting !! Under linux, any partiotioning program can do the job!!! coool !!

users with memory program that use linux, can you go try to format the player there??

by **ian_hawdon** » Sun Oct 23, 2005 10:36 am

Me thinks the firmware is told to reserver some space for the frimware, i think it has been badly programmed and toled to reserver FAR too much!

Ill update you once i have finished the first test :-)

by **wladston** » Sun Oct 23, 2005 11:06 am

nice insight ,,,, makes lot of sense ....

or maybe there is a line that tells is to reserve space to firmware FROM xxxxx to the end of the nand ... and that's what may change from one bootloader to another ...

by **ian_hawdon** » Sun Oct 23, 2005 11:19 am

I dont think so, as when i killed my player, i flashed many firmwares, and they all showed as 512 mb (of cource when i formatted, it killed the player as the firmware wasn't working proberaly!) I think the BREC gets flashed into the 2085 chip.

by **wladston** » Sun Oct 23, 2005 11:58 am

agreeded - the boot loader gets written on the atj2085 - but the rest of the firmware is written on a separated nand space ... - the theory - this space is getting oversized - and i think it's bacause the brec says : "make separeted space from xxxxx to the end" - and that xxxx is not the correct one .....

it's known that the flashing process does not change the bloader on the most of the cases .... that's why me, you and lots of people still have the full memory working i think ....

when i tried to flash coder_tex's firmware, the updade prog didn't let me do it - he said it was an "invalid firmware file" - possibly because it had a different bloader ...

by **ian_hawdon** » Sun Oct 23, 2005 2:41 pm

Right i was wrong :oops:

It MUST be in the BREC then.

Ill try another idea

Copy the firmware file to a different set of BRECs

by **ian_hawdon** » Sun Oct 23, 2005 3:27 pm

Well, that shows that the BREC is getting flashed, that brec was for my OLED 128x64 pixel screen, ill try with a diffrent brec for a 128x32 screen next.

by **ian_hawdon** » Sun Oct 23, 2005 4:28 pm

ok, just flash your orignal firmware back to the player

by **wladston** » Sun Oct 23, 2005 4:33 pm

the brec got flashed this time, but it's not usually flashed ....

What about we toghether reverse the flashing process ??

Up to now, this knowdlege is limited to wire... why don't we discover it, since he does not want to say it ?

by **Crunchy** » Thu Oct 27, 2005 2:49 pm

strange, really.

I can imagine it starts to overwrite from the front once you get over the limit*
but that it just passes al checks is downright strange...

*
Why it starts from the beginning when you cross the max limit (usually)
let's say we have a memory controller chip with three places of adress space.
that controller can handle 1000 adress spaces (we're using decimal system, for easyness, places are 000 to 999)
Now, what happens if the crazy firmware tries to write to spot 1020?
the controller recieves the data, and stores this in it's adress buffer.
BUT, that buffer is only three places long!
so what appears in the buffer is: "020", so the data is written to place 20 in the memory.
(This is why buffer overflows are so dangerous: if spot 20 would happen to be executable code, you can get a virus from an mp3 file (data) into an executable location, and then you run it.)

by **JedOi** » Sat Nov 05, 2005 9:41 am

Nice post ctren, that may indeed spur one of the gurus into a new train of thought

by **ian_hawdon** » Sat Nov 05, 2005 4:03 pm

I have noticed that the memory problem seems to only happen with hynex chips

has ANYONE had the problem with samsung chips?

by **JedOi** » Wed Nov 16, 2005 2:17 pm

Ok, well I haven't had any memory size issues with my IItronics iMP-11 512MB player but i have been scouring the web for whatever I could find which might help out with the major memory-loss issue that so many people are having ...

Whilst on my travels through the information-super-ring-road ... I came across a couple of things ...

1: a snippet from a tech-support site at -> http://www.techspot.com which said ...

... you will see we've abandoned FORMAT from XP. It seems to foul out the partition size and thus reduce the usable space. Concensus is to use ANY other system(Mac,Linux,Win/98se), recreate the partition, and format to FAT

... quite what they used to recreate the partition I don't know cos with my player the only partitioning the supplied software can do is to create an encrypted partition by presumably splitting the existing partition but with no FDISK type functionality to delete and recreate a new or primary partition. There were a few other possibilites listed in this -> http://www.techspot.com/vb/topic17341.html thread over there though which might point someone in the right direction over here

2: a "universal" usb drive formatting tool which according to quite a few sources reputedly works with ALL usb flash devices that they've tried it on ... it's the "HP USB Disk Storage Format Tool" which can be found here -> http://h18007.www1.hp.com/support/files/hpcpqdt/us/download/20306.html if anyone feels so inclined to try it.

I used it to perform a quick and a normal format on my player with no ill effects whatsoever, BUT - don't blame me if you use it and your player bursts into flames or sumfink

... and just in case this is of any use at all, here's some info relating to the disk structure and format properties of my player as SiSoft Sandra saw it ...

SiSoftware Sandra

Logical Drive
Sectors per Cluster : 16
Bytes Per Sector : 512 byte(s)
Cluster Size : 8kB
Total Clusters : 63688
Free Clusters : 63688

Physical Disk
Cylinders : 63
Heads : 255
Sectors per Track : 63
Bytes Per Sector : 512 byte(s)

might be interesting to see if anyone with the memory issue has anything significantly different like huge cluster sizes or whatever ...

Ya never know, this little post might help or inspire someone

S1mp3.org Forum

decreased Player memory

decreased Player memory

Who is online