Re: LwIP port using directly RTEMS semaphores and message queues

[ragu nath]

Hi,

lwIP can be built using RTEMS Source builder now. We have  RTEMS +
lwIP OS  glue(cc.h & sys_arch.c etc) . But it uses posix lib functions
instead of RTEMS native library.
https://github.com/ragunath3252/lwip-nodrv . It's tested and  working
but not fully optimized.

https://lists.rtems.org/pipermail/devel/2015-August/012178.html is the RSB patch

lwIP is divided into architecture independent and dependent parts.
Independent part is common to all the BSP's and it can be built for
any BSP through RSB.  The dependent part contains the driver.
Currently only beaglebone black has lwIP driver.

http://ragustechblog.blogspot.in/2015/08/rtems-beaglebone-black-with-lwip.html
has details on how to build and use for beaglebone black.

Thanks,
Ragunath

On Mon, Oct 12, 2015 at 11:14 AM, Sebastian Huber
 wrote:
> On 12/10/15 01:15, Pavel Pisa wrote:
>>
>> As for LwIP and RTEMS integration in general, does exists some
>> idea/implementation how to make LwIP sockets the fist class RTEMS
>> citizens/objects - i.e. to get file descriptor compatible with RTEMS
>> read, write etc. calls same as for native RTEMS stack?
>
>
> An alternative is to integrate the RTEMS support for lwIP in the lwIP
> project.
>
>>
>> I would like to see select() supporting socket objects together
>> with notification from character drivers as well one day
>> to port applications waiting for more event sources in one thread
>> possible. But I think that select() is not compatible with
>> drivers even in RTEMS integrated stack. It it?
>
>
> I have a hack for select() support in drivers and pipe():
>
> https://git.rtems.org/sebh/rtems.git/commit/?id=92a35861d4795075dcff3ebab177812c7422753f
>
> Its not included in the main sources due to a lack of time, testing and I am
> not sure if its really useful.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About cache enabling in LWIP port of BBB in RTEMS

[ragu nath]

Hi Marcos,

I am able to boot now. I am booting from usb. I will build lwip  with
latest RTEMS BSP with cache enabled.
I will also enable cache in lwip options.  I will test it with latest uboot
& let you know.

If there is any trouble, I will share the image with you

Thanks,
Ragunath

On Tue, Sep 22, 2015 at 7:29 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> I will test it now and let you know. I forgot to tell you that i always
> test it booting from the sdcard. I use the script sdcard.sh from Ben Gras.
> Let me know if you need some help.
>
> On Mon, Sep 21, 2015 at 5:44 PM, ragu nath  wrote:
>
>> Hi Marcos,
>>
>> I upgraded the image. I cannot boot the RTEMS image using tftp. Seems
>> there was a bug  in u-boot & fixed later. It propagated to BBB image. I am
>> having troube booting with SD card.  I am working on this.
>>
>> In the mean time, I sent you a cache enabled RTEMS BBB image. This is
>> based on rtems-libbsd. With cache enabled, it is not working. With this
>> image cache is enabled & networking is not working. Just configure a valid
>> ip address & test if it is working on your board.
>>
>> I will try booting from SD card & let you know.
>>
>> Thanks,
>> Ragunath
>>
>>
>>
>> On Fri, Sep 18, 2015 at 9:16 PM, Marcos Díaz <
>> marcos.d...@tallertechnologies.com> wrote:
>>
>>> By the way we flashed the eMMC with the u-boot image. Follow the guide
>>> to know how to do so.
>>>
>>>
>>> On Fri, Sep 18, 2015 at 12:42 PM, Marcos Díaz <
>>> marcos.d...@tallertechnologies.com> wrote:
>>>
>>>> Well, after talking with the guys of beagleboard, they made me update
>>>> the u-boot version.
>>>>
>>>> With that I could make the cache and ethernet work Ok in Rev A5C !!!.
>>>>
>>>> So, Ragu, if you can update your BBB's u-boot, try again using RTEMS
>>>> with LWIP and cache enabled, and test it.
>>>>
>>>> Download it from here:
>>>>
>>>> https://rcn-ee.com/rootfs/bb.org/testing/2015-09-13/console/BBB-eMMC-flasher-debian-8.2-console-armhf-2015-09-13-2gb.img.xz
>>>>
>>>> md5sum: 64de53c03df006f2cb6f95244871313e
>>>>
>>>> decompress the image and save it in the sd card using dd.
>>>>
>>>> And this guide helped me:
>>>>
>>>> http://derekmolloy.ie/write-a-new-image-to-the-beaglebone-black/#Flashing_the_BBB_with_the_SD_Card_Image
>>>>
>>>> Hope it helps! Let me know how the tests go.
>>>>
>>>> Greetings!
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 17, 2015 at 5:53 PM, Marcos Díaz <
>>>> marcos.d...@tallertechnologies.com> wrote:
>>>>
>>>>> I can only tell you about the boards i tested:
>>>>>
>>>>> I have a revision A5C board with an XAM3359AZCZ100 microcontroller.
>>>>> The use of cache together with ethernet makes this break.
>>>>>
>>>>> I have a revision C board with an AM3358BZCZ100. This does work with
>>>>> cache and ethernet.
>>>>>
>>>>> Apparently Ragu has a rev A5 with an AM3358BZCZ100. Cache doesn't
>>>>> work for him.
>>>>>
>>>>> After reading this document:
>>>>>
>>>>>
>>>>> http://elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes
>>>>>
>>>>> I can say that the boards I have match with that descripcion.
>>>>> Revisions A4, A4A, A4B have an AM3352 processor,
>>>>> rev A5A A5B A5C A6 A6A have an XAM3359, and revisions B and C have an
>>>>> AM3358 processor.
>>>>>
>>>>> I'm not very sure about what Ragu has, since there it says he has a
>>>>> rev A5 (not mentioned in the document) but with the processor of the newer
>>>>> revisions (AM3358).
>>>>>
>>>>> In Ragu's case the checking of the registers for the processor
>>>>> revision wont do any help, since he has the same processor that in my case
>>>>> works Ok, but his doesn't.
>>>>>
>>>>> Hope this clarifies.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 17, 2015 at 5:02 PM, Joel Sherrill <
>>>>> joel.sherr...@oarcorp.com> wrote:
>>>>>
>>>>>> Can of of you guys 

Re: About cache enabling in LWIP port of BBB in RTEMS

[ragu nath]

