04:15 <tuxd3v> still no sound :(

04:15 <tuxd3v> https://paste2.org/VfK5kH8A

09:42 <nomis> JPEW: can you tell me where the devicetree to include into the fitsImage (?) is specified?

09:43 <nomis> JPEW: it worked out of the box with the linux-yocto image, but now I'd prefer a separate recipe for the devicetree, using the devicetree.bbclass. The devicetree ends up in a different place and no longer is included into the fitImage (I think).

09:57 <nomis> Hm, the rockchip-gpt-img.bbclass seems to depend on the KERNEL_DEVICETREE variable. But I don't want to set that since that'd make the kernel-build fail (no matching target for the devicetree)

10:02 <nomis> wait. Am I using that one at all? I am building .wic-images.

11:45 <sigmaris> tuxd3v: once you get the ES8316 "soundcard" showing up in alsamixer, you need to turn on "Left Headphone Mixer Left DAC Switch" to hear any sound

11:45 <sigmaris> and the same for the Right channel too

11:46 <sigmaris> also turn up Headphone Playback/Mixer/DAC Playback volume

13:18 <JPEW> nomis: rockchip-gpt-img.bbclass is deprecated in favor of wic images

13:22 <JPEW> nomis: Are you saying you want an out of tree device tree to be put into the fitImage, or do you want in-tree device tree to be kept out of the fitImage?

13:23 <nomis> JPEW: (I managed to resolve this in the meantime)

13:23 <nomis> JPEW: I had the problem that rebuilding images takes quite a long time.

13:24 <nomis> a small change in the devicetree would trigger a rebuild of the linux-yocto recipe, taking in total about 15mins.

13:24 <nomis> So I was looking for a way to decouple the devicetree from the linux-yocto.

13:25 <nomis> I found that "devicetree.bbclass" and at first failed to build a recipe where the devicetree would actually end up in the fitimage (where it is needed by the boot process)

13:26 <nomis> I tracked the fitimage build process down and found out that I was missing a PREFERRED_PROVIDER_virtual/dtb

13:27 <JPEW> nomis: Ah, cool. That worked then?

13:28 <nomis> JPEW: yeah. Time got down to at least 50% or more.

13:28 <nomis> not that the wifi works yet though... :-/

13:28 <JPEW> nomis: Glad that worked. I've never tried it before :)

13:30 <nomis> JPEW: for the records: the kernel-fitimage.bbclass depends on a nonzero "PREFERRED_PROVIDER_virtual/dtb" to trigger the inclusion.

13:30 <nomis> (otherwise it'll just include the dtbs from the kernel tree)

13:31 <nomis> oh, and I think "KERNEL_DEVICETREE" must not be set.

13:31 <nomis> would have to look at the logic again though.

13:50 <nomis> Hrm. reading tea-leaves in devicetrees here.

13:50 <nomis> If a node has a <phandle> dtc probably had a reason for adding it, right?

13:52 <nomis> the only difference between "my" devicetree with a nonfunctional sdmmc_ext and one working (with an older kernel) is, that the latter does have a phandle in the dwmmc@ff5f0000 section. But I don't see why, I can't spot a reference to it.

16:39 <tuxd3v> sigmaris, thanks,

16:40 <tuxd3v> I tried to enable everything but still no sound on analog :(

16:40 <tuxd3v> Maybe I missed sme config..

16:40 <tuxd3v> Another thing, I wanted to caclibrate bogomips

16:40 <tuxd3v> [ 0.004307] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)

16:41 <tuxd3v> I kinow that its possible to calibrate, but I don't remember how

16:50 <robmur01> tuxd3v: https://lkml.org/lkml/2015/1/6/867 - whatever people think they want to do with that value is usually wrong ;)

17:05 <Ke> nice WWE flame war there

17:09 <tuxd3v> robmur01, thanks

17:10 <tuxd3v> I know that it is not what a lot of people thinks it is.. :)

17:12 <tuxd3v> Ke, indeed, I believe linus rejected the patch :)

17:22 <robmur01> anyway, on arm64 the architected timer has always been mandatory, so I don't think we even have code for loop-based delays

17:28 <nomis> this wifi thing is killing me.

17:29 <tuxd3v> nomis, too much radiation

19:03 <robmur01> nomis: FWIW my 3318 box also has a phandle (0xca) on sdmmc_ext, even though it's not even enabled - looks like it might just be some irrelevant crap that happens to be in the BSP sources

19:28 <nomis> probably some random devicetree sources that get copied around, carrying a lot of cargo cult in them.

19:29 <nomis> like the devicetrees found in various forums, which are obviously built from decompiling dtbs.

19:52 <robmur01> or that bloody "depending on the module installed..." comment for SDIO power sequences which was only ever relevant to older EVBs that actually had pluggable SDIO daughterboards...

20:03 <nomis> robmur01: that comment actually made sense for my a5x board (I think). The a5x is available with two different wifi/bt-modules and the one I have here is the one with the ap6255, and the pin name on the ap6255 for the power switch is the same as the first one mentioned in this comment.

20:03 <nomis> (well, I can only suspect that the other name is the one from the resp. realtek module)

20:15 <robmur01> heh, and a stopped clock is right twice a day ;)