[T-Mobile Samsung Galaxy Note 3] CalcProgrammer1:
This is a development thread at the moment. I'm going to start working on porting the kexec-hardboot patches to the N900T (actually CyanogenMod hlte) kernel. With the kexec-hardboot patch applied, the kernel will be able to act as a second stage bootloader and boot other kernels. Combined with the kexecboot program, it can act as a second stage bootloader, allowing you to boot kernels from any storage device without flashing them. Ultimately the goal here is to dual-boot Android and non-Android Linux without having to re-flash kernels constantly. Like with my Note i717 port I will be focusing on kexec first, then getting Debian to boot on the device with the Freedreno graphics driver. The Note 3 is a very powerful ARM device and with Freedreno working it could play many of the 3D FOSS games.

Here is my modified kexecboot that I will be using:

https://github.com/CalcProgrammer1/kexecboot

Here is a video showing how it works on the Note i717 (it will work the same way on the Note 3):

https://www.youtube.com/watch?v=qtb-TSGumNo

My Note i717 thread:

http://xdaforums.com/showthread.php?t=1787856

Here is the kexec-hardboot porting guide I will be using:

https://github.com/Tasssadar/multirom/wiki/Porting-kexec-hardboot

For anyone inclined you could also get MultiROM working with this. I am not familiar with that framework but have used kexecboot many times on many devices in the past, so I am going with that.

EDIT 1: I've got the main patch applied and I've found some numbers for the addresses that I think might work. Everything compiles and I'm able to build a boot.img and flashable zip, but I'm sure it won't work in its current state. The Note 3 uses a DSI command-mode panel which is different than the Note 1's video-mode panel in that it doesn't continuously refresh (i.e. at 60Hz). Instead, screen updates must be forced manually by using an ioctl for the framebuffer device. There are several ways to handle this - I could add this ioctl into kexecboot any time it draws to the screen but this would only work for kexecboot. Alternatively I could write a background program that sits in a 60Hz waiting loop and calls the ioctl repeatedly, simulating a video-mode panel. I've talked to some other people on the #freedreno Freenode IRC channel and the refreshing background program has been done with some success on other devices (2013 Nexus 7) so I think I'll take this route first as it will hopefully let me get a framebuffer console up for debugging with.

EDIT 2: I found a way to make kexecboot refresh the screen. I call the FBIOPAN_DISPLAY ioctl in kexecboot's framebuffer refresh function and that makes the kexecboot GUI appear on screen. Now to figure out how to build a kernel and pack a boot.img.

EDIT 3: I figured out how to make boot images, it requires a device-tree supporting mkimage tool such as this: https://bitbucket.org/itsmikeramsay/mkbootimg/src I was able to build a boot.img with a precompiled kernel and my new ramdisk with kexecboot, it worked enough to show the kexecboot GUI. Now to build my modified kernel into the mix and create a kexec-bootable kernel for CM11.

EDIT 4: I might put the Note 3 kexec on hold for a bit as I clean up the Note 1 and TouchPad port of Debian. I ran into an issue on the Note 1 with Kexec where CM wouldn't mount the internal storage when booted via kexec-hardboot. I still need the Note 3 as my primary phone so I can't hack on it without a backup plan.

EDIT 5: The issue with storage not mounting appears to be related to having an ext-formatted SD card inserted (which is where I keep Debian). Booting without the card inserted works fine. Hopefully the same applies to the Note 3.

EDIT 6: I got the kexecboot kernel builder scripts for the Note 1 up on github now and released the first version of it, so I'm going to look into the Note 3 some more. I didn't realize that the Note 3 uses device tree until I messed with it earlier. I'm not sure if kexec needs to reserve a dtb image for the kernel or not, that could be a major roadblock if so as the patch I ported didn't take device tree into account. I'm not entirely sure how device tree and atags work but somehow they're related apparently, at least in terms of kexec.

EDIT 7: I think I have my build root mostly set up for Note 3. Initial test was a failure, though it did at least attempt to boot my new kernel rather than drop into download mode like my earlier attempts. I need to figure out what device tree stuff is required in order to boot a compiled kernel with the new mkboot tool and then enable fbconsole so I can see when the display changes.

EDIT 8: I think I figured out how to make a dt.img file now for the device tree stuff, but I've found that my ramdisk doesn't work on the stock CM11 kernel binary nor my custom compiled one. It did, however, work when patched into LeanKernel's boot.img (replacing the default ramdisk). This was the result of that: http://i.imgur.com/c2racE1.jpg I may try using the leankernel defconfig as a base instead of the CM11 defconfigs.

EDIT 9: Derp herp derp herp didn't look at the boot partition size...it's 11.0MB. My cm-based boot.img was 12.3MB. Of course that ain't gonna work.

EDIT 10: WOOT! Kernel has booted, xz compression is some wizard level magic, it shaved off like 3MB without changing anything else. Now to reapply the kexec-hardboot stuff and see how it fares.

