PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : fehler beim bauen mit Audioniek git



Seiten : 1 2 [3]

Audioniek
05.08.2022, 21:31
This line:

/usr/lib/python2.7/site-packages/OpenSSL/crypto.py:14: CryptographyDeprecationWarning: Python 2 is no longer supported by the Python core team. Support for it is now deprecated in cryptography, and will be removed in the next release.
is normal and constitutes a warning, but it should not lead to E2 not running.

Python 2.7 has been end of life for some time now but the OpenPLi people still keep on using it. Some others, notably OpenVisionE2, have switched to Python3 but this needs elaborate patching of the OpenPLi code. One could use the OpenVision Enigma2, but in turn this requires elaborate patching in the rest of the build. Because of this situation I have decided some one and a half years ago to await what OpenPLi was going to do and try and follow that route, but they still have not switched to Python3, although there is a Python3 branch in their git.

Others have chosen to stop supporting Enigma2 on SH4 altogether like the origin of by buildsystem, Duckbox-Developers, which is now limited to building Neutrino. The result is that the number of sources to get Enigma2 for SH4 from is slowly but surely decreasing, and the build environment I am maintaining will probably follow that path in the near future.

In that respect is it perhaps good to mention that even the youngest SH4 receivers are now 8 years old, and the first ones are well underway to 15 and more. Another aspect is that apart from the sparks, SH4 receivers were never designed to run Enigma2 and the time is rapidly approaching that the technological advances will make using E2 impossible and/or impracticable on SH4 boxes. Apart from keeping using outdated versions (including the now also defunct stlinux), lack of memory and processing power will only impose more and more limitations on things. The message above is merely one of the first indicators that that is indeed happening.

As long I see possibilities to keep things going I will do so, but in my view the days of Enigma2 on SH4 are numbered and the end is a lot closer than the beginning regarding the SH4 era.

Regards,

Audioniek.

pop1234
05.08.2022, 23:48
First of all, thank you for everything you have done over the years
Secondly, my opinion is that it should continue to support Enigma 2, because these devices have only this source with which it lives
Other sources only support Spark devices
Neutrino will sooner or later migrate to Python 3.
OpenPli has supported some 4K devices for Vuplus and will move to other devices
There are some members who are still using your source to build Enigma 2 for sh4 box.
Proof of that ,when you added Titannit, they tried building it.

ainouna
06.08.2022, 11:02
Hello Audioniek

Thank you for everything you have done over the years
We build with your git for SH4 without problems
So if you stop
Believe me, it's over for the SH4 boxes
Thank you thank you a thousand times for everything you do Mr. Audioniek

Regards
ainouna

turulbird
11.08.2022, 22:24
Hi!

UFS 910 enigma2 flash build ok, flashing ok in usb stick, but after restart: No usb stick in vfd.
maxiU-boot 1.3.1 in kathrein, no mini; that error?




maxiU-Boot 1.3.1 (May 19 2010 - 23:05:16) - by SoLaLa

selected Image to start: ----Flash----

no originalsoft detected, trying bootargs_0, if empty trying e2-bootargs...
Hit any key to stop autoboot: 0
## Booting image at a0040000 ...
Image Name: Linux-2.6.32.71_stm24_0217
Image Type: SuperH Linux Kernel Image (gzip compressed)
Data Size: 4315818 Bytes = 4.1 MB
Load Address: 84001000
Entry Point: 84002000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel console=ttyAS0,115200 root=/dev/mtdblock2 ip=:kathrein:eth0:off mem=64m coprocessor_mem=4m@0x10000000,4m@0x10400000 rootdelay=0 nwhwconf=device:eth0,hwaddr:00 init=/bin/devinit - 0x00000000 - 0 ...

INIT: version booting
------------------------------------------------------------
deploy.sh version V0.13 (version for Kathrein UFS910)
------------------------------------------------------------

