Move to a mainline kernel

ben-kuhn commented 1 year ago

This may not be possible depending on the patch set used on the stock kernel.

Looking at the loaded kernel modules, most drivers appear to be built in rather than built as loadable modules. My guess is to simplify the booting process.

This may resolve [https://github.com/d3cker/gsoc-puhumod/issues/2]

ben-kuhn commented 1 year ago

Well, CONFIG_IKCONFIG isn't enabled in the stock kernel so it looks like we are doing this the hard way...

d3cker commented 1 year ago

@ben-kuhn Yeah... I know... own kernel... It will be pain :) But let me summarize:

Wifi USB stick has a module. It's loaded when USB device is discovered. That seems not to be a problem. The problem is in wpa_supplicant , I mean think so... . When I played with iwconfig I didn't notice any issues at all.
I manged to compile usbnet module and a driver for my USB ethernet card. I had to disable tracing as it was the only missing symbol in the kernel. I mean the symbol was related to the tracing. Anyway, I even managed to load it but it crashed when I connected the device. Whole USB functionality crashed :) I didn't play with kernel and it's modules for ages. Last time I did some hacking and messing with drivers was around kernel 2.2 ... or something like that. I don't think I can help much here.
Friend of mine (@michalrudowicz) managed to build generic kernel for cubieboard2 and I even did boot it. It hangs after random: crng init done with no additional messages. I tried to pass xiegu dtb to that but no luck so far. The result was black screen after a second. I hope there is a way. For example: I can decompile .dtb file into .dts and add it to the kernel source. Yet, I do not know what to do next. I never built a kernel from the scratch for Linux embeded devices.

d3cker commented 1 year ago

Just a thought... How about previous releases? I think there is v1.1 still available. Maybe there is a support for .config? I wonder if there is some initial release kernel in the wild? I mean the one that was shipped with the first batch of the devices.

ben-kuhn commented 1 year ago

Good idea. I'll see if I can track down an older image.

I was messing with an Armbian image for the Cubieboard2 and it did boot on the GSOC but there was no display. It may be time to break out the screwdriver and see how the display is interfaced. I'm also not ruling out a bug as I've seen Armbian do similar with some Pine64 boards in recent builds. Fun stuff.

d3cker commented 1 year ago

I also put my hands on stock kernel to find out what is inside. mkimage -l shows a rather sparse result.

$ mkimage -l uImage 
Image Name:   Linux-5.4.24
Created:      Mon Dec 21 08:32:42 2020
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    5316344 Bytes = 5191.74 KiB = 5.07 MiB
Load Address: 42000000
Entry Point:  42000000

I stripped u-boot part to get clear zImage:

$ tail -c+65 < uImage > zImage
$ file zImage 
zImage: Linux kernel ARM boot executable zImage (little-endian)

I wanted to to use objdump to find .config section (if present) but no luck. No headers are found. So I did a try with binwalk:

$ binwalk zImage 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Linux kernel ARM boot executable zImage (little-endian)
29536         0x7360          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

As noticed, there is a gZip data at 0x7360. So tried to extract that one. This time with some luck:

$ binwalk -e zImage
[...]
ls -l _zImage.extracted/7360 
-rw-rw-r-- 1 bartek bartek 14099496 gru  5 10:36 _zImage.extracted/7360

Now I have uncompressed kernel inside 7360 file and I'm not sure what to do next :) At least I can see some human readable strings right now:

$ strings _zImage.extracted/7360
[...]
earlycon
uart
snps,dw-apb-uart
uart
nvidia,tegra20-uart
ns16550a
ns16550a
ns16550
ns16550
uart
uart8250
random.trust_cpu
driver_async_probe=
deferred_probe_timeout=
[...]

binwalk also shows some interesting results:

