Todd Peterson(deleted)
|
Pin mux UARTs Beaglebone Black
|
Todd Peterson(deleted)
09/15/2018 9:57 PM
post119107
|
Pin mux UARTs Beaglebone Black
I am running QNX 6.6 and trying to set the UART pin modes. The register values do not get changed. I don't recall having
this problem under QNX 6.5. Here is my code, any clues?
int main(int argc, char *argv[]) {
uintptr_t vaddr;
if (ThreadCtl( _NTO_TCTL_IO, 0 )) {
printf("must be root\n");
return 1;
}
setvbuf (stdout, NULL, _IOLBF, 0);
// muxing
vaddr = mmap_device_io(0x1000, 0x44e10000);
out32(vaddr + 0x950, 0x31);
out32(vaddr + 0x954, 0x1);
out32(vaddr + 0x980, 0x30);
out32(vaddr + 0x984, 0x0);
printf("0x%x\n", in32(vaddr + 0x950));
printf("0x%x\n", in32(vaddr + 0x954));
munmap_device_io( vaddr, 0x1000);
return EXIT_SUCCESS;
}
|
|
|
Elad Lahav
|
RE: Pin mux UARTs Beaglebone Black
|
Elad Lahav
09/16/2018 7:32 PM
post119110
|
RE: Pin mux UARTs Beaglebone Black
Change _NTO_TCTL_IO to _NTO_TCTL_IO_PRIV.
--Elad
________________________________________
From: Todd Peterson(deleted) [community-noreply@qnx.com]
Sent: September-15-18 9:57 PM
To: ostech-core_os
Subject: Pin mux UARTs Beaglebone Black
I am running QNX 6.6 and trying to set the UART pin modes. The register values do not get changed. I don't recall having
this problem under QNX 6.5. Here is my code, any clues?
int main(int argc, char *argv[]) {
uintptr_t vaddr;
if (ThreadCtl( _NTO_TCTL_IO, 0 )) {
printf("must be root\n");
return 1;
}
setvbuf (stdout, NULL, _IOLBF, 0);
// muxing
vaddr = mmap_device_io(0x1000, 0x44e10000);
out32(vaddr + 0x950, 0x31);
out32(vaddr + 0x954, 0x1);
out32(vaddr + 0x980, 0x30);
out32(vaddr + 0x984, 0x0);
printf("0x%x\n", in32(vaddr + 0x950));
printf("0x%x\n", in32(vaddr + 0x954));
munmap_device_io( vaddr, 0x1000);
return EXIT_SUCCESS;
}
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post119107
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
Elad Lahav
|
RE: Pin mux UARTs Beaglebone Black
|
Elad Lahav
09/17/2018 7:11 AM
post119112
|
RE: Pin mux UARTs Beaglebone Black
That said, why do you need to be in SYS mode to access memory-mapped registers? What happens on 6.5 when you don't use
_NTO_TCTL_IO?
--Elad
________________________________________
From: Elad Lahav
Sent: September-16-18 7:16 PM
To: ostech-core_os@community.qnx.com
Subject: RE: Pin mux UARTs Beaglebone Black
Change _NTO_TCTL_IO to _NTO_TCTL_IO_PRIV.
--Elad
________________________________________
From: Todd Peterson(deleted) [community-noreply@qnx.com]
Sent: September-15-18 9:57 PM
To: ostech-core_os
Subject: Pin mux UARTs Beaglebone Black
I am running QNX 6.6 and trying to set the UART pin modes. The register values do not get changed. I don't recall having
this problem under QNX 6.5. Here is my code, any clues?
int main(int argc, char *argv[]) {
uintptr_t vaddr;
if (ThreadCtl( _NTO_TCTL_IO, 0 )) {
printf("must be root\n");
return 1;
}
setvbuf (stdout, NULL, _IOLBF, 0);
// muxing
vaddr = mmap_device_io(0x1000, 0x44e10000);
out32(vaddr + 0x950, 0x31);
out32(vaddr + 0x954, 0x1);
out32(vaddr + 0x980, 0x30);
out32(vaddr + 0x984, 0x0);
printf("0x%x\n", in32(vaddr + 0x950));
printf("0x%x\n", in32(vaddr + 0x954));
munmap_device_io( vaddr, 0x1000);
return EXIT_SUCCESS;
}
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post119107
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
Albrecht Uhlmann
|
Re: RE: Pin mux UARTs Beaglebone Black
|
Albrecht Uhlmann
09/17/2018 8:09 AM
post119117
|
Re: RE: Pin mux UARTs Beaglebone Black
Have you checked the return value of mmap_device_io()?
|
|
|
Todd Peterson(deleted)
|
Re: RE: Pin mux UARTs Beaglebone Black
|
Todd Peterson(deleted)
09/17/2018 11:29 AM
post119118
|
Re: RE: Pin mux UARTs Beaglebone Black
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>I usually check the return value. Code
snippet is quick and dirty implementation.</div><div><br>Todd Peterson<br>Chief Embedded Systems Engineer<br>Management
Sciences, Inc.<br>6022 Constitution Ave NE<br>Albuquerque, NM 87110<br>505-255-8611 (office)<br>505-205-7057 (cell)</div
><br><br><font color="#990099">-----Albrecht Uhlmann <community-noreply@qnx.com> wrote: -----</font><div class="
iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To
: ostech-core_os <ostech-core_os@community.qnx.com><br>From: Albrecht Uhlmann <community-noreply@qnx.com><br>Date: 09/17
/2018 05:53AM<br>Subject: Re: RE: Pin mux UARTs Beaglebone Black<br><br><div><font face="Courier New,Courier,monospace"
size="3">Have you checked the return value of mmap_device_io()?<br><br><br><br>
_______________________________________________<br><br>OSTech<br><a href="http://community.qnx.com/sf/go/post119117">
http://community.qnx.com/sf/go/post119117</a><br>To cancel your subscription to this discussion, please e-mail ostech-
core_os-unsubscribe@community.qnx.com<br></font></div></div></div><div><br><br>This email message and any attachments
are for the sole use of the intended recipient(s) and may contain proprietary and/or confidential information which may
be privileged or otherwise protected from disclosure. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy the original
message and any copies of the message as well as any attachments to the original message.</div></font>
|
|
|
Elad Lahav
|
Re: RE: Pin mux UARTs Beaglebone Black
|
Elad Lahav
09/17/2018 2:09 PM
post119121
|
Re: RE: Pin mux UARTs Beaglebone Black
If you are suggesting that mmap(MAP_PHYS) (which is really what
mmap_device_io() is) depends on I/O privileges then that should not be
the case. It is a privileged operation, but it is based on abilities,
not the I/O thread flag (and the root user has the ability by default).
--Elad
On Mon, 2018-09-17 at 08:09 -0400, Albrecht Uhlmann wrote:
> Have you checked the return value of mmap_device_io()?
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post119117
> To cancel your subscription to this discussion, please e-mail ostech-
> core_os-unsubscribe@community.qnx.com
|
|
|
Todd Peterson(deleted)
|
Re: RE: Pin mux UARTs Beaglebone Black
|
Todd Peterson(deleted)
09/17/2018 10:58 PM
post119123
|
Re: RE: Pin mux UARTs Beaglebone Black
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>I am getting different behavior between
QNX 6.5 and 6.6 with different code. I am experimenting and will let you know my results. Fairly swamped at the moment,
so it may take a while.</div><div><br>Todd Peterson<br>Chief Embedded Systems Engineer<br>Management Sciences, Inc.<br>
6022 Constitution Ave NE<br>Albuquerque, NM 87110<br>505-255-8611 (office)<br>505-205-7057 (cell)</div><br><br><font
color="#990099">-----Elad Lahav <community-noreply@qnx.com> wrote: -----</font><div class="iNotesHistory" style="padding
-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To: "ostech-core_os@community.
qnx.com" <ostech-core_os@community.qnx.com><br>From: Elad Lahav <community-noreply@qnx.com><br>Date: 09/17/2018 11:53AM<
br>Subject: Re: RE: Pin mux UARTs Beaglebone Black<br><br><div><font face="Courier New,Courier,monospace" size="3">If
you are suggesting that mmap(MAP_PHYS) (which is really what<br>mmap_device_io() is) depends on I/O privileges then that
should not be<br>the case. It is a privileged operation, but it is based on abilities,<br>not the I/O thread flag (and
the root user has the ability by default).<br><br>--Elad<br><br>On Mon, 2018-09-17 at 08:09 -0400, Albrecht Uhlmann
wrote:<br>> Have you checked the return value of mmap_device_io()?<br>> <br>> <br>> <br>>
_______________________________________________<br>> <br>> OSTech<br>> <a href="http://community.qnx.com/sf/go/
post119117">http://community.qnx.com/sf/go/post119117</a><br>> To cancel your subscription to this discussion, please
e-mail ostech-<br>> core_os-unsubscribe@community.qnx.com<br><br><br><br>
_______________________________________________<br><br>OSTech<br><a href="http://community.qnx.com/sf/go/post119121">
http://community.qnx.com/sf/go/post119121</a><br>To cancel your subscription to this discussion, please e-mail ostech-
core_os-unsubscribe@community.qnx.com<br></font></div></div></div><div><br><br>This email message and any attachments
are for the sole use of the intended recipient(s) and may contain proprietary and/or confidential information which may
be privileged or otherwise protected from disclosure. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy the original
message and any copies of the message as well as any attachments to the original message.</div></font>
|
|
|
Michael Schuster
|
Re: RE: Pin mux UARTs Beaglebone Black
|
Michael Schuster
09/18/2018 12:41 AM
post119124
|
Re: RE: Pin mux UARTs Beaglebone Black
I get a load of HTML code - would you mind posting in plain text?
thx
On Mon, 2018-09-17 at 20:42 -0600, community-noreply@qnx.com wrote:
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>I am getting different behavior between
QNX 6.5 and 6.6 with different code. I am experimenting and will let you know my results. Fairly swamped at the moment,
so it may take a while.</div><div><br>Todd Peterson<br>Chief Embedded Systems Engineer<br>Management Sciences, Inc.<br>
6022 Constitution Ave NE<br>Albuquerque, NM 87110<br>505-255-8611 (office)<br>505-205-7057 (cell)</div><br><br><font
color="#990099">-----Elad Lahav <community-noreply@qnx.com<mailto:community-noreply@qnx.com>> wrote: -----</font><div
class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black
2px;">To: "ostech-core_os@community.qnx.com<mailto:ostech-core_os@community.qnx.com>" <ostech-core_os@community.qnx.
com<mailto:ostech-core_os@community.qnx.com>><br>From: Elad Lahav <community-noreply@qnx.com<mailto:community-noreply@
qnx.com>><br>Date: 09/17/2018 11:53AM<br>Subject: Re: RE: Pin mux UARTs Beaglebone Black<br><br><div><font face="Courier
New,Courier,monospace" size="3">If you are suggesting that mmap(MAP_PHYS) (which is really what<br>mmap_device_io() is)
depends on I/O privileges then that should not be<br>the case. It is a privileged operation, but it is based on
abilities,<br>not the I/O thread flag (and the root user has the ability by default).<br><br>--Elad<br><br>On Mon, 2018-
09-17 at 08:09 -0400, Albrecht Uhlmann wrote:<br>> Have you checked the return value of mmap_device_io()?<br>> <br>> <br
>> <br>> _______________________________________________<br>> <br>> OSTech<br>> <a href="http://community.qnx.com/sf/go/
post119117">http://community.qnx.com/sf/go/post119117</a><br>> To cancel your subscription to this discussion, please
e-mail ostech-<br>> core_os-unsubscribe@community.qnx.com<mailto:core_os-unsubscribe@community.qnx.com><br><br><br><br>
_______________________________________________<br><br>OSTech<br><a href="http://community.qnx.com/sf/go/post119121">
http://community.qnx.com/sf/go/post119121</a><br>To cancel your subscription to this discussion, please e-mail ostech-
core_os-unsubscribe@community.qnx.com<mailto:ostech-core_os-unsubscribe@community.qnx.com><br></font></div></div></div><
div><br><br>This email message and any attachments are for the sole use of the intended recipient(s) and may contain
proprietary and/or confidential information which may be privileged or otherwise protected from disclosure. Any
unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s), please
contact the sender by reply email and destroy the original message and any copies of the message as well as any
attachments to the original message.</div></font>
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post119123
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com<mailto:ostech
-core_os-unsubscribe@community.qnx.com>
|
|
|
Todd Peterson(deleted)
|
RE: Pin mux UARTs Beaglebone Black
|
Todd Peterson(deleted)
09/16/2018 11:01 PM
post119111
|
RE: Pin mux UARTs Beaglebone Black
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>Bingo!</div><div>Thanks!</div><div><br>
Todd Peterson<br>Chief Embedded Systems Engineer<br>Management Sciences, Inc.<br>6022 Constitution Ave NE<br>Albuquerque
, NM 87110<br>505-255-8611 (office)<br>505-205-7057 (cell)</div><br><br><font color="#990099">-----Elad Lahav <community
-noreply@qnx.com> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;
padding-left:5px;border-left:solid black 2px;">To: "ostech-core_os@community.qnx.com" <ostech-core_os@community.qnx.com>
<br>From: Elad Lahav <community-noreply@qnx.com><br>Date: 09/16/2018 05:16PM<br>Subject: RE: Pin mux UARTs Beaglebone
Black<br><br><div><font face="Courier New,Courier,monospace" size="3">Change _NTO_TCTL_IO to _NTO_TCTL_IO_PRIV.<br><br
>--Elad<br>________________________________________<br>From: Todd Peterson(deleted) [community-noreply@qnx.com]<br>Sent:
September-15-18 9:57 PM<br>To: ostech-core_os<br>Subject: Pin mux UARTs Beaglebone Black<br><br>I am running QNX 6.6
and trying to set the UART pin modes. The register values do not get changed. I don't recall having this problem under
QNX 6.5. Here is my code, any clues?<br><br>int main(int argc, char *argv[]) {<br> uintptr_t vaddr;<br> if
(ThreadCtl( _NTO_TCTL_IO, 0 )) {<br> printf("must be root\n");<br> return 1;<br> }<br> setvbuf
(stdout, NULL, _IOLBF, 0);<br> // muxing<br> vaddr = mmap_device_io(0x1000, 0x44e10000);<br>
out32(vaddr + 0x950, 0x31);<br> out32(vaddr + 0x954, 0x1);<br> out32(vaddr + 0x980, 0x30);<br>
out32(vaddr + 0x984, 0x0);<br> printf("0x%x\n", in32(vaddr + 0x950));<br> printf("0x%x\n", in32(vaddr +
0x954));<br> munmap_device_io( vaddr, 0x1000);<br><br> return EXIT_SUCCESS;<br>}<br><br><br><br><br>
_______________________________________________<br><br>OSTech<br><a href="http://community.qnx.com/sf/go/post119107">
http://community.qnx.com/sf/go/post119107</a><br>To cancel your subscription to this discussion, please e-mail ostech-
core_os-unsubscribe@community.qnx.com<br><br><br><br><br>_______________________________________________<br><br>OSTech<
br><a href="http://community.qnx.com/sf/go/post119110">http://community.qnx.com/sf/go/post119110</a><br>To cancel your
subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com<br></font></div></div></div>
<div><br><br>This email message and any attachments are for the sole use of the intended recipient(s) and may contain
proprietary and/or confidential information which may be privileged or otherwise protected from disclosure. Any
unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s), please
contact the sender by reply email and destroy the original message and any copies of the message as well as any
attachments to the original message.</div></font>
|
|
|
Todd Peterson(deleted)
|
RE: Pin mux UARTs Beaglebone Black
|
Todd Peterson(deleted)
09/17/2018 11:32 AM
post119119
|
RE: Pin mux UARTs Beaglebone Black
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>I am not sure what happens in 6.5 if I
don't use that call. I see from the QNX documentation that the _PRIV variant was added in 6.6. I wouldn't want a non-
privileged user program to change pin muxes or mess with many other machine-level registers.</div><div><br>Todd Peterson
<br>Chief Embedded Systems Engineer<br>Management Sciences, Inc.<br>6022 Constitution Ave NE<br>Albuquerque, NM 87110<br
>505-255-8611 (office)<br>505-205-7057 (cell)</div><br><br><font color="#990099">-----Elad Lahav <community-noreply@qnx.
com> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:
5px;border-left:solid black 2px;">To: "ostech-core_os@community.qnx.com" <ostech-core_os@community.qnx.com><br>From:
Elad Lahav <community-noreply@qnx.com><br>Date: 09/17/2018 04:55AM<br>Subject: RE: Pin mux UARTs Beaglebone Black<br><br
><div><font face="Courier New,Courier,monospace" size="3">That said, why do you need to be in SYS mode to access memory-
mapped registers? What happens on 6.5 when you don't use _NTO_TCTL_IO?<br><br>--Elad<br>
________________________________________<br>From: Elad Lahav<br>Sent: September-16-18 7:16 PM<br>To: ostech-core_os@
community.qnx.com<br>Subject: RE: Pin mux UARTs Beaglebone Black<br><br>Change _NTO_TCTL_IO to _NTO_TCTL_IO_PRIV.<br><
br>--Elad<br>________________________________________<br>From: Todd Peterson(deleted) [community-noreply@qnx.com]<br>
Sent: September-15-18 9:57 PM<br>To: ostech-core_os<br>Subject: Pin mux UARTs Beaglebone Black<br><br>I am running QNX 6
.6 and trying to set the UART pin modes. The register values do not get changed. I don't recall having this problem
under QNX 6.5. Here is my code, any clues?<br><br>int main(int argc, char *argv[]) {<br> uintptr_t vaddr;<br>
if (ThreadCtl( _NTO_TCTL_IO, 0 )) {<br> printf("must be root\n");<br> return 1;<br> }<br>
setvbuf (stdout, NULL, _IOLBF, 0);<br> // muxing<br> vaddr = mmap_device_io(0x1000, 0x44e10000);<br>
out32(vaddr + 0x950, 0x31);<br> out32(vaddr + 0x954, 0x1);<br> out32(vaddr + 0x980, 0x30);<br>
out32(vaddr + 0x984, 0x0);<br> printf("0x%x\n", in32(vaddr + 0x950));<br> printf("0x%x\n", in32(vaddr +
0x954));<br> munmap_device_io( vaddr, 0x1000);<br><br> return EXIT_SUCCESS;<br>}<br><br><br><br><br>
_______________________________________________<br><br>OSTech<br><a href="http://community.qnx.com/sf/go/post119107">
http://community.qnx.com/sf/go/post119107</a><br>To cancel your subscription to this discussion, please e-mail ostech-
core_os-unsubscribe@community.qnx.com<br><br><br><br><br>_______________________________________________<br><br>OSTech<
br><a href="http://community.qnx.com/sf/go/post119112">http://community.qnx.com/sf/go/post119112</a><br>To cancel your
subscription to this discussion, please e-mail...
|
|
|
|