Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: MTCAT on February 16, 2021, 10:31:52 AM
-
Hello,
After much help from Rich, I was happily able get my ethernet working and install pciutils.tgz and the gcc compiler on TinyCore3 (2.6.33.3).
My next step is to build and install the module for an analog-to-digital converter. The instructions I've received from the mfr are to change directory to;
"usr/src/linux/drivers"
And then unpack the ADC driver tar file in the directory above, which unpacks the contents of the tar file to;
"usr/src/linux/drivers/24dsi_pll"
Then I change directory to "usr/src/linux/drivers/24dsi_pll" and run "./make_all" which then builds and installs the module "24dsi12_pll.ko".
I notice that the version of TinyCore that I have has a usr/src directory, but it's empty.
Do you think it would work for me to simply make the needed directory structure and go ahead an try to build/install the driver ?, or is there something else that would be better ?
Thank you very much.
-
You need to unpack and prepare the Linux kernel source in /usr/src.
-
Hi MTCAT
Here's a link for someone else that was trying to build an out of tree driver:
http://forum.tinycorelinux.net/index.php/topic,24436.msg154978.html#msg154978
Due to the age of the Tinycore version you are using, it won't work as written.
If you want to attempt to make it work, the config and source packages are:
http://tinycorelinux.net/3.x/release/src/kernel/config-2.6.33.3-tinycore
http://tinycorelinux.net/3.x/release/src/kernel/linux-2.6.33.3-patched.tbz2
You would need to get Module.symvers from linux-headers-2.6.33.3-tinycore.tcz under /usr/src/linux/.
... I notice that the version of TinyCore that I have has a usr/src directory, but it's empty. ...
Try installing linux-headers-2.6.33.3-tinycore.tcz. Then:
mkdir /usr/src/linux/drivers
Make sure you have a proper toolchain installed:
tce-load -wil compiletc perl5 bash ncursesw-dev bc-1.06.94 glibc_apps elfutils-dev
Then unpack the ADC driver tar file continue from there.
-
Thanks again Rich, thanks as well Juanito, Rich, would this be the correct workflow so to speak ?
1) Install (run ?) the config http://tinycorelinux.net/3.x/release/src/kernel/config-2.6.33.3-tinycore
2) Install the source package http://tinycorelinux.net/3.x/release/src/kernel/linux-2.6.33.3-patched.tbz2
3) Install linux-headers-2.6.33.3-tinycore.tcz (check to make sure Module.symvers is in usr/src/linux)
4) mkdir /usr/src/linux/drivers
5) run tce-load -wil compiletc perl5 bash ncursesw-dev bc-1.06.94 glibc_apps elfutils-dev
6) Unpack driver and try to run ./make_all
-
Hi MTCAT
I would first try it using steps 3 through 6.
Steps 1 and 2 are only if trying to follow the instructions in the link provided which likely will be far more involved.
-
Hi Rich,
I went through those steps with two exceptions;
1) I had to re-install pciutils.tgz and gcc.
2) I had to omit the "l" in the big "tce-load -wil compilte tc perl5......" command.
But otherwise, everything went okay, except the ADC driver did not get built unfortunately, attached a screenshot here.
Any ideas ?
-
Hi Rich,
Sorry, here's a "real" screenshot using the built in app in TinyCore3, MUCH better.
-
Hi MTCAT
I found your linuxquestions.org thread:
https://www.linuxquestions.org/questions/linux-newbie-8/makefile-confused-about-kernel-version-that%27s-running-failed-module-insertion-4175690004/
I don't think trying to place variables after ./make_all is correct. See if this works any better:
CC_FLAGS="-march=i486 -mtune=i686" KERNELDIR="/lib/modules/`uname -r`/build" ./make_all 2>&1 > build.txt
Those are back ticks around uname -r not apostrophes. They are on the ~ (tilde) key. Hopefully, this will also redirect
output messages into build.txt which you can attach to your next post instead of images.
-
"struct proc_info has no member named get_info" - this error means your module source is not compatible with this kernel version.
-
Hi curaga
Thanks, I saw that error. The source package tests if version <= 2.6.25 so it shouldn't throw that error. Unless, ..........
-
Hi MTCAT
Your error message shows the error occurred in:
24dsi12_pll/driver/proc,c
The source package I found does not have a proc.c file, it has:
24dsi.linux.4.11.91.32.0/driver/os_proc,c
Where did you get that source package from?
The package I found is:
24dsi.linux.4.11.91.32.0.tar.gz
Found here:
http://www.generalstandards.com/downloads/
-
Hi everyone, thank you so much for the help, the source package was bundled in with a little acquisition program I had written up for me many years ago, stored away on a pen drive, the .tar file should be from the mfr though (General Standards), but I suppose I don't know if the acquisition program developer changed anything in the tar file.
General Standards is recommending trying their new 4.11 driver, which I haven't tried to build/install yet.. I was hoping the old driver would work to maintain compatibility with the acquisition program, the new driver for example gets installed in usr/src/linux/drivers/24dsi as opposed to....../24dsi_pll, so at minimum I would assume some path names will need to be changed in the acquisition program before compiling it ?
I was just fearing that using the new driver would only solve one problem (build/install the driver) only to create another problem (not work with the acquisition code).
My previous discussions/attempts on linuxquestions.org were related to trying to get this all to work in Slackware12 (2.6.21), which I've given up on.
Thanks a lot Rich, I'll try your fancy ./make_all command, outputting to build.txt, and see how that goes..I could also send you guys the "old" .tgz driver file as well ?, or I could check for the proc.c
This is all an attempt of mine to lower power consumption, so I'm trying a VortexDX3 CPU, in the case of Slackware, Slackware was confused about what CPU was being used, or so it seemed, Slack12 could build the module, but failed to insert as the module was being built for "686" but my gcc target was "486" I believe, Slack12 was confused about what my CPU was.....I hope that's not the case here and the reason for the failed module building ? But here, like in Linux Mint, the module doesn't even get built, with Slack 12, it did "build", but failed to insert....
Slack12 would not recognize both CPU cores, I had to boot the "huge" version only, non SMP, running on one core. TinyCore3 seems fine, seems to recognize both VortexDX3 cores, but on startup, there is a message flashed, something to the effect, "CPU unknown, using generic init, your system may be unstable", but I've been ignoring it up til this point, maybe at my peril !
I guess I could try the new compiler "switches" first with the "old" driver, and failing that, try to build/install the new driver ?
Thanks for all this amazing help, I would be in a hopeless situation otherwise.
-
Hi Rich,
I tried out your big command,
CC_FLAGS="-march=i486 -mtune=i686" KERNELDIR="/lib/modules/`uname -r`/build" ./make_all 2>&1 > build.txt
But I got an error
sh: can't create build.txt: Permission denied
I tried putting sudo right at the beginning of the command, and also right before the ./make_all, but still got the same error, not sure what I'm doing wrong ?
Thanks
-
Hi MTCAT
First run:
./build_all cleanThis will remove any files leftover from a previous build. Then run the command in the attached file. It will redirect
all messages into a file called build.txt which you cann attach to your next post if required.
-
Hi Rich,
I ran "sudo ./make_all clean" first, and then tried your new command, but I still couldn't write to build.txt, not sure why.
So I tried out your original command, but without the re-direct (if that's the correct term) to build.txt, unfortunately, I think we get the same error behavior as before.
Sorry for the screenshot, but can see attached here.
Thanks.
-
Hi MTCAT
You are still trying to compile the old source package. That package is looking for get_info which was removed in
kernel 2.6.26. You are running 2.6.33. It doesn't have get_info so the old driver won't build on it.
-
Hi MTCAT
If you unpack the source package in your home directory, you won't need to use sudo for everything.
-
Hi Rich,
Oh, okay, sorry I didn't "clue in" to that, thanks for explaining that to me, I'll try building the newest driver (4.11) this afternoon then.
Explains why Slack12 (2.6.21.5) was able to build the driver at least (but still wasn't able to load the module due to CPU confusion I think).
Thanks,
David
-
Hi Rich,
I tried to install the new driver package (24dsi.linux.4.11.91.32.0.tar.gz) and unfortunately the behavior seems worse, immediately started spewing errors.
Attached a screenshot, "/bin/sh: stat: not found", over and over !
Is there perhaps another tinycore "package" that needs to be installed ?
Thanks,
David
-
Hi MTCAT
Install coreutils.tcz.
-
Hi Rich,
Thanks, that did it ! ! !, awesome, thanks so much.
There's now a 24dsi.o (not .ko ??) module that's loaded, when I type "lsmod", whoop there it is, 24dsi !, sure took a long time to compile all the individual c programs though, seems a lot more complicated than the "old" driver, a lot of new functions available I suppose, I'm sure it will give my existing acquisition code fits...
With respect to the old driver, do you think a version of TinyCore with kernel 2.6.26 or older would be worth a try ? Would that be TinyCore2 ?
Or, maybe just grin and bear it and try to move forward with the new driver, I have no idea the horrors that may await trying to get the acquisition code to work with it though...
Thanks,
David
-
Hi MTCAT
... With respect to the old driver, do you think a version of TinyCore with kernel 2.6.26 or older would be worth a try ? ...
If you reread reply #15, that function was removed in 2.26.26. So you would need 2.6.25 or older.
... Would that be TinyCore2 ? ...
TC2 used kernel 2.6.29.
TC1 used kernel 2.6.26.
-
Hi Rich, thanks again so much, I have to make a journal here of all the steps you guys "walked me through" to get this to work ! I can post that too if you think it might help someone else ?
But then, I still need to save all the changes so I don't have to re-install all the packages every boot up, just reading up on the wiki-page on that, boot codes, etc.
Sounds like, when installing packages, I can also use the "SET" option in the Installer to set the location of the package install, i.e., a hard drive, or in my case, a CF card, and then with a boot code, can load all those packages on every boot up, is that the basic idea ?
I guess I'll probably stick with the new driver and move forward with that, one advantage of the new driver is that I should also be able to use a newer version of TinyCore if I want too, I don't know if there would be any advantages though ?, I don't have a problem with TinyCore3, looks like it will do everything I need, so, not sure, I always would like to keep things as simple as possible....
The next (last ?) step will be getting the acquisition code running, hopefully that will be possible.
Thanks again for all your help !
-
Hi Rich,
For my own notes and education, can you tell me why the command below is needed to install the ADC driver ?
tce-load -wi compiletc perl5 bash ncursesw-dev bc-1.06.94 glibc_apps elfutils-dev
I do know that "compiletc" installs gcc of course.
Are Perl5 and Bash also needed just to be able to execute the commands in the ADC "makefile" ? Scripting commands, almost like a batch file dare I say ? My programming experience to date has been very crude (Fortran77/90) in the sense of just compiling single programs at the command line, or compiling a few programs separately, and then just linking the few object files manually, I've never made my own "Makefile" before, so I'm new to Makefiles in general.
What about these guys ?
ncursesw-dev - for reading "wide" characters, Unicode, not even sure what that is.
bc - command line calculator I think ?
glibc_apps - extra C functionality ?
elfutils-dev - to be able to read ELF binary files, whatever that is ?
Thanks so much.
David
-
Hi MTCAT
For my own notes and education, can you tell me why the command below is needed to install the ADC driver ?
tce-load -wi compiletc perl5 bash ncursesw-dev bc-1.06.94 glibc_apps elfutils-dev ...
It's not. It's needed to compile the driver. I don't know that you need all of them. This is the list of extensions required
to compile a kernel, so I used it as a starting point.
-
Hi Rich,
Oh, okay, better to have more packages than less I suppose, play it safe type of thing.
Thanks for letting me know.
Cheers,
David
-
Hi MTCAT
In your thread Persistence Question the topic of creating an extension came up. An extension is really a read only
file system.
So first set up the directory structure:
mkdir -p package/usr/local/lib/modules/2.6.33-tinycore/kernel/drivers/dsi
Next copy the library and driver into that directory structure:
cp 24dsi.linux.4.11.91.32.0/24dsi/lib/lib24dsi_api.so package/usr/local/lib/
cp 24dsi.linux.4.11.91.32.0/24dsi/driver/24dsi.ko package/usr/local/lib/modules/2.6.33-tinycore/kernel/drivers/dsi/
Finally, create the extension:
tce-load -iw squashfs-tools
mksquashfs package 24dsi-2.6.33-tinycore.tcz
Leave the 2.6.33-tinycore in the extension name because it indicates which kernel version it will work with.
-
Hi Rich,
Thanks for the help, I've been reading up on this, making an extension with a binary source, your directions are great !, thank you. I've become generally aware of replicating the directory structure and using squashfs to make the extension, but I wasn't sure, I was going to copy the entire /usr/src/linux/drivers/24dsi/... into the extension ! Would have been a lot bigger than necessary !
And then, lastly, does the new .tcz file needs to be added to onboot.lst ?
I've been meaning to ask you though, this weekend I've noticed in TC3.8.4, quite often (50 % of the time maybe ?), TC3.8.4 doesn't seem to "see" the PCI bridge on the ADC card.
Specifically, typing "lspci -v" doesn't always return me with a "PLX Technology PCI9080..." at the bottom of the list, or anywhere in the list, it's just not there...yet in TC3, although I had to download and install pciutils every time, it always worked, I was always able to "see" the PCI bridge.
Any ideas what might be causing the oddness with "lspci -v" with TC3.8.4 ?? I do also occasionally see an odd error message at the SYSLINUX level of booting up TC3.8.4, something to do with a memory problem as relates to a PCI device, I need to try to capture this on my phone maybe (burst photo's) during boot. I don't see that boot-up error message all that often, however, even when I do, "lspci -v" still may work fine, so not sure if these two things are related or not.
I wasn't sure if maybe uninstalling and re-installing pciutils would be needed , but I wasn't sure how to uninstall an extension either. I hope it's not a hardware issue, the card is quite expensive !
Thanks,
David
-
Hi MTCAT
... And then, lastly, does the new .tcz file needs to be added to onboot.lst ? ...
Yes, copy the extension to your tce/optional directory and add 24dsi-2.6.33-tinycore.tcz to your onboot.lst file.
... something to do with a memory problem as relates to a PCI device, I need to try to capture this on my phone maybe (burst photo's) during boot. ...
Please, no pictures. Does this return the error message you saw:
dmesg | grep -i pci
Or you can look through the kernel messages:
dmesg | less -INavigate with arrow keys and Page Up/Down keys.
Or you can save the messages to a file:
dmesg > dmesg.txt
... I wasn't sure if maybe uninstalling and re-installing pciutils would be needed ...
No, that won't change anything. You could see if updating PCI database helps:
http://repo.tinycorelinux.net/4.x/x86/tcz/pci-utils.tcz.info
You might also want to read this one to make sure you find the correct file or files to back up:
http://repo.tinycorelinux.net/10.x/x86/tcz/pci-utils.tcz.info
-
Thanks Rich, over the next couple of days, I'll try to build the extension, and install it, and if that error message comes up, I'll see if I can isolate it in a text file as you've instructed.
Thanks so much,
David
-
Hi MTCAT
... Or you can look through the kernel messages:
dmesg | less -INavigate with arrow keys and Page Up/Down keys. ...
I left out:
q to quit.
/pattern find pattern.
n find next.
N find previous.
-
Hi Rich,
We're both up before the birds it seems ! My regular work has been in the way lately so I got up extra early to take a whack at building the extension.
I fired up my little Vortex board and did see the PCI memory error message, I attached dmesg.txt here, you can see the error message I see on bootup between lines 214 to 217, the 3.01 identifier or label does refer to my 24DSI card as running lspci -v shows it as 0.3.01, hope it's nothing serious.
But, since running lspci -v was successful anyway (I could see the ADC card), I went ahead and built the extension as per your instructions (except I used 2.6.33.3-tinycore instead of 2.6.33 and also 24dsi instead of dsi in the package path or tree).
So I think that all worked, but, just want to confirm, I ran the mksquashfs command in home/tc (where I added the directory structure package/usr/...)
In home/tc I ran "mksquashfs package 24dsi-2.6.33.3-tinycore.tcz", hopefully that gives the correct directory structure (wasn't sure if I was supposed to be in /home/tc/package when running mksquashfs).
Now that I have my little .tcz file (cool), I need to put it on the pen-drive (/mnt/sdb1/tce/optional) and add it to onboot.lst ?, that seems right ?
Thanks,
David
-
Hi MTCAT
... the 3.01 identifier or label does refer to my 24DSI card as running lspci -v shows it as 0.3.01, hope it's nothing serious. ...
That's 03:01 , punctuation matters. I'l try to take a look at some of those messages later on.
... (except I used 2.6.33.3-tinycore instead of 2.6.33 and also 24dsi instead of dsi in the package path or tree). ...
Good call on the kernel version string, I missed that. The reason I used dsi for the path is 24dsi appeared to be specific
for that board. I felt the more generic name was appropriate. Either way, it's not a deal breaker.
... I ran the mksquashfs command in home/tc (where I added the directory structure package/usr/...) ...
That good. This way it's persistent and you don't need to waste time running a backup or restore for it.
... hopefully that gives the correct directory structure (wasn't sure if I was supposed to be in /home/tc/package when running mksquashfs). ...
You can list (-l) what's inside the .tcz like this:
unsquashfs -l 24dsi-2.6.33.3-tinycore.tczThe top level directory will be called squashfs-root so you will get a result similar to:
squashfs-root
squashfs-root/usr
squashfs-root/usr/local
... put it on the pen-drive (/mnt/sdb1/tce/optional) and add it to onboot.lst ?, that seems right ?
Yes.
-
Hi MTCAT
pci 0000:03:01.0: no compatible bridge window for [mem 0xbebffc00-0xbebffcff]
pci 0000:03:01.0: can't reserve [mem 0xbebffc00-0xbebffcff]
pci 0000:03:01.0: no compatible bridge window for [mem 0xbebff800-0xbebff8ff]
pci 0000:03:01.0: can't reserve [mem 0xbebff800-0xbebff8ff]It looks like the kernel could not assign these addresses to your board.
So it relocates it to a different address range:
pci 0000:03:01.0: BAR 0: assigned [mem 0xfeb00000-0xfeb000ff]
pci 0000:03:01.0: BAR 0: error updating (0xfeb00000 != 0xbeb00000)
pci 0000:03:01.0: BAR 0: set to [mem 0xfeb00000-0xfeb000ff] (PCI address [0xfeb00000-0xfeb000ff]
pci 0000:03:01.0: BAR 2: assigned [mem 0xfeb00100-0xfeb001ff]
pci 0000:03:01.0: BAR 2: error updating (0xfeb00100 != 0xbeb00100)
pci 0000:03:01.0: BAR 2: set to [mem 0xfeb00100-0xfeb001ff] (PCI address [0xfeb00100-0xfeb001ff]
The kernel is correcting this to match the PCI bus:
PCI: CLS mismatch (64 != 16), using 32 bytes
Which was set right before the no compatible bridge window for message above:
PCI: pci_cache_line_size set to 32 bytes
-
Hi Rich,
Thank you so much for your help, I'm glad it sounds like I made the extension the right way, that's pretty neat, thanks for showing me how to do that.
I like having the bare minimum needed to get the ADC running, and I think that's preferred for "production" mode, but, as I'm still kind of troubleshooting, if I wanted to add the entire /usr/src/linux/drivers/24dsi directory contents to the extension, I should be able to do that as well ? Maybe I could make a new extension, call it a different name, and then I can then "pick and choose" which extension to load.
It might be good to still to be able to run the programs in /usr/src/linux/drivers/24dsi/samples, to help with troubleshooting (see below).
Thanks for explaining the PCI memory error messages, I didn't notice the re-allocation of the memory, I "tunnel-visioned" on the error message I guess, glad to hear the kernel was able to work around it.
If it's not one thing, it's another though, it seems I need to slow down the boot-up even further though....sometimes TC3.8.4 is not able to "see" the ADC card at all ("lspci -v" doesn't return a PCI device for the ADC card), and other time's when "lspci -v" does work as expected in TC3.8.4 (this has happened in Lubuntu as well), when running the "./id" sample program, it thinks it's a 6 channel board (24DSI6).
I've been in contact with General Standards, and sent them the results of the "./id" program in this case, and the fellow there noticed all hex values of "F" in some register or something, he said this is due to the card not having enough time to initialize, so sometimes only half the board gets initialized as the OS is booting up so fast. I was very relieved to hear that as I was scared I may have damaged the board with ESD or something (even though I have grounded floor and bench mats and wrist strap).
Would simply changing the "waitsub" time be enough to help with that, I'm not sure, I thought that was just for the BIOS to make sure to catch the pen drive, and increasing the waitusb time might be like putting the delay in the wrong place so to speak ?
There is a BIOS setting I was going to change too, specifically, I was going to try disabling "QuickBoot" which will make the BIOS do more checks and therefore take longer to boot up, but I guess I'm not sure at what stage in the boot process that the 24DSI needs more time to initialize.
This is actually an issue with Lubuntu as well, the couple of times I've tried it out Lubuntu after installing the driver, "lspci -v" always works out (see's the PCI bridge associated with the ADC card), but then the sample programs fail as it also see's the board as a 24DSI6 (a 6 channel)...
Somehow, the 24DSI12 needs a bit more time to fully initialize......
Thanks,
David
-
Hi MTCAT
... It might be good to still to be able to run the programs in /usr/src/linux/drivers/24dsi/samples, to help with troubleshooting (see below). ...
So you just need the programs, not the whole source directory.
Referring to reply #26, add this where you set up the directory structure:
mkdir -p package/usr/local/bin
Where you copy the files add this:
P="24dsi.linux.4.11.91.32.0/24dsi/samples"; for F in `busybox ls $P`; do cp $P/$F/$F package/usr/local/bin/; doneThis will copy just the executable files which happen to match their directory names, i.e samples/id/id, samples/regs/regs, etc.
This way you will be able to execute those commands without specifying the path.
Those are back ticks ` by the busybox command string, not single quotes '.
-
Hi Rich,
Thanks, that's really cool (the command line to copy exe's with the same name as the directory).
I'm sorry to be all over the place, I'm sure that after building and "installing" the extension initially (4 A.M. yesterday :) ), I was able to power-down, and then power-up, and then run "lsmod" and who-hoo !, I saw "24dsi" in the list, awesome.
But now, I don't see it ?
I checked onboot.lst and "24dsi-2.6.33.3-tinycore.tcz" is still in there, and the .tcz file itself is in the right place /mnt/sdb1/tce/optional, so..., kind of like whack a mole here.
Initially today, I wasn't able to see the PCI bridge in TC3 or TC3.8.4, then I reverted to Lubuntu, could see it (some kind of a reset ?) and now when I fire up TC3.8.4 I can see the PCI bridge as well, but now the extension (module) didn't get loaded as I don't see it in the list output of "lsmod".
I'm sorry to be such a pain.
-
Hi MTCAT
If the board or driver don't show up, try this:
echo 1 | sudo tee /sys/bus/pci/devices/0000\:03\:01.0/removeecho 1 | sudo tee /sys/bus/pci/rescan
Did it help?
Also, please give me another dmesg.txt after running those commands:
dmesg > dmesg.txt
-
Hi Rich,
Thanks for the help, I didn't know how to re-scan for the PCI devices, that's pretty cool.
Last night I was playing around with BIOS IRQ settings, some of the IRQ's were not set consistent with what's in the manual, I need to get in touch with WinSystems about that, I also had some "reserved" memory enabled (64 k) under the PCI BIOS menu, which wasn't supposed to be turned on (this was my fault, from me poking around in there a couple months ago, that I forgot I did), and I also tried turning on PCI SLot Number as "1" instead of "AutoDetect", but I'm not sure if anything I did really helped, having a different set of IRQ's available and reserved did change things, the ADC board (and a lot of other things) used to show up as IRQ11, now it's IRQ10 I think, but there are a lot of other devices using IRQ10 as well...I guess PCI devices can share interrupts as each device uses a different voltage on the interrupt line I guess.
Turning off "QuickBoot" didn't help though, but now I do get to see the memory check and a quick listing of the PCI devices on boot up, I can now tell even at that point if the ADC PCI Bridge was detected or not, sometimes an extra line in the PCI devices is there, and sometimes not.
I may change the "Slot" detection thing back to Auto, reading some more, it seems the 03:01.00 designation refers to the ADC as device number 3 ? (Slot 3 ?). I only have one external PCI device though, the ADC card, with the PC104 bus, there's a little switch on it to denote it's position in the stack, mine is set to "1" right now. I'll ask General Standards, maybe it should actually be set to "zero", it's supposed to account for delay of clock signals depending how far away the PCI board is installed from the SBC.
I'll change the BIOS IRQ settings back to what they were before (and also contact WinSystems as to why they set the IRQ's this way), and experiment some more, and when I get a failure to detect the ADC card, I'll try your pci scan trick and send you the result.
Thanks so much,
David
-
Hi Rich,
I reverted back to the original BIOS setup, re-booted, and the ADC bridge was not detected, so I tried out your pci commands.
The first one, to remove, was returned with "no such file or directory"/
The second command, to rescan, was returned with " tee /sys/bus/pci/rescan: Invalid argument"
Maybe I did something wrong ?
Thanks,
David
-
Hi MTCAT
After echo 1 did you use the pipe symbol that looks like this | ? It's located on the \ key.
-
Hi Rich,
Sorry, I typed "l" as in Larry instead of the number one in the commands !, so, when using the number 1 there, the "re-scan" worked !, it showed up now after re-scan as IRQ1 ! I guess the "remove" command never worked for the same reason, but then it didn't need too as it wasn't there anyway ?
Here's the dmesg.txt (renamed dmesg1.txt).
There's also a "slot selection" switch on the card itself, I'm not sure if it should maybe set to "0" since it is right next to the CPU ? Right now it's set to "1", which is is how it was in my old setup, but in that case, the ADC card was one card farther away from the CPU, from what I've read, the selection also impacts what interrupt gets used though....
Thanks,
David
-
Hi Rich,
Cautiously optimistic, I think the flakey problem with the PCI bridge may have been due to "ACPI" being enabled in BIOS !
I disabled it and I'm now 3/3 in booting up TC3.8.4 (no BAR errors and successful detection of card), although, even though it's disabled in BIOS, Lubuntu16.04 is still using ACPI somehow as I can see in dmesg output in Lubuntu ??, kind of weird, so Lubuntu still gets these BAR errors, but not TC3.8.4 (where I can see in dmesg, that ACPI is not being used).
Was reading up on BAR (Base Address Register) error messages and "pci=nocrs" boot options and stuff, and kind of saw how this relates to ACPI, I disabled ACPI in BIOS and things seem better in TC3.8.4, no more error messages on boot up (BAR errors), seems better now.
So, fingers crossed, I seem to be reliably seeing the ADC bridge card now w/o having to re-scan (interesting though that the rescan wasn't 100 percent successful before, before I turned off ACPI - now that it's turned off, I haven't had to rescan).
So far so good, I don't think the IRQ's had a major role, just shuffled the IRQ numbers around, and the switch selector on the board just seems to change the device number, i.e., in position 1,
I get 03:00.01 and with the switch in position 0, 03:00.0
So hopefully that was it, just had to turn ACPI off, WinSystem has yet to reply though to my e-mail from this morning so I'm using the default IRQ settings in the manual, which strangely was not how the board was configured when I received it.
Now I can hopefully get back to building the extension for the ADC driver and permanently installing so that's it's always there and ready to go. For some reason, the extension only worked on the first boot-up and since then, I haven't seen my "24dsi" in the "lsmod" list. I'm going to try re-doing the extension, including those sample executables, and hopefully it will stick around now.
Thanks,
David
-
Hi MTCAT
This command will load the driver if It's not already loaded:
lsmod | grep -q 24dsi || modprobe 24dsi
You can add it to your /opt/bootlocal.sh file. Bootlocal runs as root so you don't need sudo in front of modprobe.
... I disabled it and I'm now 3/3 in booting up TC3.8.4 (no BAR errors and successful detection of card), ...
Sounds promising.
... although, even though it's disabled in BIOS, Lubuntu16.04 is still using ACPI somehow as I can see in dmesg output in Lubuntu ??, ...
It's possible Lubuntu is passing an acpi boot code to the kernel. This command will show what's passed to the kernel
in Tinycore:
dmesg | grep -i "Kernel command"It should work for Lubuntu too. If not, then this will:
cat /proc/cmdline
It may also be due to differences in the Lubuntu kernel config file. For instance, the kernel config for TC 3.8.4 lists this:
# CONFIG_ACPI_PCI_SLOT is not setFound here:
http://tinycorelinux.net/3.x/release/src/kernel/config-2.6.33.3-tinycore
If Lubuntu has that option set, it might account for what you are seeing.
-
Hi Rich,
Thanks a lot, I'll try re-doing the driver build and extension creation with the executables included as well, so far so good, everything continues to be happy with ACPI turned off !
In terms of the extension, does the loading of the extension (as indictated by onboot.lst) not actually load the driver though ? Maybe just makes it available to be loaded ?
No big deal, thanks to you, I know I can just add it to /opt/bootlocal.sh, but in my newbie mind, I thought just loading the extension would be good enough !
Thanks,
David
-
Hi MTCAT
... does the loading of the extension (as indictated by onboot.lst) not actually load the driver though ? Maybe just makes it available to be loaded ? ...
When an extension contains a driver, tce-load also runs depmod which updates the list of available drivers as well as their
location.
Drivers for detected hardware get looked up in /lib/modules/2.6.33.3/modules.alias. If you run this after your extension
gets loaded:
grep 24dsi /lib/modules/2.6.33.3/modules.aliasIt should list your devices bus, vender ID, device ID, and some other gobbledygook.
By the time your extension gets loaded it may be too late to auto load your driver. I think udev is also involved in
loading modules. If your module is not loaded, see if running this loads it:
sudo udevadm trigger
-
Hi Rich,
The only command I found that worked was "sudo modprobe 24dsi", that worked to load the driver, typing "lsmod", I now see a "24dsi" at the top of the list, awesome.
I guess "worst case" would be to add "sudo modprobe 24dsi" into bootlocal.sh, and load the driver that way ?
Sadly, on my 6'th boot up now, I got that stupid BAR error thing again, dang-it, thought I had that cleared away...at least I've always been able to see the PCI bridge since I turned off ACPI.
Thanks,
David
-
Hi Rich,
Further to the last post, I'm not sure if ACPI is actually turned off, even though it's disabled in BIOS, which might explain the error message I just saw, like in Lubuntu.
If I grep dmesg for "ACPI", there's still a ton ACPI stuff going on in there, and looks like the kernel is still letting ACPI take over the IRQ routing and memory allocation, which I was assuming was the source of the BAR errors...
Not completely sure I should, but, if I wanted to try using the boot option "pci=nocrs" (or is it "pci=no_crs" ?) where would I need to put that, in extlinux.conf ?
Thanks,
David
-
Hi MTCAT
... if I wanted to try using the boot option "pci=nocrs" (or is it "pci=no_crs" ?) where would I need to put that, in extlinux.conf ? ...
Yes. Add it to the Append line:
APPEND initrd=/boot/tinycore.gz quiet waitusb=10:UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" tce=UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" home=UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" opt=UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f"
There are other options available for pci= shown here:
https://mjmwired.net/kernel/Documentation/kernel-parameters.txt#2968
I suggest try pci=noacpi , shown here:
https://mjmwired.net/kernel/Documentation/kernel-parameters.txt#3051
You can also see if acpi=off helps:
https://mjmwired.net/kernel/Documentation/kernel-parameters.txt#200
Getting an error to repeat is key to squashing it. You might want to try turning acpi back on to to see if the kernel overrides it.
-
Hi Rich,
Thanks, maybe I'll try the pci=noacpi, and then possibly acpi=off if need be, and now that I think about it, I'm pretty sure my "old" setup (650 MHz Celeron) uses acpi=off in an append statement in lilo.conf.
Reading the General Standards manual some more, to start up the ADC, I'm supposed to actually run a program called "start" located in /usr/src/linux/drivers/24dsi/driver, and that loads the driver and makes the devices nodes for the 24DSI12 (whatever those are), so I can either do that manually, by typing "./start" in the directory above, or hopefully can just add a line to bootlocal.sh ?
/usr/src/linux/drivers/24dsi/driver/start
The first time building the driver, ./start is run for you, but next time you power up, you need to run ./start to get the 24DSI12 running.
So hopefully if the .tcz extension gets loaded with onboot.lst, then the "./start" command should do the rest...but now the start program will need to be added to the extension as well, does that sound right to you ?
Thanks,
David
-
Hi MTCAT
..but now the start program will need to be added to the extension as well, does that sound right to you ?
You can add it to the package/usr/local/bin directory. I highly recommend renaming it to something like start_24dsi.
Start is too generic a name and runs the risk of conflicting with an identically named program.
Case in point. We had one forum member name a script test. Somehow, when he tried to run it. the test command
would run instead.
-
Thanks Rich, I'll add the start program, but renamed start_24dsi, good idea.
Can you check out my attached extlinux.conf file ? The newly added boot options don't seem to be doing anything, am I doing something wrong there ? I tried both pci=noacpi and lastly, acpi=off, as attached here.
Even with acpi=off, dmesg is still full of ACPI stuff going on...
Thanks,
David
-
Hi MTCAT
Wow, you really botched this one:
APPEND initrd=/boot/tinycore.gz quiet waitusb=10 acpi=offi:UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" .....
Try it like this:
APPEND initrd=/boot/tinycore.gz quiet acpi=off waitusb=10:UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" ....
This is one command:
waitusb=10:UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f"It is used by Tinycore, not the kernel. It tells Tinycore to wait until the device with that UUID shows up or give up after
10 seconds. You placed the boot code right in the middle of that command, plus you misspelled it.
If you pass a boot code the kernel does not understand, it ignores it. This allows you to pass non kernel codes to scripts
or applications. That's how codes get passed to the TC startup script. Take a look at /etc/init.d/tc-config where it says:
# Here we check all the boot parameters using the fastest way known to men, case & loop
That's where TC specific boot codes get parsed.
... Getting an error to repeat is key to squashing it. You might want to try turning acpi back on to to see if the kernel overrides it.
I forget to mention, I was referring to the BIOS setting.
-
Hi Rich,
Oh boy, sorry about that, whoops, thanks for correcting me, I'll give that a try....
Thanks for the explanation re: the waitusb=10:UUID="...." being one command actually.
I did infer correctly that you were talking about the BIOS setting, that's about all I got right on that one I guess !
Thanks,
David
-
Hi Rich,
Unfortunately nothing worked, I tried "acpi=off" and "pci=noacpi" and "acpi=noirq" and they all resulted in TC3.8.4 having a "stressed" time booting up, took much longer than usual, and when it did boot up, my mouse was dead, and I think keyboard too.
I had to boot up my YUMI version to edit extlinux.conf to get back to normal.
Hmm, maybe I'm barking up the wrong tree here, seems like turning off the ACPI in BIOS did help, I seem to be seeing the card more consistently, but, still get those BAR errors sometimes...
For the moment, maybe I'll continue on with the extension building (incorporating the new exe's), not sure what else to try with these BAR errors...
Thanks,
David
-
Hi Rich,
If I re-installed the ADC card in my old 650 MHz Celeron stack (Slackware 3.2.2), fingers crossed that it still works, what kind of clues could I look for in terms of the setup that might help us with the new VortexDX3 board ?
I'm thinking to look in lilo.conf, also the "run-command" file in /etc (can't remember the name now), and maybe do a dmesg > dmesg.txt ? Could do lspci -v > lspci.txt as well ? lsmod > lsmod.txt ?
Anything else that you can think of ? Maybe look at the BIOS settings too ?, although I do recall that the old Celeron BIOS is quite different.
Thanks,
David
-
Hi Rich,
I installed the 24DSI12 in my old stack and thankfully it seems okay, seems to work as usual, logger program works, self-tests work, thank goodness.
I've attached dmesg.txt obtained from Slack3.2.2-rtd, lspci.txt, lsmod.txt, lilo.conf and will attach rc.local to another post.
Some interesting things I noticed,
1) How the 24dsi12 shows up in the output of "lspci -v" , looking in the BIOS, there's a setting "Resources controlled by Auto (ESCD)" which is enabled, so the manual entries of "IRQ Resources" and "DMA Resources" are greyed out in the BIOS, can't access them, so that's different. But there's also something called APIC (Advanced Programmable Interrupt Controller), which is Enabled, which apparently expands the number of interrupts from 15 to 24. So it seems that (ESCD) is taking care of assigning the interrupts and memory spaces of the different PCI devices ? It's working on the old Celeron anyway..
2) Not really sure how the 24dsi.ko is being loaded, but there is the ./start command in rc.local.
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.
These are just my crude observations, I'm sure you will see a lot more.
Thanks,
David
-
Hi Rich,
Here's rc.local from the 650 MHz Celeron, running Slack3.2.2-rtd, also attached rc.modules. there's a bunch of other ones too, for ntp, gpsd, and pps.
Thanks,
David
-
Hi Rich,
I hope I'm not overloading you now, I'm kind of running around trying all sorts of things.
As it turns out, I just received my even lower power (and older and slower) VortexDX 800 MHz (single core) SBC the other day (VDX-6354RD-512PX, from EMAC), so I figured, might as well give it a try. This guy is an amazing 4W apparently (the dual core VortexDX3 is about 8W), hopefully the single core DX has enough "horsepower" to run the logger, guess we'll see...
Anyway, with the 24DSI12 installed with the 800 MHz VortexDX, TC3.8.4 booted right up with no complaints, I've attached the output of "lspci -v" here, looks good I think, the 24DSI12 shows up as 00:02.0 now.
I've also attached the output of dmesg.
But, when I tried to build the driver I got an error "Floating point exception", attached screen-shot here (sorry), is there a compiler option maybe I need to invoke ?
You can also see the output of cat /proc/cpuinfo in the screenshot too.
I just thought, the VortexDX3 is an i686 type (when gcc was built, it was built for the DX3) and I think the VortexDX is considered a 486 type, maybe I just need to re-install gcc with tce-load -wi compiletc and try again ?
Thanks,
David
-
Hi MTCAT
That's a lot to process.
... But, when I tried to build the driver I got an error "Floating point exception", attached screen-shot here (sorry), is there a compiler option maybe I need to invoke ? ...
The real error is:
sh: invalid number ' 'That looks like the error is coming from a script. See the empty space between the 2 single quotes? That's the invalid number.
You can try turning execution tracing on in the make_all script to see if it sheds some light on where the "invalid number"
is coming from. Change the very first line in make_all
From this:
#!/bin/shTo this:
#!/bin/sh -x
... I just thought, the VortexDX3 is an i686 type (when gcc was built, it was built for the DX3) and I think the VortexDX is considered a 486 type, maybe I just need to re-install gcc with tce-load -wi compiletc and try again ?
Some (all??) of the Vortex chips that claim i686 compatibility don't support the cmov instruction which the compiler uses.
I see you unpacked the driver source package in /usr/local/src/linux-headers-2.6.33.3-tinycore/drivers/24dsi again.
If you unpack it in your /home/tc directory:
1. It will be persistent.
2. You won't need to use sudo to run it.
3. You will be able to redirect results into files without running into permission issues.
4. I won't have to deal with posted images.
Download the file attached here to your /home/tc/24dsi.linux.4.11.91.32.0/24dsi/ directory.
Make the file executable:
chmod 755 BuildADC.sh
[EDIT]: Fixed error in attachment. 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:
[ 0.155301] pnp: PnP ACPI: disabled
Yet in the dmesg1.txt file you posted here I see:
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNPTry using the boot code:
pnpacpi=off
-
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
-
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
-
Hi MTCAT
Modify the make_all file so the first 3 lines look like this:
#!/bin/sh -xexec 1>make_all.txtexec 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:
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?
-
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
-
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.
-
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
-
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
-
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
-
Hi MTCAT
I guess it does support floating point math.
-
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
-
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
-
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:
ifeq ("${KERNELVER}","2.2")and change it to:
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:
#include "os_kernel_2_2.h"and change it to:
//#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.
-
Hi Rich,
I'm having problems posting.
David
-
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
-
Hi MTCAT
Nice try, but you broke the script with all the echo commands. For example:
if CONDITION
# echo -e "e"
then
Do this when CONDITION is true.
else
Do this when CONDITION is false.
fi
By placing a command between the if and then clauses, you altered the outcome of the test. Since the echo command
always returns an error code of 0 (true), the then clause will always execute and the else clause will never execute.
I don't think the issue is in the make_all script, but further down the chain. That's why I suggested trying those changes
in the driver directory.
-
Hi Rich,
Oh, okay, I need to read up more on shell scripting I guess, thanks for correcting me !
I'll try your suggestions this afternoon.
Thanks,
David
-
Hi Rich,
I followed your instructions in reply 72 but unfortunately I'm still seeing the same errors, still in groups of 3, with either one of those modifications implemented (but not both at the same time).
I forgot to say, my little messed up make_all test did show (to me anyway) that this VortexDX can compile the source code okay, how bad would it be to just compile all the programs manually and skip the GS script completely ?...
My programming experience has been very crude I guess, mainly in Windows as well, g77 "program_name.f" -o "program_name.exe", as you can tell, I've never had to write a program (a script) to compile a program !
Thanks,
David
-
Hi Rich,
I also tried to comment out ALL the other kernel include statements, other than 2.6, in os_main.h, and this made things worse actually, with "Floating Point Exception" scrolling by endlessly after typing ./make_all.
It is different though, no Invalid number ' ' echoed to screen in this case.
Not sure if that helps or not.
David
-
Hi MTCAT
I followed your instructions in reply 72 but unfortunately I'm still seeing the same errors, still in groups of 3, with either one of those modifications implemented (but not both at the same time). ...
So are you saying with both changes the errors came in 2's instead of 3's?
-
Hi Rich,
One other thing I've noticed, in the past, on the first unpacking of the driver archive, and on the first ./make_all execution, the first thing that gets echoed back to screen is something about "analyzing dependencies", but, this is only done the first time running ./make_all after unpacking the driver tar file, on all subsequent executions of ./make_all, the build script skips this step because I think it does a check, and doesn't need to do it because it's already been done.
However, on the VortexDX, I've yet to see the "analyzing dependencies" part of the build script, despite doing "fresh" installs almost every time.
I've also noticed a file in 24dsi/driver directory called makefile.dep, but it's empty, 0 bytes....
Thanks,
David
-
Hi Rich,
Sorry, just saw your reply #79, no, unfortunately, I saw the same errors as before, in groups of 3's still, in either case.
Except, when I commented out ALL the #include "os_kernel.... statements EXCEPT for the 2.6 one, it was just a continuous stream of "Floating Point Exception" and in this case, there was no sh: Invalid number ' ' errors, just the "Floating Point Exception" error, over and over.
Thanks,
David
-
Hi MTCAT
I just realized there is an error in the BuildADC.sh script I attached in reply #59.
The line that says:
./build_all cleanShould have said:
./make_all cleanI don't know if it will fix anything, but the clean function should be run between builds.
You can fix it locally or download the corrected copy in reply #59.
-
Hi Rich,
Thanks, I noticed that before and fixed it already.
Apologies for the confusion, I can't replicate/confirm my statement in the last paragraph
"Except, when I commented out ALL the #include "os_kernel.... statements EXCEPT for the 2.6 one, it was just a continuous stream of "Floating Point Exception" and in this case, there was no sh: Invalid number ' ' errors, just the "Floating Point Exception" error, over and over"
I still do get all the errors in 3's though, I don't know what I did to get just the Floating Point Exceptions by themselves, sorry..
David
-
Hi MTCAT
It just occurred to me, you have a DX3 board you can use to build and and package the driver, library, utilities, etc.
It might make more sense to do that and copy it to the DX board rather than fighting with this. Copy the BuildADC.sh
script to the DX3 board so it builds strict 486 compatible code.
I can think of only 2 reasons why this error is occurring:
1. The build environment installed on the DX card is different from what's installed on the DX3 card.
2. The CPU on the DX card has some incompatibility.
-
Hi Rich,
Thanks, I will try that, one last question though re: the DX, the VortexDX will compile the source codes okay, could we just compile and then link the individual object files ourselves to do a "DIY" build of the driver on the DX ? Easier said than done maybe, it seems very complicated, but I wonder if most of that is just catering to all the possible kernels...
I also wanted to play around in the BIOS a bit more on the DX3 to see if I can get rid of the ACPI error, the BAR errors, and increase PCI Latency timing, hoping it will to detect the card more faithfully (GSC recommends doing this).
I do also have one last option in terms of a lower power SBC, it's an AMD Geode LX800, it would be somewhere between the DX and the DX3 in terms of power consumption, but, would hopefully be a fall-back board with a "normal" CPU. Only problem, they are end-of-life and the only ones left also have only 256 MByte of RAM (Digikey), the logger program itself uses a 128 MByte buffer !
But, hopefully we can get something stable working on at least one of the Vortex boards.
Thanks, I'll try what you suggest, run BuildADC.sh on the DX3, make a new extension I guess, and then try loading that new extension when booting the DX ?
Thanks,
David
-
Hi MTCAT
... Thanks, I'll try what you suggest, run BuildADC.sh on the DX3, make a new extension I guess, and then try loading that new extension when booting the DX ?
Yes. The instructions for creating the extension were in reply #26 and #35. I believe I also mentioned somewhere you
could copy the start script to package/usr/local/bin. Just rename it to something less generic like 24dsiStart or start24dsi.
-
Hi Rich,
I don't know how I can ever repay you, I owe you big time for all your help, I hope I can pay it back somehow.
I'm so excited, with your help (aka spoon feeding !), I was able to build the driver for both 486 (VortexDX) and 686 (VortexDX3) architecture's.
I then made two new extensions,
1) 24dsi-2.6.33.3-tinycore-486.tcz
2) 24dsi-2.6.33.3-tinycore-686.tcz
Only "catch", in both cases (486 and 686 builds) there were two permission errors, one related to linking lib24dsi_api.so and another for inserting 24dsi.ko.
I built the drivers in home/tc as regular user, I hope I don't have to re-do both builds as root ?
After I did the 686 build (for the DX3), I was able to load the driver on the DX3, but I had to be root, i.e., had to type sudo ./start (I copied start to package/usr/local/bin/start24dsi).
But, after that, I was able to play around with the board in full !
Was awesome, everything worked, I did the throughput test and the DX3 was able to chug through 54,525,952 bytes in 5.684917 seconds, or 2,397,834 samples/second !, max throughput of the ADC is 200 kHz on 12 channels, or 2,400,000 samples/sec, so the DX3 is pretty much keeping up with the ADC "as is", this is very exciting ! !
I'm very embarrassed (and sorry) that I think the previous week or more of thrashing with the DX3 was simply due to me not having the 24DSI12 not fully inserted into the PCI bus connector, I hope anyway...when I first threw it together today I wasn't seeing the board at all, then I took a breath, slowed down, and re-assembled it with some standoffs and tightened it down a bit, and everything went perfectly. The connectors on the DX3 are a bit annoying in that they partially bind with the 24DSI12 analog input connector, if only hand tight like I had before, I think this was the problem. The DX is much better in that regard, connectors and layout are better designed I would say, and of course the DX hasn't given me any problems in that way, so, stupid mechanical error is all I think (with the DX3). I need to put bus extender connectors on the 24DSI12 if I end up using the DX3 as the preferred choice.
So, I've got the tcz's in place in /mnt/sdb1/tce/optional and now I can load whichever tcz file I need ! Now I can hopefully see if I can get the driver to load and do some tests on the DX !
Although, I technically have yet to load and start the driver successfully with the .tcz file, so need to do that on the DX3 as well.
Thanks so much, I think it will be a great weekend now !, some hope finally !
David
-
Hi MTCAT
... After I did the 686 build (for the DX3), I was able to load the driver on the DX3, but I had to be root, i.e., had to type sudo ./start (I copied start to package/usr/local/bin/start24dsi). ...
That's normal. Loading kernel modules (drivers) is a privileged operation requiring root (sudo) access.
I then made two new extensions,
1) 24dsi-2.6.33.3-tinycore-486.tcz
2) 24dsi-2.6.33.3-tinycore-686.tcz
As a point of reference, with very few exceptions, everything for Tinycore is compiled to be 486 compatible.
... Was awesome, everything worked, I did the throughput test and the DX3 was able to chug through 54,525,952 bytes in 5.684917 seconds, or 2,397,834 samples/second !, max throughput of the ADC is 200 kHz on 12 channels, or 2,400,000 samples/sec, so the DX3 is pretty much keeping up with the ADC "as is", this is very exciting ! ! ...
It would be interesting to load the 24dsi-2.6.33.3-tinycore-486.tcz extension on the DX3 and run the throughput test
again. You may find compiling for 686 isn't buying you anything.
-
Hi Rich,
Still playing around with the DX3, and will need the next few days it seems to get caught up on my TinyCore journal ! I'm trying to keep track of all the things you helped me do to get to this point.
By the way, for some reason, Lubuntu 16.04 (4.4.6) doesn't do near as well in the data transfer test, it fails to do "block-mode" DMA and therefore can't do more than ~ 430,000 samples second aggregate, on the other hand, TC3.8.4 was able to do the full 2,400,000 samples/sec pretty much (with block mode DMA), go TinyCore !
But, I'm still kind of confused about the extension for the 24dsi, do I really need it since I've built both 486 and 686 packages in /home/tc (which is already persistent) ?
Just wondering, to automatically load the 24dsi driver, I'm thinking I could add the following to bootlocal.sh ?
For the 686 driver (for the DX3),
sudo /home/tc/24dsi.linux.4.11.91.32.0/24dsi/driver/start
OR
sudo /home/tc/package/usr/local/bin/start24dsi
And for the 486 driver, in bootlocal.sh I would have,
sudo /home/tc/package486/usr/local/bin/start24dsi
However, for the extension that's being loaded, either the 486 or 686 package, as specified in onboot.lst, where are the files associated with that package being placed ?
Thanks,
David
-
Hi MTCAT
... However, for the extension that's being loaded, either the 486 or 686 package, as specified in onboot.lst, where are the files associated with that package being placed ?
Extensions are compressed read-only file systems (squashfs). They get mounted under /tmp/tcloop but the extension
itself lives in the tce directory of your disk drive. Once installed, you can look in /tmp/tcloop/24dsi-2.6.33.3-tinycore-686
and you will find it contains usr/local/lib/lib24dsi_api.so which is linked into the main file system as /usr/local/lib/lib24dsi_api.so.
Note the leading slash in that second path. If you execute this:
ls -l /usr/local/lib/lib24dsi_api.soit's going to indicate that it is a link that points back to /tmp/tcloop/24dsi-2.6.33.3-tinycore-686/usr/local/lib/lib24dsi_api.so.
The rest of the files in the extension get linked into their respective locations in the main file system.
... Just wondering, to automatically load the 24dsi driver, I'm thinking I could add the following to bootlocal.sh ?
For the 686 driver (for the DX3),
sudo /home/tc/24dsi.linux.4.11.91.32.0/24dsi/driver/start ...
That's just the startup script for loading the driver and creating device nodes in /dev.
You still need to place the driver in the correct location and run depmod to update the driver database for the OS.
You still need to place the library in the correct location and run ldconfig to update the library cache for the OS.
You still need to place the utility programs where the OS can find them so you don't have to keep typing a path.
With the extension you create the correct locations for the various libs, drivers, programs, etc.
tce-load handles running depmod and ldconfig.
If you are booting, it runs them after it's loaded everything in onboot.lst to save time.
The alternative is copying the files to /us/local/bin, /usr/local/lib/, etc. and running depmod and ldconfig yourself.
/usr/ is located in RAM. As a result, those files will occupy their size in RAM. As an extension, they only get linked in
and occupy around 30 to 60 bytes of RAM.
-
Hi Rich,
Thanks for the explanation of how the extensions get loaded, having tce-load take care of all the "nitty-gritty" sounds great.
So, in terms of the path to the startup script, to be put in bootlocal.sh (I think ?), sounds like it would be
sudo usr/local/bin/start24dsi
Would that be right ?
Thanks,
David
-
Hi MTCAT
Close. It should be:
/usr/local/bin/start24dsiThe sudo doesn't hurt anything, but it's not required because bootlocal.sh runs as root.
The leading slash is required because that tells the OS to start searching from the root of the directory structure.
-
Hi Rich,
Awesome, thanks a lot, I'll try that out soon, I'm still writing up a journal of all the things you walked me through, it's turning into quite the handbook, will be an excellent reference for me though.
I want to try out the 486 driver on the DX too, will be interesting to see if that works or not !
Will let you know how that goes, possibly tomorrow or Monday for sure !
Thanks,
David
-
Hi Rich,
I added the line below to my bootlocal.sh but unfortunately it didn't seem to do anything useful.
/usr/local/bin/start24dsi
I looked in dmesg for any hints and didn't see anything in there related to the new line in bootlocal.sh, but, when I type out the command myself, I get the following output;
Driver loading: 24dsi........
---->ERROR<----: module file does not exist: /usr/local/bin/24dsi.ko
I'm not sure why,
1) There's no evidence of the command in bootlocal.sh even being attempted.
2) I don't know why I didn't put the 24dsi.ko in /usr/local/bin as well ? When we made the package, we put 24dsi.ko in /home/tc/package/usr/local/lib/modules/2.6.33.3-tinycore/kernel/drivers/24dsi.
Should I leave (2) "as-is" and just add 24dsi.ko to /usr/local/bin as well ?
Thanks,
David
-
Hi MTCAT
I'll take a look at the start script later tonight. No, 24dsi.ko does not belong in /usr/local/bin.
-
Hi MTCAT
Open your start24dsi script. Replace the insmod command with modprobe. Repack your extension and copy it
to your tce/optional directory. Reboot and see if it works now.
-
Hi Rich,
Unfortunately that didn't help, even after replacing "insmod" with "modprobe" in start24dsi, I still don't see a "24dsi" when typing "lsmod" after booting up, and there's no evidence of the driver even trying to be loaded in dmesg either.
Shouldn't we see the same error that I get below, when I try to do it manually, in dmesg as well ?
Driver loading: 24dsi........
---->ERROR<----: module file does not exist: /usr/local/bin/24dsi.ko
Thanks,
David
-
Hi MTCAT
... Shouldn't we see the same error that I get below, when I try to do it manually, in dmesg as well ?
Driver loading: 24dsi........
---->ERROR<----: module file does not exist: /usr/local/bin/24dsi.ko
No. The reason you got that error is because insmod requires you to provide a full path and complete file name.
Because depmod gets run when when the extensions is loaded, modprobe knows where to find the driver. It's also
smart enough to accept modprobe 24dsi.ko or even just modprobe 24dsi.
What happens if you run:
sudo start24dsi
And what does this return:
which start24dsi
-
Hi Rich,
Oh, okay, thanks for the explanation re: "insmod".
When I typed,
sudo start24dsi
I still got the same error message,
Driver loading: 24dsi........
---->ERROR<----: module file does not exist: /usr/local/bin/24dsi.ko
When I typed,
which start24dsi
I was returned the following path,
/usr/local/bin/start24dsi
Thanks,
David
-
Hi MTCAT
If you run this:
grep insmod /usr/local/bin/start24dsiDoes the result include insmod ?
-
Hi Rich,
Yes it does, I get,
insmod ${module_file}
Sigh, in my thrashing away last night I forgot I commented out the modprobe statement (after it didn't work either) and then changed it back to insmod in start24dsi, I then "re-squashed" the package, and put it back in place in /mnt/sdb1/tce/optional, to return to "defaults" so to speak, sorry about that....
Should I change it back to modprobe, "re-squash" the package, put it back in place, re-boot and re-try your "sudo start24dsi" and "which start24dsi", and the "grep insmod /usr/local/bin/start24dsi" commands ?
Sorry for the mixup.
David
-
Hi MTCAT
... Should I change it back to modprobe, "re-squash" the package, put it back in place, re-boot and re-try your "sudo start24dsi" ...
Yes.
modprobe is the correct command:
modprobe ${module_file}
-
Hi Rich,
I uncommented the modprobe ${module_file} line, and commented the insmod ${module_file} line, in package/usr/local/bin/start24dsi and then rebuilt the package, copied into place and re-booted.
For both "sudo start24dsi" and "which start24dsi" I get the same result as previous.
For the "grep insmod /usr/local/bin/start24dsi" I now get
#insmod ${module_file}
So, insmod has been commented out.
For the "grep modprobe /usr/local/bin/start24dsi" I get
modprobe ${module_file}
Am I correct in guessing that you're thinking that this is some kind of path issue ?, but that modprobe should run okay even without the path ?
Not sure if this helps or not, but I can run ./start in /home/tc/24dsi.linux.4.11.92.32.0/24dsi/driver and that works (with insmod), I've never tried that script in that location with modprobe though.
Thanks,
David
-
Hi MTCAT
... Not sure if this helps or not, but I can run ./start in /home/tc/24dsi.linux.4.11.92.32.0/24dsi/driver and that works (with insmod), I've never tried that script in that location with modprobe though.
No no no.
Run:
sudo depmodthen try:
sudo start24dsi
-
Hi Rich,
When I ran "sudo depmod", nothing was echoed to screen, so hopefully that's normal.
But, when I ran "sudo start24dsi", I got the same error again,
Driver loading: 24dsi........
---->ERROR<----: module file does not exist: /usr/local/bin/24dsi.ko
Newbie question/comment, why in the "standard" install as per GSC is the "start" script in the same directory as the module "24dsi.ko" (/usr/src/linux/drivers/24dsi/driver), or is that not the actual module file that the start script loads ?, I know you said that we should not put 24dsi.ko in /usr/local/bin in our case.
Thanks,
David
-
Hi MTCAT
Ok, I see the problem.
Change this:
modprobe ${module_file}to this:
modprobe ${module_name}
-
Hi Rich,
Sorry to be such a pain, but still nothing, same result, no driver loaded when typing "lsmod", and I also ran "sudo depmod" followed by "sudo start24dsi" and still the same error.
Could this be it ? In the "standard" install, the directory is like /usr/src/linux/drivers/24dsi/driver
In our case, by "symmetry", we seem to be missing the driver directory, does that matter ?
In our case we have the module file located at
~/package/usr/local/lib/modules/2.6.33.3-tinycore/kernel/drivers/24dsi
Do we maybe need to add a "driver" directory underneath "24dsi" directory, and put 24dsi.ko there ?
Thanks,
David
-
Hi MTCAT
Make sure squashfs-tools-4.x is installed and run this:
unsquashfs -ll /etc/sysconfig/tcedir/optional/24dsi-2.6.33.3-tinycore-686.tcz > 24dsiList.txtAttach 24dsiList.txt to your next post.
Then change the modprobe command to this:
modprobe 24dsi
-
Hi Rich,
Thanks, I'll give that a try tonight.
Just to be sure, regarding the modprobe command change, you mean for me to do that inside the start24dsi script ?, i.e., change
modprobe ${module_name}
to
modprobe 24dsi
Just want to make sure.
Thanks,
David
-
Hi MTCAT
Exactly.
But I would also like to see what winds up in 24dsiList.txt from the other command I listed.
-
Hi Rich,
I don't have a "tcedir" directory in /etc/sysconfig, just some files in there.
Thanks,
David
-
Hi MTCAT
Then run the command on whatever drive contains tce/optional/24dsi-2.6.33.3-tinycore-686.tcz.
-
Hi MTCAT
I don't have a "tcedir" directory in /etc/sysconfig, just some files in there.
I forgot older versions of Tinycore don't have that link. This should work:
unsquashfs -ll `cat /opt/.tce_dir`/optional/24dsi-2.6.33.3-tinycore-686.tcz > 24dsiList.txtRemember, those are back ticks, not single quotes.
-
Hi Rich,
I ran "unsquashfs" on both /mnt/sdb1/tce/optional/24dsi-2.6.33.3-tinycore-686.tcz and then also with your fancier command, the output of the first "unsquashfs" is attached as 24dsiList.txt, and the output of your fancy command is 24dsiListv2.txt
Unfortunately, changing to "modprobe 24dsi" inside start24dsi didn't do anything for us, still no "24dsi" listed when typing "lsmod".
Hopefully you see something off in the output of unsquashfs.
Thanks,
David
-
Hi MTCAT
Does this return anything:
modinfo 24dsi
If not, how about if you run this first:
sudo /sbin/depmod -a
-
Hi Rich,
modinfo.txt contains the output of running "modinfo 24dsi" before doing anything special.
modinfo2.txt contains the output of running "modinfo 24dsi" after running "sudo /sbin/depmod -a".
I did run modinfo previously and was curious to see that both the 486 and 686 drivers are referred to as "486" in vermagic.
Thanks,
David
-
Hi Rich,
Sorry, forgot the attachments, here they are !
David
-
Hi MTCAT
... I did run modinfo previously and was curious to see that both the 486 and 686 drivers are referred to as "486" in vermagic.
If you compiled with:
-march=i486 -mtune-i686It generates 486 compatible code but orders instruction to take advantage of the pipelining in a 686.
So modinfo finds it. See if modprobe knows where it is:
modprobe -l 24dsi
If it does, and /usr/local/bin/start24dsi contains modprobe 24dsi , then I see no reason why this should not load the driver:
sudo start24dsi
-
Hi Rich,
Thanks for the explanation re: 486 and 686.
I ran "modprobe -l 24dsi" and I was returned with;
kernel.tclocal/drivers/24dsi/24dsi.ko
But, when I typed "sudo start24dsi", I get the usual error again,
Driver loading: 24dsi........
---->ERROR<----: module file does not exist: /usr/local/bin/24dsi.ko
However, did we try this already ?, when I simply type out "sudo modprobe 24dsi", that worked ! ! ?, I can do an "lsmod", and it's there now, "24dsi" is listed amongst the loaded modules !
But, I did put "modprobe 24dsi" into the start24dsi script in /home/tc/package/usr/local/bin, and then re-squashed the "package" directory, and put the .tcz file in /mnt/sdb1/tce/optional so, I'm not sure what I'm doing wrong....
Should I maybe just change my bootlocal.sh ?, namely, remove
/usr/local/bin/start24dsi
and replace with
modprobe 24dsi
Would that work ?, or be an okay way of going about things ?
Thanks,
David
-
Hi MTCAT
Find this in the start24dsi file:
# Make sure the module file exists.and remove it and the next 5 lines (if through fi)
That section of the script is forcing it to exit before it gets to the modprobe command.
-
Hi MTCAT
... Should I maybe just change my bootlocal.sh ?, namely, remove
/usr/local/bin/start24dsi
and replace with
modprobe 24dsi
Would that work ?, or be an okay way of going about things ?
If your software still works that way, it would certainly simplify things. However, I see the script also creates device nodes
in /dev/ for each board that it finds. I suspect your software might use those nodes to access the board.
-
Hi Rich,
Oh, okay, thanks (re: circumventing start24dsi), I'll try commenting out those lines in start24dsi and see if it will load up then !
Thanks,
David
-
Thanks Rich, that did it !, it "auto-loaded" all by itself !
I noticed during boot-up a quick message flashed on screen too, loading driver or something to that effect, and now with doing nothing other than type "lsmod", there it is, 24dsi in the list of loaded modules ! Right on !
One thing though, should I just leave start24dsi as;
modprobe 24dsi
or does it matter to change back to,
modprobe ${module_name}
I guess it's kind of academic, but, was the problem with the GSC script that it basically didn't know where to look for the 24dsi.ko file ?
Thanks,
David
-
Hi MTCAT
You can change it back to module_name if you like since it's defined at the beginning of the script as:
module_name=24dsi
-
Hi Rich,
Thanks a lot, will do.
I'm playing around with the sample programs, is there a program in TinyCore called "id" already in place ?
I notice in /usr/local/bin that all of the 24dsi "sample" programs, for "rxrate" for example, look like
/tmp/tcloop/24dsi-2.6.33.3-tinycore-686/usr/local/bin/rxrate
The 24dsi has a sample program called "id", that just gives out a bunch of diagnostic info on the board, but, in /usr/local/bin the path to the "id" program that's there is different,
/tmp/tcloop/coreutils/usr/local/bin/id
And running ./id definitely isn't testing the 24dsi, returns info on users, etc.
Similar to the change of "start" to "start24dsi", looks like I should also change the GSC program named "id" to "id24dsi" ?
Maybe even tomorrow I can try to see if the little VortexDX will load the 486 package, after I do all the necessary mod's to the start file !
Thanks,
David
-
Hi MTCAT
... I'm playing around with the sample programs, is there a program in TinyCore called "id" already in place ? ...
Yes, id is a Linux command.
... Similar to the change of "start" to "start24dsi", looks like I should also change the GSC program named "id" to "id24dsi" ? ...
That would be a good idea. I believe I mentioned the risk of using overly generic names in a previous post.
-
Hi Rich,
I changed "modprobe 24dsi" back to "modprobe ${module_name}, and changed "id" to "id24dsi", and all is well, the "id24dsi" program runs now, the driver loads faithfully, so far so good !
I also made the required changes to the 486 package, namely, the start script modifications, and re-naming id, and then re-squashed that package as well.
As you predicted, the 486 AND 686 packages seems to run equally well on the DX3.
Next step will be to see if the lower power DX will load the 486 package, hopefully will find that out tomorrow !
Then it's "only" the logger program left to get going, which needs ntp and real time Linux stuff (yikes).
Thanks,
David
-
Hi MTCAT
... Then it's "only" the logger program left to get going, which needs ntp and real time Linux stuff (yikes).
Are you referring to a real time kernel? If you are, what makes you think you need that? If I'm looking at the correct
spec sheet, its features include:
256 K-sample FIFO Buffer
Synchronous or Independent ADC Clocking
Internal Sample Rate Generators
DMA Engine Supports both Block-Mode and Demand-Mode Transfers
That suggests the hardware is capable of acquiring the data and transferring it to your computers memory. If all you have
to do is process the data that's been deposited in system RAM, you don't need a real time kernel.
-
Hi Rich,
That would be great if I didn't need to worry about the real-time kernel, I admit I don't really know if it's truly needed.
From what I understand, a PPS signal is input to one of the serial ports (RS232) to "discipline" ntp, in order to get a pretty good time sync to GPS, down to ~ the ms level.
And then we also collect the PPS signal itself with the 24DSI so that we can further refine relative timing of "events" between two separated instruments, a so called base station and a rover, which can be several miles apart.
So I don't think any of that requires real-time kernel yet ?, but, the logger program basically samples continuously at 200 kHz, saving "events" in 2 or 3 second windows whenever a simple amplitude threshold is exceeded. But on top of that, even if no "events" are found, the 200 kHz data-stream is continuously low-pass filtered and decimated to a 20 kHz sampled "continuous" data stream, which is written out to disk in 60 second chunks, and it's that continuous data stream that I think is synchronized to start sampling at the top of every minute.
Could that be a legitimate "real-time" usage scenario, to ensure that the 24DSI starts sampling at the top of every minute ?
Thanks,
David
-
Hi MTCAT
... but, the logger program basically samples continuously at 200 kHz, ...
I doubt that. That means the program would be interrupting the OS every 5 uSecs. I suspect what's really happening is
the logger program programs the 24dsi to do something similar to:
1. Take readings every 5 uSecs.
2. Save readings to FIFO.
3. When FIFO fills to a certain level, do a DMA transfer from FIFO to a buffer in system RAM.
The logger program probably processes the data in blocks as it becomes available in that buffer.
-
Hi Rich,
You could be right, one thing I forgot to add, the logger program makes use of a 128 MByte "buffer" in RAM as well, I think it's in one of the ".rc" files in Slackware, where it's declared, a big chunk of RAM that's dedicated solely for the logger program, so that ties in with your comments I think. This was one of my concerns with trying out an AMD Geode with only 256 MBytes RAM total.
In any case, hopefully the "real-time" kernel can be avoided, just to keep things simpler, maybe it's not really needed.
As I'm sure you can tell, I'm not a super-programmer by any means, I've mostly worked by "proofing" data processing code in Matlab/Octave/Scilab, and then translating to Fortran for speed, the logger program is written in C(++ ?), so it's kind of hard to read from my stand-point. But I do like the simplicity (and power) of command prompt stuff too, hence my enjoyment of TinyCore !
Wish me luck with the DX, hopefully I'll give that a go today, see if it will load the 486 package !
Thanks,
David
-
Hi MTCAT
You could be right, one thing I forgot to add, the logger program makes use of a 128 MByte "buffer" in RAM as well, ...
So if the board is running full bore, it will accumulate data at a rate of:
200K samples/sec x 12 channels x 4 bytes/sample = 9600 Kbytes/sec = 9.6 Mbytes/sec.
So your buffer can accommodate 128 Mbytes / 9.6 Mbytes = 13.33 seconds worth of data without overflowing.
Your board produces 24 bit data which only requires 3 bytes. I calculated 4 bytes because dealing with 32 bit data is faster
than 24 bit data. There's also the distinct possibility they actually use a fourth byte to provide additional information, such
as which channel the conversion was performed on.
-
Hi Rich,
I tried out the VortexDX loading the 486 package and unfortunately it didn't work, although it looks like it did load the driver ?, but something else went wrong.
I'll try to describe the bootup verbally.
After;
"Loading Extensions....Done", "Setting keymap to us Done", "Setting hostname to box Done" then the TinyCore Linux "graphic" screen pops up, and underneath that it said " login[2142]: root login on 'tty1' ", and then right under that "Driver loading: 24dsi...", and then something odd popped up on the next frame, "route: SIOCADDRT: File Exists".
And then the screen went blank for a few slides, and then "Creating /dev/24dsi.0" (that's a zero after the 24dsi.), and then next slide looked like this;
Creating /dev/24dsi.0
Floating point exception
sh: 01: unknown operand
Driver loaded: 24dsi
And then the next slide looked like this
Creating /dev/24dsi.0
Floating point exception
sh: 01: unknown operand
Driver loaded: 24dsi
Floating point exception
chown: cannot access '/usr/local/tce.icons' : No such file or directory
chmod: cannot access '/usr/local/tce.icons' : No such file or directory
And then next slide is as above, except with a lot of "Floating point exception" scrolling by now, and eventually, I just end up with a blank screen, after which I powered down.
What do you think ? Am I out of luck with the VortexDX ?
Thanks,
David
-
Hi MTCAT
Remove 24dsi-2.6.33.3-tinycore-486.tcz from your tce/onboot.lst file.
Reboot the machine.
Perform a rescan of the PCI bus:
echo 1 | sudo tee /sys/bus/pci/rescanNext load the extension:
tce-load -i 24dsi-2.6.33.3-tinycore-486Then run the startup script:
sudo start24dsi
If this causes floating point exceptions, then you should probably move on. The incompatibility that prevented compiling the
driver is also preventing its use.
-
Hi Rich,
Followed your instructions, the 486 package loaded okay on the DX, but when I typed "sudo start24dsi" I saw the same thing as before,
Driver loading: 24dsi...
Creating /dev/24dsi.0
Floating point exception
sh: 01: unknown operand
Driver loaded: 24dsi
But, typing "lsmod", I do see "24dsi" there, and I ran "./id24dsi" and it was okay, but running "./rxrate -bmdma" generated an error for the "AI Sample Rate", you guessed it, floating point exception. Even though the VortexDX claims to do floating point operations, it must not be 100 percent so to speak ?
Too bad, it's actually a well laid out board, with nice connectors, but it's really only 1.5W lower power than the DX3 it seems, I measure it at about 5.5-6.5 W even though spec is 4W. It's a noticeable step down in performance though, terminal windows in X are a lot more jerky than with the DX3. Seems like a better designed board though, oh well, too bad, back to the DX3 I guess. I could try a Geode, rated at 4.5 W, but I never seem to be able to trust the mfr's power ratings, it too might only be a Watt or two lower power than the DX3, might not be worth it.
Thanks,
David
-
Hi Rich,
Just noticed too, when running "./id24dsi" on the VortexDX, the GSC sample program thinks the VortexDX is an i586, it's supposed to be i486.
This has never been good when the software (or kernel) is confused about the CPU type.
Thanks,
David
-
Hi MTCAT
Yeah, I suspected it would fail. If you check the Vortex86 Wiki, they even mention the Vortex86SX will run i586 code.
-
Hi Rich,
Thanks a lot for all your help, I'll put the DX3 stack back together and keep moving forward with that !
I guess installing ntp and getting the PPS going into one of the serial ports will be next, and then the logger program, hopefully w/o the need for a real time kernel !
Thanks,
David
-
Hi Rich,
I put the DX3 stack back together and all is well, inow just have to read up on ntp, and seeing the PPS signal and NMEA strings over the serial port, although, apparently can do it through the "GPIO" port on the VortexDX3 too.
Kind of unrelated, but for something different and fun, I downloaded the script "tinierclock.sh" and tried out the command below in the window manager (flwm ?), it works !, now I'm trying to automatically invoke that command at bootup by placing it in bootlocal.sh,
aterm -geometry 10x1+1860+1060 -bl -si -sb -sk -sl 0 -fade 100 -e sh -c /home/tc/tinierclock.sh
But, it didn't work, I'm guessing this is not the right thing to do as the above command needs to be run within the window manager ? within "X" (FLWM ?) so to speak, and bootlocal.sh tries to run the command before "X" starts up ?
Is there an "xconfig" type of file somewhere for flwm that I could place the above command in, to have the nice little clock come up automatically for me as soon as the window manager starts ?
I downloaded "flit" package as well but it's kind of overkill I think with the battery monitor and all the sound related stuff, so I thought something simple like "tinierclock.sh" would be good enough for me.
Thanks,
David
-
Hi MTCAT
Download the newer version tinierclock2.sh attached to reply #1:
http://forum.tinycorelinux.net/index.php/topic,13794.msg150397.html#msg150397
Make it executable:
chmod 775 tinierclock2.shMove it to the your ~/.local/bin directory:
mv tinierclock2.sh ~/.local/binNow create a file in .X.d (any name you want) containing the following line:
tinierclock2.sh &
Now it will start whenever the window manager starts.
This post explains one criteria about where to place startup commands:
http://forum.tinycorelinux.net/index.php/topic,24526.msg155602.html#msg155602
-
Thanks a lot Rich, I did try tinierclock2.sh as well, manually, but I got some errors, couldn't find "pstree", I need to install a new package I guess ?
Thanks for the reference re: where to place startup commands, that's super helpful, I always forget about the hidden files and directories in home !
Thanks,
David
-
Hi MTCAT
The newer version won't work on older versions of Tinycore. It requires the busybox version of pstree.
Follow the instructions in reply #140, but with the original script (tinierclock.sh).
When you get to this part:
... Now create a file in .X.d (any name you want) containing the following line:
tinierclock2.sh & ...
Place this in the file instead:
aterm -geometry 10x1+1860+1060 -bl -si -sb -sk -sl 0 -fade 100 -e sh -c tinierclock.sh &
Restart X and the clock should be there.
-
Thanks a lot Rich, that worked like a charm !
Now back to reading up on gpsd and ntpd !
Thanks,
David
-
Hi MTCAT
Thanks a lot Rich, ...
You are welcome.
... that worked like a charm ! ...
Hey, how about that. I got it right. :)
-
Hi Rich,
I'm horsing around trying to get gpsd and ntp etc. to work, going fairly well so far, but I have a question related to that, should I start a new thread for that ?
Thanks,
David
-
Hi MTCAT
Yes, that sounds like it should get its own topic.