our Board.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz <
>>>>> marcos.d...@tallertechnologies.com >>>> marcos.d...@tallertechnologies.com>> wrote:
>>>>>
>>>>> Yes, sorry about that, There are two registers we can check to see
>>>>> the different revision numbers. I will check it myself once i confirm that
>>>>> the different revisions are the problem (i'm not sure because of what Ragu
>>>>> said). Thanks!
>>>>>
>>>>> On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill <
>>>>> joel.sherr...@oarcorp.com <mailto:joel.sherr...@oarcorp.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>>>>>
>>>>> Yes, in my case the older (that doesn't work) revision is a
>>>>> XAM3359AZCZ100
>>>>>
>>>>> And the rev C (that works well with cache) is
>>>>> AM3358BZCZ100
>>>>>
>>>>>
>>>>> Can we determine that in software?
>>>>>
>>>>> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill <
>>>>> joel.sherr...@oarcorp.com <mailto:joel.sherr...@oarcorp.com> >>>> joel.sherr...@oarcorp.com <mailto:joel.sherr...@oarcorp.com>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>  On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
>>>>> marcos.d...@tallertechnologies.com >>>> marcos.d...@tallertechnologies.com> >>>> marcos.d...@tallertechnologies.com >>>> marcos.d...@tallertechnologies.com>>> wrote:
>>>>>  >Hi,
>>>>>  >
>>>>>  >How did you see the revision number? if you are
>>>>> using u-boot you can
>>>>>  >pause the start and write printenv and enter to see
>>>>> that:
>>>>>  >
>>>>>  >
>>>>>  >board=am335x
>>>>>  >board_name=A335BNLT
>>>>>  >board_rev=00C0
>>>>>  >
>>>>>  >
>>>>>  >This is in my version.
>>>>>  >
>>>>>  >Please tell me so I can check if is the revision, or
>>>>> perhaps is
>>>>>  >something else in u-boot initialization.
>>>>>  >
>>>>>  >
>>>>>  >For the question Joel asked there is a way:
>>>>>  >
>>>>>  >
>>>>> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>>>>>  >
>>>>>  >apparently, in the eeprom thorugh i2c it is
>>>>> recorded. But first we must
>>>>>  >confirm that is a problem from the revisions, since
>>>>> Ragu has the
>>>>>  >problem in a rev C.
>>>>>
>>>>>  Does the SoC itself have a revision number we can
>>>>> read? It may be that newer boards have a newer CPU.
>>>>>
>>>>>   >Greetings
>>>>>   >
>>>>>   >
>>>>>   >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
>>>>>   >>>>> joel.sherr...@oarcorp.com> <mailto:joel.sherr...@oarcorp.com >>>> joel.sherr...@oarcorp.com>>> wrote:
>>>>>   >
>>>>>   >
>>>>>   >
>>>>>   >On 9/16/2015 2:41 PM, ragu nath wrote:
>>>>>   >
>>>>>   >Hi Marcos,
>>>>>   >
>>>>>   >Great news! I did not  find any solution to the
>>>>> issue. I have a REV C
>&g

Re: About cache enabling in LWIP port of BBB in RTEMS

[ragu nath]

Hi Marcos,

The following are the details from by board

###from uboot
board=am335x
board_name=A335BNLT
board_rev=00A5

### reg dump
0x44E10600 2b94402e

0x44E10604 20fd0383

###linux dump
hexdump -e '8/1 "%c"' "/sys/bus/i2c/devices/0-0050/eeprom" -s
0A5

Thanks,
Ragunath



On Fri, Sep 18, 2015 at 12:35 AM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> Ragu,
> I would like you to confirm which revision you have, for this I printed
> the following registers in the BBB:
>
> 0x44E10600 and 0x44E10604
>
> The first will print something like:
> 1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b means rev.A of the
> microcontroller)
> 2b94402e for BBB rev C  (AM3358BZCZ100) (2b means rev B of the
> microcontroller)
>
> The second register will print something like:
>
> 20ff0383 for A5c (this means that this is AM3359)
> 20fd0383 for C (this means it is an AM3358).
>
> Please let me know which are this values in your Board.
>
> Thanks!
>
>
>
> On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz <
> marcos.d...@tallertechnologies.com> wrote:
>
>> Yes, sorry about that, There are two registers we can check to see the
>> different revision numbers. I will check it myself once i confirm that the
>> different revisions are the problem (i'm not sure because of what Ragu
>> said). Thanks!
>>
>> On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill <
>> joel.sherr...@oarcorp.com> wrote:
>>
>>>
>>>
>>> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>>>
>>>> Yes, in my case the older (that doesn't work) revision is a
>>>> XAM3359AZCZ100
>>>>
>>>> And the rev C (that works well with cache) is
>>>> AM3358BZCZ100
>>>>
>>>
>>> Can we determine that in software?
>>>
>>> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill <
>>>> joel.sherr...@oarcorp.com <mailto:joel.sherr...@oarcorp.com>> wrote:
>>>>
>>>>
>>>>
>>>> On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
>>>> marcos.d...@tallertechnologies.com >>> marcos.d...@tallertechnologies.com>> wrote:
>>>> >Hi,
>>>> >
>>>> >How did you see the revision number? if you are using u-boot you
>>>> can
>>>> >pause the start and write printenv and enter to see that:
>>>> >
>>>> >
>>>> >board=am335x
>>>> >board_name=A335BNLT
>>>> >board_rev=00C0
>>>> >
>>>> >
>>>> >This is in my version.
>>>> >
>>>> >Please tell me so I can check if is the revision, or perhaps is
>>>> >something else in u-boot initialization.
>>>> >
>>>> >
>>>> >For the question Joel asked there is a way:
>>>> >
>>>> >
>>>> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>>>> >
>>>> >apparently, in the eeprom thorugh i2c it is recorded. But first we
>>>> must
>>>> >confirm that is a problem from the revisions, since Ragu has the
>>>> >problem in a rev C.
>>>>
>>>> Does the SoC itself have a revision number we can read? It may be
>>>> that newer boards have a newer CPU.
>>>>
>>>>  >Greetings
>>>>  >
>>>>  >
>>>>  >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
>>>>  >mailto:joel.sherr...@oarcorp.com>>
>>>> wrote:
>>>>  >
>>>>  >
>>>>  >
>>>>  >On 9/16/2015 2:41 PM, ragu nath wrote:
>>>>  >
>>>>  >Hi Marcos,
>>>>  >
>>>>  >Great news! I did not  find any solution to the issue. I have a
>>>> REV C
>>>>  >board from element14. Is this the same board you are using?  In my
>>>>  >board I saw the issue.
>>>>  >
>>>>  >Does this have anything to do with the patch you submitted [PATCH]
>>>>  >Beaglebone: fix missing clobber in inline assembly.
>>>>  >
>>>> https://lists.rtems.org/pipermail/devel/2015-September/012531.html
>>>>  >I have not yet tested with this patch.
>>>>  >
&

Re: About cache enabling in LWIP port of BBB in RTEMS

[ragu nath]

Hi Marcos,

Great news! I did not  find any solution to the issue. I have a REV C board
from element14. Is this the same board you are using?  In my board I saw
the issue.

Does this have anything to do with the patch you submitted [PATCH]
Beaglebone: fix missing clobber in inline assembly.
https://lists.rtems.org/pipermail/devel/2015-September/012531.html
I have not yet tested with this patch.

The freebsd driver is working with cache disabled.  If possible pls check
if it is working with cache enabled in your board.


Thanks,
Ragunath


On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> Hi Ragu,
> I wanted to know if you were able to see something else about the problem
> we had in the BBB when using LWIP and enabling cache ( the program freezes).
> I can tell you that here we were using BBB rev. A5C and had this problem,
> but now we could test this with a BBB Rev C, and it successfully works with
> cache enabled (using the same sdcard in both boards, one works and the
> other doesn't).
> Greetings
>
> --
>
> __
>
> 
>
>
> Marcos Díaz
>
> Software Engineer
>
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
>
> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype: markdiaz22
>
>


-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd - USB Host Stack for HID, WirelessLAN

[ragu nath]

Hi Thomas,

There is no need to manually edit the makefile. You can add whatever
files you need from freebsd to libbsd.py file.
I can see, there is already a dev_usb_input module. It is currently
disabled. You can just enable it & add additional files to it if you
need.

Then you run the freebsd-to-rtems.py which will make makefile &
wscript modifications. I was advised to use this method instead of
manually modifying the makefile.

"python freebsd-to-rtems.py -m" command will make the changes.

I am not sure how to get source files from freebsd using the scripts.
What I did was, I copied the necessary files to rtems-libbsd/freebsd
directory. Then I added those files to libbsd.py & ran
freebsd-to-rtems.py. Now you have the source files & makefile changes.
Now you can compile & start your porting work. As mentioned by yurii,
you can see my blog post on
http://ragustechblog.blogspot.in/2015/06/porting-driver-from-freebsd-to-rtems.html
which has some useful details

Note: If I run the freebsd-to-rtems.py script it is copying all the
files from freebsd to rtems. I could not import specific file/files.


Thanks,
Ragunath


>
> Message: 1
> Date: Wed, 26 Aug 2015 15:55:29 +0900
> From: Thomas Kim 
> To: Yurii Shevtsov 
> Cc: "devel@rtems.org" 
> Subject: Re: libbsd - USB Host Stack for HID, WirelessLAN
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Dear Yurii,
>
> Thank you for your kindly reply.
>
> At this time, I built lastest libbsd successfully.
> Also, I am tring to add USB input files in freebsd\sys\dev\usb\input.
>
> Question 1)
> As I guess, I think that I should modify Makefile, wscript file. also, I
> should modify USB input files(atp.c, uep.c, uhid.c, uknd.c, ums.c, etc)
> according to "Rules for Modifing FreeBSD source".
> Is it correct ?
>
> Question 2)
> As I test freebsd-to-rtems.py, it just move the ported FreeBSD code only
> from FreeBSD 9.2 original code to libbsd Freebsd. that is,
> freebsd-to-rtems.py is not used for changing additional new files from
> FreeBSD 9.2 original code automatically.
> Is it correct ?
>
> Question 3)
> As I check libbsd.py file, there is below definitions.
>   - def dev_usb_input(mm):
>   - def dev_usb_mouse(mm):
>
> Is there how to use libbsd.py for adding new files(source, header files)
> easily ?
> Or, I want to know that libbsd.py file is used for which purpose.
>
> Best Regards,
> Thomas
>
> 2015-08-25 19:19 GMT+09:00 Yurii Shevtsov :
>
>>
>>
>> 2015-08-25 12:10 GMT+03:00 Thomas Kim :
>>
>>> Dear Yurii,
>>>
>>> Thank you very much.
>>>
>>> I want to review freeBSD source code.
>>>
>>> Please let me know where is libbsd's README file. there is not README
>>> file in current tree (https://git.rtems.org/rtems-libbsd/tree/).
>>> I want to check "Rules for Modiying FreeBSD source" in REAME file.
>>>
>> https://github.com/RTEMS/rtems-libbsd/blob/master/libbsd.txt
>>
>>>
>>> Also, I want to compare FreeBSD original code and the modified FreeBSD
>>> code.
>>> I guess that FreeBSD original code version is 8.x.
>>>
>> it's actually 9.2 (from the readme)
>>
>>>
>>> Please let me know how to get FreeBSD original code version which was
>>> used for libbsd porting work.
>>>
>> https://svnweb.freebsd.org/base/release/9.2.0/ It's Subversion
>> https://www.freebsd.org/doc/handbook/svn.html
>>
>>>
>>> Best Regards,
>>> Thomas.
>>>
>>> 2015-08-21 23:57 GMT+09:00 Yurii Shevtsov :
>>>
 Hi)

 For porting guide check this blogpost

 http://ragustechblog.blogspot.in/2015/06/porting-driver-from-freebsd-to-rtems.html
 Also read libbsd's README, especially "Rules for Modifying FreeBSD
 Source"

 Can't say anything specific about USB HID and WLAN. Definitely WLAN will
 require porting libraries with auth protocols (WPA\WEP). About HID, you can
 try searching how input works in RTEMS. Maybe you can implement API in your
 future HID driver



>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

lwIP with RTEMS BBB

[ragu nath]

Hi All,

I have written a blog explaining how to use lwIP with RTEMS. The BSP
supported is BeagleBone Black(BBB).  It basically has four steps

