Where to build/install ADC module

[Rich]

Hi MTCAT

... 2) Not really sure how the 24dsi.ko is being loaded, but there is the ./start command in rc.local. ...

There's an  insmod  command in that file that loads the driver.

... 3) ACPI is enabled in the BIOS though ! (Although the BIOS clearly also says the OS must be ACPI capable - I think based on dmesg, ACPI is off  - "ACPI interpeter disabled" is in dmesg.txt), my old BIOS seems to be much better labeled or documented than the new one from WinSystems. ...

I also see this in  dmesg.txt:

Code: [Select]

[    0.155301] pnp: PnP ACPI: disabled
Yet in the  dmesg1.txt  file you posted here I see:

Code: [Select]

pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNPTry using the boot code:

Code: [Select]

pnpacpi=off

[MTCAT]

Hi Rich,

Thank you very much for the information on the "invalid number" error, I'll add the -x command to the Makefile and see what happens.

Sorry about the driver location, I just thought that's where it needs to be for other programs to find it....I kind of thought that was what the extension loading did, was make that directory structure and put the driver where it needs to be....

Sorry for the information overload, the dmesg1.txt fie you refer to is for the dual core VortexDX3 board from WinSystems......which is what you've been helping me with for the past ? months.

The dmesg.txt file you refer too could be either from my old Celeron setup, or the single core VortexDX I've been playing around with late this past weekend, in a desperate thrash to get something to work consistently I switched over to trying out the VortexDX board.

I too was alarmed/scared about the "cmov" compiler directive missing, but, for the newer dual core DX3 at least, in TC3, and Lubuntu, I was able to build and install the driver (after you told me how to do it !), and run the test programs, and it all worked. Could be coincidence, but as soon as we switched over to a "proper" install of TC3.8.4 (I think anyway), I started getting these BAR errors with the DX3 and it's been flakey ever since, but also in Lubuntu too, so I don't know how that makes sense.

As a test, I put the 24DSI12 back into my old stack, with the power hungry 650 MHz Celeron, and everything worked fine, all the test programs worked, so at least we know the board isn't damaged.

General Standards says that all the "flakey" problems we're having are due to the 24DSI not having enough time to initialize, it needs more time somehow apparently.....

But lastly, for the heck of it, I installed the 24DSI12 into a stack with a single core VortexDX SBC, and that seems kind of promising, booting up TC3.8.4 still. On the VortexDX, the system seems better behaved, no BAR errors, but now we got that "invalid number error" when trying to build the driver It seems encouraging that with the VortexDX, the pci address's are all on bus 00:xx.x, which is how my Celeron board is as well (you can see that in lspci.txt I posted), whereas with the DX3, it always puts the 24DSI12 on bus 3 03:xx.x., maybe that's irrelevant though.

So that's the recent history, sorry for the confusion, it's hard for me to keep track of it even !

I'll try that extra "-x" in the Makefile.

Thanks,

David

[MTCAT]

Hi Rich,

I made a 24dsi.linux.4.11.91.32.0 directory in home/tc and unpacked the tar file there.

I copied the BuildADC.sh script into home/tc/24dsi.linux.4.11.91.32.0/24dsi, made it executable (as you showed me), and then also added the "-x" in the "make_all" script, and then ran "./BuildADC".

Unfortunately, I saw nothing but the "floating point exceptions" scroll by and this crashed TC to the point that there was no "menu" down at the bottom to shut-down nicely and one of the Terminal windows was totally unresponsive, in the working Terminal window I tried "sudo halt", and "sudo shutdown -h now" and nothing worked, I had to cycle the power to turn it off, not knowing any other way.

Next boot up, I was missing all my extensions (lspci, etc), but then powered down, connected my ethernet cable (I had it disconnected before), and powered back up, and all my extensions were loaded again, and here's the "build.txt" file, unfortunately it didn't capture much of anything that I saw flash past on the screen ?

Thanks,

David

[Rich]

Hi MTCAT
Modify the  make_all  file so the first 3 lines look like this:

Code: [Select]

#!/bin/sh -x

Code: [Select]

exec 1>make_all.txt

Code: [Select]

exec 2>&1

... I copied the BuildADC.sh script into home/tc/24dsi.linux.4.11.91.32.0/24dsi, made it executable (as you showed me), and then also added the "-x" in the "make_all" script, and then ran "./BuildADC". ...

You mean  ./BuildADC.sh , or you renamed it, right? At any rate, now run it again and attach the  make_all.txt  file that gets created.

When you run this:

Code: [Select]

tce-load -wi compiletc perl5 bash ncursesw-dev bc-1.06.94 glibc_apps elfutils-dev squashfs-toolsDoes it run cleanly or does it report errors?

[MTCAT]

Hi Rich,

Thanks for the extra instructions, here's the "make_all.txt" file.

