uBoot for ES-series?

[xorloser]

if you pass "/dev/mmcblk0p0" to mmc.restore, it internally uses "/dev/mmcblk0p1" anyway.

and according to onboot source for echo-p there is no uboot, so being zeroed is as expected.

i looked at the kernel sources, and like sbav1 says there is currently no way to read from the boot partitions. i am considering patching the kernel in memory to support dumping the bootloader by overwriting the existing ioctl handlers with code to read instead of write. i am assuming i will be able to do this via /dev/mem and mmap(). i need to get a cross compiler going in windows first though. anyone know if windows binaries exist of cross compiler?

[E3V3A]

... i need to get a cross compiler going in windows first though. anyone know if windows binaries exist of cross compiler? :)

Look at the Wiki for E-series. I'm working on getting the Sourcery CodeBench to compile VDLinux on Cygwin. It is "almost" working but right now I'm at a blocker with an "bad -rpath" error that I can't overcome. It's been too much work to even get this far...

SpoilerShow

Code: Select all

scripts/conmakehash.c:42:7: warning: array subscript has type `char'
dos2unix: converting file scripts/.conmakehash.d to Unix format ...
Makefile:617: "WARNING: Appending $KCFLAGS (-mno-unaligned-access -mthumb -march=armv7-a -mcpu=corte
x-a9 -mfloat-abi=softfp -mfpu=neon -mabi=aapcs-linux -ftree-vectorize) from environment to kernel $C
FLAGS"
  CHK     include/linux/version.h
  UPD     include/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  Generating include/generated/mach-types.h
  CC      kernel/bounds.s
dos2unix: converting file kernel/.bounds.s.d to Unix format ...
  GEN     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
dos2unix: converting file arch/arm/kernel/.asm-offsets.s.d to Unix format ...
  GEN     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CALL    scripts/checksyscalls.sh
  CC      init/main.o
dos2unix: converting file init/.main.o.d to Unix format ...
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
dos2unix: converting file init/.version.o.d to Unix format ...
  CC      init/do_mounts.o
dos2unix: converting file init/.do_mounts.o.d to Unix format ...
  CC      init/do_mounts_rd.o
dos2unix: converting file init/.do_mounts_rd.o.d to Unix format ...
  LD      init/mounts.o
D:\zarm\csbench\bin\arm-none-linux-gnueabi-ld.exe: bad -rpath option
scripts/Makefile.build:354: recipe for target `init/mounts.o' failed
make[1]: *** [init/mounts.o] Error 1
Makefile:914: recipe for target `init' failed
make: *** [init] Error 2

So in conclusion, DON'T USE A WINDOWS BASED CROSS-COMPILER for Kernel compilation!!
You will save yourself much pain, if you just use VirtualBox with a pre-configured Ubuntu. I'm using Xubuntu...
For a single file, however, CodeSourcery works great!

[xorloser]

yeh i read some posts about compiling after writing my previous post and decided against windows. i have installed ubuntu 10.4 here in a vm and am looking into getting sources working on it.

[xorloser]

holy hell that was easy. i expected it to be a lot more painful, thanks samsung
i just followed their steps in the readme file.
there were a few small things i had to deal with, but nothing that a linux noob like me had any issues with.

[nobody]

There is no mmcblk0p0 in my ES8000!

This is actually normal; you still can use /dev/mmcblk0p0 as mmc.restore argument.

So, how should I dump the onboot bootloader?

Currently there is no support in Samsung DTV & BDP kernels for eMMC boot partitions dumping, only for flashing.

While patching kernel MMC driver sources to allow boot partitions dumping is quite easy (just adding another ioctl call with partition switch command should be sufficient), it's pretty hard to do equivalent thing safely on live/running kernel. So, for bootloader dumping, you'll need to flash custom-build kernel first in your device, OR hope someone will eventually figure out how to dump eMMC boot partition[s] "the hard way", without recompiling the kernel.

Yes. I just wanted to help.

@jusiz:
isn't here a more *ahem* 'hardcore' section in this forum?
do I need to ask someone for access?
I'm not as good as you guys but I'm a quick learner

[xorloser]

Yeh I've seen it alluded to a few times that there is a secret part of the forum. Possibly some double standards going on if the same ppl who complain when others don't share are keeping stuff secret there. Maybe they just don't want samsung to know about their exploits etc so that samsung can patch the holes.

Either way I'll pack up the sourcecode I have for mmc stuff and make it available soon. I reversed mmc.restore to C code and also make an mmcdump and mmcsmart app. As part of mmcdump I patch the kernel in memory to enable reading out of the bootloader, and then I read it out. This is very kernel build specific and not for the faint hearted.

This method worked for me at least to dump the bootloader from my UA65ES8000 tv. The result is that bootloader1 (p1 aka uboot) is still 512kb of all zeros and bootloader0 (p0 aka onboot) is 128kb of data followed by all zeros to pad it to 512kb. Strangely, onboot does a cmac over itself before calling its Main function. So if writing in a custom bootloader you could just NOP the checks?!

[E3V3A]

I have now completed the kernel building using Cygwin and the CodeSourcey (garbage).
Check the Wiki and the ARM toolchain thread.

Not all issues are resolved but those issues are due to
1) missing CodeBench libraries (processor support)
2) too modern compiler, throwing errors were old version let pass
3) (a yet) unknown (to me) but needed compiler flag (wchar_t)

SpoilerShow

Regarding "hidden" forum:

Due to our active development, we often need to communicate by sharing copyrighted material and code, or better, often we don't even know what rights the code fall under, at all. This information cannot be open to the public as it would endanger our website and forums. Second, if you ask the right questions, we might be able to help you get what you need. Finally, some of the hidden stuff are highly experimental and are very likely to cause hardbricks, which can only be resolved by JTAG and other tricks. We don't want to be responsible and have to support hundreds of boneheads who brick their new TVs just to get some obscure function working, that might not even be possible for their device.

[xorloser]

hehe posting publicly that you are sharing such stuff probably doesn't help

[E3V3A]

hehe posting publicly that you are sharing such stuff probably doesn't help :)

I think you might need to readup on your understanding of "Copyright". Copyright, doesn't mean that you can't see it or use it. It means that you cannot make profit on material based upon it...

[E3V3A]

...This method worked for me at least to dump the bootloader from my UA65ES8000 tv. The result is that bootloader1 (p1 aka uboot) is still 512kb of all zeros and bootloader0 (p0 aka onboot) is 128kb of data followed by all zeros to pad it to 512kb. Strangely, onboot does a cmac over itself before calling its Main function. So if writing in a custom bootloader you could just NOP the checks?!

BTW. Nice work! But can you explain what you mean with: "nboot does a cmac over itself before calling its Main function"??