**** BEGIN LOGGING AT Sat Jun 20 03:00:22 2020 Jun 20 04:47:44 lmore377_: hrrm i have one of those 2nd-screen-china whatnot's Jun 20 04:48:33 lmore377_: i want a move-made 2nd-thinkpad-screen, preferaby intrdependent-rotation, stick to existing thinpad screen somehow... Jun 20 05:05:22 how do i set the pcie mode of something in dts? im pretty sure this is the source of my woes: qcom-pcie 1b500000.pci: PCIe controller is not set to bridge type (hdr_type: 0xff)! Jun 20 05:05:42 or does it need to be changed in uboot Jun 20 05:09:17 lmore377_: fwiw I (thought) on lots of thees emebedded gadgets the appropriate dts is provided with uboot/kernel as opposed to in some separate firmware "bios" Jun 20 05:12:17 enyc: im porting openwrt to a new device and the oem fw was built before this patch sneaked into kernel 5.4 and i dont see anything having to do with setting the pci mode in the original dts https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pci/controller/dwc?h=v5.4.43&id=0b24134f7888175c9638e6fd1900e23e44fc172f Jun 20 05:16:26 at least i think that's the patch that's causing this. building in 4.19 works fine Jun 20 05:30:47 enyc: that is the idea, but aside from the rare breed of server class ARM systems, reality is very, very different Jun 20 05:33:17 devices usually are on the market long before anyone starts working on device support and mainline drivers for it, so the DTS evolves with the kernel and its driver support. bootloaders are generally ancient forks of u-boot, often without any means to separate DTS and kernel (so the FDT gets appended to the kernel) - and devices don't even have any storage for a device specific DTS (aside from it Jun 20 05:33:23 being part of the kernel) Jun 20 05:40:03 also the uboot on this thing has the pci command but askey decided to strip out all the help enteries for all the commands Jun 20 05:40:09 help Jun 20 05:40:26 ignore that, forgot to alt tab back to my serial console lol Jun 20 07:25:56 lmore377_, maybe send a mail to ppl involved and the (correct) subsystem mailing list and report a regression with your hardware / board Jun 20 07:26:29 I dont know how easy it is to enable some "quirks" or write up special case handling Jun 20 07:27:33 will the router have to support 5.4 if I want to add it to the main openwrt repo? 4.19 is pretty much perfect Jun 20 07:27:37 its probably accepted in Kernel-Land that many boot loaders, BIOS, UEFI are buggy when setting up hardware and there have to be some special case Jun 20 07:29:19 lmore377_, yes because the next release will not work - and if a board doesnt work its a bug - and that issue will be reported to upstream anyway Jun 20 07:31:47 keeping 4.19 is basically a vendor approach - you have a fixed version and if that fixed version isnt supported anymore - 4.19 until end of 2024 the users are out of luck Jun 20 07:33:58 if you know the bad commit did you already try to revert it in a custom 5.4 compiled kernel ? Jun 20 07:34:17 as a first step to "fix" the issue Jun 20 07:38:49 honestly i really dont know much about kernel level things at all. the only reason i kniw that patch exisits is because of this post in the thread for this router: https://forum.openwrt.org/t/askey-rac2v1k-support/15830/23 Jun 20 07:42:57 well you dont have to know much - first you are a user of the Kernel with hardware that (i dont know) has stopped working or lost some functionality since a certain patch in the Kernel and you are reporting Jun 20 07:45:31 lmore377_: what happens if you try to specify the same mode in DT as detected? Jun 20 07:48:02 PaulFertser: that's what i've been trying to do but i haven't figured out what to add/change Jun 20 07:48:17 lmore377_: I'm looking through the source code, trying to understand what it takes Jun 20 07:51:33 thanks Jun 20 07:51:53 lmore377_: what compatible line are you using for pci controller? Jun 20 07:51:55 maybe asking on the kernel / subsystem mailing list might help - since they mention DT setup so they should know which one Jun 20 07:52:23 i think lmore just extracted the dtb and didnt write it himself Jun 20 07:54:15 plntyk: i took the dtb for the r7800 and edited parts of it to get it to match up with the oem dt. worked fine with 4.19 Jun 20 07:55:10 PaulFertser: i didn't specify anything so it's just using the default: "qcom,pcie-ipq8064" Jun 20 07:57:28 lmore377_: hdr_type 0xff doesn't look sane Jun 20 08:00:06 PaulFertser: i just looked at the dtsi files it imports and noticed that there's 2 extra registers compared to oem. just added that line and added "compatible = "qcom,pcie-ipq8064-v2";" so now we'll see if it worked or not in 15 minutes or so Jun 20 08:00:15 lmore377_: I wouldn't be surprised if the issue is elsewhere. I'd build with 'goto err_free_msi;' commented out to see if it magically works. Jun 20 08:00:51 i added that compatible line because oem has it Jun 20 08:04:25 for a regression report between 4.19 and 5.4 with that upstream patch one should probably dump all the config registers of the PCIe too Jun 20 08:04:34 https://elixir.free-electrons.com/linux/v5.4/source/Documentation/devicetree/bindings/pci/qcom,pcie.txt lists 4 different config domains Jun 20 08:19:50 just a little spook that just happened, the battery bank on my bed lit up by itself Jun 20 08:31:18 Oh now I'm getting a different error. hmmm Jun 20 08:32:37 qcom-pcie 1b500000.pci: Missing *config* reg space Jun 20 08:40:27 i changed some things and but i gotta do make clean so ill report back im problably like an hour Jun 20 08:40:36 in* Jun 20 09:12:11 it was a false lead. i think the only option is to just email the people that made the patch Jun 20 09:13:52 actually i'll try filing a bug at the bugzilla dor the kernel Jun 20 09:13:57 for* Jun 20 09:21:38 well not yet actually. i fell like there has to be something i can do in the dts, specially since the patch explicitly says that it checks the dt "To make sure there is no discrepancy (e.g. FW configured the port to EP mode while the DT specifies it as a host bridge or vice versa), a check has been added for each mode." Jun 20 09:40:34 lmore377_: but 0xff doesn't match either bridge or EP. That header is not read properly at all apparently. Jun 20 09:40:52 lmore377_: so the error you see is probably a manifistation of other problem rather than the actual cause. Jun 20 09:41:16 lmore377_: and you can just patch it out right in the sources (build_dir/target/*/linux*/linux*/ and rebuild the image for testing. Jun 20 09:52:52 U-Boot> if test "${bootedfrom}" == "${bm_dev}"; then echo yes; fi Jun 20 09:52:52 yes Jun 20 09:52:52 U-Boot> printenv bootedfrom Jun 20 09:52:52 bootedfrom=eMMC Jun 20 09:52:53 U-Boot> printenv bm_dev Jun 20 09:52:53 bm_dev=SD Jun 20 09:52:55 U-Boot> Jun 20 09:52:57 * dwmw2_gone frowns at u-boot Jun 20 09:54:31 oh, one = Jun 20 09:56:01 those sneaky == = differences Jun 20 09:58:14 == in shell scripts is a bashism Jun 20 17:51:52 oh, I thought that libubox regression was part of 19.07.3, but it is not Jun 20 17:51:57 *libubox regression fix Jun 20 18:41:16 Paul Jun 20 23:34:47 PaulFertser: its a pci config problem. i finally found a help thing for the pci command and running pci long in u-boot says that it's found pci device 00.00.00 through 00.1f.00 and the config registers are the same for all of them (including class code which is 0xff) https://pastebin.com/hiSpxkez Jun 21 01:10:00 so if i run bootipq (which fails because oem firm is gone) all of the pci devices disappear from uboot but when i boot it works fine **** ENDING LOGGING AT Sun Jun 21 02:59:58 2020