I also tried the big tce-load command, in all cases except for squashfs-tools, I received a message, "xxxxx" package is already installed.

For squashfs-tools, it did complain though, it couldn't find "squashfs-tools.tcz", but I went into the AppBrowser and was able to select "squashfs-tools-4.x" and tried to install that, but got the "is already installed" message back, I guess we just missed the "-4.x" part on the command line.

Thanks,

David

[Rich]

Hi MTCAT
I don't know. Assuming the software and loaded extensions are the same, I can only assume the processor does not
support floating point math.

... For squashfs-tools, it did complain though, it couldn't find "squashfs-tools.tcz", but I went into the AppBrowser and was able to select "squashfs-tools-4.x" and tried to install that, but got the "is already installed" message back, I guess we just missed the "-4.x" part on the command line.

My mistake. I forgot earlier versions included  -4.x  in their names.

[Rich]

Hi MTCAT
Download the attached file and compile it (make sure  compiletc  is loaded). Directions for compiling are included
in the file. Then see if it runs. It should print out:

A good approximation of pi is 355/113=3.141593

[MTCAT]

Thanks Rich, odd thing is, that was the advertising point for the VortexDX (over the VortexSX), that the VortexDX has a Floating-Point-Unit....so , no problem about the squashfs-tools.

Flip-flopping back to the newer VortexDX3, which did briefly work for us (compiled driver and ran self tests just fine, but then seemed to get flakey over time) I did find how to fully access the BIOS on the DX3, I have to hit "F4" in the Security tab of the BIOS to enter "Engineering Mode", now I can access the full BIOS.

Just saw your post on calculating pi, thanks, will give that a try !

Thanks,

David

[MTCAT]

Hi Rich,

That was a great idea re: estimating pi, I compiled and ran the program on the older (super low power) single core 800 MHz VortexDX (the one that gave us all the floating point exceptions when trying to build the 24DSI driver), and it worked !, attached a text file here.

Thanks,

David

[Rich]

Hi MTCAT
I guess it does support floating point math.

[MTCAT]

Hi Rich,

The plot thickens, could we use "gdb" I think it's called to help "debug" the compilation process on the VortexDX ?, to get a better hint as to where the problem might be ?, i..e, the source of the "invalid number ' ' ", or maybe we already did that with the "make_all.txt" file I already sent you a while ago.

Thanks,

David

[MTCAT]

Hi Rich,

Not sure if this helps or not, but I tried a couple things today, I added "-Wl --hash-style=sysv" to the compiler flags, saw this on some other posts and figured, why not try it, but, it didn't do anything positive.

I notice that gcc is generating object files though, even though it generates all these floating point exceptions, so I also installed gdb and then ran it on all the object files, one by one, but in each case, no debugging symbols were found.

Not sure what else to try.....

The first thing I see when running ./make_all is;

driver========================================================================================
make[1]: Entering directory `/usr/local/src/linux-headers-2.6.33.3-tinycore'
Floating point exception
sh: Invalid number ' '
Floating point exception
sh: Invalid number ' '
Floating point exception
sh: Invalid number ' '[/b]
CC [M] /home/tc/24dsi.linux.4.11.91.32.0/24dsi/driver/close.o

I don't think anything is being compiled in the first section under "Entering directory....", not sure what's happening there, yet, we already get these Floating point exceptions, maybe that's a clue ?

All the object files, close.o, etc., are there, in the driver directory, so, they are being compiled......

Thanks,

David

[Rich]

Hi MTCAT
I think the errors may be coming from when the kernel version is being determined. As you may have noticed, those
error messages are showing up in 3's. So we will try to isolate where the error is occurring by changing how often it
occurs, i.e. make the error show up in 2's instead of 3's.

I have 2 things for you to try, one at a time.

Open the file  24dsi/driver/os_makefile.inc.  Find the line that says:

Code: [Select]

ifeq ("${KERNELVER}","2.2")and change it to:

Code: [Select]

ifeq ("${KERNELVER}","7")Run the build again and see if the number of errors was reduced.

Undo the previous change.
Open the file  24dsi/driver/os_main.h.  Find the line that says:

Code: [Select]

#include "os_kernel_2_2.h"and change it to:

Code: [Select]

//#include "os_kernel_2_2.h"Run the build again and see if the number of errors was reduced.

I don't think gdb will help tracking this down.

[MTCAT]

Hi Rich,

I'm having problems posting.

David

[MTCAT]

Hi Rich,

See files attached, I was able to compile the code w/o any exceptions !, I placed echo -e "a", echo -e "b" etc, etc. around all the GSC commands in an effort to see exactly where the script bombs, but now it didn't generate any errors !! ??

I've been excited to post this since last night but haven't been able too, it's been killing me !

Do you think this might be related to what you're suggesting to try ?

Thanks,

David