$ binwalk _zImage.extracted/7360 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1939537       0x1D9851        Certificate in DER format (x509 v3), header length: 4, sequence length: 774
2800569       0x2ABBB9        Certificate in DER format (x509 v3), header length: 4, sequence length: 8194
2956705       0x2D1DA1        Certificate in DER format (x509 v3), header length: 4, sequence length: 5452
6642909       0x655CDD        Certificate in DER format (x509 v3), header length: 4, sequence length: 592
7483577       0x7230B9        Certificate in DER format (x509 v3), header length: 4, sequence length: 773
7888121       0x785CF9        Certificate in DER format (x509 v3), header length: 4, sequence length: 5384
8386473       0x7FF7A9        Certificate in DER format (x509 v3), header length: 4, sequence length: 5380
9508260       0x9115A4        DES SP2, little endian
9509284       0x9119A4        DES SP1, little endian
9532160       0x917300        CRC32 polynomial table, little endian
9969692       0x98201C        AES S-Box
10033892      0x991AE4        Neighborly text, "Neighbor entry is now dead header for neighbor dump request"
10033967      0x991B2F        Neighborly text, "neighbor dump requestdump request"
10034021      0x991B65        Neighborly text, "neighbor dump requestp request"
10034072      0x991B98        Neighborly text, "neighbor dump request"
10034249      0x991C49        Neighborly text, "neighbor dump requestInvalid values in header for neighbor get request"
10034291      0x991C73        Neighborly text, "neighbor get requestrequest"
10034341      0x991CA5        Neighborly text, "neighbor get request request"
10034392      0x991CD8        Neighborly text, "neighbor get requestor get request"
10034449      0x991D11        Neighborly text, "neighbor get requestrequest"
10034499      0x991D43        Neighborly text, "neighbor get requestest"
10034545      0x991D71        Neighborly text, "neighbor get requestnot specified"
10034955      0x991F0B        Neighborly text, "neighbor table dump requestbor table dump request"
10035013      0x991F45        Neighborly text, "neighbor table dump requestghbor table dump request"
10035073      0x991F81        Neighborly text, "neighbor table dump requestnot specified"
10064414      0x99921E        Unix path: /var/run/rpcbind.sock
10078404      0x99C8C4        Certificate in DER format (x509 v3), header length: 4, sequence length: 676
10086376      0x99E7E8        LZO compressed data
10727360      0xA3AFC0        Unix path: /dev/vc/0
10767472      0xA44C70        Ubiquiti firmware header, third party, ~CRC32: 0x4C455445, version: "_DOWNGRADE"
10787372      0xA49A2C        xz compressed data
10856302      0xA5A76E        Unix path: /sys/kernel/debug/dri.
10872977      0xA5E891        Unix path: /sys/kernel/debug/dri.
10894056      0xA63AE8        Unix path: /lib/firmware/updates/5.4.24
10905168      0xA66650        Ubiquiti firmware header, third party, ~CRC32: 0x332E3130, version: "-"
11050415      0xA89DAF        Copyright string: "Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>"
11103764      0xA96E14        Unix path: /sys/firmware/devicetree/base
11104861      0xA9725D        Unix path: /sys/firmware/fdt': CRC check failed
11139441      0xA9F971        Neighborly text, "neighbor table overflow!solicit"
11194368      0xAAD000        ELF, 32-bit LSB shared object, ARM, version 1 (SYSV)
12933600      0xC559E0        ASCII cpio archive (SVR4 with no CRC), file name: "dev", file name length: "0x00000004", file size: "0x00000000"
12933716      0xC55A54        ASCII cpio archive (SVR4 with no CRC), file name: "dev/console", file name length: "0x0000000C", file size: "0x00000000"
12933840      0xC55AD0        ASCII cpio archive (SVR4 with no CRC), file name: "root", file name length: "0x00000005", file size: "0x00000000"
12933956      0xC55B44        ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
13618240      0xCFCC40        AES S-Box
13618496      0xCFCD40        AES Inverse S-Box

I checked 0x99E7E8 and 0xA49A2C but those were false positives. I hope this helps a little.

NeonFux commented 1 year ago

Some useful info and tools here https://github.com/orgs/cubieboard/repositories?type=all

d3cker / gsoc-puhumod

Move to a mainline kernel #6