Still chasing that white whale of running Minecraft on an BBB, I eventually came to the conclusion that the major issue was twofold. First, Minecraft has a dependency on the Lightweight Java Games Library, or LWJGL, and it does not have an ARM version to reference when it's downloading the run environment. Second, Minecraft's launcher doesn't allow you to reference specific jars in the boot up process, meaning that any version of LWJGL and it's accessories that could be ported to ARM would also have to pass the sha checks. Granted, those could be fudged, but I'm at a bit of a loss on how to proceed since I seem to be in uncharted territory. Anyone have any pieces of advice or suggestions on where to go from here?
I have found some information here for LWJGL for ARM:
http://www.raspberrypi.org/forums/viewtopic.php?f=34&t=19532
This brought me to 2 places:
More info on running ARM LWJGL: http://www.trimslice.com/forum/viewtopic.php?f=48&t=393
And, what appears to be precompiled LWJGL for ARM: http://openjdk.gudinna.com/lwjgl-es/
I have yet to test anything, but it's a step in the direction. I am new to a lot of this myself, so we'll see where it goes.
I am also in the same boat, trying to do the same thing.
All I know for sure so far:
JWJGL is built for x86, so it can't run on ARM processor - we would need to recompile for ARM.
There is a checksum when you do replace the LWJGL library, which triggers minecraft to replace the file with the x86 version.
I had an idea that, in order to get around the checksum issue, if someone with the know how could make a mod that also included the LWJGL for ARM. In this manner, as I understand it, getting MC to run on BBB would be as simple as copying over a mod.
Sorry I couldn't help further. I'll keep an eye on this post and I'll let you know what I find out.
Related
I want a latest version of GCC for Windows.
Now the latest version is 9.2 but for Windows via MinGW it is just 8.1...
I have tried to build from source for Windows 10 include WSL, but have not found how to do it exactly, I do not want use via CygWin or other emulater, just real on Windows as clang and MSVC.
Note: I have Windows 10 latest version with WSL.
The latest version of GCC (9.2.0) compiler combined with the latest MinGW-w64 (7.0.0) headers and libraries can be found in the standalone build at http://winlibs.com/
Oh the pain, getting a working GCC for Windows.
build your own?
Building is a fun experience, or a no-fun experience, depending on how you look at it.
I've spent literally weeks of time building GCC successfully and unsuccessfully (native and cross). Follow the instructions to the letter, and it works. And then, another day, it doesn't work (with the slightest different sub-sub-release or revision, or the tiniest little change that is entirely "harmless", or to the best of your knowledge no change at all, and you never get it to build again).
Save everything you've done (copy console), keep the build tree, and repeat the build (paste text) 6 months later after first doing a svn update. Compiles fine for 15-20 minutes, then fails. Start from scratch, and spend a day or two until it works, and you cannot tell why it works now.
Use a build script by someone who offers binary builds (so the assumption is that it must work, otherwise where do the binaries come from). The build script more or less does exactly what you've done by hand anyway, and it works, or maybe doesn't work. If you are only interested in actually having a compiler that works for compiling under Windows, and not in spending your life fiddling around, that's not a lot of fun.
use a pre-built binary?
There exists serval binary distros from a variety of sources.
Although downloading binaries is of course always a tidbid risky (even when scanning everything before you run it, malware scanners are nowhere near perfect, or even good or halfway reliable), compilers are particularly high-risk. That's because compilers are a very interesting target for malware distributors as they get free redistribution with everything you build.
I've actually seen GCC builds with malware built-in on apparently harmless sites (forgot the name, but one such example was a site offering GCC builds for several architectures, which looked very nice).
Now... there exists a distro which supports GCC 9.2 since some time built by someone under the pseudonym "nuwen".
It turns out, that "nuwen" is actually Stephan T. Lavavej, so... chances are that this is a distro that you actually want to use (I'm using it anyway). It's unlikely that you will be able build one yourself that's substantially better (also that one has a lot of useful support libs already coming with it), and it's unlikely that it is harmful.
https://nuwen.net/mingw.html
Note that MSYS2 will also allow you to install a very recent GCC (9.1 or 9.2, not sure) via pacman, very fast and very trouble-free. MSYS2 is nice insofar as you get a 95% working Unix-like working environment with 95% of the tools.
And 95% of the time, it works fine in every practical respect. Until then, one day, it doesn't, usually related to some configure script messing up pathnames, or something with environment variables. Or something else very subtle. For example, it is very much possible to successfully build GCC with MSYS2 (I've done it), and it works "perfectly fine" until some weeks later you discover that something doesn't work in your custom build, so some old project of yours now suddenly doesn't build any more when it did with the old stock compiler.
That's probably issues that one could fix, if determined (I'm however too lazy, for me a compiler is something that simply must work).
There are two well known distributions of the GCC bundle for Windows. The first one is by equation.com
http://www.equation.com/servlet/equation.cmd?fa=fortran
and the second one is by winlibs.com
http://winlibs.com/
I'm trying to cross compile a project from x86_64 Linux to Win64 in Lazarus. On build, I get:Fatal: Cannot find system used by fcllaz of package FCL.
I've seen this question asked in several places, and I guess I don't understand the answers. I do have fcllaz.pas. I've seen "Check your -Fu" answers, but there isn't enough detail for me to determine what I'm looking for or need to do. I've seen those statements in fpc.cfg, I'm just not sure what to do with them.
I'm quite new to Lazarus. In the form of a question: how do I point Lazarus/fpc to fcllaz and get this thing compiled?
The error is that it can't find unit system, fcllaz is just what is being compiled when it first misses system.
Not finding system means the compiler can't find the RTL (and the rest of the precompiled units) for the selected target (win64). These probably don't come with your installation so you have to build and install them yourself.
The -Fu are lines in the fpc.cfg that should point to the relevant units.
Though a bit outdated, the buildfaq has a lot of background info how the system builds and finds its units.
I have a DragonBoard APQ8074 with SnapDragon 800. I am able to successfully build Android and run some OpenCL related apps on this.
I am currently trying to build a linux kernel and load either Ubuntu or Fedora on this board.
It wouldbe really helpful if anyone could point me to suitable posts or guides.
I did look into Freedreno, it is really a good starting point, but i am still unable to understand the part of initrd/ramdisk img file.
Also the bootloader (similar to u-boot i assume), i am not clear which parts of it i need to update, if at all necessary.
Thanks in advance.
regard,
Anup.
This might help http://whiteboard.ping.se/Android/Android. There's a few sections there that might be handy. I also found this other article that helped me understand intrd and intramfs a bit better if that helps. http://www.linux.com/learn/linux-career-center/114923-the-kernel-newbie-corner-qinitrdq-and-qinitramfsq-some-unfinished-business
We've been compiling kernel modules for an embedded powerpc system for a few years now and generally things are ok with some rare unexplained stability problems. Recently a collegue pointed out that kernel modules should be compiled with the same compiler as the kernel. After doing a bit of digging i find that the kernel (montavista linux 2.4.20) was compiled with gcc3.4.1 and we've been using (denx eldk) gcc4.0.0. I've recently built gcc4.7.1 for our userspace code but loading kernel modules built with this version cause the system to crash. I then build gcc3.4.1 from source and some builds work and some don't - think i may have an issue with the make scripts but thats another story.
So my question: Is my collegue correct? And if so can anyone explain what is different in the resulting .o file that causes the incompatibility?
Wow, that kernel has been around a long time, since the early days of my former MontaVista employment! I'm not sure there is a hard fast answer here, but I know if it were me, I would be concerned about compiler differences. The Linux kernel has always been sensitive to compiler versions, in part because of it's sheer size and complexity. The kernel uses lots of GNU extensions, and actually makes a pretty good stress test for a new compiler build.
You can discover what compiler was used to build the kernel simply by looking at the output of /proc/version (I think that exists that far back in the 2.4.20 kernel days, but I could be wrong on that.) $ cat /proc/version. It certainly works for modern kernels and has been in the kernel for a long time.
My first suggestion would be to upgrade the kernel to something more modern, but I suspect that's not really an option, or you wouldn't be asking the question! ;)
I suspect that even a compiler expert (not me) would have a hard time answering the question "what's different". But do this simple test. Compile your module with 3.4.1, and then 4.7. The resulting objects (.ko files) will certainly be different.
The reality is, bugs exist in all software, and may lurk for ages until something comes along to stimulate the bug. See my blog post here: http://blogs.mentor.com/chrishallinan/blog/2012/05/18/fun-with-toolchain-versions for a perfect example of this.
Now I'm not saying that's your issue, but I think I'd feel alot better if my modules and kernel were both compiled with the same compiler version.
Good luck.
It matters.
Mostly you would encounter the following, i.e.
rmmod: ERROR: could not remove 'hello': Device or resource busy
I am a complete newbie to the ARM world. I need to be able to write C code, compile it, and then download into an ARM emulator, and execute. I need to use the GCC 4.1.2 compiler for the C code compilation.
Can anybody point me in the correct directions for the following issues?
What tool chain to use?
What emulator to use?
Are there tutorials or guides on setting up the tool chain?
building a gcc cross compiler yourself is pretty easy. the gcc library and the C library and other things not so much, an embedded library and such a little harder. Depends on how embedded you want to get. I have little use for gcclib or a c library so roll your own works great for me.
After many years of doing this, perhaps it is an age thing, I now just go get the code sourcery tools. the lite version works great. yagarto, devkitarm, winarm or something like that (the site with a zillion examples) all work fine. emdebian also has a good pre-built toolchain. a number of these places if not all have info on how they built their toolchains from gnu sources.
You asked about gcc, but bear in mind that llvm is a strong competitor, and as far as cross compiling goes, since it always cross compiles, it is a far easier cross compiler to download and build and get working than gcc. the recent version is now producing code (for arm) that competes with gcc for performance. gcc is in no way a leader in performance, other compilers I have used run circles around it, but it has been improving with each release (well the 3.x versions sometimes produce better code than the 4.x versions, but you need 4.x for the newer cores and thumb2). even if you go with gcc, try the stable release of llvm from time to time.
qemu is a good emulator, depending on what you are doing the gba emulator virtual gameboy advance is good. There are a couple of nds emulators too. GDB and other places have what appear to be ARMs own armulator. I found it hard to extract and use, so I wrote my own, but being lazy only implemented the thumb instruction set, I called mine the thumbulator. easy to use. Far easier than qemu and armulator to add peripherals to and watch and debug your code. ymmv.
Hmmm I posted a similar answer for someone recently. Google: arm verilog and at umich you will find a file isc.tgz in which is an arm10 behavioural (as in you cannot make a chip from it therefore you can find verilog on the net) model. Which for someone wanting to learn an instruction set, watching your code execute at the gate level is about as good as it gets. Be careful, like a drug, you can get addicted then have a hard time when you go back to silicon where you have relatively zero visibility into your code while it is executing. Somewhere in stackoverflow I posted the steps involved to get that arm10 model and another file or two to turn it into an arm emulator using icarus verilog. gtkwave is a good and free tool for examining the wave (vcd) files.
Above all else you will need the ARM ARM. (The ARM Architectural Reference Manual). Just google it and find it on ARM's web site. There is pseudo code for each instruction teaching you what they do. Use the thumbulator or armulator or others if you need to understand more (mame has an arm core in it too). I make no guarantees that the thumbulator is 100% debugged or accurate, I took some common programs and compared their output to silicon both arm and non-arm to debug the core.
Toolchain you can use Yagarto http://www.yagarto.de/
Emulator you can use Proteus ISIS http://www.labcenter.com/index.cfm
(There is a demo version)
and tutorials, well, google them =)
Good luck!