I wonder what "improvements" have been hacked into the latest Khadas bootloader.
Maybe related to this: init/Kconfig: increase INIT_ENV_ARG_LIMIT as otherwise maybe the limi… · CoreELEC/[email protected] · GitHub
I wonder what "improvements" have been hacked into the latest Khadas bootloader.
Maybe related to this: init/Kconfig: increase INIT_ENV_ARG_LIMIT as otherwise maybe the limi… · CoreELEC/[email protected] · GitHub
Why haven't you PR'd your changes yet?
Because you refused the changes I proposed on Slack. And I don't bother doing same thing twice.
Want a cookie?
Yes please. Can I send you an address?
Because I was bored today I looked this issue just for fun. Like Gentoo Wiki link I posted.
After examining how U-Boot works with extlinux.conf I noticed that there is a tag named FDTDIR which specifies the directory where FDT files are located. The actual filename is set by U-Boot and allows booting similar devices from same image. The requirement is that all dtb files must be in some folder pointed by FDTDIR tag.
So there is no need to use 2 (or more) images and follows LE way of using modern extlinux.conf
Seems I'm still the most knowledgeable man with i.MX6Q U-Boot
I can only think: OMG. You should just say "I don't know how to do this generic for ALL devices including iMX6". Because I really doubt that there are technical incapacity.
And why do you have to set dtb file anyway? Leave this to u-boot. Like this: Cubox-i - Gentoo Wiki I don't see file specified there.
Anyway, I just had to to point on a stupid thing taking years. And it seems situation will just be like that forever. Good job!
I'm interested to know what happens when users with a quad board don't change the dtb name and boot using the dual dtb? (or should the defaults be switched to quad?). Also, looking at the device-tree files in the kernel, didn't we (you) also used to ship an image for the Hummingboard devices?
Users don't need to set any dtb name because all magic is happening automatically in u-boot. U-boot for solidrun check the SoC type and sets one part of the dtb (imx6dl or imx6q). Then it also checks the SoM type (cubox, hummingboard, hummingboard2) and at the end also SoM revision (v15 or nothing). So same image runs on every device from solidrun without knowing what type it is and without setting dtb name. Same thing is happening on u-boot for Wandboard and Udoo. But there is probably just setting SoC type (at least this was true for Udoo when I add support for it).
But maybe mainline u-boot remove or broke all those things
So lrusak: you still think it doesn't matter how u-boot works?
lrusak, you are still talking nonsense And doesn't care for users to make theirs live easier. And this post is proof: user doesn't need to know if he have dual or quad soc in his device. At least for i.MX6.
chewitt, sorry but my i.MX6 days are past (and ruined thanks to LE). And you seem to have expert just few posts above.
chewitt, you should know that I had better idea years back because I actually know how u-boot works on this SoC. But no one listen. And now I don't care anymore (but it still hurts after all this time).
After all this time there are still two images for cubox? What a nonsense.
Nobody knows how to do it ??
Read the instructions for the plugin.
Did someone actually tried this patch on LE build server?
could you please help me a little bit?
Sorry, but I'm not giving any help here anymore because of last events.
any possibility to update to PHP7
Sure, you just need to update version for php and maybe few other small things.
Dear balbes150,
sorry for my last posts. They were meant to be positive but not everyone saw the same. Same applies to Team LibreELEC.
To make this post more useful I would like to point it out that you made a typo in post #1,268 from Wednesday, 2:43 pm. Or maybe this was intentional because I do not know Amlogic platform well and mainline things always brings something new and better.
You can try to install touchscreen addon from LE repozitory and enable waveshare config. Maybe it will work.
Config file is /storage/.kodi/userdata/addon_data/service.proftpd/proftpd.conf. You can use editor vi or nano. Or edit this file over samba.
with the TEST account, I try the something.. and Owner/Group is test 10
This is ok.
I don't have any permission denied error. All operations work. But resuming download doesn't. And I don't think this is server problem but on the client side.
Can you write exactly what you are doing so I can repeat the same? How to restart/resume transfer?
EDIT: Seems resume download really doesn't work and starts from beginning. But resume upload works.
Maybe it is just client who doesn't resume (filezilla used here)? Because it always using RETR command and not REST.