<- Mounting USB stick ->
mount: mounting /dev/sdb1 on /instsrc failed: No such device or address
mount: mounting /dev/sdb on /instsrc failed: No such device or address
mount: mounting /dev/sdb1 on /instsrc failed: No such device or address
mount: mounting /dev/sdb on /instsrc failed: No such device or address
mount: mounting /dev/sdb1 on /instsrc failed: No such device or address
mount: mounting /dev/sdb on /instsrc failed: No such device or address
mount: mounting /dev/sdb1 on /instsrc failed: No such device or address
mount: mounting /dev/sdb on /instsrc failed: No such device or address
mount: mounting /dev/sdb1 on /instsrc failed: No such device or address
mount: mounting /dev/sdb on /instsrc failed: No such device or address
mount: mounting /dev/sdb1 on /instsrc failed: No such device or address
mount: mounting /dev/sdb on /instsrc failed: No such device or address
INIT: Entering runlevel: 3
INIT: no more processes left in this runlevel

Audioniek
12.08.2022, 12:23
You have built the wrong version. If you select flash as destination an image is built that is intended to run from the internal hard disk (which of course must be present, to connect it one has to add a SATA connector on the mainboard, and if I remember correctly four capacitors as well), using the original bootloader. If you look in the log you provided, one can see this is indeed the case: deploy.sh is the script started by the installation kernel, and tries to mount sdb. This fails because of the missing hard disk which would be sda, and causing the USB stick to be sdb. The USB stick without the internal hard disk ends up being sda, resulting in a failed installation.

To run from an USB stick, you indeed need MaxiUboot, and an image built with destination USB. The flash procedure should then result in a tar.gz file that can be used to prepare the USB for use using software written for that purpose (makeMINI? or AAF Recovery Tool?). All this is unfortunately untested but in theory should work as I did not change anything for the USB variant.

Regards,

Audioniek.

turulbird
12.08.2022, 13:12
Two out of the three UFS 910 during repair-conversion (SATA). Doesn't it work without HDD, just miniflash.img (16.5 MB)?
Atemio Titan has enough flash.
http://atemio.dyndns.tv/nightly-images/Kathrein/UFS-910/


My build UFS 910, enigma2 flash, no wifi; version ok. In script not needed UFS 910 hdd install, how disabled, what xxx.mk files?

Usb img working with: CreateMini usb stick, install Maxiboot Installer.
Neutrinos usb fully working, tested my stb and upload my dropbox:

https://www.dropbox.com/sh/t6hd0hi192vuuqw/AADuoOxGMj6K7e-qAjiML7Tsa?dl=0 (https://www.dropbox.com/sh/t6hd0hi192vuuqw/AADuoOxGMj6K7e-qAjiML7Tsa?dl=0)


Enigma2 usb run, but error and not loading fully.

As with my two comments above

Thanks

Audioniek
12.08.2022, 18:34
Two out of the three UFS 910 during repair-conversion (SATA).
It is completely unclear to me what information your are trying to convey here. That out of three UFS910's you have converted to SATA, two do not work?


Doesn't it work without HDD, just miniflash.img (16.5 MB)? Titannite has enough flash.
Leave miniflash.img alone. It contains the bootargs, the miniuboot containing the emergency boot and in case of a "flash" image the installation kernel. Or in other words: nothing pertaining the image you are trying to run.The actual kernel used by the image is flashed in mtd1. In the UFS910 there is not enough room left in flash for Enigma2. Neutrino as you write runs OK. At the moment there is no support for Titan in flash on the UFS910, although the flash setup for Neutrino is probably usable. I have not built and tested Titan for the UFS910 yet.


