[Android General] smtddr:
UPDATE#20

I shortened the crashing code into a one-liner, printk("%d crash me now!", *(int *)0); because it's easier to clean-up and remove when I'm done looking at a particular file.

So... the game has changed a bit. What I just found out by accident, is that if I remove "qcom,mdss_dsi_otm1284a_720p_video" from dt.img.. the stock kernel will fade out the screen, but if I wait long enough it will still boot up. The screen won't work but adb-shell does and I can see all the kmsg errors about not being able to setup the framebuffer.... and a devide-by-zero error somewhere. This means my newer kernel has 2 problems. One is the screen and the 2nd is something else because apparently starting up the screen is not a fatal error to Android. Sounds hopeless, but hold on! A couple of other things I've just discovered....

In the file mdss_mdp_splash_logo.c:

rc = mdss_mdp_splash_parse_dt(mfd);
if (rc) {
pr_err("splash memory reserve failed\n");
goto end;
}

if (!mfd->splash_info.splash_logo_enabled) {
rc = -EINVAL;
printk("%d crash me now!", *(int *)0);
goto end;
}
mfd->splash_info.splash_thread = kthread_run(mdss_mdp_splash_thread,
mfd, "mdss_fb_splash");
end:
return rc;

In the parse code, it sets mfd->splash_info.splash_logo_enabled to whatever it found by asking the dt.img for "qcom,mdss-fb-splash-logo-enabled"... at least it looks that way to me, however no matter how I manually added that to the dt.img this code kept saying no. Eventually, I just decided to remove that if-statement entirely forcing the code path to go start that splash thread. The result? After the while-BLU-logo, the screen went immediately blank then immediately blue! ....Hmm!

Above I said that even if I remove the main video-mode from the dt, the phone will still boot up just without a display, but there is an interesting detail here. When the stock-kernel tries to show the animated logo, the display blinks for a moment like it's switching modes(makes sense).... then fades out when apparently things didn't work out but continues the bootup process to allow adb-shell to work. My custom kernel just fades out without that blink. But I can cause a very similar looking blink by forcing that splash-thread to start. I also noticed that even with a stock-kernel AND stock dt.img, the screen does blink for a moment before starting the animated boot. If I use the stock kernel BUT a dt.img with _ALL_ splash-enable tags removed, then the screen blinks for a moment, the white logo is cut in half by a blue square on the lower half of the screen... then it fades out just like my custom-kernel.... but then suddenly the animated boot screen shows up and the phone works normally from there! I find that interesting too!

Also, there are comments in the file "./mdss/mdss_mdp_overlay.c" that suggest that this code where the switch from the bootloader logo to the animated one will happen - or at least is very imminent. Because the splash code that changed the screen blue was started in a kthread, I now suspect whatever code I'm looking for that starts the boot-animation will be a kthread started thing as well. In a way, that makes sense. The kernel shouldn't start the gui in its own main process.(pid 1 I assume, judging from init/main.c). I think I'm close. I'm hoping to solve this issue and reach an animated-boot-logo. But I still need another way to communicate what's going on because it doesn't appear that I can rely on the screen-fade to help me. That'll be especially true if I manage to fix stuff and reach the animated-boot-logo, but then the phone gets stuck there. I looked in the dt.img and saw what appeared to be the video region:

memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x0>;
#address-cells = <0x2>;
#size-cells = <0x2>;

external_image__region@0 {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x86000000 0x0 0x800000>;
label = "external_image_mem";
};

The above "reg" section says image starts at 0x86000000 and is the size of 0x00800000. I hoped that was video-ram so I wrote code to set all the bits in that memory region

int i = 0
for(i = 0; i < 0x00800000; i ++)
*(char*)(0x86000000 + i) = 255 ;

...but I didn't see anything appear on screen.

I haven't given up, seeing the screen change blue from the splash-logo code gave me hope that this kernel can find & draw to the screen beyond the bootloader's hardcoded white-BLU logo.

UPDATE#20.b

