Posts by meijjaa

I tried to hunt down the problem by adding some debug logging and a NULL pointer check over here: linux-amlogic-le/aml_thermal_hw.c at amlogic-3.14.y · kszaq/linux-amlogic-le · GitHub (because of something like this VBCL ).

But at some other boots the CPU seems to completely halt and a timeout is reported after 60 seconds. I think the a problem starts after registering the thermal callbacks over here: linux-amlogic-le/aml_thermal_hw.c at amlogic-3.14.y · kszaq/linux-amlogic-le · GitHub so switching modes freezes the CPU...?

Also tried to change the dynamics of booting a little by skipping USB initialization by U-boot (WARNING booting from USB will be disabled). Not sure if it helps yet but booting from NAND seems to be a lot faster .

Quote

fw_setenv bootcmd "if test ${bootfromnand} = 1; then setenv bootfromnand 0; saveenv; else run librefromsd; fi; run storeboot"

Also was hoping that changing the CPU governor helped but I guess not (included in 7.0.3.012d): projects/S905: set default CPU governor to ondemand · kszaq/LibreELEC.tv@d34caf6 · GitHub

Quote from kszaq

The speeds that we need to use is 115200 for initial communication and 2000000 afterwards. Thank you for the patch, I will include it in my next build!

Alright, thanks!
[hr]

Quote from Xitro01

Is 'wait for network' fixed in 012d? In 012c it stopped working after upgrading from 011. I had to create a ping autostart.sh myself.

Did you try to toggle the option in the GUI? Also are you sure it's the network connection? I noticed that sometimes the date isn't setup in time which also causes problems. Virtual RTC will just set the date to 1-1-2015 since we don't have a real RTC and the ntp client isn't triggered in time or at all.

Quote from kszaq

Great, thank you a lot!

Have you tried using sleep / nosleep option with hciattach? I'm curious whether this could resolve this as well.

Happy to be able to help!

The sleep option is only used for Atheros devices though, I think this patch is the only way to fix it.
hciattach.c\tools - bluez.git - Bluetooth protocol stack for Linux
hciattach.c\tools - bluez.git - Bluetooth protocol stack for Linux

Also maybe it's a good idea to leave the init speed to the default hciattach.c\tools - bluez.git - Bluetooth protocol stack for Linux
but the default final speed (3000000) doesn't seem to work. Maybe we should use standard baud rates for the final speed (thought I didn't try to optimize this yet) e.g.:
115200
230400
460800
921600

Quote from kszaq

Thanks. Please also grab
udevadm info /sys/bus/mmc/devices/sdio\:0001/sdio\:0001\:*
systemctl status brcmfmac_sdio-firmware-aml.service.

Also check if systemctl start brcmfmac_sdio-firmware-aml.service makes BT available?

Hi,

It turns out these Broadcom chips need a few reset retries after firmware upload. brcm_patchram already does this but hciattach just times out.

Here is a patch to fix hciattach, enjoy.

0001-hciattach-retry-device-reset-when-no-response.patch

Quote from Poida

I shortened the quote of your post in my response to only the relevant parts, so as not to create an outrageously long thread.
Those reading the response, can click the little green arrow in the quote to be taken to, and read your full, untouched post if they haven't already read it (those that have, really don't need the complete post presented to them again)

Glad that you discovered you no longer need any workaround in autostart.sh

Point taken :). But after a couple more reboots it turns out I still need the workaround for it to be stable (channels / EPG data / movies + music library not loaded), I should test more before making statements

Quote from Poida

The wait for network option in LE settings works fine here, wonder why you have to 're-invent the wheel' ? :s

Not really sure why you edited my quote or why it would work for me just because it works for you. All I can say is that I need it to get stable results every boot, maybe others can benefit.

edit:
Apparently although the option was enabled in the GUI it really wasn't, toggling the wait for network option in the GUI fixed it and no workaround is needed anymore :).

Quote from genecic

Hello guys and thank you kszaq for this amazing build.