1. Build BBB BSP with cache disabled.
2. Build lwIP library. We can build it using RSB
3. Build driver library using RSB
4. Build the application

All the steps are explained with details in the blog.
http://ragustechblog.blogspot.in/2015/08/rtems-beaglebone-black-with-lwip.html

Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: devel Digest, Vol 45, Issue 25

[ragu nath]

Hi Yurii,

For RPi USB support, can you pls try including
"default-network-init.h" in the application (I tested with netshell01)
instead of "default-init.h" and see if it works.

If we use default-init.h, nexus.content is empty and device is not probed.

Thanks,
Ragunath

On Mon, Aug 10, 2015 at 7:15 AM,   wrote:
> Send devel mailing list submissions to
> devel@rtems.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rtems.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-requ...@rtems.org
>
> You can reach the person managing the list at
> devel-ow...@rtems.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
>
> Today's Topics:
>
>1. Re: GSoC 2015 RPi USB Support (Gedare Bloom)
>2. Re: GSoC 2015 RPi USB Support (Gedare Bloom)
>
>
> --
>
> Message: 1
> Date: Sun, 9 Aug 2015 19:09:53 -0400
> From: Gedare Bloom 
> To: Yurii Shevtsov 
> Cc: "devel@rtems.org" 
> Subject: Re: GSoC 2015 RPi USB Support
> Message-ID:
> 
> Content-Type: text/plain; charset=UTF-8
>
> There isn't much action here on Fridays or Weekends normally. Have you
> gotten around to writing up your blog post describing the various
> steps you have tried? It's a little hard to help you to debug without
> understanding the full scope of what you have been trying to do.
>
> Gedare
>
> On Sun, Aug 9, 2015 at 12:36 PM, Yurii Shevtsov  wrote:
>> Ping! Any news?
>>
>> 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov :
>>> These macroses are placed here
>>> https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h
>>> And of course I added proper lines to specific testsuites, like
>>> init01. And IRC, without this macro driver just won't be linked
>>>
>>> 2015-08-07 0:34 GMT+03:00 Joel Sherrill :


 On 8/6/2015 4:29 PM, Yurii Shevtsov wrote:
>
> Isn't this line enough?
> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)


 I was looking in nexus-devices.h since that is BSP specific.
 I wasn't expecting a generic macro.

 But where is that referenced? That is a macro that somewhere
 should be referencing so it is expanded.

 I would expect to see

 SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)

 below the nexus definition in nexus-devices.h.

 Anyway, it is never being expanded so that definition has no impact.

 Whether it will work and find the right bus, is another issue
 but it isn't putting code in for sure. :)

 I have the pc386 to the point where it the RTEMS nexus device
 is trying to find em on the legacy bus but it is configured
 as being on pci. Need to run down that or trick it to work.
 But the probe is working.

 --joel



> 2015-08-07 0:23 GMT+03:00 Joel Sherrill :
>>
>>
>>
>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
>>>
>>>
>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill :




 On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov 
 wrote:
>
>
> What do you mean by "getting pulled"?




 As I understood things, you had a linked executable but an empty
 section.
 Just curious if your devices were showing up at all.
>>>
>>>
>>>
>>> Yes, exactly. If you mean is probe function being executed, the answer
>>> is
>>> ''no"
>>
>>
>>
>> You have to associate the drivers with a nexus bus.  Something like this
>>
>> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc);
>> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc);
>>
>> That's from the Altera Cyclone.
>>
>> You only configured a nexus device and didn't hang anything off it.
>>
>>
> 2015-08-06 23:48 GMT+03:00 Joel Sherrill :
>>
>>
>>
>>
>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
>>>
>>>
>>>
>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill
>
>
> :





 On 8/6/2015 3:22 PM, Yurii Shevtsov wrote:
>
>
>
>
> Ping! Any news?





 The people with experience with the libbsd code is quite small. :(

>
> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov :
>>
>>
>>
>>
>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in
>> final elf. If I change driver's name in
>
>
> RTEMS_BSD_DEFINE_NEXUS_DEVICE

Re: RTEMS lwIP porting

[ragu nath]

Hi Daniel,

Most of the  work comes from  your/marcos port.  The aim was to
integrate a working lwIP port to RTEMS Source Builder.
I took the port & understood what has been done. Then I wrote  an
application that uses lwip stack on RTEMS.
I ran into some issues and fixed them. Now with the changes,  the
application works.

I discussed with chris on how to integrate the changes to RSB. As per
his suggestion, the idea is to separate lwip base and drivers. The
lwip base is compiled as a library using RSB and driver will be
compiled as a separate library .  The application can then link to it.
The driver is also from your port with some fixes.

I am not aware of the issue with POSIX API. Once we get this working,
I am ready to implement with native api in the future.


Thanks,
Ragunath


On Mon, Aug 10, 2015 at 9:50 PM, Daniel Gutson
 wrote:
> On Mon, Aug 10, 2015 at 10:48 AM, Joel Sherrill
>  wrote:
>>
>>
>> On 8/9/2015 4:57 AM, ragu nath wrote:
>>>
>>> Hi All,
>>>
>>> I have sent the patches for building lwIP from RSB.  First patch
>>> contains changes for RTEMS Resource Builder. The second patch is RTEMS
>>> specific changes that will be applied to lwIP base.This patch contains
>>> only lwIP sources. I will be sending another patch for the driver to
>>> be used with lwIP. The application can then link to both of the
>>> libararies (lwip & driver).
>>>
>>
>> Has the LWIP patch been submitted upstream to the LWIP maintainers?
>>
>> And where do drivers come from? From what I have seen, LWIP seems
>> to not have a unified base of device drivers. Would this just be to
>> build the basic stack and then it is the users responsibility to
>> find and compile a driver?
>
> Also, what from these comes from our work? Sorry that I'm a little bit
> confused and arrived late to the
> subject. BTW, there is still work to do, since the state we left
> working LWIP is using the posix layer,
> which we observed introduces important overhead, so a further step is
> to reimplement the LWIP's HAL
> using the RTEMS native API instead. Any plan for that?
>
> Thanks!
>
> Daniel.
>
>>
>> What is your RTEMS configuration so I can try it?
>>
>> I will try to build it today.
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
>
> Daniel F. Gutson
> Chief Engineering Officer, SPD
>
> San Lorenzo 47, 3rd Floor, Office 5
> Córdoba, Argentina
>
> Phone:   +54 351 4217888 / +54 351 4218211
> Skype:dgutson
> LinkedIn: http://ar.linkedin.com/in/danielgutson



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS lwIP porting

[ragu nath]

Hi All,

I have sent the patches for building lwIP from RSB.  First patch
contains changes for RTEMS Resource Builder. The second patch is RTEMS
specific changes that will be applied to lwIP base.This patch contains
only lwIP sources. I will be sending another patch for the driver to
be used with lwIP. The application can then link to both of the
libararies (lwip & driver).

-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Temporary fix for ethernet rx intr hang issue and Disable cache

[ragu nath]

Hi Sebastian,

If we want to use cache flush/invalidate calls, what is the general
method one has to follow?
I saw the if_cgem driver, but it is somewhat different from cpsw
driver. What are all the places which may need these calls?

Thanks,
Ragunath

On Fri, Jul 10, 2015 at 4:29 AM, ragu nath  wrote:
> Hi Sebastian,
>
> I read about rtems_cache_coherent_allocate(). I understand first we
> need to add an area to use this.
> I added rtems_cache_coherent_add_area(bsp_nocache_heap_begin,(uintptr_t)
> bsp_nocache_heap_size); in bsp start.
> Is that right? I do not know how bsp_nocache_heap_begin &
> bsp_nocache_heap_size are defined. How to define/check correct vaules
> for them?
>
> Can you pls explain how to use rtems_cache_coherent_allocate? I am not
> sure which memory needs to be allocated with this.
> Do we need to make the mbufs part of this memory?
>
>
> Thanks,
> Ragunath
>
>
> On Mon, Jun 29, 2015 at 12:49 PM, Sebastian Huber
>  wrote:
>>
>>
>> On 25/06/15 18:20, ragunath wrote:
>>>
>>> This patch has two changes that are needed for networking to work in BBB.
>>> We disable cache as it is causing random values to be learned in the cpsw
>>> Address
>>> Lookup Engine(ALE) causing tx to fail. Vector enable is done after handler
>>> is called by the server task.
>>>
>>> ---
>>>   c/src/lib/libbsp/arm/beagle/irq.c | 2 ++
>>>   c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c | 8 +---
>>>   2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c
>>> b/c/src/lib/libbsp/arm/beagle/irq.c
>>> index c6485cd..64e7756 100644
>>> --- a/c/src/lib/libbsp/arm/beagle/irq.c
>>> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
>>> @@ -73,6 +73,7 @@ void bsp_interrupt_dispatch(void)
>>> _ARMV4_Status_restore(psr);
>>>   +if(!(irq == 40 || irq == 41 || irq == 42 || irq == 43))
>>>   bsp_interrupt_vector_enable(irq);
>>> }
>>>   }
>>
>>
>> Why not remove the bsp_interrupt_vector_disable/enable() calls in
>> bsp_interrupt_dispatch() unconditionally?
>>
>>
>>> @@ -94,6 +95,7 @@ rtems_status_code
>>> bsp_interrupt_vector_enable(rtems_vector_number vector)
>>> uint32_t mask, cur;
>>> uint32_t mir_reg = get_mir_reg(vector, &mask);
>>>   +  irqs_enabled[vector] = 1;
>>> cur = mmio_read(omap_intr.base + mir_reg);
>>> mmio_write(omap_intr.base + mir_reg, cur & ~mask);
>>> flush_data_cache();
>>> diff --git a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>>> b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>>> index 157edfa..6cd0f38 100644
>>> --- a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>>> +++ b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>>> @@ -44,15 +44,17 @@ BSP_START_TEXT_SECTION void
>>> beagle_setup_mmu_and_cache(void)
>>>   {
>>> /* turn mmu off first in case it's on */
>>> uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
>>> -ARM_CP15_CTRL_M | ARM_CP15_CTRL_A, /* clear - mmu off */
>>> +ARM_CP15_CTRL_M | ARM_CP15_CTRL_A | ARM_CP15_CTRL_I |
>>> ARM_CP15_CTRL_C, /* clear - mmu off */
>>>   ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
>>> );
>>>   -  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
>>> -ctrl,
>>> +  arm_cp15_start_setup_translation_table(
>>>   (uint32_t *) bsp_translation_table_base,
>>>   ARM_MMU_DEFAULT_CLIENT_DOMAIN,
>>>   &beagle_mmu_config_table[0],
>>>   RTEMS_ARRAY_SIZE(beagle_mmu_config_table)
>>> );
>>> +
>>> +  ctrl |= ARM_CP15_CTRL_M;
>>> +  arm_cp15_set_control(ctrl);
>>>   }
>>
>>
>> I would rather fix the driver. Add cache flush/invalidate calls to the right
>> spots or use a non-cacheable memory area, see
>> rtems_cache_coherent_allocate() for example.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
>
>
> --
> ragu



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Temporary fix for ethernet rx intr hang issue and Disable cache