My build UFS 910, enigma2 flash, no wifi; version ok. In script not needed UFS 910 hdd install, how disabled, what xxx.mk files?
Enigma2 "flash" is not possible without an internal hard disk, hence "flash" in quotes. The Enigma2 rootfs is simply too large for the available flash memory, so it has to reside somewhere else: it is either on a partition on the internal hdd (using the ufsinstaller approach, original boot loader) or on a USB stick using maxiUboot. The first can be built using flash as destination, the second with USB as destination. The ufsinstaller "flash" setup uses and boots a kernel in NOR flash, the maxiUboot USB setup boots the kernel from a FAT formatted partition on the USB stick and has the rootfs on a second ext3 formatted partition on that same stick.
Regarding changing xxx.mk files: all the magic is done in the flash directory where the final image is made ready for transfer to the receiver and/or USB stick.


Enigma2 usb run, but error and not loading fully.
Something strange is happening there. The logs you sent complain about the module pyexpat not being found. In my test build is it present, so my conclusion is that the tar.gz is either damaged or not unpacked correctly or completely.

Regards,

Audioniek.

turulbird
12.08.2022, 18:48
Two UFS 910 bad, only one working; without sata.

Added back panel 16 Gb usb pen, run after only booting... in vfd:


INIT: version booting
------------------------------------------------------------
deploy.sh version V0.13 (version for Kathrein UFS910)
------------------------------------------------------------

<- Mounting USB stick ->
./deploy.sh: line 103: can't open /instsrc/Image_Installer.ini: no such file
grep: /instsrc/Image_Installer.ini: No such file or directory
grep: /instsrc/Image_Installer.ini: No such file or directory
grep: /instsrc/Image_Installer.ini: No such file or directory
grep: /instsrc/Image_Installer.ini: No such file or directory
-------------------------------------
Using the following settings:

partition :
createmini :
keepsettings :
keepbootargs :

usejfs :
useext2e2 :

usbhdd :
format :
update :
-------------------------------------
sh: 1: unknown operand

<- Formatting HDD (rootfs) ->
mke2fs 1.46.5 (30-Dec-2021)
/dev/sda1 contains a vfat file system labelled 'MULTIBOOT'
Creating filesystem with 4095992 4k blocks and 1024000 inodes
Filesystem UUID:
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

sh: 1: unknown operand
<- Skipping installation of root file system ->
mount: mounting /dev/sda3 on /mnt failed: No such device or address
umount: can't unmount /mnt: Invalid argument
-rwxr-xr-x 1 0 0 15712 Aug 11 2022 fw_printenv
lrwxrwxrwx 1 0 0 21 Aug 11 2022 fw_setenv -> /usr/sbin/fw_printenv
<- Flashing U-Boot args: Warning: Bad CRC, using default environment
Can't open /dev/mtd7: Permission denied
Error: can't write fw_env to flash
Warning: Bad CRC, using default environment
Can't open /dev/mtd7: Permission denied
Error: can't write fw_env to flash
Warning: Bad CRC, using default environment
Can't open /dev/mtd7: Permission denied
Error: can't write fw_env to flash
Warning: Bad CRC, using default environment
Can't open /dev/mtd7: Permission denied
Error: can't write fw_env to flash
done ->

<- Flashing kernel: done ->

<- Checking HDD rootfs ->
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
ROOTFS: 11/1024000 files (0.0% non-contiguous), 90667/4095992 blocks

<- Job done... ->
Rebooting...


booting...

Audioniek
13.08.2022, 11:59
As stated before: you are using the wrong version. The "flash" version will only work with an internal SATA connected hard disk. There is a slight possibility to get the "flash" to work with an external USB hard disk, by swapping the installation stick and and external hard disk between USB ports until you have found a setup that results in the external hard disk being sda and the installation stick being sdb. This depends on the installation kernels order of scanning the USB ports: the port to which the external hard disk is connected must be scanned first. This however may be prevented altogether by limitations in the boot loader, that may refuse to load the installation kernel or flash files from a USB port other than the front panel one.

"Two UFS 910 bad, only one working; without sata." Again: what are you trying to tell me? You have three UFS910's and two are broken? This information is not relevant given the problem.

