Where to build/install ADC module

[Rich]

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:

Code: [Select]

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:

Code: [Select]

sudo udevadm trigger

[MTCAT]

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

[MTCAT]

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

[Rich]

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:

Code: [Select]

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.

[MTCAT]

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

[Rich]

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.

[MTCAT]

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

[Rich]

Hi MTCAT
Wow, you really botched this one:

Code: [Select]

APPEND initrd=/boot/tinycore.gz quiet  waitusb=10 acpi=offi:UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" .....
Try it like this:

Code: [Select]

APPEND initrd=/boot/tinycore.gz quiet acpi=off waitusb=10:UUID="5ffd491f-bf24-42f1-9ff1-172c98399c6f" ....
This is one command:

Code: [Select]

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.

[MTCAT]

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

[MTCAT]

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

[MTCAT]

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

[MTCAT]

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

[MTCAT]

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

[MTCAT]

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

[Rich]

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:

Code: [Select]

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:

Code: [Select]

#!/bin/shTo this:

Code: [Select]

#!/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:

Code: [Select]

chmod 755 BuildADC.sh
    [EDIT]: Fixed error in attachment.  Rich