my idea is : on the 2G, there was a utility flash, because the chip was probably not able to load from main memory. redesign of the chip was launched, but far too slow to fit with the dev time of the nano. on the 3G, the modified chip was ready, and the boot flash skipped.
i doubt of security reasons being too important. the dissk manager within the bios will then map only a part to the usb, which is anyway the case because of bad blocks and so on. the only reason for what the biggest part of the firmware is within the partition visible to the PS is to assure easy update, probably... christoph MsTiFtS a écrit : > On the 2G there definitely is a utility flash. We can not tell for sure > whether the loader is in there, but as the size of the update image > roughly matches the size of the chip, I bet it is in there. > As far as I know the ARM has only a few KB of internal RAM and no ROM at > all. I think that's the same on the 3G, AFAIK there is also a utility flash. > > Don't ask me where the memory size difference comes from, but on my 2G > 8GB I have 7744MiB, that's about 8120MB, of visible flash. > I quickly flicked through your datasheet, but I didn't verify that these > chips are indeed used in the nanos. > So we have 4x 2048MiB + 64MiB redundant memory. I don't know whether the > ARM can access the redundant area, but hiding a boot loader in there > would be way too risky. > So we have 8192MiB of usable space. That's roughly 8590MB. So we have > about 470MB of hidden memory, 469762048 bytes to be exact, that's > exactly 448MiB. > I would guess that they are used as some kind of an additional > redundancy, as that's way too large to just hold a bootloader, and what > would the utility flash then be good for? > > tof wrote: > >> Hello boys (and girls) >> >> >> >> i m new here, but a lot of ENSEIRB people know me... >> >> >> My theory is : why could the loader from the 3G not be in the user flash ? >> >> imagine designing the nano 3G. You have to put away the the boot flash >> (obvious costs reasons) >> two solutions : >> >> 1. Rom in the SOC >> easy to realize if the chip maker has already this kind of solution. i >> did not check whether this exists on the nano2G controller type (if doc >> exists...) >> if not, this is a complete redesign of the chip, which could take a very >> long time, and huge effort, because 8 Mbit of flash is probably not so >> easy to add on a process that was not used for flash memory. >> mask rom is easier to do, but not very convenient. >> remember : such a project is time tough because of the very short dev time. >> >> 2. use the user FLASH >> in my opinion, a good option because getting rid of another memory. >> redesign of the chip perhaps necessary if it cannot already boot from >> this memory. >> >> the drawback of security is probably less important than the unit cost. >> >> >> i made some investigations on the flash size : >> >> http://insidetronics.blogspot.com/ >> >> It is a 8GByte chip, with four 2GByte dies stacked. In the 4Gbyte >> iphone version, the chip is the K9MCG08U1M, that is a 4GByte, dual die part. >> >> http://218.22.45.5/misc/Books/K9LAG08U0M_0.7.pdf >> here we see the organisation of the flash : >> 4* 0x100 000 *(0x800+0x40) Bytes = 0x200 000 000 B + 0x10 000 000 B >> (reserve for replacing bad blocks) >> >> >> the spec gives also the max bad block rate (new chip, some can appear >> later) : 4* 200(max bad blocks) * 256K (block size)= C8 * 4 * 0x40000 = >> C 800 000 Bytes >> >> conclusion : total usable bytes is 0x200 000 000 + 0x10 000 000 - >> 0xC800000 = 0x203 800 000 = 8 648 654 848 >> a little over 8G. assume apple rounded the use to 0x200 000 000 due to >> size reserved for the bad block table ;) >> >> on the other hand the visible size is a lot less: >> on my ipod 3G 8gig, fdisk -l gives : >> >> >>Disque /dev/sdc: 7952 Mo, 7952142336 octets >> >>217 heads, 32 sectors/track, 279 cylinders >> >>Units = cylindres of 6944 * 4096 = 28442624 bytes >> >> 7952142336 Bytes = 0x1D9 FC1 000, less than the flash size >> >> the difference is : 0x 26 03F 000 = 637 792 256 bytes >> >> Please correct me if i made some error or misinterpretation.... >> perhaps there is some space lost in the mounting process, etc... >> >> so nearly 600 meg are not in our view. this seems non negligible to me. >> >> >> so what next ? >> >> a good idea could be to check if such a difference exists on the 2G. if >> not, could be very good. (better to verify on the small size ones.) >> then its relatively easy to desolder and read the flash. >> >> >> Regards >> >> christoph(e) riehl >> >> >> _______________________________________________ >> Linux4nano-dev mailing list >> [email protected] >> https://mail.gna.org/listinfo/linux4nano-dev >> http://www.linux4nano.org >> >> >> > > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org > > _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
