Bug fix in 'apbuart_cons.c' file ?

[Daniel Hellstrom]

Hi Charles,

Sorry I missed to reply on your email. Thanks for reminding me. Which 
codebase do you use, is it the current RTEMS master or RCC-1.2?

/Daniel


On 2017-04-24 07:50, Charles INGELS wrote:
>
> Hi Joel,
>
> until now, I did not receive any answer from Daniel. I do not know if 
> my feedback has been taken into account, maybe for other users if they 
> have the same issue.
>
> Nevertheless, the fix seems to work fine with no apparent side effects.
>
> Regards,
>
> Charles
>
>
>
> Le 11.04.2017 à 03:29, Joel Sherrill a écrit :
>> I'm going to assume that Daniel didn't see this since he didn't comment.
>>
>> On Apr 10, 2017 2:41 AM, "Charles INGELS" <charles.ingels at syderal.ch 
>> <mailto:charles.ingels at syderal.ch>> wrote:
>>
>>     Hello,
>>
>>     By using the APB Uart BSP on a SPARC LEON3 target, I think that I
>>     have found something which seems to be incorrect.
>>
>>     In my RTEMS app, I just want to receive data through the UART1.
>>     Such data are then echoed on the same interface.
>>
>>     When I want to open the '/dev/apbuart1' descriptor, I get a 'No
>>     such file or directory' error message. I get the same error
>>     message whatever is the descriptor I try to open
>>     ('/dev/apbuart0', ...).
>>
>>     I am using the driver manager and I have defined the
>>     CONFIGURE_DRIVER_AMBAPP_GAISLER_APBUART to have the driver
>>     manager create the device descriptors. However, the descriptors
>>     are not created.
>>
>>     I had a look at the content of the following file :
>>
>>     U:\rtems\src2\rtems\c\src\lib\libbsp\sparc\shared\uart\apbuart_cons.c
>>
>>     On line #278, the if statement does not explicitly test the value
>>     returned by the call to function 'drvmgr_get_dev_prefix()'.
>>
>>     Since such function returns 0 in case of success, the content of
>>     the if statement is never executed. Consequently, the variable
>>     'priv->devName' is never initialized to the right string
>>     '/dev/apbuart%d', it is always empty which seems to explain why
>>     the device descriptor is not not created.
>>
>>     I have slightly modified the test with the following code :
>>
>>     if (drvmgr_get_dev_prefix(dev, prefix) != -1)
>>     {
>>     ...
>>     }
>>
>>     I explicitly test the returned value against -1 (which is
>>     considered as an error). With that code, the '/dev/apbuartX'
>>     device descriptors are successfully created and communicate with
>>     the UART.
>>
>>     So is it a known bug ? Will it be fixed in the next releases ? Is
>>     the way I fixed it correct, or no ?
>>
>>     Such fix works for me but are there some side effects that shall
>>     be taken into account ?
>>
>>     Thanks for your answers,
>>
>>     Regards,
>>
>>     Charles
>>
>>
>>
>>
>>     -- 
>>     *Charles INGELS*
>>     Embedded software expert
>>     charles.ingels at syderal.ch <mailto:charles.ingels at syderal.ch>
>>     Phone /+41 (0)32 338 99 10 <tel:+41%2032%20338%2099%2010>/
>>     iNum /+883 5100 0902 7759/
>>
>>     *SYDERAL SA*
>>     Neuenburgstrasse 7
>>     CH-3238 Gals (Suisse)
>>     Desk /+41 (0)32 338 98 00 <tel:+41%2032%20338%2098%2000>/
>>     Fax /+41 (0)32 338 99 34 <tel:+41%2032%20338%2099%2034>/
>>     Web site http://www.syderal.ch
>>     	
>>
>>
>>     _______________________________________________
>>     users mailing list
>>     users at rtems.org <mailto:users at rtems.org>
>>     http://lists.rtems.org/mailman/listinfo/users
>>     <http://lists.rtems.org/mailman/listinfo/users>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/c554dc3a/attachment-0004.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/c554dc3a/attachment-0005.html>