[ragu nath]

Hi Sebastian,

I read about rtems_cache_coherent_allocate(). I understand first we
need to add an area to use this.
I added rtems_cache_coherent_add_area(bsp_nocache_heap_begin,(uintptr_t)
bsp_nocache_heap_size); in bsp start.
Is that right? I do not know how bsp_nocache_heap_begin &
bsp_nocache_heap_size are defined. How to define/check correct vaules
for them?

Can you pls explain how to use rtems_cache_coherent_allocate? I am not
sure which memory needs to be allocated with this.
Do we need to make the mbufs part of this memory?


Thanks,
Ragunath


On Mon, Jun 29, 2015 at 12:49 PM, Sebastian Huber
 wrote:
>
>
> On 25/06/15 18:20, ragunath wrote:
>>
>> This patch has two changes that are needed for networking to work in BBB.
>> We disable cache as it is causing random values to be learned in the cpsw
>> Address
>> Lookup Engine(ALE) causing tx to fail. Vector enable is done after handler
>> is called by the server task.
>>
>> ---
>>   c/src/lib/libbsp/arm/beagle/irq.c | 2 ++
>>   c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c | 8 +---
>>   2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c
>> b/c/src/lib/libbsp/arm/beagle/irq.c
>> index c6485cd..64e7756 100644
>> --- a/c/src/lib/libbsp/arm/beagle/irq.c
>> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
>> @@ -73,6 +73,7 @@ void bsp_interrupt_dispatch(void)
>> _ARMV4_Status_restore(psr);
>>   +if(!(irq == 40 || irq == 41 || irq == 42 || irq == 43))
>>   bsp_interrupt_vector_enable(irq);
>> }
>>   }
>
>
> Why not remove the bsp_interrupt_vector_disable/enable() calls in
> bsp_interrupt_dispatch() unconditionally?
>
>
>> @@ -94,6 +95,7 @@ rtems_status_code
>> bsp_interrupt_vector_enable(rtems_vector_number vector)
>> uint32_t mask, cur;
>> uint32_t mir_reg = get_mir_reg(vector, &mask);
>>   +  irqs_enabled[vector] = 1;
>> cur = mmio_read(omap_intr.base + mir_reg);
>> mmio_write(omap_intr.base + mir_reg, cur & ~mask);
>> flush_data_cache();
>> diff --git a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> index 157edfa..6cd0f38 100644
>> --- a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> +++ b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> @@ -44,15 +44,17 @@ BSP_START_TEXT_SECTION void
>> beagle_setup_mmu_and_cache(void)
>>   {
>> /* turn mmu off first in case it's on */
>> uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
>> -ARM_CP15_CTRL_M | ARM_CP15_CTRL_A, /* clear - mmu off */
>> +ARM_CP15_CTRL_M | ARM_CP15_CTRL_A | ARM_CP15_CTRL_I |
>> ARM_CP15_CTRL_C, /* clear - mmu off */
>>   ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
>> );
>>   -  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
>> -ctrl,
>> +  arm_cp15_start_setup_translation_table(
>>   (uint32_t *) bsp_translation_table_base,
>>   ARM_MMU_DEFAULT_CLIENT_DOMAIN,
>>   &beagle_mmu_config_table[0],
>>   RTEMS_ARRAY_SIZE(beagle_mmu_config_table)
>> );
>> +
>> +  ctrl |= ARM_CP15_CTRL_M;
>> +  arm_cp15_set_control(ctrl);
>>   }
>
>
> I would rather fix the driver. Add cache flush/invalidate calls to the right
> spots or use a non-cacheable memory area, see
> rtems_cache_coherent_allocate() for example.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cache issue with BBB networking

[ragu nath]

Hi Marcos,

As far as I know, cache is enabled in Freebsd.

Thanks,
Ragunath

On Tue, Jun 30, 2015 at 7:14 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> I have a question about this, the frebsd driver, was prepared to be used
> with cache enabled?
> I mean, in freeBSD OS the cache is enabled?
>
> On Tue, Jun 30, 2015 at 12:46 AM, Daniel Gutson <
> daniel.gut...@tallertechnologies.com> wrote:
>
>> Ragu,
>>
>>Please ensure that you are getting cache coherence right. That is,
>> there are no packets crossing the cache lines.
>> FWIW, in a life ago, i got a problem with an eth driver where the
>> descriptors ring was not properly sized (ie no modulus cache line).
>> El 29/6/2015 17:23, "ragu nath"  escribió:
>>
>>> Thanks Marcos. I will let you know if there is any progress.
>>>
>>> Regards,
>>> Ragunath
>>>
>>> On Tue, Jun 30, 2015 at 12:50 AM, Marcos Díaz <
>>> marcos.d...@tallertechnologies.com> wrote:
>>>
>>>> Hi,
>>>> I'm sorry but in the development of the porting of LWIP i couldn't give
>>>> any more time to the task, so when I reached that stage I just disabled the
>>>> cache.
>>>> I will try to give some time to that to see if i can help you, and of
>>>> course, let me know if you find something.
>>>> Sorry again
>>>>
>>>> On Mon, Jun 29, 2015 at 3:16 PM, ragu nath 
>>>> wrote:
>>>>
>>>>> Hi Marcos,
>>>>>
>>>>> I am working on porting ethernet driver for Beaglebone black from
>>>>> FreeBSD to rtems-libbsd as part of GSOC 2015. I ported the driver and
>>>>> got it working.
>>>>>
>>>>> But there was one issue I faced, similar to the one you mentioned in
>>>>> our earlier correspondence (regarding lwIP). You mentioned that the
>>>>> system crashes if cache is enabled.
>>>>>
>>>>> In my case, the Address Lookup Engine (ALE) is getting corrupted if
>>>>> cache is enabled. Because of this packet transmission failed sending
>>>>> out random junk packets. With cache disabled, networking is working.
>>>>>
>>>>> I am looking for options other than disabling cache as a whole. Is
>>>>> there any other option available?  Can you share the details of any of
>>>>> the things you tried and found not working?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Ragunath
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> __
>>>>
>>>> <http://www.tallertechnologies.com>
>>>>
>>>>
>>>> Marcos Díaz
>>>>
>>>> Software Engineer
>>>>
>>>>
>>>> San Lorenzo 47, 3rd Floor, Office 5
>>>>
>>>> Córdoba, Argentina
>>>>
>>>>
>>>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>>>
>>>> Skype: markdiaz22
>>>>
>>>>
>>>
>>>
>>> --
>>> ragu
>>>
>>
>
>
> --
>
> __
>
> <http://www.tallertechnologies.com>
>
>
> Marcos Díaz
>
> Software Engineer
>
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
>
> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype: markdiaz22
>
>


-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Temporary fix for ethernet rx intr hang issue and Disable cache

[ragu nath]

Hi Sebatian,

I will try both your suggestions and let you know on the progress.

Thanks,
Ragunath

On Mon, Jun 29, 2015 at 12:49 PM, Sebastian Huber
 wrote:
