Ergebnis 11 bis 20 von 23
Thema: Dinobot image selbst bauen
-
09.02.2018, 17:17 #11
- Registriert seit
- 17.06.2013
- Beiträge
- 1.788
- Thanks (gegeben)
- 1755
- Thanks (bekommen)
- 675
- Total Downloaded
- 0
- Total Downloaded
- 0
Box 1:Vu+ Uno 4K SE und Vu+ Duo 4K SEBox 2:Zgemma H7S und verkauft H7CBox 3:Verkauft: Vu+ Solo 4KBox 4:Verkauft: Zgemma H9 Twin und ComboBox 5:Verkauft: Dreambox One und TwoFrag doch mal im futeko-Forum nach dem SDK. Die sollten es haben.
Frei nach dem bekanntem Sprichwort "Gut Ding will Weile haben":
Gute Receiver brauchen Zeit, schlechte einen werbewirksamen Hype!
-
Advertising
-
10.02.2018, 09:24 #12
- Registriert seit
- 02.12.2017
- Beiträge
- 71
- Thanks (gegeben)
- 3
- Thanks (bekommen)
- 4
- Total Downloaded
- 0
- Total Downloaded
- 0
Box 1:U5PVR DeluxeHab grad vom Dinobot support die Antwort bekommen, dass das verbaute AP6335 Modul unter Linux nicht unterstützt wird und sie selbst versucht haben einen Treiber zu schreiben. Der hat aber nicht funktioniert. Darum wird es keine WiFi-Treiber für E2 geben.
Könnte gerade ein bisschen Kotzen (sorry) ...
-
10.02.2018, 13:49 #13
- Registriert seit
- 17.06.2013
- Beiträge
- 1.788
- Thanks (gegeben)
- 1755
- Thanks (bekommen)
- 675
- Total Downloaded
- 0
- Total Downloaded
- 0
Box 1:Vu+ Uno 4K SE und Vu+ Duo 4K SEBox 2:Zgemma H7S und verkauft H7CBox 3:Verkauft: Vu+ Solo 4KBox 4:Verkauft: Zgemma H9 Twin und ComboBox 5:Verkauft: Dreambox One und TwoNaja, ganz so kann es aber nicht stimmen, dass ein AP6335 Modul vom Linux-Kernel nicht unterstützt wird. Braucht man nur mal danach zu googeln und wird sofort fündig, dass bei anderen Boards mit einem AP6335 das recht problemlos möglich ist und funktioniert!
Frei nach dem bekanntem Sprichwort "Gut Ding will Weile haben":
Gute Receiver brauchen Zeit, schlechte einen werbewirksamen Hype!
-
10.02.2018, 14:39 #14
- Registriert seit
- 02.12.2017
- Beiträge
- 71
- Thanks (gegeben)
- 3
- Thanks (bekommen)
- 4
- Total Downloaded
- 0
- Total Downloaded
- 0
Box 1:U5PVR DeluxeHier nochmal, was ein gewisser David Zhao von Dinobot mir geschrieben hat:
The AP6335 module U5pvr is using does not have a Linux driver, only Android available. I was surprised same like you when I heard this from the vendor that a BCM chipset does not have Linux driver. The BCM chipset has but Module made by AP does not.
We tried to do the driver by ourselves but it does not work out after a few weeks of trying.
We have to accept the fact no Wifi for E2.
We need support from Ampak who could not provide necessary information.
-
10.02.2018, 14:49 #15
- Registriert seit
- 02.12.2017
- Beiträge
- 71
- Thanks (gegeben)
- 3
- Thanks (bekommen)
- 4
- Total Downloaded
- 0
- Total Downloaded
- 0
Box 1:U5PVR Deluxe@Old Hab ich eigentlich auch vorher gemacht und hab nichts entsprechendes gefunden - außer dass das AP6335 Modul ein BCM4335 integriert hat und darum dachte ich, dass das brcm80211 Modul es tun sollte. Dinobot widerspricht dem. Hast du evtl. ein oder zwei Referenzen, wo du das gefunden hast? Sofern dort keine proprietären Treiber verwendet werden, sondern "normale" (offen verfügbare) Linxutreiber würd ich das dem Supportmenschen dann schicken.
-
10.02.2018, 15:49 #16
- Registriert seit
- 17.06.2013
- Beiträge
- 1.788
- Thanks (gegeben)
- 1755
- Thanks (bekommen)
- 675
- Total Downloaded
- 0
- Total Downloaded
- 0
Box 1:Vu+ Uno 4K SE und Vu+ Duo 4K SEBox 2:Zgemma H7S und verkauft H7CBox 3:Verkauft: Vu+ Solo 4KBox 4:Verkauft: Zgemma H9 Twin und ComboBox 5:Verkauft: Dreambox One und TwoDer AP6335 hat eine BCM4339 Core für WLAN integriert und die wird seit langer Zeit vom Linux-Kernel unterstützt. Da der AP6335 ja auch unter Android läuft und Android auch nur ein gepatchter Linux-Kernel ist, wo ist da das Problem???
Schau mal bitte dort:
wlan-firmware/nvram_ap6335.txt at master * OpenELEC/wlan-firmware * GitHubGeändert von Old (10.02.2018 um 16:17 Uhr)
Frei nach dem bekanntem Sprichwort "Gut Ding will Weile haben":
Gute Receiver brauchen Zeit, schlechte einen werbewirksamen Hype!
-
10.02.2018, 18:41 #17
- Registriert seit
- 28.01.2018
- Beiträge
- 12
- Thanks (gegeben)
- 2
- Thanks (bekommen)
- 3
- Total Downloaded
- 0
- Total Downloaded
- 0
ThemenstarterBox 1:HD Duo X1 TrioBox 2:Atto NET i-SmartBox 3:Ferguson U5PVRBox 4:Egreat A5Zurück zum ursprünglichen Thema; leider bricht bei mir der Build immer an der gleichen Stelle ab.
Mein Kommando ist: MACHINE=dinobot4kse DISTRO=openatv DISTRO_TYPE=release make image
Dann endet es hier:
ERROR: libgcc-6.3.0-r0 do_package: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002opulate_packages(d)
0003:
File: '/home/openatvbuilder/openatv/build-enviroment/openembedded-core/meta/classes/package.bbclass', lineno: 1176, function: populate_packages
1172:
1173: mkdir_recurse(dvar, root, os.path.dirname(file))
1174: fpath = os.path.join(root,file)
1175: if not cpath.islink(file):
*** 1176: os.link(file, fpath)
1177: continue
1178: ret = bb.utils.copyfile(file, fpath)
1179: if ret is False or ret == 0:
1180: bb.fatal("File population failed")
Exception: PermissionError: [Errno 1] Operation not permitted: './usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libgcc/gthr-default.h' -> '/home/openatvbuilder/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/packages-split/libgcc-dbg/./usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libgcc/gthr-default.h'
ERROR: libgcc-6.3.0-r0 do_package: Function failed: populate_packages
ERROR: Logfile of failure stored in: /home/openatvbuilder/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/temp/log.do_package.16116
ERROR: Task (/home/openatvbuilder/openatv/build-enviroment/openembedded-core/meta/recipes-devtools/gcc/libgcc_6.3.bb:do_package) failed with exit code '1'
Ich habe gesehen, dass die Erstellung des Links nicht geht, da die Datei vom Benutzer Root ist:
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libgcc/gthr-default.h
-rw-r--r-- 1 root root 24196 Jan 4 2016 builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libgcc/gthr-default.h
Was mache ich falsch?
-
10.02.2018, 19:58 #18
- Registriert seit
- 05.12.2016
- Beiträge
- 188
- Thanks (gegeben)
- 5
- Thanks (bekommen)
- 77
- Total Downloaded
- 1,78 MB
- Total Downloaded
- 1,78 MB
Box 1:Vu+ Solo 4KBei mir gehören alle Dateien ab dem openavtbuilder Verzeichnis auch dem User openatvbuilder. Wie sich bei Dir der root reinschmuggeln konnte,weiß ich nicht, ich würde die Eigentümer aller Dateien mit dem chown Kommando auf den openatvbuilder umswitchen.
-
10.02.2018, 20:56 #19
- Registriert seit
- 28.01.2018
- Beiträge
- 12
- Thanks (gegeben)
- 2
- Thanks (bekommen)
- 3
- Total Downloaded
- 0
- Total Downloaded
- 0
ThemenstarterBox 1:HD Duo X1 TrioBox 2:Atto NET i-SmartBox 3:Ferguson U5PVRBox 4:Egreat A5Bis zu einer bestimmten Ebene ist es ja auch openatvbuilder, alles andere darunter dann root:
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libgcc/gthr-default.h
-rw-r--r-- 1 root root 24196 Jan 4 2016 builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libgcc/gthr-default.h
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/
total 8
drwxr-xr-x 2 root root 4096 Feb 10 21:02 gcc
drwxr-xr-x 2 root root 4096 Feb 10 21:02 libgcc
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0
total 4
drwxr-xr-x 4 root root 4096 Feb 10 21:02 build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/gcc-6.3.0
total 4
drwxr-xr-x 4 root root 4096 Feb 10 21:02 build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/6.3.0-r0/
total 4
drwxr-xr-x 3 root root 4096 Feb 10 21:02 gcc-6.3.0
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/libgcc/
total 4
drwxr-xr-x 3 root root 4096 Feb 10 21:02 6.3.0-r0
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/debug/
total 4
drwxr-xr-x 3 root root 4096 Feb 10 21:02 libgcc
openatvbuilder@saturn:~/openatv/build-enviroment$ ls -l builds/openatv/release/u5/tmp/work/armv7ahf-neon-oe-linux-gnueabi/libgcc/6.3.0-r0/package/usr/src/
total 4
drwxr-xr-x 3 openatvbuilder openatvbuilder 4096 Feb 10 21:02 debug
In der Tat habe ich schon versucht, chown --recursive alles auf openatvbuilder zu setzen. Aber erstaunlicherweise ist beim nächsten "make" alles wieder auf root.
-
16.02.2018, 19:43 #20
- Registriert seit
- 28.01.2018
- Beiträge
- 12
- Thanks (gegeben)
- 2
- Thanks (bekommen)
- 3
- Total Downloaded
- 0
- Total Downloaded
- 0
ThemenstarterBox 1:HD Duo X1 TrioBox 2:Atto NET i-SmartBox 3:Ferguson U5PVRBox 4:Egreat A5Habe jetzt meine VM auf Ubuntu 16.04 aktualisiert und der vorher beschriebene Fehler tritt nicht mehr auf.
Jetzt gibt es aber einen Fetcher-Fehler u.a. beim usb-modeswitch-1.2.4.tar.bz2
Kann ich die Quelle irgendwie ändern?
Hier ist die Ausgabe:
Code:WARNING: usbmodeswitch-data-20131113-r1 do_fetch: Failed to fetch URL 403 Forbidden, attempting MIRRORS if available WARNING: usbmodeswitch-1.2.4-r0 do_fetch: Failed to fetch URL 403 Forbidden, attempting MIRRORS if available ERROR: usbmodeswitch-data-20131113-r1 do_fetch: Fetcher failure: Fetch command export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-nh2wm0QiLF"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/spitzbube/openatv/build-enviroment/openembedded-core/scripts:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/recipe-sysroot/usr/bin/crossscripts:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/recipe-sysroot-native/usr/sbin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/recipe-sysroot-native/usr/bin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/recipe-sysroot-native/sbin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/recipe-sysroot-native/bin:/home/spitzbube/openatv/build-enviroment/bitbake/bin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/hosttools"; export HOME="/home/spitzbube"; /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/spitzbube/openatv/build-enviroment/sources 'http://pkgs.fedoraproject.org/repo/pkgs/usb_modeswitch-data/usb-modeswitch-data-20131113.tar.bz2/7b5ac1226b360ddc366c286e62b3c3a4/usb-modeswitch-data-20131113.tar.bz2' --progress=dot -v failed with exit code 8, output: --2018-02-16 20:32:30-- 403 Forbidden Resolving pkgs.fedoraproject.org (pkgs.fedoraproject.org)... 209.132.181.4 Connecting to pkgs.fedoraproject.org (pkgs.fedoraproject.org)|209.132.181.4|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2018-02-16 20:32:32 ERROR 403: Forbidden. ERROR: usbmodeswitch-data-20131113-r1 do_fetch: Fetcher failure for URL: 'http://pkgs.fedoraproject.org/repo/pkgs/usb_modeswitch-data/usb-modeswitch-data-20131113.tar.bz2/7b5ac1226b360ddc366c286e62b3c3a4/usb-modeswitch-data-20131113.tar.bz2'. Unable to fetch URL from any source. ERROR: usbmodeswitch-data-20131113-r1 do_fetch: Function failed: base_do_fetch ERROR: usbmodeswitch-1.2.4-r0 do_fetch: Fetcher failure: Fetch command export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-nh2wm0QiLF"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/spitzbube/openatv/build-enviroment/openembedded-core/scripts:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/recipe-sysroot/usr/bin/crossscripts:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/recipe-sysroot-native/usr/sbin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/recipe-sysroot-native/usr/bin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/recipe-sysroot-native/sbin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/recipe-sysroot-native/bin:/home/spitzbube/openatv/build-enviroment/bitbake/bin:/home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/hosttools"; export HOME="/home/spitzbube"; /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/spitzbube/openatv/build-enviroment/sources 'http://pkgs.fedoraproject.org/repo/pkgs/usb_modeswitch/usb-modeswitch-1.2.4.tar.bz2/dbd4ce7966d7b4a5a0604a8280f7164d/usb-modeswitch-1.2.4.tar.bz2' --progress=dot -v failed with exit code 8, output: --2018-02-16 20:32:30-- 403 Forbidden Resolving pkgs.fedoraproject.org (pkgs.fedoraproject.org)... 209.132.181.4 Connecting to pkgs.fedoraproject.org (pkgs.fedoraproject.org)|209.132.181.4|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2018-02-16 20:32:32 ERROR 403: Forbidden. ERROR: usbmodeswitch-1.2.4-r0 do_fetch: Fetcher failure for URL: 'http://pkgs.fedoraproject.org/repo/pkgs/usb_modeswitch/usb-modeswitch-1.2.4.tar.bz2/dbd4ce7966d7b4a5a0604a8280f7164d/usb-modeswitch-1.2.4.tar.bz2'. Unable to fetch URL from any source. ERROR: usbmodeswitch-1.2.4-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch-data/20131113-r1/temp/log.do_fetch.3548 ERROR: Logfile of failure stored in: /home/spitzbube/openatv/build-enviroment/builds/openatv/release/u5pvr/tmp/work/armv7ahf-neon-oe-linux-gnueabi/usbmodeswitch/1.2.4-r0/temp/log.do_fetch.3549 ERROR: Task (/home/spitzbube/openatv/build-enviroment/meta-oe-alliance/meta-oe/recipes-connectivity/usb-modeswitch/usbmodeswitch-data_20131113.bb:do_fetch) failed with exit code '1' ERROR: Task (/home/spitzbube/openatv/build-enviroment/meta-oe-alliance/meta-oe/recipes-connectivity/usb-modeswitch/usbmodeswitch_1.2.4.bb:do_fetch) failed with exit code '1' NOTE: Tasks Summary: Attempted 1849 tasks of which 1845 didn't need to be rerun and 2 failed.
Geändert von Papi2000 (16.02.2018 um 20:57 Uhr) Grund: in Code gesetzt...
Lesezeichen