Upgrade Ubuntu Kernel from 12 to 16 LTS #25
Comments
|
http://xillybus.com/xillinux I copied the devicetree.dtb file from the FAT partition on our image. And the FPGA xillydemo.bit file. With that .dtb file from the old image, the new image will NOT boot; it kernel panics. With the .dtb file provided with the new image, it does boot, but there is only a /dev/uio0 and the extra /dev/uio1 which was on the old image is missing. DexRun.C expects /dev/uio1 Modifying DexRun.c to point to the /dev/uio0 causes the ethernet adapter to stop working, and DexRun fails at the test for I've verified that the correct .bit file is on the image; the According to this document; Perhaps the device tree was edited to add that new uio1. There is no devicetree.dts file on the old image. The source dts file should be: Things that do work:
Things that are missing / not configured / not working:
Those issues are moot until we can figure out why DexRun.c isn't seeing what it expects in the mapped area. |
|
The gcc compiler included in Xillinux 16.04 is C99 standard and |
|
Learning to compile the devicetree so that it can be edited and then re-compiled. Following: It appeared to complete once, but now I get |
|
http://xillybus.com/pcie-download |
|
Apparently none of that is actually needed. There is a specific application to compile or decompile device tree files I have decompiled our version of the devicetree file from the old v12 OS (see attached) In comparison to the new .dts file, I don't see anything that is in our old file that is not in the new file. There are a large number of differences because the format of a decompiled file is slightly different, but even when compiling and decompiling the v16 file, it seems like the v16 file has new items and is not missing anything that is in our v12 file. A better comparison is between their original v12 file (decompiled) and our modified V12 file (decompiled), but I'm having a difficult time finding that file in their repo. The only commit is apparently the original, or at least it says it's for Xillinux 1.3 as well as 2.0 |
|
I've downloaded the Xillinux 1.3 image, extracted the .dts file from the boot folder, compiled it, decompiled it (so that the syntax matches as much as possible) and this compared it with the decompiled version of our v12 devicetree.dtb. Here is that session (note all the warnings... no idea what's up with that). To summarize the changes:
|
|
So it turns out there is a dtc program on the image at: So now to apply the changes to the new dts file. The last section in the source file from the Xillinux 2.0 repo is And from the decompiled .dtb file it appears as: So I'm guessing our added section can be 0x3C is 60 in decimal which appears to be the preferred radix for expressing I have no idea what to do about the The With those changes, the new file appears to compile on the old image. Next to place it on the new image, compile there, and see if a /dev/uoi1 shows up. |
|
And Dexter is up! DexRun runs, and doesn't crash, DDE connects, move all joints works. The source file, made as indicated above, is attached as Which then generates devicetree.dtb.zip which then gets moved to the SDcard FAT partition, and restart I was also able to install samba and get it working by following this tutorial: TODO:
|
|
Making DexRun run on startup was confusing. The file /etc/rc.local appears to say that each time a user logs in it will execute, but it appears that it is only run once on system startup. So I just added the line: just before the P.S. Should we make DexRun check for other DexRuns and not start if one is already running? Or kill the running one and start? EDIT: That does NOT work. Starting from root, if you do I created a file in /srv/samba/share called RunDexRun and in it put: then changed it's permissions so everyone can run it, and that works from the root directory, e.g. from / the command /srv/samba/share/RunDexRun works. So I've edited /etc/rc.local to put in and after a restart, Dexter moves again. |
|
Had already
|
|
A 2D gnome-session file is apparently needed? Following this page: None of that seems to work. Many errors are listed on the debug output. I think the issue is the session files aren't right or I'm not starting it right. Searching for gnome-session documentation, I found this:
Apparently the issue is that 1. we don't have hardware acceleration since there isn't a real graphics card and 2. ubuntu-2d support has been removed, and the standard one expects unity 3d support? Perhaps sticking with Lubuntu desktop is best? |
|
DDE is running on the 16.04 image! The following instructions from Bret with one small change to the last line did it:
A "dde_apps" folder must be created under the "/root" folder (alongside Documents, not in it). Setting the dexter0 ip address to |
|
DexRun was crashing whenever I tried to make the robot move. It turns out this was as the result of a "write past end of array" error that has been in the code for a long time. See source code below. In the past, whatever was in memory after RxBuf (usually TxPacket so no harm done) was getting clobbered and there was no indication of it. The new gcc includes code that catches this at run time and causes a Here is the relevant code: SendPacket just passes that RxBuf pointer and the 16 onto UnloadUART which then shoves 27 (16+11) bytes into it, writing 7 bytes past its end. I've updated the code on the SpeedsUpdate branch to use sizeof in all cases and set the size of the char array to the size I think it's actually pulling. |
|
You're reminding me why I don't miss writing C code.
Great detective work!
…On Fri, Jan 25, 2019 at 8:33 PM JamesNewton ***@***.***> wrote:
DexRun was crashing whenever I tried to make the robot move. It turns out
this was as the result of a "write past end of array" error that has been
in the code for a long time. See source code below. In the past, whatever
was in memory after RxBuf (usually TxPacket so no harm done) was getting
clobbered and there was no indication of it. The new gcc includes code that
catches this at run time and causes a *** stack smashing detected ***
crash.
Here is the relevant code:
42df0e0#diff-691272021fae98368efb598f8e089c16R1339
<42df0e0#diff-691272021fae98368efb598f8e089c16R1339>
void UnloadUART(unsigned char* RxBuffer,int length)
{
int i;
unsigned char RecData;
for(i = 0;i < length + 11; i++)
{
mapped[UART1_XMIT_CNT] = 16; // generate next data pull
RecData = mapped[UART_DATA_IN];
RxBuffer[i] = RecData;
#ifdef DEBUG_XL320_UART
printf(" %x ", RecData);
#endif
mapped[UART1_XMIT_CNT] = 0; // generate next data pull
}
}
void SendGoalSetPacket(int newPos, unsigned char servo)
{
int i;
unsigned char RxBuf[20];
unsigned char TxPacket[] = {0xff, 0xff, 0xfd, 0x00, servo, 0x07, 0x00, 0x03, 30, 0, newPos & 0x00ff, (newPos >> 8) & 0x00ff, 0, 0};
unsigned short crcVal;
crcVal = update_crc(0, TxPacket, 12);
TxPacket[12]=crcVal & 0x00ff;
TxPacket[13]=(crcVal >> 8) & 0x00ff;
SendPacket(TxPacket, 14, CalcUartTimeout(14 + 14),RxBuf, 16); // send time plus receive time in bytes transacted
//UnloadUART(RxBuf,16); // TODO refine actual size
}
SendPacket just passes that RxBuf pointer and the 16 onto UnloadUART which
then shoves 27 (16+11) bytes into it, writing 7 bytes past its end. I've
updated the code on the SpeedsUpdate branch
<769d4dc>
to use sizeof in all cases and set the size of the char array to the size I
think it's actually pulling.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABITfXI5HnnNMUMYFqKX6z8VVbY1rNMeks5vG7B9gaJpZM4Vk673>
.
|
|
From James N above:
"A "dde_apps" folder must be created under the "/root" folder (alongside
Documents, not in it)."
I'm surprised by this because I've seen a "Documents" dir in Linux systems
that SEEMS to
be the same kind of dir that both Windows and MacOS has.
(which itself is a miracle that the 3 agreed on something so sensible.)
Now the code that determines where the dde_apps folder should live
is in DDE main.js,
let documents_dir = app.getPath("documents")
console.log("First try getting 'documents' yielded: " + documents_dir)
let the_dde_apps_dir = documents_dir + "/dde_apps"
So I guess what's happening is that in Linux,
app.getPath("documents") doesn't return
a "Documents" dir at all, but "/root"
This is more expected, ie whenever a decent standard is proposed,
somebody will screw it up.
Now is this the same for Ubuntu running on your laptop,
or can the dde_apps dir be under "documents" there?
BTW, I'm impressed that you figured this out.
Did my console.log statement above help?
I left it in there for just such a possibility.
…On Fri, Jan 25, 2019 at 8:33 PM JamesNewton ***@***.***> wrote:
DexRun was crashing whenever I tried to make the robot move. It turns out
this was as the result of a "write past end of array" error that has been
in the code for a long time. See source code below. In the past, whatever
was in memory after RxBuf (usually TxPacket so no harm done) was getting
clobbered and there was no indication of it. The new gcc includes code that
catches this at run time and causes a *** stack smashing detected ***
crash.
Here is the relevant code:
42df0e0#diff-691272021fae98368efb598f8e089c16R1339
<42df0e0#diff-691272021fae98368efb598f8e089c16R1339>
void UnloadUART(unsigned char* RxBuffer,int length)
{
int i;
unsigned char RecData;
for(i = 0;i < length + 11; i++)
{
mapped[UART1_XMIT_CNT] = 16; // generate next data pull
RecData = mapped[UART_DATA_IN];
RxBuffer[i] = RecData;
#ifdef DEBUG_XL320_UART
printf(" %x ", RecData);
#endif
mapped[UART1_XMIT_CNT] = 0; // generate next data pull
}
}
void SendGoalSetPacket(int newPos, unsigned char servo)
{
int i;
unsigned char RxBuf[20];
unsigned char TxPacket[] = {0xff, 0xff, 0xfd, 0x00, servo, 0x07, 0x00, 0x03, 30, 0, newPos & 0x00ff, (newPos >> 8) & 0x00ff, 0, 0};
unsigned short crcVal;
crcVal = update_crc(0, TxPacket, 12);
TxPacket[12]=crcVal & 0x00ff;
TxPacket[13]=(crcVal >> 8) & 0x00ff;
SendPacket(TxPacket, 14, CalcUartTimeout(14 + 14),RxBuf, 16); // send time plus receive time in bytes transacted
//UnloadUART(RxBuf,16); // TODO refine actual size
}
SendPacket just passes that RxBuf pointer and the 16 onto UnloadUART which
then shoves 27 (16+11) bytes into it, writing 7 bytes past its end. I've
updated the code on the SpeedsUpdate branch
<769d4dc>
to use sizeof in all cases and set the size of the char array to the size I
think it's actually pulling.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABITfXI5HnnNMUMYFqKX6z8VVbY1rNMeks5vG7B9gaJpZM4Vk673>
.
|
|
LOL. Adding wifi support required: 1. Plugging in a usb wifi dongle (I didn't even restart... just hot plugged it) 2. configuring my wifi SSID and password. Done. Stable and working nicely so far. I can connect to the robot from DDE on my PC to the adapters IP address and send commands. |
|
Quick note: On Ubuntu 16.04 PC, you can add the -X to ssh, as in |
|
I'm setting the cat 5 interface to 192.168.1.142 and using the WiFi interface (via a little USB dongle) via DHCP to my router. The #51 issue is effectively resolved and this greatly simplifies the use of the arm: When no router / wifi is available, a direct connection with CAT5 to a PC provides the expected static IP interface on the 192.168.1 network. With that, the user can SSH in and setup WiFi via the command line or use the xWindows interface to set it up via the very easy configuration dialog box from the network icon in the lower right corner of the desktop. If a fixed IP is desired for the WiFi, that can be configured on Dexter or, if the wifi router is accessible, it might support manually assigned DHCP addresses based on the MAC id of the WiFi adapter. I have NOT been able to get Dexter to drop the DHCP lease, so I would recommend setting that up on the router /before/ enabling WiFi on Dexter. |
|
Note that for support of the Dynamixel servos, /srv/samba/share/RunDexRun or /etc/rc.local must start DexRun with parameters I was able to confirm that BOTH servos do work after eventually getting my "3" servo made back into a "1" servo. See the Wiki Article for programming servos In DDE 2.5.13 LTS, under Jobs / Show robot status, if I press the "run update job" button, at first I get 148.48 and 0 for Joint 6 and Joint 7 "MEASURED ANGLE" but if I first move J6 / J7 by going to Jobs / Run instruction / Show dialog... and enter 0 for J6 and J7 then press "move_all_joints" then go back and do the status thing again, it works correctly. Note that the 'a' command values for J6/7 are in servo units, not arcseconds. @JamesWigglesworth says that for J6 zero degrees is actually 512 and for J7 it's 0. Apparently, the FPGA needs to be told to move J6/7 before that system becomes active. As per Kent, we can fire that off automatically on startup. e.g. there is no reason not to. The easiest way to do that is by adding values for J6/7 to a boot dance 'a' command in a make_ins file. This keeps it under customer control. e.g. if they don't want that running, they can delete or modify the file. Figuring out which file to put that in is probably a conversation to have with @JamesWigglesworth , but for now, I've just added Sadly, that file /isn't being executed/ because the code that does it was moved to after the sleep in mode 3! So I'm moving that to the start. Now the servos send back position as soon as the robot starts. |
|
Note to self: Xillinux 2.0 uses U-BOOT, not GRUB or LILO. |
|
Kamino cloned this issue to HaddingtonDynamics/OCADO |
Upgrade Ubuntu Kernel from 12 to 16 LTS and produce a new SD card image for user update. This may allow WiFi support and will allow a more modern version of Node.JS to be installed for local scripting.
The text was updated successfully, but these errors were encountered: