As far as I know the Armor and weapons DLC are supposed to be in Gorhart (I think) in a treasure chest outside one of the buildings. From what I read in the KOA: Reckoning forum the freezing problem is caused when you have the games on demand version and the season online pass house of valor dlc. If it is not there maybe it spawns somewhere else. The solution seems to be deleting the house of valor DLC. Descargar traduccion espanol kingdoms of amalur reckoning dlc 1.

$ smbusb_comm -a 16 -c 71 -w 0x0214 $ smbusb_scan -w 0x16 -b 0x70 ------------------------------------ smbusb_scan ------------------------------------ SMBusb Firmware Version: 1.0.0 Scanning for command writability. Scan range: 70 - ff Skipping: None ------------------------------------ [71] ACK, Byte writable, Word writable [72] ACK [73] ACK So this actually unlocks an extra command which disappears again when an SBS command is issued (or when doing a full command scan starting from 0.) The command however is not writable. Reading it returns. Ok, nothing straightforward.

No obvious BOOT pin as one would expect with a device that's not meant to be tampered with. But maybe pulling some pin high or low during reset will get me somewhere. After the first pass no, not really. So maybe we have to set multiple pins into multiple states for it to work.

Sanyo Service Menu. You can use the Sanyo service menu, for such things as resetting the digital tuner, a total factory reset and enabling/disabling hotel mode. In this mode you must be careful as you can cause irreparable damage to your set. Unplug the power cable.

Or maybe there's no such combination at all. How about I try to abuse N/C pins instead. I have no logical explanation as to why I came to this decision. Maybe I saw a presentation somewhere about blackbox chips and N/C pins years and years and years ago but I could just be imagining things. Either way, about 5 minutes of poking at PIN #28 with a resistor connected to 3.3v in hand and triggering RESET at random intervals while running a continuous command scan. $ smbusb_scan -w 0x16 ------------------------------------ smbusb_scan ------------------------------------ SMBusb Firmware Version: 1.0.1 Scanning for command writability.

Scan range: 00 - ff Skipping: None ------------------------------------ [0] ACK, Byte writable, Word writable, Block writable [1] ACK [2] ACK [3] ACK [4] ACK, Byte writable, Word writable, Block writable [5] ACK, Byte writable, Word writable, Block writable [6] ACK, Byte writable, Word writable [7] ACK, Byte writable, Word writable [8] ACK [9] ACK, Byte writable, Word writable [a] ACK, Byte writable, Word writable Wow, that worked? Let's just reset for now.

$ smbusb_sbsreport SMBusb Firmware Version: 1.0.1 ------------------------------------------------- Manufacturer Name: ERROR Device Name: ERROR Device Chemistry: ERROR Serial Number: Manufacture Date: 1980.00.00 Uh-oh. Well that's not good!

It seems we're stuck in the Boot ROM. Is the chip fried? It's at this point that I coded up the flash tool to try and read the flash contents. (I wasn't really bothered by the chip dying as this was one of 2 sacrificial controller boards I kept just for messing around with.) And the results?

Apparently we can corrupt (ideally just) the first couple of blocks of flash if we bully PIN #28 while the chip is trying to start up. The good news though?

(If we're lucky) We get 99% of the firmware, and thanks to we have a (zip) for it. Did messing with Pin #28 even have an effect? Could it just have been the erratic resetting of the chip that triggered the malfunction? Did I short VCELL+ to Pin28 while messing about? Was there high voltage on VCELL+?

Was it just ESD? But I did manage to reproduce the result on another chip using the same procedure. So when in doubt and you have nothing to lose, act like a caveman, I guess? The only good thing about this method is that even if you have 0 knowledge about whether there even IS a method for entering the Boot ROM in the firmware let alone what it is there's still a high chance that you'll get in. How much of the firmware survives is another question. Disassembly A couple of hours of staring at unfamiliar assembly code later, here are the relevant parts for entering the Boot ROM with annotations.

Cmd_handle_70: *snip* move r3, access_level and r3, # 0x40 cmp r3, # 0; don't even bother if access jeq cmd_handle_71; flag 0x40 is missing *snip* calls smbSlaveRecvWord move r2, (i3, 0x19); smb_word_LSB move r3, (i3, 0x18); smb_word_MSB cmp r3, # 5 jne wrong_pass cmp r2, # 0x17; is 70 0517? Jne wrong_pass *snip* (prepare leaving the firmware safely) calls bootrom_execute So now we know pretty much what we need to do. Send 0x0214 to 0x71 2.??? Send 0x0517 to 0x70 4.