How to dump the bootloader from UA65ES8000

[E3V3A]

If Kernel command line has anything to say, it's probably:

LX_MEM=0x40200000,0x14900000
LX_MEM2=0xA4E00000,0xB200000
EMAC_MEM=0x40000000,0x100000

Code: Select all

shell>cat /proc/iomem
1f222600-1f222dff : mstar_mci.0
  1f222600-1f222dff : mstar_mci

40200000-54afffff : System RAM
  40225000-404f6fff : Kernel text
  404f8000-4057da1b : Kernel data
a4e00000-afffffff : System RAM

I'll see what I can dig up.

[xorloser]

just dump that mem range i wrote in previous msgs and we'll know for sure. is your problem that you cannot build the source for viewmem?

[E3V3A]

Hi! No the problem is that I have two jobs and it takes a bit of time to get back to where I were each time...

However, I compiled and ran viewmem and it crashed my TV! I don't know what the problem is. I think they might have enabled some memory protection. I've had problems when reading memory every time. The first time was using the busybox "devmem". I can usually read one word, but when I try to read again, it dies, by either locking up the shell, or resetting TV. Very annoying, and I remain clueless... (Anyone else have or have heard of these problems?) Most funny of all, trying to read from that location, kills my TV, while other locations does nothing! What is the function of that location?

[EDIT] I think the problem have something to do with "viewmem" using /dev/mem, perhaps using /dev/kmem could work? Or if there are other "memory" devices to use? The strange thing is that my Tv has both...under /dev. Anyone know how to understand this?

Anyway, another thing about the Smart Report. Comparing yours to mine, I see that in the "ECC Uncorrectable Errors Location Physical Block Address", the first 24 addresses are different, while the last 36 are exactly the same... I find this funny.

Code: Select all

0000:0019
0000:0000
0000:008a
0000:0039
0000:0000
0000:0062
30ae:df3e
2295:c924
1457:415f
0f7c:29a5
4cdb:54ee
338a:b1dd
96ab:785f
9e0b:80bd
0000:2000

[dajojo]

mem and kmem http://pic.dhe.ibm.com/infocenter/aix/v ... %2Fmem.htm

[xorloser]

That location is the 0x0Axxxxxx address that the patch may need to be done at. Assuming it crashes because that is the wrong address, try dumping 0x100 bytes from address 0x401FBBBC instead. Maybe it will work from that 0x40xxxxxx address and it will be the one to use for patching.

[xorloser]

Hm just reread one of your earlier posts that shows:
40225000-404f6fff : Kernel text
404f8000-4057da1b : Kernel data

So praps it is differnt to the above 0x40xxxxxx address I posted too.

[xorloser]

Try dumping some areas in kernel text and kernel data, at least 0x100 byte from each area, maybe even 0x1000 bytes from each so I can gauge where stuff gets loaded to.

[E3V3A]

I'm not able to make viewmem cooperate at all. Very frustrating. :(
xorloser: Could you have a look at it or try compiling it, to see if it works for you?

NOTE: I'm on stock kernel, no mods done. So I only get a virtual shell access via remote shell. Perhaps stdio/stderr are not passed on properly? Your mmccmart works without any issues!

[E3V3A]

@xorloser: I think you're using virtual memory addresses, whereas devmem/viewmem uses physical addressing...

Can you post the output of: cat /proc/iomem

[E3V3A]

Ok, this is really weird!

1) viewmem and devmem, both works "for a little while", then nothing. Is there a memory Watchdog in here?
2) When trying "higher" than mem locations like 0x10000, TV crashes!

Because of time limit, I had to write a script to dump when using devmem, and it shows the same data as viewmem. For the same reason as above, I can't read arbitrary memory locations...

viewmem 0x100 0x100 + hexedit

Code: Select all

00000000   A1 61 16 E0  16 5F 6F E1  1C 73 9F E5  A1 76 17 E0  06 80 A0 E1
00000014   18 B5 8A E1  17 B2 8B E1  56 BF 07 EE  01 80 58 E2  FA FF FF AA
00000028   01 70 57 E2  F7 FF FF AA  02 A0 8A E2  0A 00 53 E1  E4 FF FF CA
0000003C   0E C0 A0 E1  0C F0 A0 E1  00 00 00 00  00 00 00 00  00 00 00 00

devmem dump of 1024 bytes (8-byte hex per line, starting at 0x100)

SpoilerShow

Code: Select all

0xE16F5F16E01661A1
0xE01776A1E59F731C
0xE18AB518E1A08006
0xEE07BF56E18BB217
0xAAFFFFFAE2588001
0xAAFFFFF7E2577001
0xE153000AE28AA002
0xE1A0C00ECAFFFFE4
0x00000000E1A0F00C
...
<zero>
...
0xE3A06001E59F5028
0xE3A060F0E5856000
0xE59FC018E5856004
0xE58CB000E3A0B0FF
0x00000478EA000004
0x00007FFF000003FF
0x1F20674416000100
0xE59FC028E320F003
0xE2000003E59C0000
0x1AFFFFEBE3500000
0xE59C0000E59FC018
0xE59C1000E59FC00C
0xE1A0F002E0812800
0x1F206744E59FF004
0x000004681F206740
0xE280000AE59F0014
0xE59FC00CEB0006C3
0xE58CB000E3A0B003
0x00001D7CEA000001
0xE59FC0081F206700
0xE58CB000E3A0B004
0x1F005788EA000000
0xE59FB008E59FC008
0xEA000001E58CB000
0x00003C111F00578C
0xE3A0B010E59FC008
0xEA000000E58CB000
0xE59FC0081F005790
0xE58CB000E59FB008
0x1F005794EA000001
0xE59FC0080000403C
0xE58CB000E59FB008
0x1F005798EA000001

I'm not sure this will help you find the right location...

I about to give up on this, because I'm not getting anywhere with this. This is too bad, because this is really needed to solve several other eMMC problems in Samsung devices. For example see THIS XDA thread. The guy there use a very similar method to patch mmc.c (et.al.) to make a loadable kernel module that dumps the eMMC memory to a new device. This is way beyond my abilities... Xorloser's method, is much easier, once the in-memory patching has been done. However, this kind of patching is not very portable as we see here... I think a combination of these methods should be doable, to produce something that is portable and easy to use.