Current mainlining progress #1
Comments
|
NOTE: This comment is obsolete. The things that were required to get clocks working were initializing the power manager and adding bus clock support. For anyone who wants to take up fixing clocks:
TL;DR: mainline driver matches downstream, this is probably a power management issue or a bootloader issue UPDATE: Seems like PI_MGR/dfs isn't just for clocks; I was able to find mentions of it in the UART driver (alongside some other bcm-specific fixes, enabled with the CONFIG_BRCM_UART_CHANGES kernel config (also of note are CONFIG_DW_UART_WA_JIRA_1744 and CONFIG_DW_BT_UART_CHANGES). |
|
UPDATE: this log is now obsolete, see next post [ 0.000000][ T0] Booting Linux on physical CPU 0x0␍␊ [ 0.000000][ T0] Linux version 5.12.0-next-20210427-NG (pmos@muffet) (armv7-alpine-linux-musleabihf-gcc (Alpine 10.3.1_git20210424) 10.3.1 20210424, GNU ld (GNU Binutils) 2.35.2) #1 SMP PREEMPT Tue Apr 27 19:27:10 UTC 2021␍␊ [ 0.000000][ T0] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d␍␊ [ 0.000000][ T0] CPU: div instructions available: patching division code␍␊ [ 0.000000][ T0] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache␍␊ [ 0.000000][ T0] OF: fdt: Machine model: Samsung Galaxy Grand Neo␍␊ [ 0.000000][ T0] printk: debug: ignoring loglevel setting.␍␊ [ 0.000000][ T0] Memory policy: Data cache writealloc␍␊ [ 0.000000][ T0] Ignoring RAM at 0xb0000000-0xbe200000␍␊ [ 0.000000][ T0] Consider using a HIGHMEM enabled kernel.␍␊ [ 0.000000][ T0] Zone ranges:␍␊ [ 0.000000][ T0] Normal [mem 0x0000000080000000-0x00000000afffffff]␍␊ [ 0.000000][ T0] Movable zone start for each node␍␊ [ 0.000000][ T0] Early memory node ranges␍␊ [ 0.000000][ T0] node 0: [mem 0x0000000080000000-0x00000000afffffff]␍␊ [ 0.000000][ T0] Initmem setup node 0 [mem 0x0000000080000000-0x00000000afffffff]␍␊ [ 0.000000][ T0] On node 0 totalpages: 196608␍␊ [ 0.000000][ T0] Normal zone: 1536 pages used for memmap␍␊ [ 0.000000][ T0] Normal zone: 0 pages reserved␍␊ [ 0.000000][ T0] Normal zone: 196608 pages, LIFO batch:63␍␊ [ 0.000000][ T0] percpu: Embedded 16 pages/cpu s32780 r8192 d24564 u65536␍␊ [ 0.000000][ T0] pcpu-alloc: s32780 r8192 d24564 u65536 alloc=16*4096␍␊ [ 0.000000][ T0] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 ␍␊ [ 0.000000][ T0] Built 1 zonelists, mobility grouping on. Total pages: 195072␍␊ [ 0.000000][ T0] Kernel command line: console=ttyS1,115200n8 mem=994M ignore_loglevel PMOS_NO_OUTPUT_REDIRECT nosmp␍␊ [ 0.000000][ T0] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)␍␊ [ 0.000000][ T0] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)␍␊ [ 0.000000][ T0] mem auto-init: stack:off, heap alloc:off, heap free:off␍␊ [ 0.000000][ T0] Memory: 761092K/786432K available (8192K kernel code, 3532K rwdata, 2740K rodata, 1024K init, 1166K bss, 25340K reserved, 0K cma-reserved)␍␊ [ 0.000000][ T0] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1␍␊ [ 0.000000][ T0] rcu: Preemptible hierarchical RCU implementation.␍␊ [ 0.000000][ T0] ⇥ Trampoline variant of Tasks RCU enabled.␍␊ [ 0.000000][ T0] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.␍␊ [ 0.000000][ T0] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16␍␊ [ 0.000000][ T0] random: get_random_bytes called from start_kernel+0x2e8/0x4dc with crng_init=0␍␊ [ 0.000000][ T0] __ccu_wait_bit: slave_ccu/0x0404 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for uartb2␍␊ [ 0.000000][ T0] __ccu_wait_bit: slave_ccu/0x0458 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for bsc1␍␊ [ 0.000000][ T0] __ccu_wait_bit: slave_ccu/0x045c bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for bsc2␍␊ [ 0.000000][ T0] __ccu_wait_bit: slave_ccu/0x0470 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for bsc3␍␊ [ 0.000000][ T0] __ccu_wait_bit: slave_ccu/0x0474 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for bsc4␍␊ [ 0.000000][ T0] Broadcom slave_ccu initialization had errors␍␊ [ 0.000000][ T0] __ccu_wait_bit: master_ccu/0x0358 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for sdio1␍␊ [ 0.000000][ T0] __ccu_wait_bit: master_ccu/0x0364 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for sdio3␍␊ [ 0.000000][ T0] __ccu_wait_bit: master_ccu/0x0360 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for sdio4␍␊ [ 0.000000][ T0] __ccu_wait_bit: master_ccu/0x0358 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for sdio1_sleep␍␊ [ 0.000000][ T0] __ccu_wait_bit: master_ccu/0x0364 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for sdio3_sleep␍␊ [ 0.000000][ T0] __ccu_wait_bit: master_ccu/0x0360 bit 18 was never set␍␊ [ 0.000000][ T0] __peri_clk_init: error initializing gate for sdio4_sleep␍␊ [ 0.000000][ T0] Broadcom master_ccu initialization had errors␍␊ [ 0.000000][ T0] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns␍␊ [ 0.000000][ T0] Calibrating delay loop... 2393.70 BogoMIPS (lpj=11968512)␍␊ [ 0.060000][ T0] pid_max: default: 32768 minimum: 301␍␊ [ 0.060000][ T0] LSM: Security Framework initializing␍␊ [ 0.060000][ T0] SELinux: Initializing.␍␊ [ 0.060000][ T0] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)␍␊ [ 0.060000][ T0] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)␍␊ [ 0.060000][ T0] CPU: Testing write buffer coherency: ok␍␊ [ 0.060000][ T1] CPU0: update cpu_capacity 1024␍␊ [ 0.060000][ T1] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000␍␊ [ 0.060000][ T1] Setting up static identity map for 0x80100000 - 0x80100060␍␊ [ 0.060000][ T1] rcu: Hierarchical SRCU implementation.␍␊ [ 0.060000][ T1] smp: Bringing up secondary CPUs ...␍␊ [ 0.060000][ T1] smp: Brought up 1 node, 1 CPU␍␊ [ 0.060000][ T1] SMP: Total of 1 processors activated (2393.70 BogoMIPS).␍␊ [ 0.060000][ T1] CPU: All CPU(s) started in SVC mode.␍␊ [ 0.060000][ T1] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 4␍␊ [ 0.060000][ T1] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns␍␊ [ 0.060000][ T1] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)␍␊ [ 0.060000][ T1] pinctrl core: initialized pinctrl subsystem␍␊ [ 0.060000][ T1] reg-dummy reg-dummy: no of_node; not parsing pinctrl DT␍␊ [ 0.060000][ T1] NET: Registered protocol family 16␍␊ [ 0.060000][ T1] DMA: preallocated 256 KiB pool for atomic coherent allocations␍␊ [ 0.060000][ T1] audit: initializing netlink subsys (disabled)␍␊ [ 0.060000][ T15] audit: type=2000 audit(0.060:1): state=initialized audit_enabled=0 res=1␍␊ [ 0.060000][ T1] cpuidle: using governor ladder␍␊ [ 0.060000][ T1] cpuidle: using governor menu␍␊ [ 0.060000][ T1] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.␍␊ [ 0.060000][ T1] hw-breakpoint: maximum watchpoint size is 8 bytes.␍␊ [ 0.060000][ T1] cryptd: max_cpu_qlen set to 1000␍␊ [ 0.060000][ T1] usbcore: registered new interface driver usbfs␍␊ [ 0.060000][ T1] usbcore: registered new interface driver hub␍␊ [ 0.060000][ T1] usbcore: registered new device driver usb␍␊ [ 0.060000][ T1] mc: Linux media interface: v0.10␍␊ [ 0.060000][ T1] videodev: Linux video capture interface: v2.00␍␊ [ 0.060000][ T1] Advanced Linux Sound Architecture Driver Initialized.␍␊ [ 0.060000][ T1] Bluetooth: Core ver 2.22␍␊ [ 0.060000][ T1] NET: Registered protocol family 31␍␊ [ 0.060000][ T1] Bluetooth: HCI device and connection manager initialized␍␊ [ 0.060000][ T1] Bluetooth: HCI socket layer initialized␍␊ [ 0.060000][ T1] Bluetooth: L2CAP socket layer initialized␍␊ [ 0.060000][ T1] Bluetooth: SCO socket layer initialized␍␊ [ 0.060000][ T1] NET: Registered protocol family 2␍␊ [ 0.060000][ T1] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)␍␊ [ 0.060000][ T1] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)␍␊ [ 0.060000][ T1] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)␍␊ [ 0.060000][ T1] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)␍␊ [ 0.060000][ T1] TCP: Hash tables configured (established 8192 bind 8192)␍␊ [ 0.060000][ T1] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)␍␊ [ 0.060000][ T1] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)␍␊ [ 0.060000][ T1] NET: Registered protocol family 1␍␊ [ 0.060000][ T1] Initialise system trusted keyrings␍␊ [ 0.060000][ T7] Unpacking initramfs...␍␊ [ 0.060000][ T7] Freeing initrd memory: 1108K␍␊ [ 0.060000][ T1] workingset: timestamp_bits=30 max_order=18 bucket_order=0␍␊ [ 0.060000][ T1] ntfs: driver 2.1.32 [Flags: R/W].␍␊ [ 0.060000][ T1] fuse: init (API version 7.33)␍␊ [ 0.060000][ T1] jitterentropy: Initialization failed with host not compliant with requirements: 2␍␊ [ 0.060000][ T1] Key type asymmetric registered␍␊ [ 0.060000][ T1] Asymmetric key parser 'x509' registered␍␊ [ 0.060000][ T1] io scheduler mq-deadline registered␍␊ [ 0.060000][ T1] io scheduler kyber registered␍␊ [ 0.060000][ T1] io scheduler bfq registered␍␊ [ 0.060000][ T1] bcm-kona-gpio 35003000.gpio: Setting up Kona GPIO␍␊ [ 0.060000][ T1] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled␍␊ [ 0.060000][ T1] serial8250 serial8250: no of_node; not parsing pinctrl DT␍␊ [ 0.060000][ T1] 3e000000.serial: ttyS0 at MMIO 0x3e000000 (irq = 29, base_baud = 808290) is a 16550A␍␊ [ 0.060000][ T1] printk: console [ttyS1] disabled␍␊ [ 0.060000][ T1] 3e002000.serial: ttyS1 at MMIO 0x3e002000 (irq = 31, base_baud = 808290) is a 16550A␍␊ [ 0.060000][ T1] printk: console [ttyS1] enabled␍␊ [ 0.060000][ T1] loop: module loaded␍␊ [ 0.060000][ T1] zram: Added device: zram0␍␊ [ 0.060000][ T1] tun: Universal TUN/TAP device driver, 1.6␍␊ [ 0.060000][ T1] PPP generic driver version 2.4.2␍␊ [ 0.060000][ T1] PPP BSD Compression module registered␍␊ [ 0.060000][ T1] PPP Deflate Compression module registered␍␊ [ 0.060000][ T1] PPP MPPE Compression module registered␍␊ [ 0.060000][ T1] NET: Registered protocol family 24␍␊ [ 0.060000][ T1] mousedev: PS/2 mouse device common for all mice␍␊ [ 0.060000][ T1] i2c /dev entries driver␍␊ [ 0.060000][ T1] bcm-kona-i2c 3e016000.i2c: device registered successfully␍␊ [ 0.060000][ T1] bcm-kona-i2c 3e017000.i2c: device registered successfully␍␊ [ 0.060000][ T1] bcm-kona-i2c 3e018000.i2c: device registered successfully␍␊ [ 0.060000][ T1] bcm-kona-i2c 3e01c000.i2c: device registered successfully␍␊ [ 0.060000][ T1] device-mapper: uevent: version 1.0.3␍␊ [ 0.060000][ T1] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com␍␊ [ 0.060000][ T1] sdhci: Secure Digital Host Controller Interface driver␍␊ [ 0.060000][ T1] sdhci: Copyright(c) Pierre Ossman␍␊ [ 0.060000][ T1] Synopsys Designware Multimedia Card Interface Driver␍␊ [ 0.060000][ T1] sdhci-pltfm: SDHCI platform and OF driver helper␍␊ [ 0.060000][ T1] hid: raw HID events driver (C) Jiri Kosina␍␊ [ 0.060000][ T1] usbcore: registered new interface driver usbhid␍␊ [ 0.060000][ T1] usbhid: USB HID core driver␍␊ [ 0.060000][ T1] ashmem: initialized␍␊ [ 0.060000][ T1] usbcore: registered new interface driver snd-usb-audio␍␊ [ 0.060000][ T1] snd-soc-dummy snd-soc-dummy: no of_node; not parsing pinctrl DT␍␊ [ 0.060000][ T1] GACT probability NOT on␍␊ [ 0.060000][ T1] Mirror/redirect action on␍␊ [ 0.060000][ T1] u32 classifier␍␊ [ 0.060000][ T1] input device check on␍␊ [ 0.060000][ T1] Actions configured␍␊ [ 0.060000][ T1] xt_time: kernel timezone is -0000␍␊ [ 0.060000][ T1] IPVS: Registered protocols ()␍␊ [ 0.060000][ T1] IPVS: Connection hash table configured (size=4096, memory=32Kbytes)␍␊ [ 0.060000][ T1] IPVS: ipvs loaded.␍␊ [ 0.060000][ T1] ipip: IPv4 and MPLS over IPv4 tunneling driver␍␊ [ 0.060000][ T1] Initializing XFRM netlink socket␍␊ [ 0.060000][ T1] NET: Registered protocol family 10␍␊ [ 0.060000][ T61] (NULL device *): Debounce value 200000 not in range␍␊ [ 0.060000][ T61] sdhci-kona 3f180000.sdio: Got CD GPIO␍␊ [ 0.060000][ T61] __ccu_wait_bit: master_ccu/0x0358 bit 18 was never set␍␊ [ 0.060000][ T61] kona_peri_clk_set_rate: gating failure for sdio1␍␊ [ 0.060000][ T61] __ccu_wait_bit: master_ccu/0x0358 bit 18 was never set␍␊ [ 0.060000][ T61] clk_gate: failed to enable gate for sdio1␍␊ [ 0.060000][ T61] sdhci-kona 3f180000.sdio: Failed to enable core clock␍␊ [ 0.060000][ T61] sdhci-kona 3f180000.sdio: Probing of sdhci-pltfm failed: -5␍␊ [ 0.060000][ T61] sdhci-kona: probe of 3f180000.sdio failed with error -5␍␊ [ 0.060000][ T1] Segment Routing with IPv6␍␊ [ 0.060000][ T1] mip6: Mobile IPv6␍␊ [ 0.060000][ T1] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver␍␊ [ 0.060000][ T1] NET: Registered protocol family 17␍␊ [ 0.060000][ T1] NET: Registered protocol family 15␍␊ [ 0.060000][ T1] Bridge firewalling registered␍␊ [ 0.060000][ T1] Bluetooth: RFCOMM TTY layer initialized␍␊ [ 0.060000][ T1] Bluetooth: RFCOMM socket layer initialized␍␊ [ 0.060000][ T1] Bluetooth: RFCOMM ver 1.11␍␊ [ 0.060000][ T1] Bluetooth: BNEP (Ethernet Emulation) ver 1.3␍␊ [ 0.060000][ T1] Bluetooth: BNEP socket layer initialized␍␊ [ 0.060000][ T1] Bluetooth: HIDP (Human Interface Emulation) ver 1.2␍␊ [ 0.060000][ T1] Bluetooth: HIDP socket layer initialized␍␊ [ 0.060000][ T1] l2tp_core: L2TP core driver, V2.0␍␊ [ 0.060000][ T1] l2tp_ppp: PPPoL2TP kernel driver, V2.0␍␊ [ 0.060000][ T1] NET: Registered protocol family 35␍␊ [ 0.060000][ T1] Key type dns_resolver registered␍␊ [ 0.060000][ T1] Registering SWP/SWPB emulation handler␍␊ [ 0.060000][ T1] Loading compiled-in X.509 certificates␍␊ [ 0.060000][ T1] input: gpio-keys as /devices/platform/gpio-keys/input/input0␍␊ [ 0.060000][ T1] cfg80211: Loading compiled-in X.509 certificates for regulatory database␍␊ [ 0.060000][ T1] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'␍␊ [ 0.060000][ T1] ALSA device list:␍␊ [ 0.060000][ T1] No soundcards found.␍␊ [ 0.060000][ T1] dw-apb-uart 3e002000.serial: forbid DMA for kernel console␍␊ [ 0.060000][ T16] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2␍␊ [ 0.060000][ T16] cfg80211: failed to load regulatory.db␍␊ |
|
Update: IT'S ALIVE
Turns out SMP was more broken than I thought, and just setting nosmp didn't fix all issues. Disabling SMP in the kernel config did, however, and I managed to get the boot log from the initramfs! Now to get USB working... |
|
For anyone who wants to take up writing the charging driver:
Generally, we still need a LOT more research to figure this out. Which parts of the driver are responsible for what? What does the accy driver do by itself, and what does sec_charging to that accy doesn't? What handles the battery, and battery values? How is USB detection handled (and how should we handle it in mainline?) |
|
Today's progress: did some research on how to approach the USB issue. I found a few things:
|
|
The last 2 days' progress: I modified the bcm590xx driver to use bcm59054 regulator values. So far, it appears to work well! While skimming through the downstream source though, I found some extra code related to default/available regulator modes. This has yet to be implemented. |
|
For anyone who wants to take up fixing USB:
As of now, the driver fails to initalize with the following errors: Which is odd, considering that all initial values (i2c address, irq number, GSNPSID mask) match up with their downstream counterparts. Update: seems like the hsotgctrl driver is actually mostly responsible for usbphy bringup, and the drivers seem to be quite similar! Downstream has a lot of extra setup though, and whatever MDIO is. Currently investigating this. As of now, considering that the "configuration mismatch" part comes after usb-phy bringup (checked this with printk statements), I'm assuming it's some kind of misconfiguration/miscommunication between the two? Could still be something that Broadcom modified in downstream. Edit 2: I suspect this might be a similar situation to the clocks, where USB is enabled upon power manager init. This has yet to be checked though. |
|
Upon further investigation, it seems like the pi_mgr driver could be quite closely connected to the pwr_mgr driver... so if we want to get things working, we might have to port both at once. |
|
Update on the clocks - it turns out there is something I missed in the clock initialization function, and it's a function that flips something related to the pwr_mgr. However switching that will probably require me to make a separate pwr_mgr driver (unless I wanna play around with trying to guess the right virtual address, which I'm quite sure wouldn't be the correct way to go about this anyways). Knowing my luck though, it'll probably also require me to port some initialization stuff from the pwr_mgr driver, and that also has ties to pi_mgr... ...this will take a while. |
|
This work is really astonishing 👍 I guess that I don't have this phone yet but the mainlining process seems challenging :) As far as I can see there is not so much working yet on mainline but would it be possible to already package the mainline kernel part for pmOS? |
@onny In theory - it could be packaged like a regular mainline kernel, but the mainline kernel packages in pmOS are just regular upstream Linux source + any needed patches, so I'd probably have to clean up my patches before it can be cleanily done. But if we used this repo as the source, it could work. (Note the localversion needs to be changed in the defconfig to match the package name IIRC, or it won't build.) Probably wouldn't get accepted into upstream at the current state, though. |
|
Hi, it's great so see that the BCM Kona platform is getting some love from a knowledgeable developer! Would you mind helping me try to compile and boot this kernel on my Samsung Galaxy Core Plus SM-G3500 (codename: cs02)? I have to say that I'm in no way a kernel developer or hacker, I've experimented my way here half-blindly and somehow my device is still alive. My skills are mostly above the kernel. cs02 documentation: https://wiki.postmarketos.org/wiki/Samsung_Galaxy_Core_Plus_(samsung-cs02) I've tried booting it with two different DTS (compiled separately) and a slightly customized defconfig based on your defconfig and I'm getting the following error in early boot (output captured with a USB serial debug cable). I'm using pmOS as a base for testing the kernel, if that matters (I'm willing to compile separately if needed). Not sure where to start to be honest.. Can you see something obviously wrong with the first DTS file? DTS option 1: https://gist.github.com/santeri3700/cfe89c73367f88a901ea7b81f11949f6 DTS option 2 kernel fork actually boots further, but is broken in some way which is described in here: https://gitlab.com/deata/kylepro-mainlining/-/issues/1 My customized defconfig: https://gist.github.com/santeri3700/61a9b87b2f9bb58b78944d6cf1e389a4
|
wouldn't necessarily call myself knowledgeable yet, but alas... :)
Kinda looks like you forgot to append the DTB to the boot image.
This is because SMP is currently broken (I suspect this might be a regression somewhere down the build chain as it worked with Deata's kernel, according to build logs they sent once...) and it just hangs when bringing up the extra cores. Adding nosmp to the CMDLINE won't help, and will only cause the device to freeze up later in the boot process - you'll have to disable CONFIG_SMP entirely. btw, I've had some people test on the kylepro and cs02 as well (using the kylepro dts which is in this repo - these two devices are basically identical except for a few peripherals which we don't enable yet anyways), and it booted for them.
The downstream DTS won't really work because Broadcom packed it full of their own bindings. |
|
@knuxify thanks for the tips! I found my mistake in the DTS Makefile (.dts -> .dtb) and now I'm able to get further with the kylepro based DTS file, but now I get stuck here.. I'll probably continue my experiments tomorrow with new eyes. |
|
@santeri3700 try changing the tty to ttyS1, one of the ttys doesn't get initialized causing the kernel to assign what should be ttyS2 to ttyS1 |
|
Thanks for helping me with my silly mistakes. I got it booting now (without SMP, framebuffer and peripherals as expected). |
|
OK, small update on the power manager and PI manager: tl;dr - I was wrong about... a lot of things. I've spent the past few days looking into the driver and slowly, function by function, porting it to the mainline kernel. Most importantly, however, I noticed that the actual software ties from the PI mgr to the pwr mgr are pretty minimal (mostly boiling down to the changes of policies). ( Although the power manager does call some PI managment functions, I haven't gotten to the PI mgr driver portion yet (or rather, I'm about to start taking a look at it as of writing), but there's quite a bit I've learnt about the power manager since my previous investigation: mostly about the actual things it manages. There are at least 4 elements that the power manager comprises of:
No ETAs on when the driver will be finished, or in an usable state; especially given that I still don't know that much about kernel development. Can't promise I'll get anything that works in any capacity; it's entirely possible I won't even finish it, I tend to jump from project to project - just in case, don't get too excited :p Just wanted to throw this correction out there - I'll need to get around to writing something about this in the docs, but as mentioned I don't have a good enough understanding of any of this to make any proper statements. I've been rather haphazard with my discoveries last year, and I'd rather avoid jumping to conclusions this time around. |
|
Any further updates on this on deck? |
|
Not really, haven't had the time to properly look into this. This turned out to be a lot more work than I was expecting even for a basic bringup, so I'm planning to first polish my Linux/C knowledge somewhere else, then maybe come back to this eventually. It could take months or even years though :/ |
|
Just a question. |
|
We might be able to avoid doing all of that because the bcm23550 is actually supported in mainline uboot, but uses some old driver model from what I've seen. The bcm21664 is pretty similar so it likely wouldn't take that long to adapt it to run on both chips. I've been planning to run it as a secondary bootloader (kinda like lk2nd on qcom devices, or the sterricson-mainline uboot fork), since it's less destructive than replacing the entire bootloader, but it's certainly something to consider. |
|
My idea was to throw the bootloader to mmcblk0boot0 and just not need the primary mmc bootloader at all. |
|
New year, new rebase, and new drivers! I've rebased the kernel on 6.1, and I can confirm that it still works... and is still equally as bare bones as before. There's a new power manager driver now, but it doesn't solve the clock issues (and also intializes only after the main ccu init part is done... moving the driver to the arch folder would probably fix this, I might try to do it later, but I am unconvinced that it will change anything.) The entire early init sequence is implemented, as for actual power island enabling/disabling... who knows. Downstream pi_mgr driver is largely just the APIs to make it available for clients, which we don't need to reimplement because genpd does pretty much the same thing. The tough part is figuring out how it actually interacts with the hardware... My power manager research is now contained in https://github.com/bcm-kona-mainline/docs/blob/main/platform/power-manager.md (sorry for the weird formatting in places, I wrote this entirely in Obsidian with the intention to use it for my own reference while writing the driver). It's still fairly barebones, but attempts to explain most of the concepts in the driver at least at a surface level. There's still a lot of unknowns. (Maybe we should ask someone from Broadcom about this, maybe they wouldn't mind revealing a bit of info for an SoC that has been EoL for nearly 9 years...) |
|
Update: found that downstream does some more stuff when initializing CCUs, implemented it in bf88ab3, clocks are still broken. Meh. |
|
update: IT WORKS (well, sort of) I forced the power manager initialization function to run before the clocks (in a very ugly hack - see 05a0ff9), and now they all initialize without complaining \o/ ...sadly it doesn't fix the remaining issues like USB not working or one of the uart lanes missing, and SMP is still broken. Also I should probably do this correctly since right now it complains about "EXPORT_SYMBOL used for init/exit symbol". (note to self: check if this hack doesn't break anything. seems like init_irq is kinda fragile (I already had to add the irqchip_init or it would hang)) |
|
holy shit/10 |
|
update: I re-added support for bus clocks (had it working on older kernels, but I figured it wasn't useful since they didn't initialize anyways). Turns out, with the power manager enabled, they do initialize, and now ttyS2 gets initialized properly! We also got some progress with USB, in that the error is now different. Same story with the sdcard controller. Buuuut, we're getting to a point where we could actually slowly start debugging things! |
|
Here's an example boot log, for future reference (note that mmc0/sd card is disabled, so mmc1/internal storage takes its place): Boot logs |
|
Update: the USB error seems to have been caused by me using the wrong settings in the baffinlite dts, now it initializes fine (although I don't know if it actually works). SD card/mmc0 errors aren't fixed, but I did find that I messed up the card detect GPIO, so now it doesn't spam the kernel logs when an SD card is not inserted. Next up: fully implementing the timer and pinmux drivers. The former might help with the SMP initialization issues, and the latter might help with miscellaneous other issues. |
|
Impressive work! Are there some fixes or drivers of your work which might can get upstreamed? |
|
Yup, I'm planning to get it all cleaned up and upstreamed once I can get at least the most important peripherals (those being SD card support, USB, and maybe framebuffer if I can do it with simple-framebuffer) and SMP working. The power manager driver still needs more work (the init does happen but I'm not convinced it's all set up properly to act as a power domain controller, plus it needs to be moved to the arch folder to get rid of the hacky "exporting init function" thing). |
|
and I've got a thermal camera in the mail just in time to figure out wtf is wrong with my own kylepro. Can't wait to run this and have plasma. |
|
Update: SMP is... weird. Seems like enabling CONFIG_SMP causes the kernel to completely hang early in the initialization process, even if Printk debugging is completely useless because the hang seems unpredictable. Adding I'm honestly at a loss as to how to debug this. My only pointer is that it at least got a bit further on the older kernel (5.12) but with |
|
Update time: it's been a while since I updated this issue, but there's been quite a bit of progress on the driver front.
Out of curiosity, I also made some test builds for the Galaxy Trend Plus (kylepro) (should hopefully work with kyleprods and cs02 as well). These are very barebones (no framebuffer or anything), but should be enough to see if SMP/clocks work on the BCM21664, or if my experimentation broke something (the Grand Neo I use for development is a BCM23550 device, and I don't own any BCM21664-based ones...) @santeri3700, do you still have your kylepro? @CheetahPixie, any updates on the state of yours? INSTRUCTIONS: Flash these with https://cloud.dithernet.org/s/ogLBpnxZDkkrdji https://cloud.dithernet.org/s/aDAA3jnjQMFreyc This applies to any BCM21664 devices: I'd appreciate downstream kernel dmesg logs (preferably from Android or recovery), since they have various useful bits of information which might prove useful while mainlining. |
|
No updates yet, but I have my thermal camera now. I did order some TMS diodes for a hard drive to fix that, but hadn't gotten around to looking at the kylepro. Guess I'll do that now real quick. |
|
Update: Blown ceramic capacitor. Short found. Near the CPU, no less. |
|
I've got news, and it ain't looking good. If I'm not wrong, the EMMC in the EMCP is shorted. It might be dead. If I could at all figure out how to boot other media, I probably could actually; It doesn't look like the RAM portion is dead, only the EMMC. Then again it might also be cracked solder joints... |
|
Minor update: the hang when CONFIG_SMP is enabled seems to have started happening after the CCU initialization was added. Disabling the entire sequence fixes the hang (then it hangs at a later point, just like in the 5.12 kernel). Enabling any part of the sequence, for any CCU, makes the freeze re-appear. I'll keep looking into this. |
|
@knuxify great work! I tested both of the kernels on my kylepro and I've attached full debug logs starting from S-boot all the way to TWRP recovery or kernel panics depending on which kernel was used.
I see that the kernel CMDLINE has I'm more than happy to do more testing. I still have my kylepro and two cs02's that I'm willing to sacrifice. |
|
You can probably drop into a twrp shell and change the requisite values with a bit of mount and loop device magic. I have static binaries on hand for precisely this purpose. |
|
...yup, I forgot to change the cmdline. These are just quickly rebuilt on top of my usual development setup (which is configured for my Samsung Galaxy Grand Neo), and I forgot to change the setting... should be fixed now. |
|
Thanks, I've gathered new logs. I hope these logs and the previous TWRP boot log can be of use. |
|
Sorry for the lack of updates, my working schedule has been all over the place. Currently working on getting PLL clocks working, since they're responsible for the CPU frequency, and will likely help us get the other cores working. If not, at least we'll have a starting point for a cpufreq driver. (The SMP hang I mentioned a few comments ago was fixed btw, see e8ef552.) |
|
Hi, I'm just leaving a comment here because I have a Galaxy S2+ with a BCM28155. If you need any testing on that, let me know. I don't have access to the debug interface tho, so I guess my time will come much later. |
|
Been a while since I updated this, so here's an update: Since the last message, I added the PLL clocks - unfortunately, SMP was still broken. I suppose I'll just leave it be for the time being, and focus on getting basic peripherals running so that we can have at least a comparable experience to downstream (simple-framebuffer works for the display, but the touchscreen is broken due to i2c issues - look-but-don't-touch is no fun on a smartphone :p). Then I went on a multiple-month break while I did all sorts of other things, including mainlining the Samsung Galaxy Tab 3 8.0 - which is an Exynos 4212 device, so in no way related to the Broadcom Kona SoCs, but the whole process meant that I became more familiar with kernel internals and, perhaps most crucially, the process of submitting patches to upstream. I'm certainly not an expert yet, but it means that I have more knowledge that can help me get these patches upstreamed and conformant with upstream quality. With that being said, I've been working for the past 2 weeks or so on getting all the patches rebased on Linux 6.5-rc1, preparing them for upstream submission, writing all the DT bindings I didn't write before (and fixing the ones I did - clearly I hadn't heard of Here's a checklist:
You can see the current progress in the |
|
Hello, @knuxify I seem to be that someone converting those pesky old TXT bindings to YAML :) I've been working on those during the last ~3 months in my free time, along with some minor cleanups for the kona mainline device trees. I believe most of the existing bindings should be already converted in linux-next: Unless I missed something, the only one that's currently not merged into linux-next and still on the mailing list is the bcm11351-pinctrl (with no feedback yet): Also, a good place to check Broadcom-related future patches is Broadcom's GitHub repo, the devicetree/next branch also having one of my patches not yet in linux-next :P I'm willing to help in my free time, let me know if you need help (with dt-bindings or otherwise) :) |
|
@StandaSK Ah, I was curious why someone would pick the Broadcom Kona bindings in particular - now I know ;) This has been immensely useful - thank you so much! As for the pinctrl bindings - I was planning to convert these as part of preparing the BCM21664 patch for the BCM28155 pin controller, though ultimately ended up postponing it since I already had a hard time forcing myself to go through all the other patches I had to remake 🙃 Fortunately, the most important prerequisites are out of the way now (literally just finished them just as you sent this comment), so this is on my priority list. I'll check the patch out in more depth when I get around to working on that. Thanks again! |
|
Hi, I have Samsung Galaxy Ace 3 Duos ( samsung-logands ) with BCM21664 SOC. I ported it to PostmarketOS with downstream kernel and want to help with some mainline work/testing. At the moment I don't have UART cable to connect to PCB, but I found JTAG 300 pads on board. |
|
Preparing-for-upstreaming update: while going through the CCU initialization sequence, I realized that the only two things actually needed to get all the clocks initializing are:
Notably, no power manager init here! That's good, since it means we can delay writing a proper power manager driver and still get somewhat functional hardware into the kernel. Well, somewhat. All of my I2C peripherals are still not working, but I suspect the issue may not be related to clocks anymore - rather, I think something's wrong with the regulators... I tried manually forcing the regulator responsible for the touchkey LEDs ( |
|
Yup, my suspicion was right - I found a bug in the regulator driver that caused it to write the enable value to the wrong register. That's fixed now, and my LEDs work, and the errors for initializing the i2c peripherals are gone! ...but the touch screen still doesn't work. It seems to start up, though for some reason it starts and stops multiple times before eventually staying started-up after the UI boots. It seems that it's not actually getting any of the interrupts (which is how the touch screen knows that it's been pressed, etc.). So... I guess that's the next thing to debug? |
|
Hi everyone I was wondering if there is any new updates on this project? Thank you. |
|
@sostk Since the last post, not really... I've been working on upstreaming some of the changes I made to the kernel, but that got stuck as I have various other things that take up my time (school, other projects...). It is very much on my todo list, but I can't give an ETA as to when I'll have the time and energy to get back to working on it... I see you have a few Android-related repos on your profile. FYI, there's a lot of work still left to be done to make the mainline kernel anywhere close to usable: once we get the basics down, we still need to write drivers for the display, audio, modem (which is rather limited by the fact that 3G has been shut down in many networks (including in the country I live in) so I can test 2G at best), cameras (this one is especially tough on mainline, many other devices struggle with it) and everything else you might expect from a working smartphone. This is mostly a hobby project with the primary goal being running postmarketOS on these devices, though it could certainly be expanded to Android (see e.g. the Replicant project which tried to do this with Exynos 4 devices) once it matures. |
|
Thank you for your reply @knuxify, you have done an amazing job till now, hope you will be able to continue working on this. |
This issue outlines the current mainlining progress in this repo.
(As a general note: the default branch in this repo will contain random commits that are simply made to save my work. Once the time comes to upstream my patches, I'll re-do them.)
For those interested in Broadcom Kona mainlining: I'm actively looking for developers to help out with the mainlining process, feel free to reply in this thread and make a pull request if you want to contribute! Just adding a DTS for your device and telling us about the status would be enough.
whatever it isit's very low-level debuging stuff, no clue if it would even work on a production device, and doubt it's of any use to usSee also: https://wiki.postmarketos.org/wiki/Samsung_Galaxy_Grand_Neo_(samsung-baffinlite)
The text was updated successfully, but these errors were encountered: