I am using yocto project to build linux os image.
I used SUMO release so I had 4.14.73 kernel version.
The problem is that i have pre-compiled linux driver which version is 4.14.88.
I think that i must upgrade my linux kernel to become the same version of the driver.
Any Idea how to do that please ?
1) You have to use PREFERRED_VERSION_linux-yocto = "4.14.88" in your distro config, e.g:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky.conf?h=daisy#n22
Note however that Sumo does not provide 4.14.88. The latest Sumo I see provides 4.14.76:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto_4.14.bb?h=sumo#n27
So your options are to create a linux-yocto_4.14.bbappend and modify the version, or create a new kernel recipe altogether to fit your needs.
Related
Currently using Buildroot-2019.02 with support for Qt5.6.3 and Qt5.11.x. BSP is built with customized Linux kernel.
Please suggest if it is possible to upgrade Qt5.15.x version in the existing Buildroot 2019.02.x version
If it is not feasible, the only option is to upgrade to a higher version of Buildroot-2022* where it is Qt5.15.8 and also upgrade the Linux kernel and customize it as older GCC wouldn't be supported(which could take some time).
I have written a module that gets distributed as a .deb file and rebuilt with kernel updates using DKMS. What I would like is to be able to restrict the system from upgrading the kernel beyond what the module can be compatible with. For example, the module should be rebuilt for any kernel upgrade up to 4.19.1. Ideally, this would be built into .deb file but a second solution would just be restricting the system from installing kernels beyond a certain version. a third option would be presenting the user with a warning that the module won't work with the kernel version being installed.
In the past the driver was installed manually and had to be rebuilt with each kernel update which the user was unaware of. The source file header checked the kernel version for compatibility and wouldn't build if it was outside the allowed kernel range.
I have two questions.
1)
I'm testing H2O 3.10.5.1 version for xgboost modeling.
There is a known bug (PUBDEV-4585) that binary save/load of xgboost doesn't work.
Has it been fixed in the recent version? Confirmation is needed in order to make a decision with the server admin whether to upgrade the system or not.
2)
H2O.ai xgboost documentation says there is some limitation to platforms.
The "compilation OS" is Ubuntu 14.04, but is there a limitation to any other linux OS version like Redhat?
h2o.xgboost.available() returns TRUE but I need to make sure.
Thanks
Ad.1 Yes it's been fixed in version 3.18.0.1
Ad.2 The distro itself isn't really important. It's more important which exact version of RedHat are we talking about (since different versions come bundled with different lib versions) and whether you can upgrade libraries on your own if necessary. For example if you want to run the GPU version you'll need a certain version of glibc (2.17 or never if I remember correctly). For the CPU version most recent Linux distributions should be ok.
The binaries for Linux, OSX, and Windows are all embedded in the sqlite-jdbc.jar...
org/sqlite/native/Linux/amd64/libsqlitejdbc.so
org/sqlite/native/Linux/i386/libsqlitejdbc.so
org/sqlite/native/Mac/i386/libsqlitejdbc.jnilib
org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib
org/sqlite/native/Windows/amd64/sqlitejdbc.dll
org/sqlite/native/Windows/x86/sqlitejdbc.dll
My problem is, that while I'm running Linux, I am not on amd64 or i386. The Raspberry Pi is ARM. Where can I get a sqlite-jdbc.jar with the ARM binaries embedded?
A lib provided by someone who claims to have build it: https://bitbucket.org/xerial/sqlite-jdbc/issue/79/compile-for-arm
Instructions for build https://pidome.wordpress.com/2013/10/01/java-goes-hard-on-the-raspberry-pi-so-does-pidome/
and
Error opening connection SQLite on Raspberry pi
#dacracot
I'm not sure if i'm prohibited by offering help this way but:
I have the library available when you would download the whole PiDome server package.
For convenience, and multiple requests i have added it as a separate download. The library has been compiled against the hard float abi and is currently using sqlite-jdbc-3.7.15.
The jar file contains the default supported platform libraries and has the arm support added.
It is available at: https://bitbucket.org/pidome/pidome-server/downloads
I'm trying to perform cross platform remote debugging from my x86 computer to a remote ARM device. (ex: Beagle Bone Black)
I'm using Ubuntu 14.04 and Eclipse CDT.
I installed the package gcc-arm-linux-gnueabihf but the gdb debugger is not in that package. (http://packages.ubuntu.com/precise/gcc-arm-linux-gnueabihf)
Therefore, I'm wondering if I should use the Linaro toolchain (which include arm-linux-gnueabihf-gdb) or if I should install the gdb-multiarch package.
What is the difference between gdb-multiarch and arm-linux-gnueabihf-gdb ?
Is it better to use gdb-multiarch ?
ssinfod
I received an answer from the linaro mailing list:
For Ubuntu hosts from 12.04 onwards, gdb-multiarch is used as gdb client for debugging. As name indicates it is a common client to any architecture and not restricted to ARM.
Generally, all gdb clients are architecture independent because architecture specific part is handled in gdbserver itself. So, other than the name arm-linux-gnueabihf-gdb, I am guessing it is same as gdb-multiarch.
I received another answer from the linaro mailing list:
The Linaro gdb release will generally be more up to date than the
Ubuntu one. For example our latest release is 7.8, and that is only
available in utopic, not trusty so if you plan to use an Ubuntu LTS
release it might be better to use the Linaro shipped gdb. Linaro gdb
also contains fixes and improvements that aren't in the upstream
stable branch. Historically Ubuntu has often picked these changes up
too but that may not always be the case.
gdb-multiarch obviously supports a range of other architectures
besides ARM, so if that is something that would be useful for you then
it might make sense to use that.