View topic - [QNX 7.0_x86_generic] Serial Port Data Receive Issue

[QNX 7.0_x86_generic] Serial Port Data Receive Issue

QNX7 release

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby ger » Thu Oct 24, 2019 8:42 am

OK.

(I hope Tim doesn't mind my following suggestions)! :-)

Please comment out the live that starts devb-ahci with the automount. Now build it and copy to the hard drive boot partition (/.boot).

Also comment out the line that refers to /etc/rc.d/rc.sysinit

Restart the machine. You should end up with a shell terminal with root privileges. At this stage you are operating within the realm of the boot image. Now start devb-ahci with no arguments. It should find the hard drive and after a bit of output and after a couple of seconds simply press <enter> to restore (to visibility) the # prompt.

Now enter:

ls /dev

You should (I hope) see listed /dev/hd0t177. This is your boot partition. You will also I think see /dev/hd0t178 - that will be the other partition that I think you eventually want to mount as /home.

Now enter:

mount -t qnx6 /dev/hd0t177 /hd

This mounts the boot partition as /hd and its contents will now be visible to you under /hd. For example, if you enter ls - laF /hd you will see the contents of the root directory of that partition. Please post this output.

I am also interested in the output of df -hk

This is really getting back to basics but that is a good place to start and move forward bit by bit. The ability to start/stop operating services (drivers such as devb-ahci, devc-ser8250, etc) and incrementally work towards a functional system is one of the great features of QNX, and one reason why I love working with it so much.

If here is a /hd/etc I'd like to see the long listing of that also.

Anyway, if you can post the long listing of /hd it will give me (and Tim I suppose) an idea of what's what with it, hopefully allow a plan to move forward to be formulated.

Geoff.
ger
Active Member
 
Posts: 29
Joined: Tue Jul 15, 2014 9:24 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby johnbevy » Thu Oct 24, 2019 10:03 am

ger wrote:OK.

(I hope Tim doesn't mind my following suggestions)! :-)

Please comment out the live that starts devb-ahci with the automount. Now build it and copy to the hard drive boot partition (/.boot).

Also comment out the line that refers to /etc/rc.d/rc.sysinit

Restart the machine. You should end up with a shell terminal with root privileges. At this stage you are operating within the realm of the boot image. Now start devb-ahci with no arguments. It should find the hard drive and after a bit of output and after a couple of seconds simply press <enter> to restore (to visibility) the # prompt.

Now enter:

ls /dev

You should (I hope) see listed /dev/hd0t177. This is your boot partition. You will also I think see /dev/hd0t178 - that will be the other partition that I think you eventually want to mount as /home.

Now enter:

mount -t qnx6 /dev/hd0t177 /hd

This mounts the boot partition as /hd and its contents will now be visible to you under /hd. For example, if you enter ls - laF /hd you will see the contents of the root directory of that partition. Please post this output.

I am also interested in the output of df -hk

This is really getting back to basics but that is a good place to start and move forward bit by bit. The ability to start/stop operating services (drivers such as devb-ahci, devc-ser8250, etc) and incrementally work towards a functional system is one of the great features of QNX, and one reason why I love working with it so much.

If here is a /hd/etc I'd like to see the long listing of that also.

Anyway, if you can post the long listing of /hd it will give me (and Tim I suppose) an idea of what's what with it, hopefully allow a plan to move forward to be formulated.

Geoff.


Hi Geoff,

Yes, as you suggested we have comment the automount and rc.sysinit ijn build file and built the same. We have created two partitions (177 (boot) and 178) using fdisk and copied the .bin file to /.boot folder of hd0t177 partition.

We have booted the image and started the disk driver using devb-ahci and found that hd0t177 and hd0178 was listing under /dev.

Then we mounted using below command (mount -t qnx6 /dev/h0t177 /hd) and took ls -laF for /hd folder.

Also, using df -hP we have verified that partitions are mounted properly. We didn't mount our second partition, since that will not necessary as of now for our issue.

We cant able to share the image. We are getting error as " Sorry, the board attachment quota has been reached"

Code: Select all
#df -hP

Filesystem          size                  Used             Available           capacity           Mounted on
/dev/hd0             24G                    24G               0                        100%                 /dev/hd0t178
/dev/hd0              5.9G                    5.9G            0                        100%                 /dev/hd0t177
/dev/hd0               30G                      30G            0                        10%



Code: Select all
#ls -laF /hd

drwrwxr-x                   ./
drwxr-xr-x                   ../
drwx-------                   .boot/


Thanks,
John
johnbevy
Active Member
 
Posts: 23
Joined: Tue Oct 15, 2019 8:41 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby ger » Thu Oct 24, 2019 11:28 am

So the hard drive is effectively blank, apart from the .boot directory where you have your boot image file.

If you now ls -laF / I suspect that you will have no /etc, /home, anything like that, as Tim's image (like mine) does not implicitly create them. You are operating completely off the /proc/boot image. If you look in /proc/boot you should find all your utility files, along with drivers, shared libraries, etc.

/proc/boot is also in your search path ($PATH). As a result you can use ls, df, etc from your shell terminal.

The trick now is to get the required file structures onto the hard drive so that when you start devb-ahci and mount /dev/hd0t177, it's all there waiting for you when you do the automount. So you can now un-comment the line with devb-ahci cam quiet ahci nports=4 blk automount=/dev/hd0t177:/:qnx6 &, rebuild it, put the new .bin file into /.boot, and reboot.

When you get your shell back you should still be able to use the utilities but an ls -laF / will (or should) also show your .boot file with your .bin file in it. Along with /proc/boot.

As for building /etc and others, well I cheat a bit but it's complicated. I am not sure how best to describe what I do as it involves another machine that is running QNX6.5. Basically I have an image of the QNX7 HD drive on the QNX6.5 machine, get QNET running on both, and then transfer the HD image across the network to the new QNX7 machine. This involves a few commands that can be manually entered to get the network up and running, and then QNET.

Tim's rc.sysinit file has some good stuff in it and you should be able to create a /tmp directory, set a hostname, get the network configured, and QNET running:

mount -T io-pkt -o bind=wm0 lsm-qnet.so

The network interface wm0 is created when io-pkt-v6-hd -de1000 is run. My other QNX7 machine has a Realtek NIC so its command is io-pkt-v6-hc -d rtl, and the interface is then rtl0. You can also start QNET with io-pkt-v6-hc -p qnet but I prefer to do it seperately.

If you want to start QNET you will need to add lsm-qnet.so to the list of components in the image file. Maybe add #Qnet and then lsm-qnet.so to it say after the #Sata block so that it ends up in your binary image.

Once you get /etc created with working files and sub-directories, other things can be added to make life a bit more comfortable. Such as the terminal emulation stuff (so less and vi work properly), maybe ssh. Whatever.

I am inclined to take this "offline" but this forum doesn't seem to have any private messaging facility. I am not keen on posting my email address here (same applies to you) so I'm not sure how we can communicate privately. If you want to do this maybe ask the forum administrator or one of the moderators for my email address. maschoen knows who I am.

Geoff.
ger
Active Member
 
Posts: 29
Joined: Tue Jul 15, 2014 9:24 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby johnbevy » Thu Oct 24, 2019 1:03 pm

ger wrote:So the hard drive is effectively blank, apart from the .boot directory where you have your boot image file.

If you now ls -laF / I suspect that you will have no /etc, /home, anything like that, as Tim's image (like mine) does not implicitly create them. You are operating completely off the /proc/boot image. If you look in /proc/boot you should find all your utility files, along with drivers, shared libraries, etc.

/proc/boot is also in your search path ($PATH). As a result you can use ls, df, etc from your shell terminal.

The trick now is to get the required file structures onto the hard drive so that when you start devb-ahci and mount /dev/hd0t177, it's all there waiting for you when you do the automount. So you can now un-comment the line with devb-ahci cam quiet ahci nports=4 blk automount=/dev/hd0t177:/:qnx6 &, rebuild it, put the new .bin file into /.boot, and reboot.

When you get your shell back you should still be able to use the utilities but an ls -laF / will (or should) also show your .boot file with your .bin file in it. Along with /proc/boot.

As for building /etc and others, well I cheat a bit but it's complicated. I am not sure how best to describe what I do as it involves another machine that is running QNX6.5. Basically I have an image of the QNX7 HD drive on the QNX6.5 machine, get QNET running on both, and then transfer the HD image across the network to the new QNX7 machine. This involves a few commands that can be manually entered to get the network up and running, and then QNET.

Tim's rc.sysinit file has some good stuff in it and you should be able to create a /tmp directory, set a hostname, get the network configured, and QNET running:

mount -T io-pkt -o bind=wm0 lsm-qnet.so

The network interface wm0 is created when io-pkt-v6-hd -de1000 is run. My other QNX7 machine has a Realtek NIC so its command is io-pkt-v6-hc -d rtl, and the interface is then rtl0. You can also start QNET with io-pkt-v6-hc -p qnet but I prefer to do it seperately.

If you want to start QNET you will need to add lsm-qnet.so to the list of components in the image file. Maybe add #Qnet and then lsm-qnet.so to it say after the #Sata block so that it ends up in your binary image.

Once you get /etc created with working files and sub-directories, other things can be added to make life a bit more comfortable. Such as the terminal emulation stuff (so less and vi work properly), maybe ssh. Whatever.

I am inclined to take this "offline" but this forum doesn't seem to have any private messaging facility. I am not keen on posting my email address here (same applies to you) so I'm not sure how we can communicate privately. If you want to do this maybe ask the forum administrator or one of the moderators for my email address. maschoen knows who I am.

Geoff.


Hi Geoff,

>>So the hard drive is effectively blank, apart from the .boot directory where you have your boot image file.

>>If you now ls -laF / I suspect that you will have no /etc, /home, anything like that, as Tim's image (like mine) does not implicitly create them.

[John] No, it's not blank. By default, bin,etc,dev, usr,sbin,var folders are created under /.

Also, .bin is in present under /hd/.boot folder.

Thanks,
John
johnbevy
Active Member
 
Posts: 23
Joined: Tue Oct 15, 2019 8:41 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby ger » Thu Oct 24, 2019 10:03 pm

Yes. A closer look at the image file shows me these directories will be created. But with little in them. For example, /etc contains only the dhclient.conf file. But it is not referencing the hard drive.

I built this image myself and installed it on a 32-bit x86 here. I then executed (noting that on this machine I use devb-eide and the boot partition is type 178):

devb-eide blk automount=/dev/hd0t178:/:qnx6 &

and the ls -laF / now shows the hard drive contents.

The /etc directory listing shows not only the real contents of the hard drive /etc but it also lists the dhclient.conf file (that isn't in the HD /etc). So I suppose its a sort of unionisation of the two - and can be confusing. It's to do with how QNX manages the path space (as I recall - it's been a while since I had to deal with this).

There will be a similar effect on the other directories hanging off /.

I don't know where the /.boot/.bin comes from.

Geoff.
ger
Active Member
 
Posts: 29
Joined: Tue Jul 15, 2014 9:24 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby johnbevy » Fri Oct 25, 2019 11:49 am

ger wrote:Yes. A closer look at the image file shows me these directories will be created. But with little in them. For example, /etc contains only the dhclient.conf file. But it is not referencing the hard drive.

I built this image myself and installed it on a 32-bit x86 here. I then executed (noting that on this machine I use devb-eide and the boot partition is type 178):

devb-eide blk automount=/dev/hd0t178:/:qnx6 &

and the ls -laF / now shows the hard drive contents.

The /etc directory listing shows not only the real contents of the hard drive /etc but it also lists the dhclient.conf file (that isn't in the HD /etc). So I suppose its a sort of unionisation of the two - and can be confusing. It's to do with how QNX manages the path space (as I recall - it's been a while since I had to deal with this).

There will be a similar effect on the other directories hanging off /.

I don't know where the /.boot/.bin comes from.

Geoff.


Hi Geoff/Tim,

Regarding devc-8250, We are planning to poll the RX FIFO using QNX application in order to check whether data received in UART registers.

We are searching for devc-8250 driver source code (DDK) in google but not able to find it. How we can get the serial driver source ? Do we need to ask QNX team regarding source code for serial driver?

Thanks,
John
johnbevy
Active Member
 
Posts: 23
Joined: Tue Oct 15, 2019 8:41 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby ger » Fri Oct 25, 2019 7:48 pm

Let us know how you go with getting the source to both the io-char DDK and devc-ser8250! :-)

Did you draw a blank with the manufacturer of your CPU board in regards to a working driver?

But it's probably not necessary at this stage. You don't need a full blown driver to simply test whether or not UARTs are working, and their interrupts. A simple program can do that and depending on the results, then decide what to do about it. If there is a problem with devc-ser8250 with a particular set of hardware I'm not sure what can be done about it.

Geoff.
ger
Active Member
 
Posts: 29
Joined: Tue Jul 15, 2014 9:24 am

Re: [QNX 7.0_x86_generic] Serial Port Data Receive Issue

Postby ger » Mon Oct 28, 2019 4:58 am

It was back in 2002 that I last had anything to do with devc-ser8250. So my memory is a bit hazy, but there is still some clarity (I think). What it was back then is probably vastly different to how it is now. I do not have any current source code for it.

But what I do remember is that back then all UART interactions took place inside the interrupt handler (ISR). This is not how I do my drivers as it makes debugging rather painful as you can't put printf()'s (for example) in there. The ISR executes in kernel context so you are somewhat restricted in what you can do inside it. You don't want to be spending any more time than is necessary inside an interrupt handler.

I think adapting the driver, as it was then at least, to poll the UART's might not be a trivial affair.

What I do in my drivers (note they are NOT 8250 or 16550 UART's) is have the ISR identify the source of the interrupt, the type of interrupt, and then bug out ASAP, returning with a pulse. I take care of the UART outside of the ISR in process (or thread) context which makes life very much easier. It certainly makes debugging easier. The drivers I have written support both interrupt driven and polling operation. It is trivial to move from polling to interrupt - with interrupt I have a pulse that is triggered by the return from the ISR: with polling I simply have the pulse triggered by a timer. The code that services the UART is identical for both. I can deal with 32 serial ports using this approach quite efficiently.

So, as I said i my previous post, it will probably be easier to simply write a program that initialises the UART(s) and allows you to send characters out and receive them back by use of a loopback plug. I think I would set it up so that I was polling for received characters and get that working first. I'd then introduce the interrupt handler and see what happens with that. You can test your interrupt on the timer interrupt, that I think is IRQ0 (one of the hazy bits of my memory)!

Geoff.
ger
Active Member
 
Posts: 29
Joined: Tue Jul 15, 2014 9:24 am

Previous

Return to QNX7

Who is online

Users browsing this forum: No registered users and 1 guest

cron