I've a gumstix Overo which I am configuring to work with a e-CAM camera. The documentation provided by camera manufacture asks me to patch a 2.6.34 kernel and compile in Video For Linux support. When I look at gumstix user documentation they say I should execute:
bitbake -c menuconfig virtual/linux
However when I run this command I get
bacon:~/proj/overo-oe$ bitbake -c menuconfig virtual/linux
NOTE: Handling BitBake files: \ (7100/7100) [100 %]
NOTE: Parsing finished. 6382 cached, 413 parsed, 305 skipped, 2 masked.
ERROR: Nothing PROVIDES 'virtual/linux'
I'm not altogether sure about how I provide virtual/linux. Any ideas about how to fix this error?
This might be a case of out-of-date documentation. In any case, my current work around is to name the kernel explicitly: bitbake -c menuconfig linux-omap3-2.6.34
I can help with a step-by-step procedure to bitbake 3.0 kernel.
If that may be helpful for you. Using a WMware Ubuntu ...
I would stay away from convoluted build systems as bitbake. Every one seems to be inventing one... making the 'tool' to get more of your time then the thing you want to do with the tool. All of them are the same. Linus would quote on those guys:
Just don't do it...!
Related
The tested platform is windows using cygwin. I download bonmin-1.8.8 from https://www.coin-or.org/download/source/Bonmin/.
First, I obtained the third party code with the commands
./get.asl
./get.blas
./get.lapack
./get.mumps
then ran the command
./configure -C
and it shows that the configuration of bonmin is successful.
But then, when I run
make
There's something wrong with the makefile of Mumps.
It shows a rank mismatch between the actual arguments at (1) and (2)
MUMPS/src/dmumps_comm_buffer.F:2670:23:
I want to know how can I successfully make it?
I am attempting to compile the code at this Coral example on Colab to run on runtime version 10, since I have a Coral USB Accelerator connected to a customized build for Raspberry Pi Zero W.
The command I'd like to get working is
edgetpu_compiler --min_runtime_version 10 [.TFLITE file]
It always ends with an internal error; unknown to me why that would be...? The error is:
Edge TPU Compiler version 2.1.302470888
Internal compiler error. Aborting!
To reproduce this, you should do the import, preparation, build, and first training steps. No need to fine-tune: results are the same.
I understand that certain operations are not available for lower runtimes, but I am at a loss at what exactly would need to change in the demo so as to compile it successfully.
Does anyone know what might be missing, or otherwise provide guidance?
just got a chance to check this out, looks like there is actually a bug preventing compilation at older runtime version...
This is fixed as I'm able to compile this model with -m 10 form the code base, it'll be fixed for you by next release. For now here is a work around (essentially checking out an older compiler version to compile the model):
$ git clone https://github.com/google-coral/edgetpu.git && cd edgetpu
$ git checkout 657d2b6
$ ./compiler/x86_64/edgetpu_compiler -s -m 10 /path/to/model
This should works, although with an older runtime, many ops weren't supported then so you may not see the performance increase that you would with the current runtime version!
I am currently using the linux-x86.img which I downloaded from the documentation page for gem5 (http://www.m5sim.org/Download), but since I was not able to compile the fscanf and fopen commands on this image I was wondering if there is a more recent image which I could download and use instead.
The error message throw when trying to compile the lines with fopen and fscanf are
./obj/edgelist.o: In function loadEdgeArray': edgelist.c:(.text+0x148): undefined reference to __isoc99_fscanf'
./obj/edgelist.o: In function loadEdgeArrayInfo': edgelist.c:(.text+0x20c): undefined reference to __isoc99_fscanf'
collect2: ld returned 1 exit status
make: *** [test] Error 1
This error is thrown when trying to compile from both from qemu as well as gem5.
Here's one setup that generates such an image with Buildroot. I'm a fan of Buildroot because it builds everything from source. I don't understand how fscanf and fopen could fail in that image, but I have tested them in the above setup and they work fine.
Boot used to work in the past, but gem5 X86 full system boot has been broken for likely easy to fix reasons for a few months now as of March 2020 on the gem5 side, although there are efforts in place to fix it, and so likely it will work again soon: https://www.gem5.org/project/2020/03/09/boot-tests.html
Other alternatives include:
https://gem5art.readthedocs.io/en/latest/ which Jason has been pushing and uses Packer to generate disk images
You can also extract working disk images from Docker: https://hub.docker.com/_/ubuntu This requires exporting them to a file to give to gem5.
It is also worth noting that when the gem5.org website migrated from the old Wiki to the new static website setup in Q1 2020, we lost the ability of doing directory listing under http://dist.gem5.org/dist/current/arm/ for some reason, and so devs were forced to list them one by one on the static website... https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
I am not sure why the error is no longer occurring for me, but documenting the steps I went through which might have fixed something. I reinstalled Ubuntu18.04 therefore had to rebuild gem5 and I used the parsec image (http://www.cs.utexas.edu/~parsec_m5/x86root-parsec.img.bz2) referenced in this answer Booting gem5 X86 Ubuntu Full System Simulation
I have developed an application for MacOS. I am including notarization process as part of its distribution. I have followed all the steps and I have run:
xcrun altool --notarize-app --primary-bundle-id "${APP_BUNDLE_ID}" --username "${APPLE_DEV_ID}" --password "${DEV_APP_SPECIFIC_PASSWORD}" --file "${DMG_PATH}"
Then I check notarization progress using:
xcrun altool --notarization-info "${notarize_uuid}" -u "${APPLE_DEV_ID}" -p "${DEV_APP_SPECIFIC_PASSWORD}
Output of it is:
RequestUUID: =<Request>
Date: 2019-05-26 09:40:34 +0000
Status: success
LogFileURL: <Log file>
Status Code: 0
Status Message: Package Approved =~ success ]]
Then I launch staple command:
xcrun stapler staple -v <dmg file>
It also ends with success:
The staple and validate action worked!
However when I extract the .app file and run:
spctl --assess --verbose ./macos/MyApp.app
./macos/MyApp.app/: accepted
According to the docs I have read it should say something like: “source=Notarized Developer ID”, right?
I am running this on MacOS Mojave 10.14.5
What am I missing??
Could someone help me?
Thanks in advance
In case someone faces the same problem I will post the solution to this:
First of all you must staple .app file not the dmg. This means you must extract the binary and staple it
Also in order to check if application has been notarized, in
`System Preferences - Security and Privacy`
Option Allow apps downloaded from: must have Apple Store and identifier developers option checked
Hope this helps
Both the app and the dmg may be notarized and stapled, seperately, one after the other. Try doing that and the error should go away.
Short answer
It could be due to an RPATH referencing a path outside the App bundle. Removing this RPATH would resolve the issue.
Inspecting log files
You can find extra information about the rejection (after trying to launch the blocked app) in the Console.app. Note that you should open the Console.app, before trying to open your blocked app, otherwise not all messages may be logged. You should look for process XprotectService in the logs of your device (i.e. choose your device in the left side bar of the Console.app). If the RPATH is indeed the problem, you should find a record like this:
XprotectService: [com.apple.xprotect:xprotect] File /path/to/your/executable/or/library failed on rPathCmd /rpath/causing/the/problem (rpath resolved to: (path not found), bundleURL: /path/to/your/bundle.app)
Inspecting these log files may give you a key to solve other issues too.
Note that I received the following information from an Apple engineer:
Gatekeeper does not inform users via UI about the specifics of the
error, though it is in the logs for developers to look at. The
notarization process is purely about a detecting malicious software
and does not replicate Gatekeeper enforcement. You still need to get
software notarized and test with Gatekeeper.
We are looking to provide better tooling for developers in the future
to pre-flight some of these common errors.
Contact Apple
If you are not able to solve your issue with the above information, you may want to contact Apple itself using the Feedback Assistant. They do not respond very quickly (~1-2 weeks), but the answers are rather to the point.
I run poclbm on my system but for some reason both deepbit and slush don't "see" the work being performed. My system reports about 200 megabashes per second being done. I tried mining with my cpu using the same settings, and then both deepbit and slush recognized that work was being performed.
These are the errors I am getting out of the respective mining hardware (every minute or so):
poclbm error: pit.deepbit.net:8332 22/02/2013 21:50:59, Verification failed, check hardware! (0:0:Cypress, d47b7ba0)
cgminer error: [2013-02-22 22:18:51] GPU0: invalid nonce - HW error
I am using Ubuntu 12.10 (Quantal Quetzal) with the 12.10 version poclbm with an ATI 5800 series video card. The video drivers are installed and work as far as I can tell. When I run a "aticonfig --odgc --adapter=all", the gpu does seem to be utilized with poclbm (around 70% utilization or so).
I found the solution through an irc channel (Freenode on channcel #cgminer). Basically, at least on the version of Ubuntu that I have (12.10), the 2.8 version of the SDK does NOT work properly with cgminer or poclbm. I was instructed to download the 2.4 version of the SDK. Here:
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx32.tgz
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx64.tgz
Some distributions require the "2.7" version so I'll put the links here:
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.7-lnx32.tgz
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.7-lnx64.tgz
I compiled it. There is no "make install" for this Makefile, apparently, so you have to manually copy the files to your lib directory:
for 32 bit: $ cp -pv lib/x86/* /usr/lib/
for 64 bit: $ cp -pv lib/x86_64/* /usr/lib/
Also copy the include files: $ rsync -avl include/CL/ /usr/include/CL/
With the libraries installed in the appropriate directories, I recompiled cgminer and then it worked. I also tried it with poclbm and it worked with that too.
Hm, I experienced the same error with pclbm and cgminer. Then I found https://bitcointalk.org/index.php?topic=139406.msg1502120#msg1502120 .. I tried phoenix and all is ok now. Hope it helps. Sry my bad english.