Well, I seriously doubt that. To my knowledge the 3G also has a utility 
flash, and the security issues seem to be very important to apple, as 
they not only prevent installing iPodLinux but only prevent you from 
cracking their music/games DRM scheme. They know what they are doing!

tof schrieb:
> 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
>
>   


_______________________________________________
Linux4nano-dev mailing list
[email protected]
https://mail.gna.org/listinfo/linux4nano-dev
http://www.linux4nano.org

Reply via email to