aarch64 processor-rev1是高通810处理器吗_百度知道
aarch64 processor-rev1是高通810处理器吗
提问者采纳
毫无疑问这是三星猎户座CPU，CPU的型号为：三星Exynos
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁aarch64 processor-rev1是高通810处理器吗_百度知道
aarch64 processor-rev1是高通810处理器吗
提问者采纳
我的小米也是这个处理器型号，也不知道究竟是不是高通810，望解答。
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁ARM Cortex-A Series Programmer’s Guide for ARMv8-A_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
ARM Cortex-A Series Programmer’s Guide for ARMv8-A
阅读已结束，如果下载本文需要使用
想免费下载本文？
你可能喜欢GNU ARM Eclipse / Bugs / #59 'Program "gcc" not found in PATH' error when creating a project with linaro gcc (aarch64-none-elf-gcc).
Error: CSS did not load.
This may happen on the first request due to CSS mimetype issues.
Try clearing your browser cache and refreshing.
#59 'Program "gcc" not found in PATH' error when creating a project with linaro gcc (aarch64-none-elf-gcc).
Milestone:
closed-works-for-me
Abstract: 'Program "gcc" not found in PATH' error when creating a project with linaro gcc (aarch64-none-elf-gcc).
Steps to reproduce:
- create 'HelloWorld ARM C Project' with 'Cross ARM GCC'
- choose toochain name: Linaro AArch64 bare-metal ELF (aarch64-none-elf-gcc)
- toolchain path: ../gcc-linaro-aarch64-none-elf-4.8_win32/bin (the package is in my eclipse layout)
- in Problems view I see two errors:
"Error: Program "g++" not found in PATH"
Error: Program "gcc" not found in PATH
- in Properties && Build Variables I correctly configured ${cross_make} and ${cross_rm}
- build project (the build process finishes without errors, the binaries are created), but the above errors don't disappear
From my investigations, the issue is in Properties && Preprocessor Include Paths, Macros etc. && Providers && CDT GCC Built-in Compiler Settings Cross ARM. I checked "Allocate console in the Console View" and the log is:
11:47:31 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD D:/WORKSPACES/runtime-New_configuration/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "g++": Launching failed
Error: Program "g++" not found in PATH
If I modify the ${COMMAND} to aarch64-none-elf-gcc I get:
11:56:10 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
aarch64-none-elf-g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD D:/WORKSPACES/runtime-New_configuration/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
aarch64-none-elf-g++: error: ${FLAGS}: No such file or directory
aarch64-none-elf-g++: error: ${cross_toolchain_flags}: No such file or directory
I'm using plugin version 1.1.2- with eclipse Kepler, Windows host. The .metadata log is attached.
1 Attachments
Discussion
(Page 1 of 2)
status: open --& open-accepted
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I attach my project to see the settings. It has hard-coded paths for ${cross_make},
${cross_rm} and toolchain path.&
Attachments
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reproduced the issue on Linux too. Is there a workaround without having to edit the PATH variable? Can I disable Scanner Discovery somehow?&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you can disable the scanner providers, but this is by the indexer being one of the main strengths of CDT, without the scanner providers the indexer is rendered useless.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. I'll wait for a solution.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
toolchain path: ../gcc-linaro-aarch64-none-elf-4.8_win32/bin (the package is in my eclipse layout)
using relative paths here is not a good idea, since you do not now the current path when the execution is attempted. the actual build is done inside each configuration folder (Debug/Release), the discovery process... I don't know by heart, I have to check
in Properties && Build Variables I correctly configured ${cross_make} and ${cross_rm}
why would you like to change the internal build variables, when there is a special page to configure all toolchain details.
please read the new documentation pages on how to configure the path to make & rm, and avoid entering absolute paths in macros, they are not portable across workspaces
with the correct path to the toolchain (absolute path in Toolchain tabs) and the build
tool (make & rm) in a separate folder, with its path added to the entire workspace environment, my test was successful, including correct discovery and indexer.
19:36:15 * Build of configuration Debug for project t4 *
'Building file: ../src/t4.c'
'Invoking: Cross ARM C Compiler'
aarch64-none-elf-gcc -mcpu=generic+simd -mcmodel=small -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall
-g3 -MMD -MP -MF"src/t4.d" -MT"src/t4.d" -c -o "src/t4.o" "../src/t4.c"
'Finished building: ../src/t4.c'
'Building target: t4.elf'
'Invoking: Cross ARM C Linker'
aarch64-none-elf-gcc -mcpu=generic+simd -mcmodel=small -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall
-g3 -Wl,-Map,"t4.map" --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group -o "t4.elf"
./src/t4.o
'Finished building target: t4.elf'
'Invoking: Cross ARM GNU Create Flash Image'
aarch64-none-elf-objcopy "t4.elf" -O ihex
'Finished building: t4.hex'
'Invoking: Cross ARM GNU Create Listing'
aarch64-none-elf-objdump "t4.elf" --source --all-headers --demangle --line-numbers --wide & "t4.lst"
'Finished building: t4.lst'
'Invoking: Cross ARM GNU Print Size'
aarch64-none-elf-size
--format=berkeley "t4.elf"
hex filename
55a4 t4.elf
'Finished building: t4.siz'
19:36:17 Build Finished (took 1s.187ms)
Note: there is an error logged initially (Program "echo" not found in PATH) that is due to a bug in CDT, which is trying to run the discovery process before the toolchain is properly configured, but if happens only when the project is created, and, if you delete it, it does not happen again.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Resolution: 'Program "gcc" not found in PATH' was due to a misconfigured PATH, a relative path was used with a wrong reference point.
Recommandation: to avoid problems, use an absolute path. Although it is stored in the .cproject file, during the project life span it is stored in the workspace, so projects are portable and can be moved from workspace to workspace (even between windows and non windows) without problems.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
status: open-accepted --& closed-works-for-me
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did everything you said, absolute toolchain path, read documentation, configured make & rm as mentioned in the doc, same result. To be sure I'm not doing something stupid, I followed 'Create a test project' tutorial using gcc-arm-none-eabi toolchain and not linaro, same story. On Windows, the error is obvious:
11:43:32 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD D:/WORKSPACES/workspace_LS2_3/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.
Cannot run program "g++": Launching failed
Error: Program "g++" not found in PATH
On Linux, because gcc/g++ are by default in system path, there are no errors reported in Problems view, but the Scanner Discovery console complains:
11:39:34 * Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM *
g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD /home/iulia/workspaces/workspace_dev/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
g++: error: ${FLAGS}: No such file or directory
g++: error: ${cross_toolchain_flags}: No such file or directory
This may be the case on Mac OS too (host you are using), to work by chance as it does on Linux. In the test you did previously, can you please enable Scanner Discovery console and check the log? &
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran my test on a Windows machine too, so there should not be a platform problem.
Could you retry the test on a fresh Eclipse?
unpack a new Eclipse Kepler CDT
install the plug-in
create a new project in a new workspace
If this test fails, you are systematically doing something wrong. If this test passes, the problem should be due to an interference with some other plug-ins.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
status: closed-works-for-me --& open-accepted
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I re-tested on a fresh Eclipse Kepler CDT, it didn't reproduce. I see only the CDT bug 'Program echo not found in PATH', everything else works fine. So apparently,
there is an interference between plugins as you mentioned above.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, please keep me posted on your findings.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you install eclipse-standard-kepler then cdt-master-8.2.0 and arm plugin on top of it you'll see the error.
Don't know why.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Although your suggested configuration is pretty unusual, I did just that, I installed Eclipse Luna 4.4M2 Standard and on top of it I installed CDT 8.2.0 from the master zip, then 1.1.3 from the test site and... the Cortex-M3 template built successfully. :-)
Another project build with AArch64 toolchain did not exhibit the unusual behaviour reclaimed, just the expected 'aarch64-none-elf-gcc: command not found' (the toolchain was not installed).
Attached is a screen snapshot of the Eclipse configuration.
I also did the following tests:
- Eclipse Kepler 4.3.1 Standard with CDT 8.2.1 from the master zip
- Eclipse Kepler 4.3.1 CDT
- Eclipse Luna 4.4M2 Standard with CDT 8.3 from Luna update site
- Eclipse Luna 4.4M2 Standard with CDT 8.2.1 from master zip
All worked flawlessly.
Some general remarks:
you mixed Eclipse Luna 4.4, which is the next Eclipse version, not yet released, with CDT 8.2.0, which is the already outdated CDT. If you do this... you' generally CDT and Eclipse should be from the same release, and as up-to-date as possible.
you use a separate standard Eclipse release and a separate CDT archive, instead of using the already packed Eclipse CDT (and so you increase the risk of incompatible/missing plug-ins).
there must be something else in your configuration that prevents the plug-in to start, since my attempts to run it on multiple fresh Eclipses (even in unusual combinations of versions) could not reproduce the behaviour you describe.
Attachments
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I copy + pasted the wrong link for eclipse standard, it should have been
This is the one I have. However, I really appreciate you did all these tests, it helped me to understand the faulty combination:
Eclipse Kepler 4.3 with CDT 8.2.0 from the master zip doesn't work
Eclipse Kepler 4.3 with CDT 8.2.1 from the master does work
see attachments.
Eclipse Kepler 4.3 and CDT 8.2.0 were released almost in the same time,
and , so they should be compatible. Anyway, we'll update our procedure and use the whole CDT package to keep out of trouble.
Thanks again for your support, this ticket can be closed now.&
Attachments
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attachments
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
status: open-accepted --& closed-works-for-me
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Eclipse Kepler 4.3 with CDT 8.2.0 from the master zip doesn't work
I checked Kepler 4.3 R Standard (not 4.3 SR1 which is current now), plus the 8.2.0 from master zip, plus 1.1.3 from the updates-test and it worked flawlessly, as all other tests.
we'll update our procedure and use the whole CDT package to keep out of trouble.
good choice. and go to SR1, not plain R.
this ticket can be closed now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This becomes quite awkward. For me, neither eclipse-standard-kepler-R nor eclipse-standard-kepler-SR1 works flawlessly with CDT 8.2.0, only CDT 8.2.1 combinations. But fortunately, eclipse-cdt-kepler works great.&
Attachments
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i had a similar problem, although, in the new-project wizard, i specified an absolute path to the toolchain folder right from the beginning.
Error: 'Program "gcc" not found in PATH' !
Then i double-checked a lot of things, but nothing helped.
At the end, i was so desperate, that i was beginning to supect that i might need to remove the trailing dash from the toolchain prefix name.
So i changed "arm-linux-gnueabihf-" to "arm-linux-gnueabihf".
Now i got a different error message:
Error: 'Program "arm-linux-gnueabihfgcc" not found in PATH'
Now this error message actually made sense to me.
After changing the toolchain prefix back to "arm-linux-gnueabihf-",
everything unexpectedly worked fine!! No error message anymore! How odd!?
It seems that the wizard messed up the internal storage of the toolchain prefix name?
Anyway, it seems that once "touching" the toolchain prefix name entry in the project properties is a functioning workaround.
Best regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you retry and see if you can find a way to reproduce the bug and document it in detail?
Please use a fresh workspace, not the one that you already used before.
My first thought is that you manually changed the project environment PATH, and this is known to interfere with the plug-in automatic mechanism. So be sure you do not touch the PATH setting except the Global toolchain path.&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
status: closed-works-for-me --& open
--& Future release
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well yes, i reproduced it with a fresh workspace.
It was exactly the same this time, without touching anything else.
I did nothing but this:
I set up a new C-Project and correctly specify the toolchain path and prefix.
Then when building, i get the error message:
'Program "gcc" not found in PATH'
Then i go to menu Project/Properties/C_C++ Build/Settings/Tool Settings/Cross Settings/Prefix
and change it from "arm-linux-gnueabihf-" to "arm-linux-gnueabihf-", which is exaclty the same term, which actually should make no difference at all. It's like merely touching that entry.
Anyway i get rid of the error message, after this.
So Eclipse seems to ignore the toolchain prefix wich i entered in the wizard.
So i suspect that the wizard's data is being stored in some corrupted way, but that's just a wild guess, as i am a desperate Eclipse beginner and not aware of any Eclipse internals.
Sorry for not being of any better help.
Maybe it's worth mentioning that i use Eclipse 64Bit version:
Kepler Service Release 2
Build id: 7
Java 7u60 (64Bit)
Win7 64Bit with all newest Microsoft updates, stable running, healthy files system, etc...
Greetings,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
correctly specify the toolchain path and prefix
oops! toolchain path and prefix?! my wizards no longer require this, are you sure you are using my plug-ins?
please read the documentation pages carefully and do exactly as instructed there.
if you still have problems, please report back, but provide full details of the input in the New C Project wizard, especially the selections used for:
- 'Project type:'
- 'Toolchains:'&
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Page 1 of 2)