i have a question and i don't know if also other users facing the same problem like me. I have used almost all the releases of kszaq from 009-012 but unfortunately the repos (official) like KODI repo etc are not updated automatically each time i start my device. I have to manually check for updates for the installed addons.

Is it common problem or its just my device? Is there a solution?

I have a MINI M8S II - 2GB S905X

Thank you

It looks to me like Kodi is started before the network is ready. I for instance have problems with Tvheadend PVR plugin and MySQL media database even with "wait for network" enabled on DHCP and static IP. I can't tell if this is because of the hardware or just a timing issue, probably should check some other devices to.

I use this workaround to halt Kodi for one ping to Google (or max 10 seconds):

/storage/.config/autostart.sh

(
 ping 8.8.8.8 -c 1 -I eth0 -w 10
)

Quote from kszaq

Newer than...?

This driver is not intended for the kernel we are using.

The timestamp is more recent than the last commit in your kernel tree so I assumed it would be more recent. But I really wouldn't know, that's why I was asking.

edit:
I just noticed it's just a pre-compiled blob from Samsung? Ow well, I see it's the same as the driver included in buildroot-openlinux-20160930. Please ignore my previous question :).

I could do some logging on the serial port if that would help?

Quote

Issues with booting? Freezes? Use a build with disabled temperature sensor:
http://kszaq.libreelec.tv/s905/7.0.3.012...led.img.gz

Looks like my MXQ Pro 4K (S905) needs to have the thermal driver disabled to prevent regular boot problems (getting stuck before the splash screen). But wouldn't this driver be needed to do proper thermal management? Also I see there is a newer thermal driver version available from Amlogic. Or maybe you already tested it?

aml_thermal-2016-08-18 (Index of /download/ARM/modules)

Quote from kszaq

Unfortunately I don't know what's the exact colour encoding output. I know that you can force RGB output - again don't if it's limited or full. Maybe someone with a TV set that shows these values would be able to help you. Currently there is no way to switch output colour range in Kodi.

According to my AVR (Denon x3300w) my s905 box outputs YCbCr 4:2:0. I haven't tried to force full RGB because I think 420 would prevent any color space converting and give the best result. Of course one could wonder what kind of internal processing is happening but picture quality is great so I'm happy :).

Quote from kszaq

Kernel driver has been available for some time at Index of /download/ARM/gpu

Amlogic doesn't have fbdev libs for S912, at least none that they can share. That's all I know.

Thanks, I think they are comparable to the ones made available by Arm? Mali GPU Drivers | Open Source Mali Midgard GPU Kernel Drivers – ARM Developer interesting though they only mention the T860 / T880 GPU.

I think we would be really lucky if they would put in the man hours to create this fbdev driver.

Quote from kszaq

Please don't. I'm in touch with Amlogic regarding fbdev libraries for S912. No ETA though.

Thanks! So maybe there is some hope still. Do you know why the t8xx support is not there? Except for the pretty well hidden kernel driver of course :). I could imagine they only care about Android DRM support but on the other hand t7xx and t6xx fbdev drivers are available.

Hi kszaq,

Thanks for all the hard work. I'm currently enjoying your S905 builds very much on my MXQ Pro 4k :).

Just for fun I also bought a km8 (s912).

So far I tried t8xx kernel drivers r11 and r12 which seem to load alright (as far as I can see).

On to the userspace I tried the included r6 driver which just reports a version mismatch(I assume?):

ERROR: EGL error in InitDisplay: 3003
ERROR: InitWindowSystem: Could not create display

Also did an arm 32-bit userspace build to try these Mali fbdev blobs (Mali GPU Drivers | Mali GPU User-Space Binary Drivers – ARM Developer).

But no luck, as expected they are device specific:

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x620 r0p1 status range [0..15], but none of the GPUs matched:
ERROR: Unable to create GUI. Exiting

Even the latest Amlogic buildroot only includes r6 userspace driver. I guess we just have to be patient...