Touch About compiling the kernel (actually `g_ether' for now)

[educosta]

Hey guys!

I plan on spending some time tinkering with a spare N905 I have, and would like to be able to telnet or ssh to it through USB.

I have upgraded it to the newest firmware available, have gained telnet access, have installed the toolchain (linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf), and have used it to compile and run FBink, so it should work as expected.

Because of the module versions problem, I'm gonna need to compile the `g_ether' module, so I headed to kobolabs' hw github repository for the imx508, and I see two folders: `cls' and `nxt'. On both I can see a kernel matching what my `uname' currently reports: `Linux (none) 2.6.35.3-568-g4cf53cf-gb548272-dirty' but what folder is the one I should choose, and what's the meaning for both folders?

Whichever it is, I guess it will be a fully working kernel for the device? Not that I plan compiling the whole kernel yet, but would like to know that diff'ing it with a vanilla 2.6.35.3 would result in having the patches Freescale/nxp/kobo made for it to work.

This is the output my `/proc/cpuinfo' if it's of any help, as I know there are a couple of versions of N905 ot there:

Processor       : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 159.90
Features        : swp half thumb fastmult vfp edsp neon vfpv3 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 5

Hardware        : Freescale MX50 ARM2 Board
Revision        : 50011
Serial          : 0000000000000000

Or if more details are needed I can provide them.

Regards,

[NiLuJe]

IIRC, one kernel (the earliest) is for the A/B, and the other is for the C.

If they're built the same way as newer devices (i.e., with CONFIG_MODVERSIONS), you'll have to build the full kernel anyway.

c.f., http://trac.ak-team.com/trac/browser...mpile.sh#L3991 for my latest notes.

If things implode at runtime, double-check (i.e., readelf) which TC is actually used to build your production kernel, as it happens to be completely different than the one used to build Nickel on my two devices ^^.

[davidfor]

Doesn't a hack already exist to support USB networking? My memory says it is part of KSM, or maybe that it can be added to KSM.

[NiLuJe]

The required modules are certainly there on newer devices, yeah .

I would assume the Touch does too. The one I'm not sure about is the original Freescale wifi.

[davidfor]

Originally Posted by NiLuJe

The required modules are certainly there on newer devices, yeah .

I would assume the Touch does too. The one I'm not sure about is the original Freescale wifi.

Just checked the 4.19.14123 update package. There is a "g_ether.ko" in "drivers/ntx508/usb/gadget". But not in "drivers/freescale/usb/gadget". Not sure if that means the N905B has it, but the N905 doesn't. Other than the internal storage, I never remember what the differences in these two are.

[educosta]

Originally Posted by NiLuJe

IIRC, one kernel (the earliest) is for the A/B, and the other is for the C.

If they're built the same way as newer devices (i.e., with CONFIG_MODVERSIONS), you'll have to build the full kernel anyway.

c.f., http://trac.ak-team.com/trac/browser...mpile.sh#L3991 for my latest notes.

If things implode at runtime, double-check (i.e., readelf) which TC is actually used to build your production kernel, as it happens to be completely different than the one used to build Nickel on my two devices ^^.

Hey thanks!

Quite helpful. I managed to compile the kernel and g_ether, and even nano and strace, just for fun.

Can I ask you what the most comfortable/less cumbersome method would it be to deploy this kernel I have compiled in a non-destructive way? I'd like to try making an image I could use. My touch is the one with internal emmc and an (externally accessible) SD card slot.

Answering davidfor's last message (I don't know how to quote a future message), that's exactly the problem I faced. The g_ether module seems to be there for another kernel, the only usable for me was the `arcotg_udc.ko' under the `/drivers/freescale' directory, but without the `g_ether' module it was pretty much useless.

Thanks all!

[NiLuJe]

I think I link to Marek's GitHub page in my notes above, that's probably the best source of info about that, as I don't think anyone else ever actually deployed a custom kernel . I certainly haven't ^^.

[educosta]

Originally Posted by NiLuJe

I think I link to Marek's GitHub page in my notes above, that's probably the best source of info about that, as I don't think anyone else ever actually deployed a custom kernel . I certainly haven't ^^.

Oh, thought it was more common around. I've seen a post claiming the kobo can be instructed to boot from the external sd card if the home button is pressed while powering it up. So I'll locate one, write the kernel to it, and give it a go. I could send the image from the host, and flash it from within the kobo itself.

If somebody seein this happens to know the on-board pinouts of this kobo, please let me know. Very little information on this particular model out there that I've seen so far.

All I can see within the board is 7 pins in a row, with (non-populated) resistor terminations. Will check if it's jtag or usart ports or something.

Thanks!

[pazos]

Originally Posted by educosta

Oh, thought it was more common around. I've seen a post claiming the kobo can be instructed to boot from the external sd card if the home button is pressed while powering it up. So I'll locate one, write the kernel to it, and give it a go. I could send the image from the host, and flash it from within the kobo itself.

If somebody seein this happens to know the on-board pinouts of this kobo, please let me know. Very little information on this particular model out there that I've seen so far.

All I can see within the board is 7 pins in a row, with (non-populated) resistor terminations. Will check if it's jtag or usart ports or something.

Thanks!

Hi Edu! I think the post is mine.

You can boot using a rootfs on a external sdcard but the kernel should be loaded at that point of time. That's it: we use a key combo to override the arguments passed to the kernel but we don't modify that kernel.

It should be possible to modify uboot to load a kernel stored on a ext2 partition (or in raw disk) but isn't recommended on your case, for the following reasons:

- uboot has a watchdog that resets the board each few seconds.
- uboot has the environment hardcoded and does a CRC32 check of that environment on boot.
- messing with uboot (or replacing the kernel) in a device with soldered EMMC is a bad idea because there's no way to recover that.

If you have other device with a user-replaceable sdcard then you can go straight and copy the kernel at the same offset. But, in your case, is too dangerous.

You can check if stock kernel has kexec support. In that case you can use the trick to boot from external sdcard and use kexec there to load your new kernel.

I hope the message is clear. Have fun with your lurking.

[educosta]

Originally Posted by pazos

Hi Edu! I think the post is mine.

You can boot using a rootfs on a external sdcard but the kernel should be loaded at that point of time. That's it: we use a key combo to override the arguments passed to the kernel but we don't modify that kernel.

It should be possible to modify uboot to load a kernel stored on a ext2 partition (or in raw disk) but isn't recommended on your case, for the following reasons:

- uboot has a watchdog that resets the board each few seconds.
- uboot has the environment hardcoded and does a CRC32 check of that environment on boot.
- messing with uboot (or replacing the kernel) in a device with soldered EMMC is a bad idea because there's no way to recover that.

If you have other device with a user-replaceable sdcard then you can go straight and copy the kernel at the same offset. But, in your case, is too dangerous.

You can check if stock kernel has kexec support. In that case you can use the trick to boot from external sdcard and use kexec there to load your new kernel.

I hope the message is clear. Have fun with your lurking.

Hey thanks!, yes, quite clear. This kernel on the touch doesn't have kexec, but I've got another N437? It's a glo or hlo hd, which I remember having an internal sd card, so I could definitely use it.

I'll nonetheless, take the touch apart enough to be able to discern how many layers the board has, if it has the typical occluding embedded ground plane (If more than two layers), and whether I can access jtag, usart, or if these have already been brougth out on these seven pins the board has.

Thanks a lot!