EDIT 11: I spent some more time looking into kexec-hardboot on the Note 1 (as it's a ton easier to debug since it has a video-mode panel) and figured out how to properly reset it. The important code is in relocate_kernel.S, an assembly function that does the very last wrap-up stuff before rebooting. On the Note I was letting the watchdog timer kick the reset after hanging on an infinite loop, but the Note 3 doesn't seem to have this watchdog in place and will loop endlessly. The important thing to note from this is that relocate_kernel.S uses physical addressing. The Note had a pretty in-depth reboot procedure and it looks like the Note 3 may be a bit simpler. I'll be looking into this soon to see if I can get it rebooting correctly.

EDIT 12: I'm going to use USB serial for debugging instead of messing with the stupid fbconsole. To initialize the USB you need to set up the ID fields in /sys/class/android_usb/android0 and set functions to acm. Then use getty (part of busybox) to open a bash shell on the port with "getty -n -l bash 115200 ttyGS0 linux". Then use minicom or other terminal on PC to connect to the ttyACMx interface.

EDIT 13: I was able to get a working shell through USB and play around with kexec tools directly. It would not boot when I did kexec -e, whether or not I used hardboot or not. I may need to apply a patch to load dtb images for the kexec'd kernel.

EDIT 14: Looks like I'll need to build my own kexec-tools based off the newest release (v2.0.7) which has device tree image support. I'm still looking for a hardboot implementation that uses dtb images.

EDIT 15: I dug through the stack of calls up from machine_kexec to figure out why machine_kexec was never called. It appears that kernel_restart_prepare (kernel/kexec.c, line 1595) might be hanging and keeping the system awake instead of dropping through to machine_kexec() like it should. Since we're rebooting with hardboot anyways it should be reasonably safe to just forget a clean shutdown and cut straight to the machine_kexec() function. The bootloader will reinitialize the hardware anyways. This is hopefully almost the end, as I'm sure my reboot code is being called and it is successfully rebooting. It hasn't booted the new kernel yet but it could be an address issue.

EDIT 16: Something's happening...I think I may be right on the edge of getting it working but not quite there yet. I got it to lock up after rebooting which means that the redirection was successful (redirecting to the kexec kernel instead of the kexec-boot kernel) but the kexec kernel is crashed or something. Probably something to do with device tree. It might require a dt.img passed in or it might require the command line being set.

EDIT 17: I managed to get Tasssadar's MultiROM kexec-tools to build. I talked to XDA user flar2 who had done some work on the HTC One M8 and ran into a similar issue with device tree kernels not booting. He mentioned that there may be some custom device tree entries that aren't being picked up by kexec-tools and gave me a link to a repository to look at. For now, here's my kexec-tools branch based on Tasssadar's work with the fixed-up Makefiles that compile correctly: https://github.com/CalcProgrammer1/kexec-tools/tree/kexec-tools-2.0.2 I will look into this more this weekend or so.

EDIT 18: So the Note 3 kernel doesn't have last_kmsg (RAM console) enabled for some reason, or at least it isn't appearing despite being enabled in config. RAM console shows the dmesg (kernel log) of the previous kernel run so long as the reserved RAM area isn't erased. This is important as it allows viewing any logs left behind by failed-to-boot kexec'd kernels. I'm guessing both the host (kexecboot) and guest kernel will need RAM console to be working for any meaningful debugging. Samsung has all sorts of goofy debug stuff (SEC_DEBUG_) but the RAM console doesn't appear to be part of that.

EDIT 19: After a lot of printk's and a lot of failures I got last_kmsg support working! This means booting a last_kmsg supporting kernel and then rebooting into another last_kmsg supporting kernel will grant you a /proc/last_kmsg file that contains the previous boot's dmesg log. This will be incredibly helpful for kexec testing. For any other kernel devs who want this capability, you need to register a platform_device for ram_console using the start and end addresses already included for the persistent_ram ram_console registration. For some idiot reason it reserves the persistent RAM but it doesn't set up a ram_console device to use said RAM.

EDIT 20: New Tools! With the help of some users in the S4 forum, I have some new debugging tools available to better see what's going on with reboots. First is viewmem (http://blog.maurus.be/2011/01/23/samsung-i9000-irom-dump/) which dumps memory to stdout. The Note 3 kernel has sec_debug which logs boot messages from the bootloader and optionally kernel to address 0x10000008 in memory. Viewmem is able to read this log as well as inspect other memory locations to see if things are where they should be. The other debugging tool is a physical serial port, hidden on the USB data pins. Putting a 615K resistor between GND and the ID pin of the USB connector as well as shorting the VCC and GND pins causes the port to go into serial debug mode on reboot. The D+ and D- pins become TX and RX, and hooking up a 3.3V serial interface (PL2303 USB serial breakout in my case) you can dump bootloader and kernel messages to a PC running a serial console.