ssh on Onyx Boox M92

[kodomo]

This was indeed my problem with the arm build (see above )

My current problem is with build:x86:static . g++ is unhappy with some assembler code in onyx_wireless... given that it's unlikely that I will ever need that on the x86 platform, I'm wondering whether I should just disable it...

[  1%] Building CXX object code/src/wireless/CMakeFiles/onyx_wireless.dir/ap_item.cpp.o
cd /home/grsch/arbeit/home/boox_m92/booxsdk/build/x86/code/src/wireless && /usr/bin/g++   -DSHARE_ROOT=\"/usr/share\" -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DQT_SCRIPT_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_DBUS_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SCRIPT_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_DBUS_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/home/grsch/arbeit/home/boox_m92/booxsdk/third_party/gtest/include -I/home/grsch/arbeit/home/boox_m92/booxsdk/code/include -I/opt/onyx/arm/include -I/opt/onyx/arm/include/QtScript -I/opt/onyx/arm/include/QtWebKit -I/opt/onyx/arm/include/QtGui -I/opt/onyx/arm/include/QtTest -I/opt/onyx/arm/include/QtDBus -I/opt/onyx/arm/include/QtXml -I/opt/onyx/arm/include/QtSql -I/opt/onyx/arm/include/QtNetwork -I/opt/onyx/arm/include/QtCore   -Wall -Werror -o CMakeFiles/onyx_wireless.dir/ap_item.cpp.o -c /home/grsch/arbeit/home/boox_m92/booxsdk/code/src/wireless/ap_item.cpp
/opt/onyx/arm/include/QtCore/qatomic_arm.h: Assembler messages:
/opt/onyx/arm/include/QtCore/qatomic_arm.h:131: Error: no such instruction: `swpb %bl,%al,[%rdx]'
make[2]: *** [code/src/wireless/CMakeFiles/onyx_wireless.dir/dialup_dialog.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

[peterx]

When I compile the SDK for x86, the qt header files from my system are used, not those from /opt/onyx/include. Do you have the qt header files installed? It could also be that you have some environment variable defined that tells the build script that they should use the arm headers.

[kodomo]

Originally Posted by peterx

When I compile the SDK for x86, the qt header files from my system are used, not those from /opt/onyx/include. Do you have the qt header files installed? It could also be that you have some environment variable defined that tells the build script that they should use the arm headers.

libqt4-dev is installed.
No special environment variables are set.
Nonetheless, the arm headers are explicitely included:

/usr/bin/cmake -E cmake_progress_report /home/grsch/arbeit/home/boox_m92/booxsdk/build/x86/CMakeFiles 
[  2%] Building CXX object code/src/wireless/CMakeFiles/onyx_wireless.dir/ap_item.cpp.o
cd /home/grsch/arbeit/home/boox_m92/booxsdk/build/x86/code/src/wireless && /usr/bin/g++   -DSHARE_ROOT=\"/usr/share\" -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DQT_SCRIPT_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_DBUS_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SCRIPT_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_DBUS_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/home/grsch/arbeit/home/boox_m92/booxsdk/third_party/gtest/include -I/home/grsch/arbeit/home/boox_m92/booxsdk/code/include -I/opt/onyx/arm/include -I/opt/onyx/arm/include/QtScript -I/opt/onyx/arm/include/QtWebKit -I/opt/onyx/arm/include/QtGui -I/opt/onyx/arm/include/QtTest -I/opt/onyx/arm/include/QtDBus -I/opt/onyx/arm/include/QtXml -I/opt/onyx/arm/include/QtSql -I/opt/onyx/arm/include/QtNetwork -I/opt/onyx/arm/include/QtCore   -Wall -Werror -o CMakeFiles/onyx_wireless.dir/ap_item.cpp.o -c /home/grsch/arbeit/home/boox_m92/booxsdk/code/src/wireless/ap_item.cpp

There must be some problem with the make files (didn't find the source of the problem, yet)... could it be that they updated the repository between your checkout and mine?

[kodomo]

Starting with a fresh checkout and using
build:static instead of build:arm/x86:static it finally worked.

Furthermore, I managed to compile some of the packages in boox-opensource , though not all:

• dictionary_tool was missing the libz statement again (patch attached)
• cr3, djvu_reader, fbreader_onyx, feed_reader, music_player, rss_reader failed to compile for X86 (not yet tried for ARM) for diverse reasons (not yet tried to debug).
• feed_reader seems to be missing a file (feed_action.cpp)

I've updated the wiki on how to compile boox-opensource packages.

Cheers.

[kodomo]

So it turned out that music_player was merely missing some -dev packages on the x86 platform.

feed_reader is indeed missing the feed_action.h header file.

cr3, djvu_reader, fbreader_onyx, and rss_reader have portability issues compiling for x86 on amd64 machines (e.g., casting pointers to int).

djvu_reader and rss_reader compile for arm on amd64, and for x86 in 32bit environments.

fbreader compiles for x86 in 32bit environments, if a not needed cryptopenssl lib inclusion is removed from its CMakeLists.txt (patch attached) - but arm toolchain & sdk are lacking the needed libcrypto .

cr3 yields linker errors (several 'multiple definition' errors, such as this one)

./../../../libs/libonyx_ui.a(number_dialog.cpp.o): In function `ui::NumberDialog::keyPressEvent(QKeyEvent*)':
number_dialog.cpp:(.text+0x0): multiple definition of `ui::NumberDialog::keyPressEvent(QKeyEvent*)'

All in all, the 32bit environment tools also seem much more forgiving, as the libz (missing in some CMakeLists.txt) was found even without the applied patches.

Hence what we need from Onyx seems

• The feed_action.h header file
• The crypto lib in the SDK (prebuilt and/or source)
• The kernel sources and patches
• A solution to the cr3 linker issue (anyone?)

[kodomo]

...wrote a support ticket requesting the missing resources (but didn't get feedback that submission actually worked)... hope they will react

Cheers!

[Koudijs]

Originally Posted by kodomo

Hence what we need from Onyx seems

• The feed_action.h header file
• The crypto lib in the SDK (prebuilt and/or source)
• The kernel sources and patches
• A solution to the cr3 linker issue (anyone?)

libcrypto is provided by the openssl package, you can download the sources here.

[kodomo]

Originally Posted by Koudijs

libcrypto is provided by the openssl package, you can download the sources here.

Cool - an OpenBoox devel. stumbled across our thread

Welcome, Koudijs!

Thx for the link (though I'd still prefer them adding it to the regular sdk package :P )

Btw., since you're already 'here' - do you happen have a pointer to firmware/software update (procedure/safety) documentation?

Do the update routines reside in the bootloader? Initrd? Another partition? Or does one have to fear bricking a device by replacing files in the regular file system?

And are there plans to extend OpenBoox support to the M92? :P

[FDD]

Originally Posted by kodomo

Btw., since you're already 'here' - do you happen have a pointer to firmware/software update (procedure/safety) documentation?

Do the update routines reside in the bootloader? Initrd? Another partition? Or does one have to fear bricking a device by replacing files in the regular file system?

You could give a look at this post of mine.

I didn't mention there that the bootloader runs the update kernel+initramfs only if you hold down the "ok" button (if there is no update file, nothing happens, except displaying messages).

Just replacing files in the root filesystem will do no permanent harm. A bad flash can brick the device, since the initramfs where most of the updating procedure is gets updated as well, leaving you unable to update again; however that update is done last, so you should be able to log in the M92 and fix everything by hands.
Also as long as the bootloader is good you should be able to flash a good image manually, but I don't know how to connect to the serial port (no obvious serial/jtag pin header).

Hope this helps!

[tuxor]

When connecting to my M92 via g_serial over USB everything works fine. But as soon as I log out by typing "exit" in the remote console, I have to remove the "g_serial.ko" module on M92 and insmod it again in order to login again. Is this intended? Any way around this?

[FDD]

Originally Posted by tuxor

When connecting to my M92 via g_serial over USB everything works fine. But as soon as I log out by typing "exit" in the remote console, I have to remove the "g_serial.ko" module on M92 and insmod it again in order to login again. Is this intended? Any way around this?

There should be no need to remove and insert back the module, just run again the start script, because putty exec's the shell, so it is not running anymore when you logout. I didn't feel confortable running putty in a background loop, let alone changing the inittab, because having it running could prevent you from removing the module and I thought it was simpler this way. IMHO a script that runs getty, sleeps 5 seconds and loops is safe, as long as you kill it when you don't need the serial anymore.

[tuxor]

Okay, your solution sounds very sensible Thanks for the explanation!

[kodomo]

Originally Posted by FDD

You could give a look at this post of mine.

I didn't mention there that the bootloader runs the update kernel+initramfs only if you hold down the "ok" button (if there is no update file, nothing happens, except displaying messages).

Just replacing files in the root filesystem will do no permanent harm. A bad flash can brick the device, since the initramfs where most of the updating procedure is gets updated as well, leaving you unable to update again; however that update is done last, so you should be able to log in the M92 and fix everything by hands.
Also as long as the bootloader is good you should be able to flash a good image manually, but I don't know how to connect to the serial port (no obvious serial/jtag pin header).

Hope this helps!

Does - thx (linked to wiki pointers section).

I'm still trying to assess the situation (though I don't have much time these days ), finding out what you can/cannot do and collecting infos/resources to play around with the device.

Mentioning jtag: Did you actually disassemble the device? It might interest some folks to know about the specific hardware built into the product (e.g., the wacom tablet type to facilitate a search for alternative styli).

Unfortunately, I didn't get any response from Onyx on my ticket requesting kernel sources/patches yet... I'm wondering whether something went wrong submitting the ticket, or whether they're ignoring it... has anyone else tried?

[kodomo]

Originally Posted by FDD

I handed out a copy of the one I used to a few users, but it still not quite ok. As soon as I get a fully working configuration I'll publish it and let you know.

Hi FDD.

How are things going with the kernel config?

Can you please add a section to the Devel Wiki page w.r.t. kernel module compilation?

If I interpret this post https://lists.ubuntu.com/archives/ke...ly/006417.html correctly, there's a considerable chance that the M92 USB controller may support host mode... and that would open a new world of possibilities (bluetooth/keyboard support for text input, e.g. )

I hope that Onyx will release the sources and patches in accordance to the GPL, though... It'd be a shame to have to involve the FSF :-| .

btw.: I'm a little surprised to see bluetooth.ko included with the std. fw image... it seems to be used by the wifi driver... does anyone know why? Does the atheros chip support bluetooth, or is it only this bt coexistence interface?

[kodomo]

Originally Posted by kodomo

fbreader compiles for x86 in 32bit environments, if a not needed cryptopenssl lib inclusion is removed from its CMakeLists.txt (patch attached) - but arm toolchain & sdk are lacking the needed libcrypto .

cr3 yields linker errors (several 'multiple definition' errors, such as this one)

./../../../libs/libonyx_ui.a(number_dialog.cpp.o): In function `ui::NumberDialog::keyPressEvent(QKeyEvent*)':
number_dialog.cpp:(.text+0x0): multiple definition of `ui::NumberDialog::keyPressEvent(QKeyEvent*)'

Hence what we need from Onyx seems

• The feed_action.h header file
• The crypto lib in the SDK (prebuilt and/or source)
• The kernel sources and patches
• A solution to the cr3 linker issue (anyone?)

Compiling openssl and placing the resulting 'lib' and 'include' directory content into respective /opt/onyx/arm/ subdirectories allowed compilation of fbreader.

Attached, you'll find a patchfile modifying the Makefile to make it easy to use the toolchain.

To use it, download and unpack the openssl archive, patch the Makefile, set your environment variables (as described in the Development wiki), and call

export INSTALLTOP=`pwd`/build/arm ; export TC_PREFIX=arm-linux- ; make install

The binaries will then be put into ./build/arm .
Copy the contents of the include and lib directories into your onyx sdk environment (presumably under /opt/onyx/arm - mind that there's already an include/openssl directory).

fbreader should compile thereafter (mind to remove the other library dependency).

I'll update the Devel wiki to that respect.

Cheers!

Update: initial post was missing a '-' after arm-linux