>
>
> On 25/06/15 18:20, ragunath wrote:
>>
>> This patch has two changes that are needed for networking to work in BBB.
>> We disable cache as it is causing random values to be learned in the cpsw
>> Address
>> Lookup Engine(ALE) causing tx to fail. Vector enable is done after handler
>> is called by the server task.
>>
>> ---
>>   c/src/lib/libbsp/arm/beagle/irq.c | 2 ++
>>   c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c | 8 +---
>>   2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c
>> b/c/src/lib/libbsp/arm/beagle/irq.c
>> index c6485cd..64e7756 100644
>> --- a/c/src/lib/libbsp/arm/beagle/irq.c
>> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
>> @@ -73,6 +73,7 @@ void bsp_interrupt_dispatch(void)
>> _ARMV4_Status_restore(psr);
>>   +if(!(irq == 40 || irq == 41 || irq == 42 || irq == 43))
>>   bsp_interrupt_vector_enable(irq);
>> }
>>   }
>
>
> Why not remove the bsp_interrupt_vector_disable/enable() calls in
> bsp_interrupt_dispatch() unconditionally?
>
>
>> @@ -94,6 +95,7 @@ rtems_status_code
>> bsp_interrupt_vector_enable(rtems_vector_number vector)
>> uint32_t mask, cur;
>> uint32_t mir_reg = get_mir_reg(vector, &mask);
>>   +  irqs_enabled[vector] = 1;
>> cur = mmio_read(omap_intr.base + mir_reg);
>> mmio_write(omap_intr.base + mir_reg, cur & ~mask);
>> flush_data_cache();
>> diff --git a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> index 157edfa..6cd0f38 100644
>> --- a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> +++ b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
>> @@ -44,15 +44,17 @@ BSP_START_TEXT_SECTION void
>> beagle_setup_mmu_and_cache(void)
>>   {
>> /* turn mmu off first in case it's on */
>> uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
>> -ARM_CP15_CTRL_M | ARM_CP15_CTRL_A, /* clear - mmu off */
>> +ARM_CP15_CTRL_M | ARM_CP15_CTRL_A | ARM_CP15_CTRL_I |
>> ARM_CP15_CTRL_C, /* clear - mmu off */
>>   ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
>> );
>>   -  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
>> -ctrl,
>> +  arm_cp15_start_setup_translation_table(
>>   (uint32_t *) bsp_translation_table_base,
>>   ARM_MMU_DEFAULT_CLIENT_DOMAIN,
>>   &beagle_mmu_config_table[0],
>>   RTEMS_ARRAY_SIZE(beagle_mmu_config_table)
>> );
>> +
>> +  ctrl |= ARM_CP15_CTRL_M;
>> +  arm_cp15_set_control(ctrl);
>>   }
>
>
> I would rather fix the driver. Add cache flush/invalidate calls to the right
> spots or use a non-cacheable memory area, see
> rtems_cache_coherent_allocate() for example.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cache issue with BBB networking

[ragu nath]

Thanks Marcos. I will let you know if there is any progress.

Regards,
Ragunath

On Tue, Jun 30, 2015 at 12:50 AM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> Hi,
> I'm sorry but in the development of the porting of LWIP i couldn't give
> any more time to the task, so when I reached that stage I just disabled the
> cache.
> I will try to give some time to that to see if i can help you, and of
> course, let me know if you find something.
> Sorry again
>
> On Mon, Jun 29, 2015 at 3:16 PM, ragu nath  wrote:
>
>> Hi Marcos,
>>
>> I am working on porting ethernet driver for Beaglebone black from
>> FreeBSD to rtems-libbsd as part of GSOC 2015. I ported the driver and
>> got it working.
>>
>> But there was one issue I faced, similar to the one you mentioned in
>> our earlier correspondence (regarding lwIP). You mentioned that the
>> system crashes if cache is enabled.
>>
>> In my case, the Address Lookup Engine (ALE) is getting corrupted if
>> cache is enabled. Because of this packet transmission failed sending
>> out random junk packets. With cache disabled, networking is working.
>>
>> I am looking for options other than disabling cache as a whole. Is
>> there any other option available?  Can you share the details of any of
>> the things you tried and found not working?
>>
>>
>> Thanks,
>> Ragunath
>>
>
>
>
> --
>
> __
>
> <http://www.tallertechnologies.com>
>
>
> Marcos Díaz
>
> Software Engineer
>
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
>
> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype: markdiaz22
>
>


-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Cache issue with BBB networking

[ragu nath]

Hi Marcos,

I am working on porting ethernet driver for Beaglebone black from
FreeBSD to rtems-libbsd as part of GSOC 2015. I ported the driver and
got it working.

But there was one issue I faced, similar to the one you mentioned in
our earlier correspondence (regarding lwIP). You mentioned that the
system crashes if cache is enabled.

In my case, the Address Lookup Engine (ALE) is getting corrupted if
cache is enabled. Because of this packet transmission failed sending
out random junk packets. With cache disabled, networking is working.

I am looking for options other than disabling cache as a whole. Is
there any other option available?  Can you share the details of any of
the things you tried and found not working?


Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Ethernet driver For BBB ported from FreeBSD

[ragu nath]

Hi Gedare,

I will send them separately.

Thanks,
Ragunath



