[KERNEL] [KEXEC] Kernel EXECution for locked devices [N900V] [WIP]

[CalcProgrammer1]

I recall my old post on dtb quoted bellow. It seems that you need to apply similar patches for dtb address/size. "The boot loader must provide either a tagged list or a dtb image for passing configuration data to the kernel. The physical address of the boot data is passed to the kernel in register r2."

Sounds good, I'll take a look at those patches. My kexec-tools binary is the one Tasssadar has on his github for kexec-hardboot, but I guess now that I'm trying to use non-hardboot kexec I should use a different kexec-tools. Either way, I confirmed that execution is getting to the main kernel entry point in arm/kernel/head.S after successfully decompressing the kernel in arm/boot/compressed/head.S. I haven't looked at what happens after that but it looks to turn on the MMU and go into virtual addressing mode. Might be tricky to keep memory tagging after that point.

 

[CalcProgrammer1]

Trying to figure out /dev/mem <--> /dev/kmem mapping. It is getting to the code that turns on the MMU and after that the memory mapping should be changed, so to tag physical address 0x50000000 I need to know what the corresponding kmem virtual address is. From what I've found, at least in Android, it is 0x10000000

    MEM     |    KMEM
 0x40000000 | 0x00000000
 0x50000000 | 0x10000000
 0x60000000 | 0x20000000
 0x70000000 | 0x30000000
 0x80000000 | 0x40000000
 0x90000000 | 0x50000000

Hopefully this is the same in my kexec kernel. I'm trying to put this code:

asmlinkage void __init start_kernel(void)
{
	char * command_line;
	extern const struct kernel_param __start___param[], __stop___param[];
	
	volatile unsigned long *ptr = (unsigned long *)0x10000000;
	*ptr = 0x50505050;

	/*

in start_kernel (init/main.c).

 

[hsbadr]

@CalcProgrammer1 & @ryanbg: let me know if you're still interested in Hangouts discussions! I've made a few changes in my kexec-mod source, but I don't have time for testing/debugging. I'll push the changes to the Github repo only if it makes any difference/progress. However, I could send you the modules to test if you wish.

 

[CalcProgrammer1]

@hsbadr: Still interested for sure! I don't know what all good Hangouts will be unless we're all online at the same time though. @ryanbg mentioned FIQ debugger in a PM he sent me so I'm going to investigate that route on the host kernel and try to get it working. Otherwise the memory tagging method works but isn't great. ryanbg, if you have any updates on this front let me know and I can test them on the host kernel.

 

[hsbadr]

@hsbadr: Still interested for sure! I don't know what all good Hangouts will be unless we're all online at the same time though. @ryanbg mentioned FIQ debugger in a PM he sent me so I'm going to investigate that route on the host kernel and try to get it working. Otherwise the memory tagging method works but isn't great. ryanbg, if you have any updates on this front let me know and I can test them on the host kernel.

Good to know! Do you've a working arm binary or source code for it?

 

[CalcProgrammer1]

No, I just enabled the FIQ debugger in the .config (the code is already in the kernel) but it doesn't compile, FIQ_START is undefined. ryanbg said he was working on it so I am going to wait to see if he has already solved this as to not duplicate work. Have you looked into getting a serial cable for debugging? ryanbg said he got it working on a RasPi. I think FIQ debugger will require a serial cable.

 

[hsbadr]

No, I just enabled the FIQ debugger in the .config (the code is already in the kernel) but it doesn't compile, FIQ_START is undefined. ryanbg said he was working on it so I am going to wait to see if he has already solved this as to not duplicate work. Have you looked into getting a serial cable for debugging? ryanbg said he got it working on a RasPi. I think FIQ debugger will require a serial cable.

Nope, I think that I've to patch the kernel source to compile the FIQ debugger into a loadable module for N900V NC2 kernel, or wait for your results to get an idea about how useful it is. I may also coordinate with @ryanbg (I think he has N900V) & divide the work (for example, I can take care of finding solutions/workarounds & code patches while he works on testing/debugging & providing meaningful logs).

The problem is that I've rescheduled my PhD defense because of investing more time on ROM updates So, I really need to take a break & focus on my study/work, but I can make a relatively slow kexec progress in my limited ~free time.

 

[Legitsu]

Nope, I think that I've to patch the kernel source to compile the FIQ debugger into a loadable module for N900V NC2 kernel, or wait for your results to get an idea about how useful it is. I may also coordinate with @ryanbg (I think he has N900V) & divide the work (for example, I can take care of finding solutions/workarounds & code patches while he works on testing/debugging & providing meaningful logs).

The problem is that I've rescheduled my PhD defense because of investing more time on ROM updates So, I really need to take a break & focus on my study/work, but I can make a relatively slow kexec progress in my limited ~free time.

where did the github repo go ?
https://github.com/hsbadr/N900V_KK_Kernel_Kexec is 404ing
edit:nm found calcs repo

 

[RuggedHunter]

Ahhhhhh.......memories. Reminiscing this old thread from my rooted Note 10+ tonight.....good people here.