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

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

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