To help avoid getting myself confused, I've gone into my ramdisk/init.rc and removed the bootanimation service completely. So now my device seems to boot up faster, straight from white-logo to android homescreen. A bunch of widgets are still loading though because they weren't ready in time. So now the stock-kernel with my custom-ramdisk boots straight to AndroidHomeScreen as fast as possible while my custom kernel fades out. This way I don't need to concern myself about the boot-animation working and keeps the scope of my problem smaller; just focus on getting android(the zygote service in init.rc?) to start up properly instead of the fade out. If it turns out that my custom kernel works as long as boot-animation is disabled, I can live without that feature. :)

UPDATE#20.c

Earlier I concluded that static int mdss_mdp_probe(struct platform_device *pdev) was called by the bootloader since I couldn't find any calls to it. That was wrong, I was searching the codebase for that exact string but I've since discovered that structs with similar variables/members are being used to share function-pointers and called from there. e.g.,

static struct platform_driver mdss_mdp_driver = {
.probe = mdss_mdp_probe,
.remove = mdss_mdp_remove,
.suspend = mdss_mdp_suspend,
.resume = mdss_mdp_resume,
.shutdown = NULL,
.driver = {
/*
* Driver name must match the device name added in
* platform.c.
*/
.name = "mdp",
.of_match_table = mdss_mdp_dt_match,
.pm = &mdss_mdp_pm_ops,
},
};

So now, any code call can do variableName->probe() to call mdss_mdp_probe. I'm looking for that now. I've also installed an app called "LiveBoot" by Chainfire that can save dmesg and kmsg to /cache/liveboot.log. Apparently it only starts up as soon as the /data partition is mounted. When I attempt to boot the kernel with this program, screen fade, wait a bit, reboot to TWRP, I don't see a /cache/liveboot.log file so it seems my custom kernel didn't make it far enough for that program to start logging.

UPDATE#20.d

A sidenote, the original problem I had with phone's microSD disappearing. I've updated the script I use to prevent that. I noticed that if the script is running when there is no music playing, it seems to cause issues with the microSD. And I keep forgetting to stop the script when music stops playing. So, in this updated script it won't write to the sdcard unless music is actually playing. That way all you have to do is remember to use the ScriptManager app from the PlayStore to start this script in the morning and for the whole day, listening to music shouldn't be a problem:

#increase read-ahead, supposedly this helps too.
echo -n 2048 > /sys/devices/virtual/bdi/179\:0/read_ahead_kb
echo -------------------------
id
echo -------------------------
cd /storage/sdcard1
while true; do
IS_SOUND_PLAYING=$( lsof | grep /dev/snd | grep pcm )
if [ -z "$IS_SOUND_PLAYING" ]; then
echo "[`date`] No sound detected"
else
echo "[`date`] Sound is playing"
ls -la . > ./ls_la.log 2>&1
sleep 1
ls -la . >> ./ls_la.log 2>&1
sleep 1
rm ./ls_la.log
fi
sleep 9
done

....and that probe code from my previous sub-update, traced back to generic probing code for all hardware in the linux-kernel world. When a device is probed isn't necessarily when it is used so that ended that chain of events. I'm looking at this problem from more than one angle.

Fixing the screen fade would be nice... but more important is getting access to the error-logs by:

- /fstab has this in its listening "/devices/platform/msm_hsusb /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto", USBOTG implies serial-console over USB port. I need to buy a usbotg cable and give it a shot.

- Getting the phone to at least start up enough for liveboot app to save the logs to the /cache/liveboot.log file so I can reboot into stock and get the file, then I won't be trying a bunch of stuff blindly.

- Get CONFIG_FRAMEBUFFER_CONSOLE to work so that the bootloader will show the kernel-logs right away even if nothing else works and I'd have exact error messages to work on.

- Also editing the mdss_mdp entries in the dt.img to see if I can make the stock kernel fail like my custom kernel. Giving me more of an idea of what I should be looking for. Right now, I'm still of the mindset that the stock dt needs updating for the new kernel. I just don't know exactly what to change yet.

I hope to have a major'ish update next time!