On Thu, Jun 25, 2015 at 10:29 PM, Gedare Bloom  wrote:
> Can you split the commits so that the import from BSD is separate from
> your modifications to it?
>
> On Thu, Jun 25, 2015 at 12:18 PM, ragunath  wrote:
>> This patch includes changes for porting cpsw ethernet driver for Beaglebone 
>> black from Freebsd.
>> It also includes smsc phy ported from FreeBSD. Corresponding nexus devices 
>> are added.
>> For networking to work properly, two additional changes are needed on the 
>> RTEMS side.
>>
>> ---
>>  Makefile   |3 +
>>  freebsd/sys/arm/ti/cpsw/if_cpsw.c  | 2239 
>> 
>>  freebsd/sys/arm/ti/cpsw/if_cpswreg.h   |  137 ++
>>  freebsd/sys/arm/ti/cpsw/if_cpswvar.h   |  126 ++
>>  freebsd/sys/dev/mii/smscphy.c  |  227 ++
>>  rtemsbsd/include/bsp/nexus-devices.h   |   34 +
>>  rtemsbsd/include/machine/rtems-bsd-cache.h |2 +-
>>  .../include/rtems/bsd/test/network-config.h.in |2 +
>>  8 files changed, 2769 insertions(+), 1 deletion(-)
>>  create mode 100644 freebsd/sys/arm/ti/cpsw/if_cpsw.c
>>  create mode 100644 freebsd/sys/arm/ti/cpsw/if_cpswreg.h
>>  create mode 100644 freebsd/sys/arm/ti/cpsw/if_cpswvar.h
>>  create mode 100644 freebsd/sys/dev/mii/smscphy.c
>>
>> diff --git a/Makefile b/Makefile
>> index f747106..e215a07 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -26,6 +26,7 @@ COMMON_FLAGS += -Ifreebsd/contrib/tcpdump
>>  COMMON_FLAGS += -Ifreebsd/lib/libmemstat
>>  COMMON_FLAGS += -Ifreebsd/lib/libipsec
>>  COMMON_FLAGS += -Irtemsbsd/sys
>> +COMMON_FLAGS += -Irtemsbsd/include/rtems/bsd/local
>>  COMMON_FLAGS += -ImDNSResponder/mDNSCore
>>  COMMON_FLAGS += -ImDNSResponder/mDNSShared
>>  COMMON_FLAGS += -ImDNSResponder/mDNSPosix
>> @@ -185,10 +186,12 @@ LIB_C_FILES += freebsd/sys/dev/mii/brgphy.c
>>  LIB_C_FILES += freebsd/sys/dev/mii/micphy.c
>>  LIB_C_FILES += freebsd/sys/dev/mii/ukphy.c
>>  LIB_C_FILES += freebsd/sys/dev/mii/ukphy_subr.c
>> +LIB_C_FILES += freebsd/sys/dev/mii/smscphy.c
>>  LIB_C_FILES += freebsd/sys/dev/tsec/if_tsec.c
>>  LIB_C_FILES += freebsd/sys/dev/cadence/if_cgem.c
>>  LIB_C_FILES += freebsd/sys/dev/dwc/if_dwc.c
>>  LIB_C_FILES += freebsd/sys/arm/xilinx/zy7_slcr.c
>> +LIB_C_FILES += freebsd/sys/arm/ti/cpsw/if_cpsw.c
>>  LIB_C_FILES += freebsd/sys/dev/random/harvest.c
>>  LIB_C_FILES += freebsd/sys/netinet/tcp_hostcache.c
>>  LIB_C_FILES += freebsd/sys/dev/led/led.c
>> diff --git a/freebsd/sys/arm/ti/cpsw/if_cpsw.c 
>> b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
>> new file mode 100644
>> index 000..0eb73ee
>> --- /dev/null
>> +++ b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
>> @@ -0,0 +1,2239 @@
>> +#include 
>> +/*-
>> + * Copyright (c) 2012 Damjan Marion 
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
>> PURPOSE
>> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>> + * SUCH DAMAGE.
>> + */
>> +
>> +/*
>> + * TI Common Platform Ethernet Switch (CPSW) Driver
>> + * Found in TI8148 "DaVinci" and AM335x "Sitara" SoCs.
>> + *
>> + * This controller is documented in the AM335x Technical Reference
>> + * Manual, in the TMS320DM814x DaVinci Digital Video Processors TRM
>> + * and in the TMS320C6452 3 Port Switch Ethernet Subsystem TRM.
>> + *
>> + * It is basically a single Ethernet port (port 0) wired internally to
>> + * a 3-port store-and-forward switch connected to two independent
>> + * "sliver" controllers (port 1 and port 2).  You can operate the
>> + * controller in a variety of different ways by suitably configuring
>> + * the slivers and the Address Lookup Engine (ALE) that routes packets
>> + * between the port

rtems-libbsd sample testsuite explanation

[ragu nath]

Hi All,

I am porting ethernet driver for Beaglebone black from FreeBSD. I
would like to know how to execute the following test cases.  I would
like to know how to execute the test? what is the expected result?
any setup that needs to be done etc.

1. arphole
2. foobarclient
3. foobarserver
4. media01


Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Porting ethernet driver from FREEBSD to rtems-libbsd

[ragu nath]

Hi Sebastian,

The problem is with rx interrupt. We are enabling rx interrupt before
it is processed. The rtems server task do not get an opportunity to
run.

I found this might be the logical explanation of the issue.
bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
disables the rx interrupt and creates BSP_INTERRUPT_EVENT .  For this
event, bsp_interrupt_server_task() was supposed to call the actual
interrupt handler and then enable the rx interrupt. But before the
event is processed, we enable the rx interrupt in dispatch function.
So again rx interrupt is generated and event is created and the cycle
goes on. Server task is never executed in turn actual interrupt
handler is never executed.

Since we enable the interrupt, it occurs again and again as we never handle it.

Is there any other possibility that I might need to look into?


Thanks,
Ragunath

On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
 wrote:
> Hello,
>
> the bsp_interrupt_dispatch() is quite complicated in the beagle BSP. Is the
> interrupt controller of this chip really that broken? Sane interrupt
> controllers block interrupts of equal or lower priority relative to the
> currently pending interrupt.
>
>
> On 28/05/15 13:14, ragu nath wrote:
>>
>> Hi Ben,
>>
>> I  found the reason for system hang in BBB after link goes up. It is
>> caused by enabling the interrupt before it is  processed creating a
>> continuous flow of interrupts hogging the CPU.
>>
>> In rtems-libbsd we do not directly call the interrupt handler. we
>> create an event through interrupt trigger routine and then the server
>> task detects the event and calls the actual intr handler.  While
>> registering the interrupt, we will give this trigger routine as
>> handler. Server task separately calls the actual intr handler.
>>
>> In BBB irq processing (bsp_interrupt_dispatch function), we disable
>> the vector and  call the handler and enable it.
>> For network interrupt intr, this handler will be interrupt trigger
>> routine which creates an event. After this intr is enabled but the
>> interrupt was not processed. The intr was supposed to be enabled by
>> the server task after processing the interrupt. This causes the hang.
>>
>> The irq dispatch function assumes that we are calling the actual intr
>> handler and enables the interrupt. But since we are processing the
>> interrupt in a separate server task, it needs to be enabled there not
>> in the dispatch function.
>>
>> As a temp fix, I selectively disabled bsp_interrupt_vector_enable in
>> dispatch function. There is no hang and packets are received.
>>
>> What can be the correct fix for the issue as there are other
>> interrupts that are not  processed in this way?
>>
>> Thanks,
>> Ragunath
>>
>> On Fri, May 15, 2015 at 12:39 PM, ragu nath 
>> wrote:
>>>
>>> Thank you. I will check the git log. I am also inclined to using nexus
>>> support. I already compiled the driver using nexus support. I fully
>>> intend to add more documentation to the project. I will keep posting
>>> on this thread if I have any further issues.
>>>
>>> Thanks,
>>> Ragunath
>>>
>>>
>>> On Fri, May 15, 2015 at 12:05 PM, Sebastian Huber
>>>  wrote:
>>>>
>>>> You have two options.
>>>>
>>>> 1. You port simplebus to libbsd. I tried this before and its not done in
>>>> one
>>>> day.
>>>>
>>>> 2. You get rid of all simplebus dependencies in the driver and use the
>>>> libbsd nexus support. This is normally done in a couple of minutes with
>>>> the
>>>> use some hacks to get the FDT provided parameters.
>>>>
>>>> To get an idea how a driver is ported see git log and look at all
>>>> commits
>>>> containing "if_cgem" in the subject.
>>>>
>>>> Please help to improve the documentation (libbsd.txt) while you work on
>>>> this
>>>> topic.
>>>>
>>>>
>>>> On 15/05/15 08:27, ragu nath wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> My name is ragunath. I am selected for Google Summer of Code 2015 with
>>>>> RTEMS. I will be working on improving Beagle BSP.
>>>>>
>>>>> I am in the process of porting ethernet driver for Beaglebone black
>>>>> from FreeBSD to rtems-libbsd.  I would like to know what are the
>>>>> necessary changes we need to make to add a driver. BBB is based on ARM
>>>>> Am335

Re: Porting ethernet driver from FREEBSD to rtems-libbsd

[ragu nath]

Hi Ben,

I  found the reason for system hang in BBB after link goes up. It is
caused by enabling the interrupt before it is  processed creating a
continuous flow of interrupts hogging the CPU.

In rtems-libbsd we do not directly call the interrupt handler. we
create an event through interrupt trigger routine and then the server
task detects the event and calls the actual intr handler.  While
registering the interrupt, we will give this trigger routine as
handler. Server task separately calls the actual intr handler.

In BBB irq processing (bsp_interrupt_dispatch function), we disable
the vector and  call the handler and enable it.
For network interrupt intr, this handler will be interrupt trigger
routine which creates an event. After this intr is enabled but the
interrupt was not processed. The intr was supposed to be enabled by
the server task after processing the interrupt. This causes the hang.

The irq dispatch function assumes that we are calling the actual intr
handler and enables the interrupt. But since we are processing the
interrupt in a separate server task, it needs to be enabled there not
in the dispatch function.

As a temp fix, I selectively disabled bsp_interrupt_vector_enable in
dispatch function. There is no hang and packets are received.

What can be the correct fix for the issue as there are other
interrupts that are not  processed in this way?

Thanks,
Ragunath

On Fri, May 15, 2015 at 12:39 PM, ragu nath  wrote:
> Thank you. I will check the git log. I am also inclined to using nexus
> support. I already compiled the driver using nexus support. I fully
> intend to add more documentation to the project. I will keep posting
> on this thread if I have any further issues.
>
> Thanks,
> Ragunath
>
>
> On Fri, May 15, 2015 at 12:05 PM, Sebastian Huber
>  wrote:
>> You have two options.
>>
>> 1. You port simplebus to libbsd. I tried this before and its not done in one
>> day.
>>
>> 2. You get rid of all simplebus dependencies in the driver and use the
>> libbsd nexus support. This is normally done in a couple of minutes with the
>> use some hacks to get the FDT provided parameters.
>>
>> To get an idea how a driver is ported see git log and look at all commits
>> containing "if_cgem" in the subject.
>>
>> Please help to improve the documentation (libbsd.txt) while you work on this
>> topic.
>>
>>
>> On 15/05/15 08:27, ragu nath wrote:
>>>
>>> Hi All,
>>>
>>> My name is ragunath. I am selected for Google Summer of Code 2015 with
>>> RTEMS. I will be working on improving Beagle BSP.
>>>
>>> I am in the process of porting ethernet driver for Beaglebone black
>>> from FreeBSD to rtems-libbsd.  I would like to know what are the
>>> necessary changes we need to make to add a driver. BBB is based on ARM
>>> Am335x SoC.
>>>
>>> What are the bsp specific changes we need to do (bus support api's,
>>> interrupt support, etc)? I understand all the devices are under nexus
>>> device in rtems-libbsd. In the FreeBSD code, it is under simplebus.
>>> What are the changes we need to do to take care of this?
>>>
>>> If there is any documentation available on this topic pls let me know.
>>>
>>>
>>> Thanks,
>>> Ragunath
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
>
>
> --
> ragu



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Porting ethernet driver from FREEBSD to rtems-libbsd

[ragu nath]

Thank you. I will check the git log. I am also inclined to using nexus
support. I already compiled the driver using nexus support. I fully
intend to add more documentation to the project. I will keep posting
on this thread if I have any further issues.

Thanks,
Ragunath


On Fri, May 15, 2015 at 12:05 PM, Sebastian Huber
 wrote:
> You have two options.
>
> 1. You port simplebus to libbsd. I tried this before and its not done in one
> day.
>
> 2. You get rid of all simplebus dependencies in the driver and use the
> libbsd nexus support. This is normally done in a couple of minutes with the
> use some hacks to get the FDT provided parameters.
>
> To get an idea how a driver is ported see git log and look at all commits
> containing "if_cgem" in the subject.
>
> Please help to improve the documentation (libbsd.txt) while you work on this
> topic.
>
>
> On 15/05/15 08:27, ragu nath wrote:
>>
>> Hi All,
>>
>> My name is ragunath. I am selected for Google Summer of Code 2015 with
>> RTEMS. I will be working on improving Beagle BSP.
>>
>> I am in the process of porting ethernet driver for Beaglebone black
>> from FreeBSD to rtems-libbsd.  I would like to know what are the
>> necessary changes we need to make to add a driver. BBB is based on ARM
>> Am335x SoC.
>>
>> What are the bsp specific changes we need to do (bus support api's,
>> interrupt support, etc)? I understand all the devices are under nexus
>> device in rtems-libbsd. In the FreeBSD code, it is under simplebus.
>> What are the changes we need to do to take care of this?
>>
>> If there is any documentation available on this topic pls let me know.
>>
>>
>> Thanks,
>> Ragunath
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Porting ethernet driver from FREEBSD to rtems-libbsd

[ragu nath]

Hi All,

My name is ragunath. I am selected for Google Summer of Code 2015 with
RTEMS. I will be working on improving Beagle BSP.

I am in the process of porting ethernet driver for Beaglebone black
from FreeBSD to rtems-libbsd.  I would like to know what are the
necessary changes we need to make to add a driver. BBB is based on ARM
Am335x SoC.

What are the bsp specific changes we need to do (bus support api's,
interrupt support, etc)? I understand all the devices are under nexus
device in rtems-libbsd. In the FreeBSD code, it is under simplebus.
What are the changes we need to do to take care of this?

If there is any documentation available on this topic pls let me know.


Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTC patch for BBB

[ragu nath]

Hi All,

I have attached the RTC patch for BBB. I have addressed the comments
given for my earlier submission.

I am having problems with sending patch using git send-email. I
understand this is the preferred way but I not able to send patch
using git send-email. I am behind a http proxy and git was not able to
configure the smtp server. I could not find any solutions in the net.
Is there any known solutions to this problem? For time being I am
attaching the patch. Meanwhile I will also try to figure out the
solution for this problem



Thanks,
Ragunath
From 635092dba006e54aa90619f01101f70a680969be Mon Sep 17 00:00:00 2001
From: ragunath 
Date: Sun, 3 May 2015 15:25:55 +0530
Subject: [PATCH] RTC patch for BBB

---
 c/src/lib/libbsp/arm/beagle/Makefile.am  |   6 +
 c/src/lib/libbsp/arm/beagle/configure.ac |   4 +
 c/src/lib/libbsp/arm/beagle/rtc.c| 272 +++
 c/src/lib/libcpu/arm/shared/include/am335x_rtc.h |  25 +++
 c/src/lib/libcpu/arm/shared/include/omap3.h  |   6 +
 5 files changed, 313 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/beagle/rtc.c
 create mode 100644 c/src/lib/libcpu/arm/shared/include/am335x_rtc.h

diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am b/c/src/lib/libbsp/arm/beagle/Makefile.am
index abef8ba..cbe13ad 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -114,6 +114,12 @@ libbsp_a_SOURCES += ../../shared/console.c \
 # I2C
 libbsp_a_SOURCES += misc/i2c.c
 
+#RTC
+if beaglebone_rtc
+include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/am335x_rtc.h
+libbsp_a_SOURCES += rtc.c
+libbsp_a_SOURCES += ../../shared/tod.c
+endif
 # Clock
 libbsp_a_SOURCES += clock.c
 libbsp_a_SOURCES += ../../shared/clockdrv_shell.h
diff --git a/c/src/lib/libbsp/arm/beagle/configure.ac b/c/src/lib/libbsp/arm/beagle/configure.ac
index a7e99eb..0574b78 100644
--- a/c/src/lib/libbsp/arm/beagle/configure.ac
+++ b/c/src/lib/libbsp/arm/beagle/configure.ac
@@ -12,6 +12,7 @@ RTEMS_TOP(../../../../../..)
 
 RTEMS_CANONICAL_TARGET_CPU
 AM_INIT_AUTOMAKE([no-define nostdinc foreign 1.11.1])
+AM_CONDITIONAL(beaglebone_rtc, test "$RTEMS_BSP" = "beagleboneblack")
 RTEMS_BSP_CONFIGURE
 
 RTEMS_PROG_CC_FOR_TARGET
@@ -30,6 +31,9 @@ RTEMS_BSPOPTS_HELP([CONSOLE_BAUD],[initial baud for console UART])
 RTEMS_BSPOPTS_SET([CONSOLE_POLLED],[*],[0])
 RTEMS_BSPOPTS_HELP([CONSOLE_POLLED],[polled console i/o (e.g. to run testsuite)])
 
+RTEMS_BSPOPTS_SET([BBB_DEBUG],[beaglebone*],[0])
+RTEMS_BSPOPTS_HELP([BBB_DEBUG],[Enable BBB debug])
+
 RTEMS_BSP_CLEANUP_OPTIONS(0, 0)
 RTEMS_BSP_LINKCMDS
 
diff --git a/c/src/lib/libbsp/arm/beagle/rtc.c b/c/src/lib/libbsp/arm/beagle/rtc.c
new file mode 100644
index 000..0312983
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/rtc.c
@@ -0,0 +1,272 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief RTC driver for AM335x SoC.
+ *
+ */
+
+/*
+ * Copyright (c) 2015 Ragunath .
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define setbit(a,x) (a | (1<> 4 )*10))
+#define dec(a) (((a / 10) << 4) | (a % 10))
+#define WRITE_WAIT_MAX_COUNT 1
+
+rtems_device_minor_number RTC_Minor;
+size_t RTC_Count = 1;
+
+static void rtc_write_enable(void);
+static void rtc_write_disable(void);
+static int rtc_write_wait(void);
+static void rtc_clk_init(void);
+void rtc_init(int minor);
+void print_time(void);
+int am335x_rtc_gettime(int minor,rtems_time_of_day *t);
+int am335x_rtc_settime(int minor, const rtems_time_of_day *t);
+void am335x_rtc_debug(void);
+
+/*
+ * probe for a rtc. we always claim to have one.
+ */
+static bool am335x_rtc_probe (int minor)
+{
+  return true;
+}
+
+/*
+ * Write key values to kick0 and kick1 registers to enable write access
+ */
+static void rtc_write_enable(void)
+{
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK0,AM335X_RTC_KICK0_KEY);
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK1,AM335X_RTC_KICK1_KEY);
+}
+
+/*
+ * Write random (0x) value to kick0 and kick1 registers to disable write access
+ */
+static void rtc_write_disable(void)
+{
+  /* Write some random value other than key to disable*/
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK0,0x);
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK1,0x);
+}
+
+/*
+ * Wait till busy bit is reset
+ */
+static int rtc_write_wait(void)
+{
+  int i = WRITE_WAIT_MAX_COUNT;
+  while((mmio_read(AM335X_RTC_BASE+AM335X_RTC_STATUS_REG) & 0x1) && (i--));
+
+  if(i == 0)
+  return RTEMS_RESOURCE_IN_USE;
+  else
+  return RTEMS_SUCCESSFUL;
+}
+
+
+/*
+ * Initialize RTC clock
+ */
+static void rtc_clk_init(void)
+{
+  uint32_t a = 0x0;
+
+  a = setbit(a,1);
+  /* IDLEST = 0x0 & MODULEMODE = 0x1*/
+  mmio_write(CM_RTC_BASE+CM_RTC_RTC_CLKCTRL,a);
+  a = 0x0;
+
+  /*32K rtc clock active*/
+  a = setbit(a,9);
+  a

Re: Beagle bsp improvements RTC driver for beaglebone black

[ragu nath]

Hi All,

My semester exams have started and  I could not find enough time to
work on this.
I have addressed most of the comments but testing is pending.
Once I get time, I will finish it and submit the patch.  Sorry for the delay.

Regards,
Ragunath


On Sun, Apr 5, 2015 at 2:22 AM, Ben Gras  wrote:
> All,
>
> I built & tested the change based on current master. Looks great,
> ragunath! I agree it's worth addressing Joel's comments. I have two
> more:
>
>  - please check in the device read/write functions that you're getting
> the 'minor' argument that you expect (0), and not return valid data
> otherwise.
>  - git reports some spurious white space
>
> can you address these & resubmit? I'll be happy to merge then. Thanks
> for your contribution, very good companion to your GSOC proposal!
>
>
>
> On Wed, Apr 1, 2015 at 7:48 PM, Joel Sherrill  
> wrote:
>> I noticed this wasn't merged.
>>
>> Ben.. ?
>>
>> some comments interspersed.
>>
>> On 3/10/2015 4:21 PM, ragu nath wrote:
>>> Hi All,
>>>
>>> I was exploring the beagle code base to find a task to get hands on
>>> experience with RTEMS internals. I found that "Real time Clock (RTC)" 
>>> support is
>>> missing for beaglebone. I made the effort to add the driver for the device.
>>> Included the patch for the driver. RTEMS already have a RTC framework.
>>> I defined the necessary structures to hook the driver to the framework.
>>>
>>> Enabled the driver by defining the macro
>>> "CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER" and tested the following.
>>> Testing is done from the shell using "date" and "rtc" commands.
>>> 1. Able to read the time from rtc.
>>> 2. Able to set the time
>>> 3. Time values are preserved between reboots
>>>
>>> Pls review the patch and let me know if you have any comments.
>>>
>>> I have following doubts
>>>
>>> 1. The support is applicable only to beaglebone black. It is not valid
>>> for beagleboard. Both of them seem to have same codebase.  Is there any 
>>> compile
>>> time flags available to not compile the driver for beagleboard?
>>
>> Look in the configure.ac in the BSP. There is already a cpp define generated
>> based on the board variant for DM3730 or AM335x. Do you need more than
>> that? I am not an expert on the differences between the various models so
>> this is just a question.
>>
>> If the RTC has to be ignored completely for some variants, the configure.ac
>> logic can be enhanced to generate a conditional the Makefile.am can use
>> to conditionally build some files.
>>
>>
>>> 2. What is procedure to commit the change (In case the patch is
>>> accepted)? Do we need to open a bug to track the changes?
>> This normally would have been more than enough. But pinging if you don't
>> get a response in a reasonable length of time.
>>
>> The patch didn't get included in my response so here are some odd comments.
>>
>> + "disabl" check spelling.
>> + "Steps to enable RTC" should have "*" at front of each line in comment
>> block
>> + spaces around equal signs
>> + Don't print from driver
>> + I see an unneeded blank line before closing } in some methods
>> + Put ";" on busy spin loops on a separate line so it is obvious
>>- if there is a known number of maximum spins, it should not
>>  lock up.
>>   - the spins do look the same so moving them to a subroutine
>> and adding a maximum spin count would be a nice way to
>>make the code more robust and clearer.
>> + Rather than RTEMS_DEBUG, may want to use a BB_DEBUG
>>or similar for debug code.
>> + Watch columns lining up. RTC_Table comments don't line up
>>and value column in register macros in .h don't either.
>> +
>>> Thanks,
>>> Ragunath
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>
>>



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS libbsd port: how to link the driver