It seems to me you have flashed an miniFLASH.img with an installation kernel in it, together with a set of boot arguments that tell the boot loader to start the kernel in flash. This setup will never start an USB image residing on a USB stick.
My suggestion is going back to a defined starting state, by first installing the original boot loader and a factory Kathrein firmware using AAF recovery tool. Then start over carefully obeying all installation instructions to the letter. As long as there is no working internal SATA hard disk in your UFS910, do NOT attempt to install a "flash" version: you will only end up with the problems you are experiencing now.

Regards,

Audioniek.

turulbird
13.08.2022, 16:56
Yes, three UFS910's and two are broken...
Builds finish... for the time being.

Thanks all!

ainouna
18.08.2022, 18:38
Regards
ainouna

turulbird
20.05.2023, 16:13
Hi!

UFS 910 neutrino tangos, DDT USB image build ok and working.


Enigma2 usb image run, but opkg error:



[rcS] Loading Enigma2
[rcS] Starting Enigma2 ->
PYTHONPATH: /usr/lib/enigma2/python
DVB_API_VERSION 5 DVB_API_VERSION_MINOR 3
ENIGMA_DEBUG_LVL=3
ntpd: setting time to 2023-05-18 22:16:14.526325 (offset +722121344.873790s)
[MAIN] executing main
[Profile.py] no profile data available
cat: can't open '/var/lib/opkg/info/kernel-module-*.control': No such file or directory


/var/lib/opkg/ directory is empty.

What could be the error since last year?

New 2023 UFS 910 usb neutrino images on my Homepage.

Thanks!

kader_73
04.06.2023, 19:32
hello ,, Audioniek

Is it possible to have hs7819 installer to create an uImage for usb image ?

B regards

Audioniek
04.06.2023, 23:14
Hello kader_73,

Yes and no. First: it is not needed, as the HS7819 has plenty of flash memory to install an image in. Second: it is not needed, because there are modified loaders that can run an image off a USB stick with only one FAT32 partition. In addition both these options are supported in full by the flash git.

If you study the installers, they have something in common. The first is they are for receivers with very little flash memory. The second is they have a built-in hard disk or a SATA connected hard disk can very easily be added (the latter category is currently the ufs910 and the opt9600prima). After this is done you can run an image without a USB stick, by flashing the kernel in flash memory and storing the root on the hard disk, which also is used for the swap area and the recording storage. For this, the hard disk has three partitions, one for the root, a swap partition and the remainder for recording storage. The installers on offer automate the process of partitioning and formatting the hard disk, flash the kernel and copying the the root.

On the HS7819 it is certainly possible to do the same, but it cannot have a SATA internal hard disk (no SATA interface is present in the STx7111 SoC, the cabinet is too small, and the power supply has insufficient power to spare for an internal drive), so you would need an external USB drive. This last fact more or less defeats the purpose for an installer, as having the kernel in flash but the root on an external USB hard is needlessly complicated and destroys an image in flash anyway. Most people want to run off USB because they want to retain the image in flash. Why they do is a mystery to me, as the 7819 has plenty of NAND flash and flashes with lightning speed (reading in the image from an USB stick takes longer than flashing it). And as said with the USB enabled loader the 7819 can very comfortably run a complete image on a USB device, either a stick or a FAT32 formatted USB hard disk while another image remains untouched in flash memory. The upshot of it all is that I see no advantages for building an installer-style option for the HS7819.

This all pertains to the sister models HS7119 and HS7429 as well, and in a lesser extend for the HS7110, HS7420 and HS7810A too. A possible candidate is the HS8200, because Engma2 with Gstreamer does not fit its 64 Mbyte of flash.

Regards,

Audioniek.

kader_73
05.06.2023, 23:02
hello Audioniek , and thnks for all explanations;
the reason why I asked for this, mainly to be able to test the built images (which carry certain local modifications) before installing them on flash to save the latter from repeated erasures and writes; that said I would like to have a kernel installed capable of mounting an image on an ext2 partition, something that has become impossible with the current u-boot (7.27). which was probably due to the config.
I don't know if you see what I'm trying to come back to?! but I do understand your point about the time and effort you see being spent on something that isn't really necessary.

