PRS-T2 To rupor: Enable ADB

[ebmr]

Would you mind telling the commands necessary to create both new

• u-boot RAMDisk Image
• Boot environment

as you did in your enable-adb, for example. (PM is ok.)

It would be a time saver to me.

Thanks in advance.

EDIT: Just the commands to create newly after I've made changes.

[porkupan]

Making a ramdisk image:

# find . -print | cpio -o -H newc | gzip -v9 > ../ramdisk-adb.gz
# mkimage -A ARM -O Linux -T ramdisk -C gzip -a 0x70308000 -e 0x70308000 -n "Normal Rootfs" -d ramdisk-adb.gz ramdisk-adb.uimg

Unpacking and extracting a ramdisk image:
(for PRS-T2):

# dd if=T2_NAND_dump_1.0.03.09110.dd of=ramdisk.uimg bs=1024 skip=5120 count=1024
# dd if=T2_NAND_dump_1.0.03.09110.dd of=nboote.bin bs=1024 skip=15360 count=128

# mkdir ramdisk
# dd if=uramdisk.img of=ramdisk.gz bs=64 skip=1
2834+1 records in
2834+1 records out
181410 bytes (181 kB) copied, 0.0168186 s, 10.8 MB/s
# cd ramdisk
# gunzip -c ../ramdisk.gz | cpio -i -v

[ebmr]

Originally Posted by porkupan

Making a ramdisk image:

# mkimage -A ARM -O Linux -T ramdisk -C gzip -a 0x70308000 -e 0x70308000 -n "Normal Rootfs" -d ramdisk-adb.gz ramdisk-adb.uimg

Thanks a lot. (Nice to read of you again, btw.)

Hopefully you don't mind some further questions:

• Why 0x70308000? Isn't 0x00500000 the entry point? (OTOH, the end of the reader partition (mmcblk2p4) would have to be 0x74C08000.)

Is there a tool to make a new Boot Env nboote.bin? If not:

• The first 4 bytes are a checksum? Calculated by what method?
• What is the meaning of the changed parameter 0x290 (from 0x1F4) in

  mmc read 2 ${loadaddr_ramdisk} 0x2800 0x290

If there is documentation available somewhere, a link as reply would be appreciated as well.

[porkupan]

Originally Posted by ebmr

Why 0x70308000? Isn't 0x00500000 the entry point? (OTOH, the end of the reader partition (mmcblk2p4) would have to be 0x74C08000.)

Well, this is the address in RAM, so the flash offset doesn't matter. Why that particular address? I dumped the parameters of the original ramdisk image, and copied them.

Is there a tool to make a new Boot Env nboote.bin? If not:

• The first 4 bytes are a checksum? Calculated by what method?
• What is the meaning of the changed parameter 0x290 (from 0x1F4) in

  mmc read 2 ${loadaddr_ramdisk} 0x2800 0x290

If there is documentation available somewhere, a link as reply would be appreciated as well.

I modified u-boot's fw_printenv/fw_setenv to allow working on a regular disk file (as opposed to going directly into the flash, which is what's normally done). Not sure the exact format of the environmental block, but you are probably right about the checksum. See the sources of u-boot to be sure. The environmental parameter that I changed had to do with length of the flash ramdisk image to be loaded into the RAM. Sony had specified very tight 0x1F4 blocks, we increased it to 0x290, since we added some files into the ramdisk, and it became bigger.

[rupor]

I was not able to use porkupan's method (modified fw_setenv) - so out of curiosity I simply used hex editor on my windows computer and verified that result is the same as he provided Second number (if I remember correctly) is number of blocks to be loaded and I believe checksum is CRC32 - I googled this.

[ebmr]

porkupan, rupor .

This information is what I was looking for.

[ebmr]

Originally Posted by porkupan

Well, this is the address in RAM, so the flash offset doesn't matter. Why that particular address? I dumped the parameters of the original ramdisk image, and copied them.

I see (and should have worked it out for myself). I was thinking too much about real addresses and forgetting about the mmu.

BTW, it is interesting that the compression type header entry of the original ramdisk is 0 (no compression) where it should be 1 (gzip) since, in fact, it is gzip compressed.

[ebmr]

Originally Posted by porkupan

Sony had specified very tight 0x1F4 blocks, we increased it to 0x290, since we added some files into the ramdisk, and it became bigger.

Is there a special reason for the extra 15 Blocks? 0x281 would have been enough.

Sony probably had added 10 extra blocks so that they can increase the rootfs image without updating the u-boot environment data, but if anyone of us provides a new rootfs image he must provide a new and appropriate u-boot environment anyway, because he doesn't know what the current u-boot environment looks like. So there seems no point in adding extra blocks.