es8316

[wdthompson]

The driver ,, module snd_soc_es816 continues to be "bad" (rockpro) . I don't know if other rk3399 have this problem....compleatly fills dmesg with spam Problem is, cfg="Y" ,, should be m or "" ... Also, how to change uboot,, boot_tatgerts order, I mean I can interupt boot and env set .... but would rather not have to

[pyavitz]

What Distro Release and Kernel Version?

NOTE: I don't own this board so I have no idea of its behavior.

Boot targets are defined by this patch: https://github.com/pyavitz/debian-image-builder/blob/feature/patches/uboot/v2023.01/rk3399/001-rk3399-rockchip-common-usb-nvme-boot.patch

If you just wanna use the defaults, disable the patch and rebuild u-boot. You can update u-boot on the board, by manually installing the deb sudo dpkg -i u-boot*.deb and running sudo /lib/u-boot/flash*

I don't know what you mean by this? cfg="Y"

I have a NanoPC-T4, but I have never seen it spam the dmesg with anything audio related. Could also be that I just use it headless, I'll take a look and see what it does.

[wdthompson]

Sorry, should have been more clear CONFIG_SND_SOC_ES8316=m in rockchip64-rk3399_defconfig I changed it to m, it started as =y Maybe the NanoPC-T4 uses a different sound chip? As to uboot, When I put a bootable sd card in, that is what I want to boot If I don't want it to boot, then I just wait a few seconds going to uboot source and..... grep -r boot_targets * |grep rock only gets me binaries. If I remove the last grep, several other boards not rock

Oh, and let me say, I really like this software, it does a really good job Thank You ( and why did it bold everything else...shrug) kernel 6.1.30, chimera and daedalus I see the image in https://arm-files.devuan.org/ (rockpro64) has CONFIG_SND_SOC_ES8316= and that is 5.6.10

Maybe I should be using something like savenv but I know almost nothing about uboot

[pyavitz]

Not sure about the RP64, but the default is usually SD/eMMC as a boot target. The patch I apply has the unit check the USB/NVME for something bootable before checking the MMC. You can join our discord, I'm sure someone there has this unit and could be more help on this front. https://discord.gg/mypJ7NW8BG

As for the SND SOC, I can set it to M instead Y if that corrects ur issue? and Yes, the NPi-T4 uses something different.

You are welcome. Thanx.

[wdthompson]

Since it seems to be a serious-long standing issue (soc_es8316) maybe =m boot_targets as stock are MMC0 MMC1 USB0 NVMEsomething,,, some net stuff I just want to reverse the first 2 include/bootstd.h........ /**

• bootstd_get_bootdev_order() - Get the boot-order list
• This reads the boot order, e.g. {"mmc0", "mmc2", NULL} .........BUT from WHERE? Thanks --more-- maybe I was not initially clear, dmesg is just FULL of the same error msg (es8316) shift-pgup 20 or 30 times (but then I recompiled and installed over problematic kernels so OK now,just next guy)

[wdthompson]

About uboot, the one made by your script does indeed prioritize mmc1,, specifically boot_targets=usb0 nvme0 mmc1 mmc0 scsi0 pxe dhcp sf0 but ,as so often, it is a bit defective, does a bootloop,, and even more annoying somehow the emmc does not show (lsblk), in 3 different distros ???? Anyway, went back to original maybe a bug, maybe not, this with putty (ssh),, (cause I like large fonts) In the scripts, -eq seems to error if only surronded by [ ... ] rather than [[ ... ]] For the rockpro64 , nprocs which I assume =6 seems to be too much, manually set it to 4 which seems to work a lot better

[pyavitz]

There very well could be a bug in it. I added the board as a request and at the time had to mod the defconfig to get the board to boot, I think I have since removed those mods? I can attempt to put them back and see if it makes any differences?

As for u-boot and rockchip, whenever there is an eMMC available and u-boot is flashed to it, in my experience it will take priority over the initial boot process. Meaning if you wanna boot off the u-boot on the SDCARD, you need to put it into maskrom mode or else the u-boot on the eMMC will load.

This is also common on other SoC's like Amlogic, especially in the case of say a TVBOX.

Another problem, is that vendor u-boot doesn't play well with mainline, so it is recommended to purge vendor u-boot off the eMMC if you are trying to use mainline on the SD or else where.

As for lsblk not working, I'm not sure why that? Never seen that before. My guess is either something is off with the u-boot setup in the builder on the RP64 or ur eMMC is going bad.

To run the builder burning on all $CORES you need active and passive cooling when on RK3399.