Tegra2 dev tools and "read-only mode"

[joeyhewitt]

It looks like most of you with "read-only mode" have either gotten it replaced or given up (or are trying Nocturnal_50's method). But for anyone still interesting in bashing their head against this wall:

I got a Tegra2 OS Image from http://developer.nvidia.com/mobile/tegra-development-kit-updates . The bundled nvflash seems to have some things not in what's commonly circulated around here (newer?). Here's the stuff that stood out to me.

$ ./nvflash --help
Nvflash v1.2.57794 started

--updatebct command usage ->
nvflash --bct <bct> --updatebct <bctsection> --bl <bootloader> --go
-----------------------------------------------------------------------
used to update some section of system bct(bctsection) from bct specified
this command is run in 3pserver. As of now, bctsection can be SDRAM which
updates SdramParams and NumSdramSets field of bct, DEVPARAM updates
DevParams, DevType and NumParamSets fields and BOOTDEVINFO updates
BlockSizeLog2, PageSizeLog2 and PartitionSize fields of system bct
-----------------------------------------------------------------------

--setblhash command usage ->
nvflash --blob <blob> --setblhash <bct> --configfile <cfg> --download N
<filename> --bl <bootloader> --go (in odm secure mode)
-----------------------------------------------------------------------
used to download bootloader in secure mode into already flashed device
it updates the hash value of updated bootloader to be downloaded, from
encrypted bct got from sbktool, into system bct in miniloader
-----------------------------------------------------------------------

--dumpbit command usage ->
nvflash --dumpbit --bl <bootloader> --go
-----------------------------------------------------------------------
used to display the bit table read from device in text form on user
terminal. Also gives info about bct and various bootloaders present in
media, normally used for debugging cold boot failures
-----------------------------------------------------------------------

--obliterate command usage ->
nvflash --configfile <cfg> --obliterate --bl <bootloader> --go
-----------------------------------------------------------------------
used to erase all partitions and bad blocks in already flashed device
using partition info from configuration file cfg used in nvflash earlier
-----------------------------------------------------------------------

--delete_all command usage ->
nvflash --delete_all --bl <bootloader> --go 
-----------------------------------------------------------------------
used to delete all existing partitions on already flashed device
-----------------------------------------------------------------------

--dumpbit gives a bunch of boring info (I can post if anyone's interested), but says it can't find a BCT. The other versions of nvflash can dump a BCT that matches the one in the restore packages, so I think it's really there. I'm thinking the offset has changed, so this version doesn't find the BCT. (And --setbct seems to hang, maybe because of errors in trying to write it out.) Unfortunately, this seems to prevent other commands from working. --format_all says "partition table is required for this command" (earlier nvflash finds a partition table), --delete_all seems to hang indefinitely, and --obliterate fails silently.

I was most interested in obliterate, since "read-only" could conceivably be caused by some sort of "bad block" marker. If I do manage to "obliterate" my device so there's really nothing on it, will APX mode still work so I can use nvflash?

Any ideas?

 

[giveen]

And why could you keep this in the same thread? And why isn't this in a general section its not related to Android development.

 

[TheManii]

And why could you keep this in the same thread? And why isn't this in a general section its not related to Android development.

Yes, it should have been kept in the prev thread, it's too similar.

If it had a solution it belongs in dev, but it's just questions and research so I'd also agree.

(Note: I am not a forum mod, just expressing my opinion)

 

[giveen]

There already was an entire long thread about the read-only error in the general section, there wasn't a need for TWO threads just discussing possible ideas. AND from the same person.

 

[joeyhewitt]

OK, I guess I don't have the same opinions about forum organization, I'm not really into any of xda dev scenes. Mods can delete/move this thread, I don't care, but I can't see a way to do so from my interface.

And why isn't this in a general section its not related to Android development.

Yeah, it's not like people are using nvflash to do Android development.

There already was an entire long thread about the read-only error in the general section, there wasn't a need for TWO threads just discussing possible ideas

I thought it warranted another thread because it's another approach, and two specifically-titled threads seemed better than one giant "read-only" thread. I thought it would get lost in the sea of "oh hai guys I had read-only error too I just flipped the switch on my SD card and it started working" and "sent it to dell for replacement" and "anyone fix this yet?". But apparently people like threads dozens of pages long with wandering topics and low signal-to-noise ratio, I'll keep that in mind for the future.