07:24 <Necrosporus> ] <chewitt> https://github.com/dancefire/hd806-kernel-android // My device is MESON3 8726M SKT SH, and I have two working kernel binaries for it, but both have CONFIG_MACH_MESON3_STV_MBX_MC=y but by your link I can't find this config option in provided configurations

07:25 <chewitt> I have no real opinion .. the LE 3.10 kernel codebase was always "someone else's problem"

07:26 <chewitt> my only experience is .. they are all hacked up for a specific box, so YMMV

07:27 <Necrosporus> Should I try to go with meson6tvc_h15_defconfig meson6tv_defconfig meson6tvd_defconfig or whatever?

07:27 <Necrosporus> If my board is meson3?

07:28 <Necrosporus> I just want _any_ kernel source for my device because I want to enable framebuffer console and it's disabled in the kernels

07:28 <Necrosporus> I want to be able to use the device at least somehow without UART

07:29 <Necrosporus> Kernel from official firmware has # CONFIG_FRAMEBUFFER_CONSOLE is not set

08:13 <chewitt_> if one of those defconfigs builds a kernel that boots .. start adding things that you need

09:02 <Necrosporus> So you suggest to build stuff for another SoC and try it?

09:06 <chewitt> there are normally a set of amlogic defconfigs, then the one(s) for the vendor who hacked their board into the bsp

09:06 <chewitt> I have nothing to suggest other than "experiment"

11:30 <Necrosporus> Uh, is it possible to find vendor sources for my particular board? Hm...

11:38 <chewitt> first problem will be figuring out who made the board

11:39 <chewitt> most tvbox devices have no-name branding

11:39 <chewitt> and even if it has 'name' branding there's no guarantee it was made by that manufacturer

11:40 <chewitt> any good design gets stolen and cloned pretty quickly.. sometimes with a slightly different mix of components on the board

11:42 <chewitt> but, the guesswork has to start somewhere

11:42 <chewitt> one challenge you'll have is that GitHub became a thing about 10-years ago

11:44 <chewitt> so you're less likely to find nicely indexed sources for old stuff

11:45 <Necrosporus> except that my board is also about 10 years ago, not super old

11:46 <chewitt> 10 years is prehistoric for Amlogic kernels :)

19:24 <asdf28> i'm trying to get bluetooth working on my s905x p212 board

19:25 <asdf28> what i don't understand is, according to this patch: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1582216366-12964-1-git-send-email-christianshewitt@gmail.com/

19:26 <asdf28> it should have a "bcm43438-bt" broadcom bluetooth adapter, but mine has a realtek rtl8723bs chip (wifi/bluetooth combined)

19:28 <asdf28> and the firmware i found for this patch ( https://github.com/lwfinger/rtl8723bs_bt ) says it needs to connect to a serial device that apparently does not exist on my machine

19:29 <asdf28> the patch removed a line "serial1 = &uart_A;" from the device tree file, could this be the reason?

19:30 <asdf28> i have no idea if all p212 boards are exactly the same and have the same bluetooth chips

19:32 <asdf28> dmesg says "Bluetooth: hci0: command 0xfc18 tx timeout / Bluetooth: hci0: BCM: failed to write update baudrate"

19:32 <asdf28> could this be because this broadcom chip does not actually exist on my board?

19:48 <asdf28> i'm going to try with the older dts file now, see if that changes anything

20:28 <xdarklight> asdf28: you probably have "some board" that happens to be mostly compatible with the p212 reference design but at least wifi and Bluetooth are different. minimalist example (based on the link you sent) for RTL8723BS: https://pastebin.com/2mCM9Djk

20:33 <asdf28> oh

20:33 <asdf28> thanks xdarklight, that's awesome

20:33 <asdf28> i'm gonna try this now

20:34 <asdf28> i tried to remove the bluetooth node entirely (mimicking the legacy android dts) and add the serial device, this time the driver appeared to do something, but had a connection timeout

20:35 <asdf28> i don't understand the magic behind this, but the old system appears to work without the bluetooth node

20:49 <asdf28> but as far as i understand, the 8723bs driver that comes with the kernel does not support the bluetooth part of this chip

20:50 <asdf28> only this one from realtek does: https://github.com/lwfinger/rtl8723bs_bt

20:50 <asdf28> and that probably doesn't even make use of the device tree node

20:50 <asdf28> so it might not even matter what's in there

21:02 <asdf28> adding the bluetooth node didn't make it work yet (probably something else needed by the driver), but this made the broadcom error message disappear so that's nice

21:03 <asdf28> i'll try to find some examples of a working setup with this

21:04 <asdf28> anyway, thanks again xdarklight for the code you sent me, i added it!

21:26 <xdarklight> asdf28: the Bluetooth "driver" for the Bluetooth part of RTL8723BS lives in drivers/bluetooth/hci_h5.c in the mainline kernel

21:29 <xdarklight> the downstream (lwfinger) driver has opposite requirements than the mainline driver: upstream requires the "bluetooth" node to be present so the kernel managed the serial connection and no /dev/tty* is created. the downstream driver on the other hand relies on /dev/tty* being missing, which means that there must not be any bluetooth node in the .dts(i) - serial connection is then managed in userspace

21:30 <xdarklight> you can find one more example in Documentation/devicetree/bindings/net/realtek-bluetooth.yaml - the GPIOs are based on an Allwinner (IIRC) board though. host-wake-gpios is optional, and depending on the wifi/Bluetooth combo module device-wake-gpios can be optional as well

21:33 <xdarklight> with the information you're giving it's a hard to say what's going wrong on your board. if you can provide the .dts (or .dtb) for the Android kernel on your board as well as kernel log (dmesg) and the patch you have come up with it'll be easier for me to help :)

21:35 <asdf28> oh, wow. i didn't know that the kernel already has a driver

21:36 <asdf28> thanks for the insight

21:39 <asdf28> yes i couldn't provide a lot of info, i wasn't sure if the proprietary driver even works with a mainline kernel

21:40 <asdf28> dmesg said nothing specific about the driver

21:40 <asdf28> i have already powered my dev machine off, i was getting too tired

21:42 <asdf28> but your insight is much appreciated, this was helpful

21:43 <asdf28> i have the android dts, i'll upload it tomorrow

21:43 <asdf28> i'm pretty sure it uses the old driver with the serial connection

21:43 <asdf28> i'll also try to compare the firmware blob that it's using

21:48 <xdarklight> sure, come back whenever works best for you. I'll have limited time during the week but still try to get back to you when I can

21:49 <xdarklight> from my experience the firmware blob which is in the upstream linux-firmware repo works fine (just in case you find any difference)

21:52 <asdf28> thanks. good night!