I will look for a solution by building a u-boot with an appropriate configuration that allows the use of new bootargs that boot an image from usb (as was the case with that of pkteam). I think that will be the best solution.
b Reagards

Audioniek
06.06.2023, 18:24
Hello kader_73,

I see what you are getting at. To achieve what you want is not that hard and you do not need to build an installer nor a new boot loader for that. If I am correct the current loader 7.27 can do what you want. I would proceed as follows.

First built the kernel/image you want with flash as destination. When that is done, run fakeroot X/flash/flash.sh [desired resellerID], and select flash the kernel only. This will yield an IRD file with only the kernel in it that can be flashed using the channel-up procedure. After flashing you have the kernel in place. Switch off the USB feature of the loader (power up with front panel channel-down pressed and held, repeat until you see OFF in the display). This is needed because with USB ON the bootargs variable from the environment is not used, but one fixed in the boot loaders code.

Second rebuild the same image, but now using USB as destination. When finished, run X/flash/flash.sh. Ignore the output of the flash procedure, but your ext2/3 image is in the directory X/flash/tmp/ROOT. Copy this lot to a ext2/3 formatted USB stick.

The last step is changing the boot loader's bootargs setting. Connect a serial cable to the box and start a terminal on your attached PC. Fire the receiver up and repeatedly press Enter on the PC. This should stop the autoboot and get your at the boot loaders prompt.

The bootargs entry will look something like this (use printenv):


bootargs console=ttyAS0,115200 root=/dev/mtdblock2 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs rw init=/bin/devinit...

You need to change this part: [ root=/dev/mtdblock2 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs ] to [ root=/dev/sda1 rootfstype=ext3 ] or [....rootfstype=ext2 ]

After some copying and pasting and printenv, setenv and saveenv commands, you should be in business.

You do not have to change the bootcmd, this already gets the kernel from flash.

Hope this helps a bit.

Regards,

Audioniek.

- - - Aktualisiert - - -

Oh yes I forgot to mention: NAND flash is guaranteed to sustain 100.000 flash cycles. This means if you reflash your receiver 10 times a day each day, it would still take you more than 25 years to wear it out, so do not worry about flash/erase cycles.

Regards,

Audioniek.

ainouna
09.11.2023, 11:05
Hello Audioniek

How are you mr Audioniek



Regards
anouna

Audioniek
23.11.2023, 09:15
Sorry for the slow reaction. I am doing OK, thank you. Currently I am very busy with a lot of retro computer stuff, machines I used when I was in my twenties, the beginning of the microcomputer era. Regarding satellite stuff and SH4 boxes in particular, I have come to the conclusion that this is more or less coming to an end. Enigma2 becomes more and more incompatible with SH4 boxes as time progresses, and also keeps growing in size. The result is that in practice only the sparks can run a current E2 in flash nowadays. Though I have made some progress regarding python3, I have not finished that part yet and it is not high on my list of priorities.

Regards,

Audioniek.

ainouna
24.11.2023, 14:04
Hello Audioniek
You are in shape
so much the better Mr. Audioniek
Some modifications
if you have the time
enigma2
insmod $MODDIR/cimax.ko #paramDebug=20
rc is not configured in cic
Titan
insmod $MODDIR/cimax.ko #paramDebug=20
rc is not configured in cic
I configured the cic plugin in (cimax)
for hs7429


enigma2 does not start and titan does not start either
I reconfigured the cic for hs7429 in (starci)
that works
but Titan decrypts encrypted channels but no images


Regards
anouna

ghani
20.01.2024, 13:04
cuberevo-mini with default options doesnt build. It appairs following message
Would You please fix it ?
Thank You very much. Greets




