Buildumgebung für die AX-Entwickler/Tester

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ich hab das NI BS auch installiert, sind damit auch andere für HD51 Images möglich? Oder ist man damit auf NI festgelegt?
      Mich schreckte erst ab das von vorn herein nur der Support für Debian angekündigt wurde, jedoch auch mit Hinweis auf Verwendung auf Ubuntu wurde mir dort geholfen. ;)
      Nur das Yocto BS hat sich hier heftig gewehrt, ich habs dann aus Unerfahrenheit aufgegeben.
      Lieber Fernsehgeil als Radioaktiv!
    • Mit dem NI Buildsystem kann man hd51 und CST Images bauen, je nach dem was man eingestellt hat.

      Quellcode

      1. # config.local
      2. # Change it to your name.
      3. MAINTAINER = Dumpfbacke
      4. # Choose one (1) of the following BOXMODELs. O n e !
      5. # Coolstream
      6. #BOXMODEL = nevis
      7. #BOXMODEL = apollo
      8. #BOXMODEL = shiner
      9. #BOXMODEL = kronos
      10. #BOXMODEL = kronos_v2
      11. # AX Technologies
      12. BOXMODEL = hd51
      13. # Create debug-image. Not useful in real life.
      14. #DEBUG = yes
      Alles anzeigen
    • bazi98 schrieb:

      südschwede hat bei seinen BS die libttool version 2.4.6-2 und ich habe bei meinen ubuntu die 2.4.6-0.1 also beide neuer als deine, wie jung die Version aber mindestens sein muss kann ich dir nicht sagen
      Danke, mit 2.4.6 läuft es weiter bis hierher:

      Quellcode

      1. checking whether -lc should be explicitly linked in... no
      2. checking dynamic linker characteristics... GNU/Linux ld.so
      3. checking how to hardcode library paths into programs... immediate
      4. checking whether stripping libraries is possible... yes
      5. checking if libtool supports shared libraries... yes
      6. checking whether to build shared libraries... yes
      7. checking whether to build static libraries... yes
      8. checking to see if compiler understands -Wall... yes
      9. checking for pkg-config... yes
      10. ./configure: line 12083: syntax error near unexpected token `GST,'
      11. ./configure: line 12083: `PKG_CHECK_MODULES(GST, \'
      12. make: *** [/home/getaway/cs-hd51/.deps/gst_plugin_subsink] Fehler 2
      Alles anzeigen
    • walter1212 schrieb:

      Ich hab das NI BS auch installiert, sind damit auch andere für HD51 Images möglich? Oder ist man damit auf NI festgelegt?
      Mich schreckte erst ab das von vorn herein nur der Support für Debian angekündigt wurde, jedoch auch mit Hinweiis auf Verwendung auf Ubuntu wurde mir dort geholfen. ;)
      Nur das Yocto BS hat sich hier heftig gewehrt, ich habs dann aus Unerfahrenheit aufgegeben.
      Wenn du mal wieder yocto testest, einfach die Fehlermeldung posten. So kann ich da wenig dazu sagen




      Janus schrieb:

      Wie wäre es mit einem aktuellen (ax-bezogenen) Howto für interessierte Selbstbauer der hier verwendeten Buildumgebung mit Buildsystem und Quelle der Sourcen. Die Stelle hier ist auch für später "Suchende" zentral.

      Sich das hier einzeln aus den Foren und Monsterthreads raussuchen zu müssen, ist eher abschreckend für den 'Nachwuchs'.

      Ich würde es ja selbst machen, gehöre aber eher zu denen, die es yoctomäßig erst werden wollen
      Ich denke, für die Eingeweihten ist das eine überschaubare copy&paste - Arbeit.

      Für deinen Zweck wäre das yocto sdk vermutlich sinnvoller als das BS. Finden kannst du das hier:

      yocto sdk

      Im tar Archiv befindet sich eine ausführbare sh Datei, die das sdk an eine beliebige Stelle kopiert (default ist ~/tuxbox_sdk)

      Bedient wird das ganz ähnlich, wie das Buildsystem. Zuerst muss man mit:


      Quellcode

      1. cd ~/tuxbox_sdk
      2. ./environment-setup-cortexa15hf-neon-vfpv4-oe-linux-gnueabi

      in das Verzeichnis wechseln. Zentrales Werkzeug im sdk ist das "devtool". Damit lässt sich das ganze steuern. Zunächst vielleicht mal ohne Parameter aufrufen, damit man sieht, was damit alles möglich ist:

      Quellcode

      1. OpenEmbedded development tool
      2. options:
      3. --basepath BASEPATH Base directory of SDK / build directory
      4. --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it
      5. from the metadata
      6. -d, --debug Enable debug output
      7. -q, --quiet Print only errors
      8. --color COLOR Colorize output (where COLOR is auto, always, never)
      9. -h, --help show this help message and exit
      10. subcommands:
      11. Beginning work on a recipe:
      12. add Add a new recipe
      13. modify Modify the source for an existing recipe
      14. upgrade Upgrade an existing recipe
      15. Getting information:
      16. status Show workspace status
      17. search Search available recipes
      18. Working on a recipe in the workspace:
      19. build Build a recipe
      20. rename Rename a recipe file in the workspace
      21. edit-recipe Edit a recipe file in your workspace
      22. find-recipe Find a recipe file in your workspace
      23. configure-help Get help on configure script options
      24. update-recipe Apply changes from external source tree to recipe
      25. reset Remove a recipe from your workspace
      26. finish Finish working on a recipe in your workspace
      27. Testing changes on target:
      28. deploy-target Deploy recipe output files to live target machine
      29. undeploy-target Undeploy recipe output files in live target machine
      30. package Build packages for a recipe
      31. build-image Build image including workspace recipe packages
      32. runqemu Run QEMU on the specified image
      33. Advanced:
      34. build-sdk Build a derivative SDK of this one
      35. extract Extract the source for an existing recipe
      36. sync Synchronize the source tree for an existing recipe
      37. export Export workspace into a tar archive
      38. import Import exported tar archive into workspace
      39. SDK maintenance:
      40. sdk-update Update SDK components
      41. sdk-install Install additional SDK components
      42. Use devtool <subcommand> --help to get help on a specific command
      Alles anzeigen

      Zunächst sollte man mal ein komplettes Image bauen. Weil die Buildartifakte mit im sdk ghespeichert sind, sollte das in wenigen Minuten erledigt sein:



      Quellcode

      1. devtool build-image

      Ist das erledigt, findet man das fertige Image in /tmp/deploy/images/hd51. Man kann jetzt z.B Änderungen an Neutrino durchführen, indem man den Quellcode in den Workspace holt:

      Quellcode

      1. devtool modify neutrino-mp-ax51


      ... den Quellcode in workspace/sources/neutrino-mp-ax51 bearbeiten. Das geänderte Paket bauen:

      Quellcode

      1. devtool build neutrino-mp-ax51

      und hinterher zum Testen auf die Box kopieren:

      Quellcode

      1. devtool deploy-target neutrino-mp-ax51 root@192.168.x.x

      danach wieder deinstallieren mit:

      Quellcode

      1. devtool undeploy-target neutrino-mp-ax51 root@192.168.x.x


      Man kann sich mit:


      Quellcode

      1. devtool modify paketname

      den Quellcode von jedem Paket des Images zur Bearbeitung in den Workspace holen. Soll der Quellcode bereinigt werden, hilft:


      Quellcode

      1. devtool reset paketname

      Das sdk beinhaltet sämtliche verwendeten yocto layer. Die findet man in layers/poky. Dort kann man die Recipes finden und bearbeiten

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von flk ()

    • bazi98 schrieb:

      Anscheinend ist es ungewünscht oder man darf hier nicht über das NI-BS diskutieren ...

      Miky1968 schrieb:

      Ich verstehe gar nicht, warum man NI Sachen hier diskutiert.
      ich werde auf jeden Fall nichts zu den BS schreiben da sonst nur wieder auf mich eingehauen wird.
      Genau aus dem Grund habe ich vom NI wieder Abstand genommen :D
      --> 2xT90 mit 16 Satpositionen 42,0O-30,0W
      --> 2xAX HD51 4KUHD PVR
      --> 1xCoolstream Tank PVR
      --> 2xCoolstream Trinity PVR
      --> 1xCoolstream NEO² PVR
      --> 1xCoolstream NEO PVR
      --> 1xCoolstream ZEE PVR
      --> 1xCoolstream HD1 PVR
      --> 1xOpenbox SX6 CI+
      --> 1xOpenbox X810
    • GetAway schrieb:

      Danke, mit 2.4.6 läuft es weiter bis hierher:

      Quellcode

      1. checking whether -lc should be explicitly linked in... no
      2. checking dynamic linker characteristics... GNU/Linux ld.so
      3. checking how to hardcode library paths into programs... immediate
      4. checking whether stripping libraries is possible... yes
      5. checking if libtool supports shared libraries... yes
      6. checking whether to build shared libraries... yes
      7. checking whether to build static libraries... yes
      8. checking to see if compiler understands -Wall... yes
      9. checking for pkg-config... yes
      10. ./configure: line 12083: syntax error near unexpected token `GST,'
      11. ./configure: line 12083: `PKG_CHECK_MODULES(GST, \'
      12. make: *** [/home/getaway/cs-hd51/.deps/gst_plugin_subsink] Fehler 2
      Alles anzeigen
      Gelöst mit update von pkg-config 0.26 --> 0.29.1
    • flk schrieb:
      Für deinen Zweck wäre das yocto sdk vermutlich sinnvoller als das BS

      Liest sich wirklich so.

      Leider lief das in meiner Jessie-vmWare genauso in fehlermeldungen wie der Bau des Yocto BS.

      ERROR: SDK preparation failed: error log written to /home/janus/development/yocto/sdk/ax/preparing_build_system.log
      janus@vmJessie:~/development/yocto/sdk$
      Ich hänge das Log mal an.
      preparing_build_system.log.tar.gz

      Hab's aber nicht eilig, Box ist noch tabu!
      Ich probiere das am WE noch auf meiner Linux-Kiste mit purem Jessie.
      Vielleicht passt das ja besser...
    • im DDT wurde etwas rum optimiert, deswegen:

      1) make crosstool-renew
      2) make update-self
      3) make update

      zum Update, und dann wie bisher:

      4.) ./make.sh 37 1 1 1 3
      5) make neutrino-mp-tangos-plugins
      6) make flashimage

      Kann auf schwachen Rechnern etwas dauern, da der crosscompiler neu gebaut werden muss.
      (ca 15 Min. auf nem Intel Xeon E3-1240 v3 @ 3.40GHz mit 16GB im Heizlüfterbetrieb)
      a.k.a. DaHooD

      Es gibt nur 10 Arten von Menschen auf der Welt, die die binär können, und die die die anderen 1000 suchen.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von TangoCash ()

    • Hinweis:
      Seit dem Update der Treiber für die HD51, ist ein "make kernel-distclean" unbedingt nötig, damit ein erstelltes Image hinterher bootet !

      Edit:

      Einmal komplett neu bauen wäre also:

      Quellcode

      1. make update kernel-distclean neutrino-mp-tangos-plugins flashimage
      a.k.a. DaHooD

      Es gibt nur 10 Arten von Menschen auf der Welt, die die binär können, und die die die anderen 1000 suchen.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von TangoCash ()

    • 2 neue Features im Buildsystem:

      boxmode 12 kann man nun wählen.
      Fest einstellen per: ./make.sh

      oder nur beim erstellen vom Image:
      make HD51_BOXMODE=12 flashimage

      Zusätzlich gibt es noch ein neues target:
      make ofgimage

      Dabei wird eine kleines Image erstellt zum flashen per ofgwrite.
      a.k.a. DaHooD

      Es gibt nur 10 Arten von Menschen auf der Welt, die die binär können, und die die die anderen 1000 suchen.
    • Hi,

      ich habe mal ein aktuelles ubuntu in einer Virtualbox installiert und wollte auch nach langer Zeit mal wieder ein Image bauen.
      bin so vorgegangen.

      1.) git clone "https://github.com/TangoCash/buildsystem-ddt.git"
      2.) cd ~/buildsystem-ddt
      3.) sudo ./prepare-for-bs.sh
      4.) ./make.sh 37 1 1 3 3 1
      5.) make update-self
      6.) make bootstrap

      leider bleibt er mit dieser Fehlermeldung hängen :(

      Spoiler anzeigen


      [INFO ] Installing binutils for host
      [INFO ] Installing binutils for host: done in 145.55s (at 09:28)
      [INFO ] =================================================================
      [INFO ] Installing pass-1 core C gcc compiler
      [ERROR] /home/hawke/buildsystem-ddt/build_tmp/crosstool-ng-1dbb06f2/targets/src/gcc-linaro-6.3-2017.02/gcc/ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
      [ERROR] make[3]: *** [ubsan.o] Error 1
      [ERROR] make[3]: *** Waiting for unfinished jobs....
      [ERROR] make[2]: *** [all-gcc] Error 2
      [ERROR]
      [ERROR] >>
      [ERROR] >> Build failed in step 'Installing pass-1 core C gcc compiler'
      [ERROR] >> called in step '(top-level)'
      [ERROR] >>
      [ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@338]
      [ERROR] >> called from: do_gcc_core_backend[scripts/build/cc/100-gcc.sh@674]
      [ERROR] >> called from: do_gcc_core_pass_1[scripts/build/cc/100-gcc.sh@227]
      [ERROR] >> called from: do_cc_core_pass_1[scripts/build/cc.sh@35]
      [ERROR] >> called from: main[scripts/crosstool-NG.sh@655]
      [ERROR] >>
      [ERROR] >> For more info on this error, look at the file: 'build.log'
      [ERROR] >> There is a list of known issues, some with workarounds, in:
      [ERROR] >> 'docs/B - Known issues.txt'
      [ERROR] >>
      [ERROR] >> If you feel this is a bug in crosstool-NG, report it at:
      [ERROR] >> github.com/crosstool-ng/crosstool-ng/issues/
      [ERROR] >>
      [ERROR] >> Make sure your report includes all the information pertinent to this issue.
      [ERROR] >> Read the bug reporting guidelines here:
      [ERROR] >> crosstool-ng.github.io/support/
      [ERROR]
      [ERROR] (elapsed: 15:43.42)
      [15:46] / ct-ng:146: recipe for target 'build' failed
      make[1]: *** [build] Error 2
      make/crosstool-arm.mk:33: die Regel für Ziel „crosstool-ng“ scheiterte
      make: *** [crosstool-ng] Fehler 2
      hawke@hawke-VirtualBox:~/buildsystem-ddt$

    • Die config hat er im BS Ordner, durch sein ./make.sh.
      Vermute mal Ubuntu 17.10 installiert, darin enthalten ist gcc7, da kann es zu dem Fehler kommen.

      Quellcode

      1. [ERROR] /home/hawke/buildsystem-ddt/build_tmp/crosstool-ng-1dbb06f2/targets/src/gcc-linaro-6.3-2017.02/gcc/ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
      2. [ERROR] make[3]: *** [ubsan.o] Error 1
      3. [ERROR] make[3]: *** Waiting for unfinished jobs....
      4. [ERROR] make[2]: *** [all-gcc] Error 2


      Dafür gibt es auch einen Patch.
      Building gcc-cross-initial with GCC7 on the host fails due to the comparison of a pointer to an integer in ubsan_use_new_style_p, which
      is forbidden by ISO C++:

      Unterschiede-Datei

      1. --- gcc-6.3.0/gcc/ubsan.c
      2. +++ gcc-6.3.0/gcc/ubsan.c
      3. @@ -1471,7 +1471,7 @@ ubsan_use_new_style_p (location_t loc)
      4. expanded_location xloc = expand_location (loc);
      5. if (xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0
      6. - || xloc.file == '\0' || xloc.file[0] == '\xff'
      7. + || xloc.file[0] == '\0' || xloc.file[0] == '\xff'
      8. || xloc.file[1] == '\xff')
      9. return false;

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von max_10 ()

    • Ich habe hier ein Problem mit "aclocal-1.15"

      config.status: executing chmod-scripts commands
      CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/janus/development/ddt/build_tmp/glib-2.54.0/missing aclocal-1.15 -I m4macros
      /home/janus/development/ddt/build_tmp/glib-2.54.0/missing: line 81: aclocal-1.15: command not found
      WARNING: 'aclocal-1.15' is missing on your system.
      You should only need it if you modified 'acinclude.m4' or
      'configure.ac' or m4 files included by 'configure.ac'.
      The 'aclocal' program is part of the GNU Automake package:
      <gnu.org/software/automake>
      It also requires GNU Autoconf, GNU m4 and Perl in order to run:
      <gnu.org/software/autoconf>
      <gnu.org/software/m4/>
      <perl.org/>
      Makefile:930: recipe for target 'aclocal.m4' failed
      make[1]: *** [aclocal.m4] Error 127
      make/contrib-libs.mk:167: recipe for target '/home/janus/development/ddt/.deps/libglib2' failed
      make: *** [/home/janus/development/ddt/.deps/libglib2] Error 2
      VMWare 12.5.8
      Jessie/Debian 8 Gestern => apt update & upgrade ausgeführt
      Heute in DDT:
      make update-self
      make update
      ./make.sh 37 1 1 3 3 1
      make yaud-neutrino-mp-tangos-plugins => hier knallt's!

      Ich komme unter meinem Jessie maximal an automake 1.14:

      janus@vmJessie:~/development/ddt$ sudo apt install automake*
      Paketlisten werden gelesen... Fertig
      Abhängigkeitsbaum wird aufgebaut.
      Statusinformationen werden eingelesen.... Fertig
      Note, selecting 'automake1.5' for regex 'automake*'
      Note, selecting 'automake1.6' for regex 'automake*'
      Note, selecting 'automake1.11' for regex 'automake*'
      Note, selecting 'automake' for regex 'automake*'
      Note, selecting 'automaken' for regex 'automake*'
      Note, selecting 'automake-1.14' for regex 'automake*'
      Note, selecting 'automake1.10-doc' for regex 'automake*'
      Note, selecting 'automake' instead of 'automake-1.14'
      automake ist schon die neueste Version.
      Ich hoffe, es ist nur eine Kleinigkeit. Aktuell keine Absicht, auf Stretch umzustellen...