Otto K

@SMGJohn

di-camera-app is leaking (not freeing after use properly) a small amount of RAM every frame it processes. Normally this is not an issue since it does not exhaust the available RAM in 30 minutes, but with time restriction lifted you hit it at ~75min. There are two options to fix this - find a memory leak and fix it in di-camera-app binary (hard) and this possible quick hack if you (or somebody else) is willing to try - create and enable swap file and use it (leaked memory is no actually used and can be safely moved to swap). For some reason swap file on SD card is not working (swap partition might, but it's too much work for an average person), but there is a writeable partition in camera already with ~2GB free, mounted on /opt/usr, so this might help:

First to see hwo things look before (all commands from telnet session):

[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     499896      11684          0       5260      70556
-/+ buffers/cache:     424080      87500
Swap:            0          0          0
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  105M  2.1G   5% /opt/usr

OK, so we have no swap and have plenty of free disk space on /opt/usr, let's create some swap:

[root@drime5 ~]£ dd if=/dev/zero of=/opt/usr/swap bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 42.882 s, 12.5 MB/s
[root@drime5 ~]£ mkswap /opt/usr/swap
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=63995c82-cf71-43c6-ae32-34e520e7e280

Ouch, internal storage is not very fast... Let's turn it on:

[root@drime5 ~]£ swapon /opt/usr/swap
[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     506540       5040          0       4404      82108
-/+ buffers/cache:     420028      91552
Swap:       524284          0     524284
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  617M  1.6G  29% /opt/usr

Yup, it works

You have to do everything before swapon only once, after that (and after every reboot) you only have to re-enable the swap with swapon /opt/usr/swap

I hope sombody with enough free time tests this, I have a good feeling.

@raj90 @ricardo_sousa11 you can kinda  already do that by putting settings in EV_RIGHT.sh and similar files and using keyscan utility documented in github repo. 

HEVC seems to be in a separate block as PMU can shut off the power to HEVC block. It's most likely that days from sensor is handled by SRP that does demosaicing, curves, noise and similar and it's then fed to the HEVC block. 

I'm mostly poking around and finding out what Samsung engineers already made but is not exposed through standard menu or keys. This is nowhere near actual "firmware hacking", but there's some useful stuff there.

I'm actually trying not to hack the firmware. I'm just too afraid to end up with even the nx500 sized brick  

Simple "hack" to enable silent shooting in single mode (not CH/CN):

[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)

ROLLING is full electronic shutter

Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.

I have not time to test whether image quality suffers, but it looks OK to me

Could someone check if it works with NX1 as well?

Cheers and have fun,

Otto

33 minutes ago, MountneerMan said:

What else is in this DEV menu?

Care to take some screen shots and upload? 

 

Also on behalf of everyone thank you your hard work is much appreciated.

Here you go

http://***URL removed***/forums/thread/3979382#forum-post-57446956

So, for NX500 the partition layout is as follows (/etc/parttable):

[root@drime5 ~]£ cat /etc/parttab
nx500 partition table
<vol>       <dev>       <size(M)>        <image>  <order> <compress>  <fs>  <mkfs-option>  <mount-point>

adj           /dev/mmcblk0p1     20             none   1    None        raw
rtos          /dev/mmcblk0p7     30          rom.bin   2    None        raw
rtos_data     /dev/mmcblk0p8     50             none   3    None        raw
extended     /dev/mmcblk0p4      0             none   4    None        raw
platform      /dev/mmcblk0p10  1024       rootfs.img   5    LZO        ext4
opt           /dev/mmcblk0p11   100          opt.img   6    LZO        ext4      -j              /opt
pref          /dev/mmcblk0p2     10             none   7    None        raw
pref_default  /dev/mmcblk0p3     30 pref_default.bin   8    None        raw
pref_recovery /dev/mmcblk0p5     20             none   9    None        raw
opt-usr       /dev/mmcblk0p14     0             none  10    None       ext4      -j              /opt/usr
rImage        /dev/mmcblk0p13    10           rImage  11    None        raw
pcache        /dev/mmcblk0p12     5      pcache.list  12    None        raw
devicem4      /dev/mmcblk0boot1   4     devicem4.bin  13    None        raw
snapshot      /dev/mmcblk0p9    100     snapshot.img  14    LZO         raw
uImage        /dev/mmcblk0p6     10           uImage  15    None        raw
bootloader    /dev/mmcblk0boot0   4   bootloader.bin  16    None        raw

There also seems to be some provision for different gammas in video, as well as luminance settings but I don't see any difference. Changes do not survive reboot.
[root@drime5 ~]£ st cap capdtm setusr 118 0x00760000
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 118           
UserData is MOVIE_GAMMA_CONTROL_STANDARD (0x760000)
[root@drime5 ~]£ st cap capdtm setusr 118 0x00760001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 118           
UserData is MOVIE_GAMMA_CONTROL_GAMMA_V (0x760001)
[root@drime5 ~]£ st cap capdtm setusr 118 0x00760002
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 118           
UserData is MOVIE_GAMMA_CONTROL_GAMMA_D (0x760002)
[root@drime5 ~]£ st cap capdtm setusr 119 0x00770000
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 119           
UserData is MOVIE_LUMINANCE_LEVEL_0_255 (0x770000)
[root@drime5 ~]£ st cap capdtm setusr 119 0x00770001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 119           
UserData is MOVIE_LUMINANCE_LEVEL_16_235 (0x770001)
[root@drime5 ~]£ st cap capdtm setusr 119 0x00770002
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 119           
UserData is MOVIE_LUMINANCE_LEVEL_16_255 (0x770002)

@Tim Fraser there's actually an open source download center at Samsung and it contains all the software they have to release under GPL that does in fact include OS sources, but that's that. All the really interesting parts are in closed source binaries. 

@sandro there are plenty of tutorials on https://github.com/ottokiksmaler/nx500 including the archive you should unpack to SD card for telnet, etc. 

Well, for NX500 it seems CPU freq is from 100MHz to 800MHz:

[root@drime5 debug]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq  
800000

[root@drime5 debug]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
100000

Someone with NX1 could see what's there.

Ok, few short notes. 

First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 

Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.

As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 

Cpu cores are most likely based on 1600MHz A9. 

@Syme dfmsd is not needed by camera app, o it is used to control the camera remotely (either by scripts or by ptp over usb - have to check this out as well). For direct control from command line one should use st command (it's just it's easier for me to use dfmstool add I can also monitor the output from dfmsd log file). 

It seems that all heavy lifting and low level stuff is actually done by libudd5.so that configures all the things I don't see in command lines (like 3dlut and similar). Just have to see how to do it... 

No, I'm trying not to mess with the firmware. 

Argh! I typed a silly long post and then hit backspace outside of this box and ... poof ... it's gone

OK, shorter version:

If you start telnet server as described and connect to camera you can do following:

killall dfmsd; sleep 2; dfmsd -p &

This will kill original dfms daemon and start a new instance that we can now use by dfmstool command that sends commands to daemon like this:

dfmstool -s "this is a command"

Be careful, as soon as it encounters an invalid command it stops processing all other commands so we need to do killall... to restart it (it does not affect the camera state).

The command we want is sys_param movie size 2560_1440_30p. Yup, it's still in the firmware, it has no crop and it supports peaking. Why they removed it from the menu I have no idea. It's labelled as MJPEG on screen but it records HEVC as others and is limited to 29:59.

dfmstool -s "sys_param movie size 2560_1440_30p"

Here's what ffmpeg has to say (I have to find a way to set the quality as well):

Stream #0:1(eng): Video: none (hvc1 / 0x31637668), 2560x1440, 11280 kb/s, 29.97 fps, 29.97 tbr, 120k tbn, 120k tbc

Oh, yeah, remember how there is no 1080p at 120fps in NX500? Think again:

dfmstool -s "sys_param movie size 1920_1080_120p"

And output of ffmpeg:

Stream #0:0(eng): Video: none (hvc1 / 0x31637668), 1920x1080, 38589 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 120k tbc

If you really want to you can put just the command in the nx_cs.adj file and call it a day (dfmsd will parse it and finish) or put a small script in test.sh that will do it for you (there is no touchscreen available while dfmsd is running). You could have SD cards for special video modes to simplify it.

For NX500 full list of modes is

4096_2160_24p
3840_2160_30p
2560_1440_30p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_15p
1280_720_120p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p

For NX1, full list of modes is (yeah fractional ones too, don't know whether they are just for show or are there really differences between 24 and 23.98 when recorded)

4096_2160_24p
3840_2160_30p
3840_2160_24p
3840_2160_23_98p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_23_98p
1920_1080_15p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p

Well, that's it for now, have fun

7 hours ago, sandro said:

Very interesting. I would like to test this, could you please upload telnetd since the samsung site takes forever to download?

 

This is a generic busybox binary, it's not samsung specific, just compiled for ARM cpus. It can be a lot of things, like "less" if you name it that.

busybox

240fps iz just a value in a table describing parameters, there is no guarantee it can actually work on nx500 (for example, I tried enabling external audio - via USB - but all I'm getting are app crashes). 

OK, an update:

If you want to experiment with your device but don't want to be constantly reinserting the SD card - here's the solution.

First, unfortunately, NX500/NX1 do not use busybox but toybox that does not contain telnetd. However, there is nothing stopping you from extracting it from NX300 open source packages (available at Samsung Open Source repo) and copying it to SD card (and naming it "telnetd") and runnig it from there. Just remember that you need to give yourself some time to turn the wifi on after powering the camera. Login is "root" and there is no password. So, after the camera boots and telnetd starts, you do

telnet 192.168.1.44
Trying 192.168.1.44...
Connected to 192.168.1.44.
Escape character is '^]'.

************************************************************
*                 SAMSUNG LINUX PLATFORM                   *
************************************************************

drime5 login: root

[root@drime5 ~]# ps aux
USER      PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        1  0.4  0.2   4684  1452 ?        Ss   23:15   0:01 /sbin/init
root        2  0.0  0.0      0     0 ?        S    23:15   0:00 [kthreadd]
root        3  0.0  0.0      0     0 ?        S    23:15   0:00 [ksoftirqd/0]

...

root      363  0.1  0.0      0     0 ?        S    23:15   0:00 [ksdioirqd/mmc1]
root      399  0.0  0.0   4696   380 ?        S<s  23:16   0:00 /mnt/mmc/telnetd
root      402  0.0  0.2   2704  1352 pts/0    S<s  23:16   0:00 -sh
root      469  3.0  0.1   2664   904 pts/0    R<+  23:20   0:00 ps aux

Yippie - we have remote root!

The fun stuff is the command st. It's swiss army knife - it contains everything. For example, you want to take a "smart" shot?

st cap capt smart

Work with aperture?

st cap capt iris drive 7.1

Shoot in RAW?

st cap capt quality raw

Help works in most things, just add help (e.g. st cap capt help).

You want to push an OK button?

st key click ok

You can also push/release it in two steps.

How about jog dials?

st key jog jog1_cw or jog1_ccw

You want to touch the screen in exact coordinates?

st key touch push/release/click 400 300

There is so many things available, just explore st app nx capture (for stills) or st app nx record (for video)...

Hi,

A nice breakthrough in hacking NX500 (and possibly NX1 - could someone try and report back?).

So, TLDR version first: I'm able to run a shell script off the SD card without hacking the firmware (and some other stuff). This is just a very modest start, now we need to do everything else. That said, this is a useful start as we can now play around without bricking cameras.

That was the moderately good news, the moderately bad news is that I'm absolutely swamped by work related stuff next few weeks.

Now for longer version:

First a small "hack": If you want to take a screenshot of your camera screen put a file named save_screen_enable.txt in the SD card root and every time you press EV+OK a file named OSD####.jpg will be saved to SD card root. save_screen_enable.txt will contain the integer of next image id (as bytes, not text).

Another small "hack": If you want to see how all the popups and notices look in all the languages (for any reson) put a file named qa.txt in the root of the SD card. When you power the camera on you will see a popup menu that enables you to access all the popups, etc, in camera (press up and down to change them, left and right to change the language). It's meant for quality assurance staff, but here it is.

If you like scrolling through the popups - that's fine. Even better is that the camera app crashes on popup 188 (of 189, go figure) and produces a lot of detailed logs on the SD card. These logs are named timestamp_{log,a7_log,a9_crash,a9_dlog,a9_dmesg}.info

If you take your sweet time analyzing these logs you will find that NX500 does not boot all that often - it hibernates and then wakes up when you power the camera on - cute - that's how it starts up in one second

Also, some RAM information: Total RAM is 512MB, reserved (buffer?) is 380MB. It fits nicely with known buffer limitations. It also means it's very very difficult to extend it to anything larger (maybe by eliminating allshare app or similar but that would give us a frame or two in RAW at best - hardly worth it).

How to run a shell script file:
1. Put file named "info.tg" on the SD card root with contents "nx_cs.adj" and a newline
2. Put file named "nx_cs.adj" (can use something else really) on the SD card root and put "shell script /mnt/mmc/test.sh" and a newline in it
3. Put file named "test.sh" (or whatever you put up there) on SD card root and put whatever bash shell commands you want to in it. Word of caution - it's easy to make a mistake - start small and work carefully
4. Put SD card in camera
5. Camera to AUTO mode (IIRC it works in any mode but whatever, it's in AUTO in the Service Manual)
6. Power on the camera and wait a bit (or a lot, it seems it's quite lazy with closing files and syncing, might do it for it by calling "sync" at the end)
7. Power the camera off (and wait for blinking light to stop blinking if it's blinking)

For example, if you put following in test.sh

st > /mnt/mmc/test

This is what you get on the output:

usage: st [command] [param]
Supported bult-in commands
    help        readl        writel        dump    
    gpio        hdmi        log        lcd    
    cap        pmu        clk        thread    
    key        firmware    util        app    
    leak        devman        stlcd        bat    
    rtc        tbm        micom        misc    
    oic        dvfs        adc    

I put a "ls -laR / > /mnt/mmc/test" and it did list the whole filesystem including /proc /sys /dev etc. And /etc tar also works.

I can see for example that every time process id 247 is given to /usr/apps/com.samsung.di-camera-app/bin/di-camera-app and it runs under root (almost everything does), dfmsd (that's the deamon that interprets commands in nx_cs.adj file that are read and sent by dfmstool - I will have to see what else I can do with it), /usr/apps/com.samsung.ap-setting-app/bin/ap-setting-app running with some access keys or hashed caller PIDs, etc, the works.

Only two modules are loaded (exfat_fs and exfat_core) but I guess we could compile anything we need and enable it in the future (usb audio anybody?).

That's it for now (and some time).

Oh, yeah, the touch screen does not work with info.tg or info.tgw present on the SD card.

Cheers,
Otto