Start build of tools-libmme_host.
Generating configuration files for tools-libmme_host, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:11: warning: AC_OUTPUT should be used without arguments.
configure.ac:11: You should run autoupdate.
configure.ac:4: installing './compile'
configure.ac:2: installing './missing'
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/mme/mme_linux_user.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least one source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However, this
automake: behavior may change in a future Automake major version, with object
automake: files being placed in the same subdirectory as the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/mme/ExecutionLoop.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/mme/LocalTransformer.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/mme/LookupTable.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/mme/MMEMessageQueue.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/mme/mme_tune.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
Makefile.am:6: warning: source file '$(DRIVER_TOPDIR)/multicom/embxshell/embx_linux.c' is in a subdirectory,
Makefile.am:6: but option 'subdir-objects' is disabled
Makefile.am: installing './depcomp'
configure: WARNING: using cross tools not prefixed with host triplet
make all-am
CC mme_linux_user.lo
CC ExecutionLoop.lo
CC LocalTransformer.lo
CC LookupTable.lo
CC MMEMessageQueue.lo
In file included from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/mme_hostP.h:12:0,
from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/ExecutionLoop.c:10:
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:388:2: error: invalid preprocessing directive #elselock
#elselock->n[cpuID].marker
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:389:0: warning: "EMBX_INLINE" redefined [enabled by default]
#define EMBX_INLINE
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:387:0: note: this is the location of the previous definition
#define EMBX_INLINE inline
^
make[2]: *** [Makefile:508: ExecutionLoop.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/mme_hostP.h:12:0,
from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/LookupTable.c:9:
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:388:2: error: invalid preprocessing directive #elselock
#elselock->n[cpuID].marker
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:389:0: warning: "EMBX_INLINE" redefined [enabled by default]
#define EMBX_INLINE
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:387:0: note: this is the location of the previous definition
#define EMBX_INLINE inline
^
make[2]: *** [Makefile:522: LookupTable.lo] Error 1
In file included from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/mme_hostP.h:12:0,
from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/LocalTransformer.c:9:
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:388:2: error: invalid preprocessing directive #elselock
#elselock->n[cpuID].marker
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:389:0: warning: "EMBX_INLINE" redefined [enabled by default]
#define EMBX_INLINE
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:387:0: note: this is the location of the previous definition
#define EMBX_INLINE inline
^
In file included from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/mme_linux_user.c:20:0:
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:388:2: error: invalid preprocessing directive #elselock
#elselock->n[cpuID].marker
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:389:0: warning: "EMBX_INLINE" redefined [enabled by default]
#define EMBX_INLINE
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:387:0: note: this is the location of the previous definition
#define EMBX_INLINE inline
^
In file included from /home/ghani/Audioniek/buildsystem/driver/include/multicom/mme_queueP.h:12:0,
from /home/ghani/Audioniek/buildsystem/driver/multicom/mme/MMEMessageQueue.c:14:
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:388:2: error: invalid preprocessing directive #elselock
#elselock->n[cpuID].marker
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:389:0: warning: "EMBX_INLINE" redefined [enabled by default]
#define EMBX_INLINE
^
/home/ghani/Audioniek/buildsystem/driver/include/multicom/embx_osinterface.h:387:0: note: this is the location of the previous definition
#define EMBX_INLINE inline
^
make[2]: *** [Makefile:515: LocalTransformer.lo] Error 1
make[2]: *** [Makefile:529: MMEMessageQueue.lo] Error 1
make[2]: *** [Makefile:501: mme_linux_user.lo] Error 1
make[1]: *** [Makefile:368: all] Error 2

chaban
21.01.2024, 06:39
hello dear ...ghani
pls ....Can you build for me an image for HS8200

Audioniek
25.01.2024, 14:37
Hello chaban,

In a few days time you will find a recently built image based on OpenPLi release 8.3 here (http://www.hdmedia-universe.com/board/showthread.php?11222-Audioniek-Images-download).

Regards,

Audioniek.

chaban
26.01.2024, 12:38
Hello, AudionieK...

Thks you very much ...Dear im waiting to test :)