Where to build/install ADC module

[Rich]

Hi MTCAT

... Or you can look through the kernel messages:

Code: [Select]

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.

[MTCAT]

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

[Rich]

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:

Code: [Select]

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:

Code: [Select]

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.

[Rich]

Hi MTCAT

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

PCI: CLS mismatch (64 != 16), using 32 bytes
Which was set right before the  no compatible bridge window for  message above:

Code: [Select]

PCI: pci_cache_line_size set to 32 bytes

[MTCAT]

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

[Rich]

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:

Code: [Select]

mkdir -p package/usr/local/bin
Where you copy the files add this:

Code: [Select]

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  '.

[MTCAT]

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.

[Rich]

Hi MTCAT
If the board or driver don't show up, try this:

Code: [Select]

echo 1 | sudo tee /sys/bus/pci/devices/0000\:03\:01.0/remove

Code: [Select]

echo 1 | sudo tee /sys/bus/pci/rescan
Did it help?

Also, please give me another  dmesg.txt  after running those commands:

Code: [Select]

dmesg > dmesg.txt

[MTCAT]

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

[MTCAT]

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

[Rich]

Hi MTCAT
After  echo 1  did you use the  pipe  symbol that looks like this  | ?  It's located on the  \  key.

[MTCAT]

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

[MTCAT]

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

[Rich]

Hi MTCAT
This command will load the driver if It's not already loaded:

Code: [Select]

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:

Code: [Select]

dmesg | grep -i "Kernel command"It should work for Lubuntu too. If not, then this will:

Code: [Select]

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:

Code: [Select]

# 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.

[MTCAT]

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