[ragu nath]

Thanks for your help. I added the driver in the nexus-devices.h and it
was working.  I was missing the header file default-network-init.h in
my application. Now I am able to link the driver to the application.

Regards,
Ragunath


On Tue, Apr 7, 2015 at 10:55 AM, Sebastian Huber
 wrote:
> Hello,
>
> do you refer to the new network stack (https://git.rtems.org/rtems-libbsd)?
> There is documentation in the file 'libbsd.txt', but I have to admit its
> poorly documented, mainly due to lack of time and budget.  For the driver
> registration see the file nexus-devices.h and the tests.
>
>
> On 06/04/15 21:12, ragu nath wrote:
>>
>> Hi,
>>
>> What is the procedure to link a network driver to the application in
>> rtems libbsd port? The drivers are compiled and available in the
>> libbsd archive. I dont know how to link the driver to the application.
>>
>> I followed the RTEMS NETWORKING supplement document and tried defining
>> the following structures. But it did not work
>>
>> static struct rtems_bsdnet_ifconfig netdriver_config = {
>> RTEMS_BSP_NETWORK_DRIVER_NAME,
>> RTEMS_BSP_NETWORK_DRIVER_ATTACH
>> };
>> struct rtems_bsdnet_config rtems_bsdnet_config = {
>> &netdriver_config,
>> rtems_bsdnet_do_bootp,
>> };
>>
>> If there is any latest documentation available, pls let me know.
>>
>> Thanks,
>> Ragunath
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS libbsd port: how to link the driver

[ragu nath]

Hi,

What is the procedure to link a network driver to the application in
rtems libbsd port? The drivers are compiled and available in the
libbsd archive. I dont know how to link the driver to the application.

I followed the RTEMS NETWORKING supplement document and tried defining
the following structures. But it did not work

static struct rtems_bsdnet_ifconfig netdriver_config = {
RTEMS_BSP_NETWORK_DRIVER_NAME,
RTEMS_BSP_NETWORK_DRIVER_ATTACH
};
struct rtems_bsdnet_config rtems_bsdnet_config = {
&netdriver_config,
rtems_bsdnet_do_bootp,
};

If there is any latest documentation available, pls let me know.

Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

lwIP for beaglebone black

[ragu nath]

Hi,

I would like to know what is the status of running lwIP on beaglebone
black on RTEMS.  I understand that  there was some considerable amount
of work already done on running lwIP on BBB.  It would be really
helpful if I can get the details on what has already been done and
what are the remaining things to be done.


Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Beagle bsp improvements RTC driver for beaglebone black

[ragu nath]

Hi All,

I was exploring the beagle code base to find a task to get hands on
experience with RTEMS internals. I found that "Real time Clock (RTC)" support is
missing for beaglebone. I made the effort to add the driver for the device.
Included the patch for the driver. RTEMS already have a RTC framework.
I defined the necessary structures to hook the driver to the framework.

Enabled the driver by defining the macro
"CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER" and tested the following.
Testing is done from the shell using "date" and "rtc" commands.
1. Able to read the time from rtc.
2. Able to set the time
3. Time values are preserved between reboots

Pls review the patch and let me know if you have any comments.

I have following doubts

1. The support is applicable only to beaglebone black. It is not valid
for beagleboard. Both of them seem to have same codebase.  Is there any compile
time flags available to not compile the driver for beagleboard?
2. What is procedure to commit the change (In case the patch is
accepted)? Do we need to open a bug to track the changes?

Thanks,
Ragunath
From 03b7fccb6605ada6a5c022d960efa4a9e653c3bb Mon Sep 17 00:00:00 2001
From: ragunath 
Date: Tue, 10 Mar 2015 15:09:37 +0530
Subject: [PATCH] RTC driver for Beaglebone black

---
 c/src/lib/libbsp/arm/beagle/Makefile.am  |   4 +
 c/src/lib/libbsp/arm/beagle/rtc.c| 250 +++
 c/src/lib/libcpu/arm/shared/include/am335x_rtc.h |  27 +++
 c/src/lib/libcpu/arm/shared/include/omap3.h  |   6 +
 4 files changed, 287 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/beagle/rtc.c
 create mode 100644 c/src/lib/libcpu/arm/shared/include/am335x_rtc.h

diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am b/c/src/lib/libbsp/arm/beagle/Makefile.am
index abef8ba..13569fc 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -45,6 +45,7 @@ include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/arm-cp15.h
 include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/omap3.h
 include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/am335x.h
 include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/omap_timer.h
+include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/am335x_rtc.h
 
 ###
 #  Data   #
@@ -114,6 +115,9 @@ libbsp_a_SOURCES += ../../shared/console.c \
 # I2C
 libbsp_a_SOURCES += misc/i2c.c
 
+#RTC
+libbsp_a_SOURCES += rtc.c
+libbsp_a_SOURCES += ../../shared/tod.c
 # Clock
 libbsp_a_SOURCES += clock.c
 libbsp_a_SOURCES += ../../shared/clockdrv_shell.h
diff --git a/c/src/lib/libbsp/arm/beagle/rtc.c b/c/src/lib/libbsp/arm/beagle/rtc.c
new file mode 100644
index 000..e64df11
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/rtc.c
@@ -0,0 +1,250 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief RTC driver for AM335x SoC.
+ * 
+ */
+
+/*
+ * Copyright (c) 2015 Ragunath .
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if IS_AM335X
+#define setbit(a,x) (a | (1<> 4 )*10))
+#define dec(a) (((a / 10) << 4) | (a % 10))
+
+rtems_device_minor_number RTC_Minor;
+size_t RTC_Count = 1;
+
+static void rtc_write_enable(void);
+static void rtc_write_disable(void);
+static void rtc_clk_init(void);
+void rtc_init(int minor);
+void print_time(void);
+int am335x_rtc_gettime(int minor,rtems_time_of_day *t);
+int am335x_rtc_settime(int minor, const rtems_time_of_day *t);
+void am335x_rtc_debug(void);
+
+/*
+ * probe for a rtc. we always claim to have one.
+ */
+static bool am335x_rtc_probe (int minor)
+{
+  return true;
+}
+
+/*
+ * Write key values to kick0 and kick1 registers to enable write access
+ */
+static void rtc_write_enable(void)
+{	
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK0,AM335X_RTC_KICK0_KEY);
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK1,AM335X_RTC_KICK1_KEY);
+	
+}
+
+/*
+ * Write random (0x) value to kick0 and kick1 registers to disabl write access
+ */
+static void rtc_write_disable(void)
+{
+  /* Write some random value other than key to disable*/
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK0,0x);
+  mmio_write(AM335X_RTC_BASE+AM335X_RTC_KICK1,0x);
+}
+
+/*
+ * Initialize RTC clock
+ */
+static void rtc_clk_init(void)
+{
+  uint32_t a=0x0;
+
+  a=setbit(a,1);
+  /* IDLEST = 0x0 & MODULEMODE = 0x1*/
+  mmio_write(CM_RTC_BASE+CM_RTC_RTC_CLKCTRL,a);
+  a=0x0;
+
+  /*32K rtc clock active*/	
+  a=setbit(a,9);
+  a=setbit(a,8);	
+  mmio_write(CM_RTC_BASE+CM_RTC_CLKSTCTRL,a);
+}
+
+void rtc_init(int minor)
+{
+  int rmajor,rminor,reg;
+  uint32_t a=0x0;	
+
+  rtc_clk_init();
+  reg = mmio_read(AM335X_RTC_BASE+AM335X_RTC_REV_REG);
+  rminor = (reg & 0x001f);
+  rma

GSOC 2015 Beagleboard BSP improvements

[ragu nath]

Hi All,

Congratulations on getting accepted as a mentoring organization.

My name is Ragunath. I am currently pursuing my master's degree in
computer science from IIT Kharagpur, India.
My area of interests are operating systems and embedded systems
development. I am interested in working with
RTEMS for GSOC'15 this summer.

I am interested in the project "Beagle BSP improvements".  I own a
beaglebone black and have been testing rtems with it.
I can see that the project is marked with bold text having some
importance to RTEMS. I would like to contribute to it by
adding more support to the beagle BSP.

I  went through the Getting started page and project page. As
mentioned in the project page as requirements for the project,
I have the dev environment set. I am able to compile the beagle BSP
target, run it on the hardware and the qemu emulator.
Now I am exploring more about the project by browsing the code and
running various available tests on hardware.

There were four sub projects mentioned in the project page.  Does all
of them constitute a single GSOC project or a combination
of one or two tasks can be taken? What would be the order of priority
of the sub tasks?

If there is anything you recommend me to do or study something, pls let me know.
Hoping for reply

Thanks,
Ragunath
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel