kernel as a module?

[aalm]

Hi,

looks like a good start for modularizing things for different goke cameras.

I built a kernel with ext2 etc. missing from vendor provided kernels, and can load it from u-boot w/o flashing the spi, but i think i need to find out a safe path for other users to try it out, which i think your project is perfect for as it is kind of "read-only".

I got static kexec(8) built, among other tools i'd like to write "modules" for, but i'm unsure where&how to start..

Do you want/accept pull requests? or?

[bolshevik]

Hi,

the module itself is just anything you want with two shell scripts: boot and run. There is only a convention, that first boot of all modules are executed and then run. For example on boot one might mount needed filesystem images etc. But then on run execute the program.

The entry point in mod/main.sh is executed either by the ipc firmware on K21 or via debug_cmd.sh on INQMEGA.

Please consider, that those are executed when the kernel is already loaded, so there is no way to replace it.

What you need is probably as you are mentioning the u-boot entry, that loads the kernel. If you supply a rootfs for it pointing to the existing mtd, it should boot with your kernel.

What you could also try is to embed a custom init script into the root image and assemble the rootfs and other filesystems from files on the SD card to make the whole setup fully readonly.

Please pay attention to the risk of the firmware overwriting the mtd devices on firmware update. I was not able to test if removing these devices from /dev/ eliminates it or not.

[aalm]

Please consider, that those are executed when the kernel is already loaded, so there is no way to replace it.

but atleast my vendor provided kernel was built with CONFIG_KEXEC=y

which i'm hoping would allow rebooting into new kernel with static kexec(8). by changing the kernel cmdline, we could easily avoid boot-looping because of this module, which is also usable for hiding the mtd devices, if necessary. :]

but i haven't tried kexec(8) yet in practice (will do so in the next few days when i get time for that).

[bolshevik]

Sounds interesting, did not hear about it. Please pay attention to the sensor drivers. I think I was not able to unload them at all... I hope it works for you. For sure I can accept your pull requests.

[aalm]

Yep, it does work :]

the tool: kexec-tools-2.0.20-static-armv6.tar.gz

and the kernels with support for ext2,3,4 etc., i succesfully booted the uImage kernel w/above kexec, and have booted the zImage w/u-boot before, so i know they both work: gk_kernels-ext2_etc.tar.gz

but i think i'll begin with a smaller/easier module for now.

[bolshevik]

And how are you launching it? Would be cool to see the script.

[innerfire3]

Yep, it does work :]

the tool: kexec-tools-2.0.20-static-armv6.tar.gz

and the kernels with support for ext2,3,4 etc., i succesfully booted the uImage kernel w/above kexec, and have booted the zImage w/u-boot before, so i know they both work: gk_kernels-ext2_etc.tar.gz

but i think i'll begin with a smaller/easier module for now.

Can you tell me how you build the kernel?

[aalm]

Can you tell me how you build the kernel?

I'm sorry, but i'm not sure i have time for that; building a linux kernel is very well documented process, so i'm not even sure what you're exactly asking for?

cd path/to/sdk/linux/kernel/3.4.43 && make # but you need to setup tools&fix env first

fwiw., you might want to get the both SDKs referred to here, as neither of them is "fully complete".

[bolshevik]

@aalm so do you have any luck running a custom kernel via kexec?

[aalm]

@aalm so do you have any luck running a custom kernel via kexec?

i haven't had time to work on it really, but i pushed a branch with few kernels, and some notes for testing/using it.

[aalm]

@bolshevik have you tested kexec from the branch linked above? if you don't have gk7102s, i could try building those kernels w/.config for gk7102 too.

[bolshevik]

@aalm I tried to play with it but was not successful, it looks either it hangs or wifi is not working anymore. What is your model?

[aalm]

@aalm I tried to play with it but was not successful, it looks either it hangs or wifi is not working anymore. What is your model?

"CIPC-GC13H", i pasted some info below.

So you have a model with GK7102S too? The kernels are compiled with hub.c for RTL8188 wifi(8188fu.ko.lzma), but the linux source tree i built from appears to support mt7601 too, it has two versions of drivers/usb/core/hub.c, one for each.

I haven't actually tested the wifi either, as it's one of the things i'd like to disable, because i have wired LAN where i would use the cameras, and might even like to use the only usb-port for something(storage?) else later. I think atleast the wifi module is easy to solder off.

sensor is sc1135, and iirc., this is my from my original /home/hardinfo.bin:

<?xml version="1.0" encoding="UTF-8"?>
<DeviceInfo version="1.0">
<DeviceClass>0</DeviceClass>
<OemCode>0</OemCode>
<BoardType>1003</BoardType>
<FirmwareIdent>eyeplus_ipc_gk_001</FirmwareIdent>
<Manufacturer>JSL</Manufacturer>
<Model>GK7102S</Model>
<WifiChip>RTL8188</WifiChip>
<GPIO>
<BoardReset>30_0x00000000_0_0</BoardReset>
<SpeakerCtrl>6_0x00000000_0_0</SpeakerCtrl>
<BlueLed>51_0x00000000_0_1</BlueLed>
<IrCut1B>20_0x00000000_0_1</IrCut1B>
</GPIO>

[bolshevik]

Hello @aalm , yeah, I was trying it on INQMEGA IL-HIP291-2M-AI with 8188fu and gc2053. I tried your custom kernel wmtd and mtd as a rootfs (just to eliminate other failures and just reboot the kernel), then also tried the stock kernel just to see if it works. But none of them worked. It hangs probably... this board has no exposed UART... just very small pads. I will see, if I could get into it again somehow to see the serial output.

What is also different is mem=36M, but I changed it accordingly to use the original cmdline.

[aalm]

ok, i will try to create a minimal bare .img for sd card with everything necessary(your modules etc.) for testing this up to working network&sshd next, that should work just by dd'ing it to a card.

fwiw., i've written an "LD_PRELOAD hook wrapper"-.so to take over 'ipc', as it does have +7000 symbols in the .dynsym table, it seems it would be doable to rewrite just "selected pieces" (not really "would be", because i have a working poc done). just hooking ioctl(), system(), popen()/pclose(), access(), open() and read() does give a lot of control over what 'ipc' does, but hijacking the individual threads/code paths does give freedom much further:]

do you like/do C ? i do.

[bolshevik]

@aalm would be interesting, I do not do C, only as a hobby to fix or improve something.

Any pull requests would be welcomed! I really like your idea, because then we could pre-build a rootfs with all tools without a need to hook in busybox or dropbear via symlinks or bind mounts etc.

And also it will be fully writable so anyone could install any software on top on the one hand, and will not be touching the internal mtd making it readonly and safe to use on the other hand.

[bolshevik]

@aalm I was playing with cross-compilation of user-land tools, it would be great if you could share more information on how to build the kernel here https://github.com/bolshevik/goke-GK7102-customizer/tree/master/tools/compile . I think it might be useful for everyone.

[aalm]

hmmph, i suppose i could give it a try, by documenting the steps necessary to build the kernel on ie. debian vm, but docker etc. are things i don't know anything about...

fwiw., it does mostly boil down to editing "Config.mak" in the SDK dir, and sourcing /path/to/SDK/env/build_env.sh from ie. ~/.bash_aliases, but i will work on documenting those steps in a pull request to readme.md later next week i hope. I still have the sd card .img in my TODO for tomorrow.