Bug fix in 'apbuart_cons.c' file ?

Mon Apr 24 14:14:18 UTC 2017

Hi Charles,

There has been some recent improvements in the patches related to the 
device name etc. for the APBUART driver. The patches were posted to the 
devel list. I'm planning on pushing them to master tomorrow. 
Historically the APBUART1 would be /dev/console_b.

Best Regards,

Daniel Hellstrom
Software Section Head
Cobham Gaisler
T : +46 (0) 31 775 8657
F : +46 (0) 31 421407
daniel.hellstrom at gaisler.com

Cobham Gaisler AB, Kungsgatan 12, SE-411 19, GÖTEBORG, Sweden.
+46 (0) 31 775 8650, www.cobham.com/gaisler

Please consider the environment before printing this email

This e-mail and any files transmitted with it ("E-mail") is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure,
reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail.

Neither the company nor any subsidiary or affiliate or associated company nor any individual sending this Email accepts any liability in respect of the content (including errors and omissions) nor shall this e-mail be deemed to enter the company or any subsidiary or affiliate or associated company into a contract or to create any legally binding obligations unless expressly agreed to in writing under separate cover and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version from the sender.

On 2017-04-24 13:58, Charles INGELS wrote:
>
> Hi Daniel,
>
> thanks for your answer. The version I use is from the master branch 
> and the checkout has been done the 7th of march. It is definitely not 
> the latest release because I need to freeze one version that I use to 
> compile against the software applications I am currently developing. 
> This is mainly because each time I make an "update", I have to go 
> through a new integration test cycle for each of the software apps, 
> which can become very time consuming, at least for the moment.
>
> However, since that work is on the go, I might in a near future update 
> my RTEMS working copy and then go again into a hopefully final test 
> campaign, before releasing the latest final version of the software apps.
>
> Regards,
>
> Charles
>
>
>
> Le 24.04.2017 à 12:41, Daniel Hellstrom a écrit :
>>
>> 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/dde17153/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/dde17153/attachment-0001.html>