[PATCH] lwIP configuration & build files

2015-08-09 Thread Ragunath 
From: ragunath 

Patch to build lwip with RTEMS Resource builder. It builds the lwip sources and 
creates a library.
---
 rtems/config/4.11/net/lwip.bset  | 20 +++
 rtems/config/net/lwip-1-1.cfg| 27 
 source-builder/config/lwip-1.cfg | 54 
 3 files changed, 101 insertions(+)
 create mode 100644 rtems/config/4.11/net/lwip.bset
 create mode 100644 rtems/config/net/lwip-1-1.cfg
 create mode 100644 source-builder/config/lwip-1.cfg

diff --git a/rtems/config/4.11/net/lwip.bset b/rtems/config/4.11/net/lwip.bset
new file mode 100644
index 000..71f7841
--- /dev/null
+++ b/rtems/config/4.11/net/lwip.bset
@@ -0,0 +1,20 @@
+#
+# Build set for LWIP
+#
+
+%define release 1
+
+#
+# RTEMS Version
+#
+%define rtems_version 4.11
+
+#
+# The RTEMS URL paths.
+#
+%include rtems-urls.bset
+
+#
+# Build LWIP.
+#
+net/lwip-1-1.cfg
diff --git a/rtems/config/net/lwip-1-1.cfg b/rtems/config/net/lwip-1-1.cfg
new file mode 100644
index 000..cf25963
--- /dev/null
+++ b/rtems/config/net/lwip-1-1.cfg
@@ -0,0 +1,27 @@
+#
+#  LWIP MASTER
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# LWIP Version
+#
+%define lwip_version lwip-c2ebf5544b4268eac9b32c7f3a689ff646d96eef
+
+#Will be modified to be pointing to RTEMS repo
+%define rtems_ragu_git 
https://raw.githubusercontent.com/ragunath3252/lwip-nodrv/master
+#
+# Patch for RTEMS support.
+#
+%patch add lwip %{rtems_ragu_git}/rtems.patch
+%hash  md5 rtems.patch 489c0def3a89e538fb526a5396bf27ca
+
+#
+# LWIP Build configuration
+#
+%include %{_configdir}/lwip-1.cfg
diff --git a/source-builder/config/lwip-1.cfg b/source-builder/config/lwip-1.cfg
new file mode 100644
index 000..a90fde1
--- /dev/null
+++ b/source-builder/config/lwip-1.cfg
@@ -0,0 +1,54 @@
+#
+# LWIP MASTER  Version 1. commit -- c2ebf5544b4268eac9b32c7f3a689ff646d96eef
+#
+# This configuration file configure's, make's and install's LWIP.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  lwip-%{lwip_version}-%{_host}-%{release}
+Summary:   Light weight TCP/IP stack
+Version:   %{lwip_version}
+Release:   %{release}
+URL:  http://git.savannah.gnu.org/cgit/lwip.git
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# LWIP Source
+#
+%source set lwip 
git://git.sv.gnu.org/lwip.git?fetch?reset=hard?branch=master?checkout=c2ebf5544b4268eac9b32c7f3a689ff646d96eef
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_lwip="%{lwip_version}"
+  %source setup lwip -q -n %{lwip_version}
+  %patch setup lwip -p1
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  %{build_directory}
+
+  mkdir -p ${build_dir}
+  cd ${build_dir}
+
+  %{host_build_flags}
+
+  cd ${build_top}/%{lwip_version}
+  export RTEMS_MAKEFILE_PATH=%{_exec_prefix}
+  %{__make} all
+
+#  cd ${build_top}
+
+#%install
+  build_top=$(pwd)/%{lwip_version}
+
+  %{__make} install
+
-- 
1.9.1

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

[PATCH] RTEMS specific changes for lwIP

2015-08-09 Thread Ragunath 
From: ragunath 

---
 .gitignore|   1 +
 Makefile  | 170 +++
 ports/include/arch/cc.h   | 123 
 ports/include/arch/perf.h |  38 +++
 ports/include/arch/sys_arch.h |  59 
 ports/include/lwipopts.h  | 178 
 ports/sys_arch.c  | 663 ++
 src/include/lwip/opt.h|   2 +-
 8 files changed, 1233 insertions(+), 1 deletion(-)
 create mode 100644 .gitignore
 create mode 100644 Makefile
 create mode 100755 ports/include/arch/cc.h
 create mode 100755 ports/include/arch/perf.h
 create mode 100644 ports/include/arch/sys_arch.h
 create mode 100755 ports/include/lwipopts.h
 create mode 100644 ports/sys_arch.c

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..c81beb4
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+o-optimize/*
diff --git a/Makefile b/Makefile
new file mode 100644
index 000..0cbae64
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,170 @@
+include $(RTEMS_MAKEFILE_PATH)/Makefile.inc
+include $(RTEMS_CUSTOM)
+include $(PROJECT_ROOT)/make/leaf.cfg
+
+ CONFIG 

+#For debugging symbols add -DLWIP_DEBUG
+# COMPILER/LINKER
+CFLAGS+=-g -O2   \
+ -Wall
+
+# OUTPUT
+LWIP_EXEC=lwip
+
+ PATHS 
#
+
+# LWIP
+LWIP_PATH=.
+LWIP_SRC_PATH=$(LWIP_PATH)/src
+LWIP_API_PATH=$(LWIP_SRC_PATH)/api
+LWIP_CORE_PATH=$(LWIP_SRC_PATH)/core
+LWIP_INCL_PATH=$(LWIP_SRC_PATH)/include
+LWIP_NETIF_PATH=$(LWIP_SRC_PATH)/netif
+
+# ARCH
+LWIPARCH_PATH=$(LWIP_PATH)/ports
+LWIPARCH_SRC_PATH=$(LWIPARCH_PATH)
+LWIPARCH_INCL_PATH=$(LWIPARCH_PATH)/include
+
+# DRIVER
+LWIPDRIVER_PATH=$(LWIP_PATH)/ports
+LWIPDRIVER_SRC_PATH=$(LWIPDRIVER_PATH)/netif
+LWIPDRIVER_INCL_PATH=$(LWIPDRIVER_PATH)/include/netif
+
+ SOURCES 
###
+
+## CORE
+CORE_SRC=$(wildcard $(LWIP_CORE_PATH)/*.c)
+
+## IPv4
+IPV4_SRC=$(wildcard $(LWIP_CORE_PATH)/ipv4/*.c)
+
+## IPv6
+IPV6_SRC=$(wildcard $(LWIP_CORE_PATH)/ipv6/*.c)
+
+## SNMP
+SNMP_SRC=$(wildcard $(LWIP_CORE_PATH)/snmp/*.c)
+
+## API
+API_SRC=$(wildcard $(LWIP_API_PATH)/*.c )
+
+## NETIF
+NETIF_SRC=$(wildcard $(LWIP_NETIF_PATH)/*.c) \
+  $(wildcard $(LWIP_NETIF_PATH)/ppp/*.c) \
+  $(wildcard $(LWIP_NETIF_PATH)/ppp/polarssl/*.c)
+
+
+ARCH_SRC=$(wildcard $(LWIPARCH_SRC_PATH)/*.c)
+
+# DRIVER
+DRIVER_SRC=$(wildcard $(LWIPDRIVER_SRC_PATH)/*.c ) \
+   $(wildcard $(LWIPDRIVER_SRC_PATH)/*.S )
+
+
+SOURCES =  $(DRIVER_SRC) $(SNMP_SRC)\
+   $(CORE_SRC) $(IPV4_SRC) $(API_SRC) $(NETIF_SRC) $(ARCH_SRC)
+
+
+ HEADERS 
###
+
+## CORE
+CORE_H=$(LWIP_INCL_PATH)
+
+## IPv4
+#IPV4_H=$(LWIP_INCL_PATH)/ipv4
+
+## IPv6
+#IPV6_H=$(LWIP_INCL_PATH)/ipv6
+
+## POSIX
+POSIX_H=$(LWIP_INCL_PATH)/posix
+
+##POSIX_SYS
+POSIX_SYS_H=$(LWIP_INCL_PATH)/posix/sys
+
+
+## NETIF
+NETIF_H=$(LWIP_INCL_PATH)/netif
+NETIF_H_PPP=$(LWIP_INCL_PATH)/netif/ppp
+NETIF_H_PPP_POLARSSL=$(LWIP_INCL_PATH)/netif/ppp/polarssl
+
+## ARCH
+ARCH_H=$(LWIPARCH_INCL_PATH)
+
+## DRIVER
+DRIVER_H=$(LWIPDRIVER_INCL_PATH)
+
+# HEADERS
+HEADERS=-I$(CORE_H) -I$(POSIX_H) -I$(POSIX_SYS_H) -I$(NETIF_H) \
+-I$(NETIF_H_PPP) -I$(NETIF_H_PPP_POLARSSL) -I$(ARCH_H) \
+-I$(DRIVER_H)
+
+
+
+
+
+BIN=${ARCH}/$(LWIP_EXEC).bin
+LIB=${ARCH}/lib$(LWIP_EXEC).a
+
+# optional managers required
+MANAGERS=all
+
+# C source names
+CSRCS=$(filter %.c ,$(SOURCES))
+COBJS=$(patsubst %.c,${ARCH}/%.o,$(notdir $(CSRCS)))
+
+ASMSRCS=$(filter %.S , $(SOURCES))
+ASMOBJS=$(patsubst %.S,${ARCH}/%.o,$(notdir $(ASMSRCS)))
+
+OBJS=$(COBJS) $(ASMOBJS)
+
+all:${ARCH} $(LIB)
+
+$(LIB): $(OBJS)
+   $(AR)  rcs  $@ $^
+
+${ARCH}/%.o: $(LWIP_CORE_PATH)/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_CORE_PATH)/ipv4/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_CORE_PATH)/ipv6/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_CORE_PATH)/snmp/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_API_PATH)/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_NETIF_PATH)/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_NETIF_PATH)/ppp/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIP_NETIF_PATH)/ppp/polarssl/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIPARCH_SRC_PATH)/%.c
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIPDRIVER_SRC_PATH)/%.S
+   ${COMPILE.c} $(AM_CPPFLAGS) $(AM_CXXFLAGS) -o $@ $<
+
+${ARCH}/%.o: $(LWIPDRIVER_SRC_PATH)/%.c
+   ${C

RTEMS lwIP porting

2015-08-09 Thread 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

No interrupt on VirtualBox

2015-08-09 Thread 김진현 
 Hi,I made a simple driver for RTEMS to use network application on VirtualBox.But I have a problem about interrupt.I success to setup interrupt handler and there is no error return on "BSP_install_rtems_irq_handler".However I don't receive any interrupt by network device.My VirtualBox's version is 4.3.20 and Host OS is ubuntu 14.04.Please see screenshot and help me...



150809_box_mbuf.png
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Porting Linux driver into Xtratum

2015-08-09 Thread Shabnam Engineer 
Hello,I have a question about porting Linux drivers into Xtratum.Can I port 
Linux drivers into Xtratum? or is there something like DDE/DDEKit (it is for 
l4-based systems) for Xtratum.I want to implement Xtratum on a board and test 
some features, At first I want to  be sure that if I need a driver for our 
special tests that is not in Xtratum package, Could I choose it from Linux 
drivers and port it into Xtratum hypervisor? 
Thank you for your considering my question.Regards,Shabnam___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: xilinx microblaze

2015-08-09 Thread Hesham ALMatary 
On Fri, Aug 7, 2015 at 11:22 PM, Joel Sherrill
 wrote:
>
>
> On 8/7/2015 6:20 AM, Hesham ALMatary wrote:
>>
>> On Fri, Aug 7, 2015 at 12:07 PM,   wrote:
>>>
>>> Zitat von Hesham ALMatary :
>>>
 Hi,
>>>
>>>
>>>
 FYI, there's some initial port that runs hello world here [1]. I'll
 most likely work on rebasing and improving it soon, and perhaps revive
 the discussion of the upstreaming process, if it's of interest.
>>>
>>>
>>>
>>> Any chance, you could check it in?
>>>
>> I'd like to, but this will be subjected to some Xilinx licence issues,
>> and my schedule. So no (timing) guarantees.
>
>
> How much code is dependent on the Xilinx code?
>
Pretty much small. It's just some bits for UART lowest-level driver,
which I think it can be easily replaced by any other uart16550/RTEMS
driver.
> As much as I hate to ask, is it the port or the BSP?
> We really need a BSP that runs on a simulator to run tests
> on with a port.
>
> There is nothing preventing you two from privately sharing
> the code if you both meet the licensing terms. We just can't
> merge it.
>
> --joel



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

Re: GSoC 2015 RPi USB Support

2015-08-09 Thread Yurii Shevtsov 
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


 macro, linker will throw an error
 (.rtemsroset.bsd.nexus.content+0x10): undefined reference to
>>>
>>>
>>> '%wrong


 driver's name%'. Otherwise with correct name - no
>>>
>>>
>>> errors(warnings) and


 no nexus.content section. How can you explain this??
>>
>>
>>
>>
>>
>> The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a
>>>
>>>
>>> bus/mexus,
>>
>>
>> not a regular device driver. I would expect a nexus device for the
>>>
>>>
>>> Pi
>>
>>
>> to be in
>>
>>>
>>> https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835
>>
>>
>> or pointed to by a file in there.
>>
>> Look at the configuration for the various bsps in nexus-devices.h
>>>
>>>
>>> and
>>
>>
>> then at the source the macros refer to.
>>
>> Raspberry Pi source will have to be imported from the FreeBSD tree.
>
>
>
>
> Of course, I did it!)
>
>
>>>
>>>
>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace




 Is bcm283x_dwcotg* getting pulled into your build?


 2015-08-02 18:02 GMT+03:00 Joel Sherrill
>>>
>>>
>>> :
>
>
>
>
> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote:
>>
>>
>>
>>
>>
>> During debugging of compiled Nexus module(driver) I found out

Re: SMP support for Raspberry Pi 2

2015-08-09 Thread Rohini Kulkarni 
There is no documentation or information from forums I can find to get a
lead. I suppose i will go ahead with mailboxes. Each core has 4 mailboxes,
usage being left to us. One of the mailboxes can be used here.

On Sun, Aug 9, 2015 at 2:28 AM, Joel Sherrill 
wrote:

>
>
> On August 8, 2015 3:17:01 PM CDT, Rohini Kulkarni 
> wrote:
> >Can mailboxes be useful here? Nothing else that is coming to my mind
> >
>
> They may be and I am seeing references to ARM's own mpcore which uses the
> GIC. This appears to be SOC specific but ARM has recommendations which may
> be followed by the SOC manufacturer
>
> >On Sun, Aug 9, 2015 at 1:44 AM, Rohini Kulkarni 
> >wrote:
> >
> >Hi,
> >
> >I am stuck at how to set up IPI for Pi 2. This is a document I have
> >referred to get an idea of interrupts. Would be great to get some help
> >on how to proceed.
> >
> >
> >On Fri, Jul 31, 2015 at 7:33 PM, Joel Sherrill
> > wrote:
> >
> >
> >
> >On 7/31/2015 8:11 AM, Rohini Kulkarni wrote:
> >
> >Hi,
> >
> >How is the number of processors to be used for an application
> >specified?
> >The used count minimum of that supported in hardware and that
> >configured. How to specify the latter?
> >
> >
> >
> https://docs.rtems.org/doc-current/share/rtems/html/c_user/Configuring-a-System-SMP-Specific-Configuration-Parameters.html#Configuring-a-System-SMP-Specific-Configuration-Parameters
> >
> >and see the smptests. Many of which do specify the maximum.
> >
> >Thanks.
> >
> >On 29 Jul 2015 15:29, "Sebastian Huber"
> > >> wrote:
> >
> >
> >
> >On 29/07/15 11:52, Rohini Kulkarni wrote:
> >
> >
> >
> >On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber
> > >
> > >>> wrote:
> >
> > Hello Rohini,
> >
> > please use the devel list.
> >
> > On 28/07/15 07:41, Rohini Kulkarni wrote:
> >
> > Hi,
> >
> >   I wish to understand where the interprocessor interrupts are
> >   used during the boot process. During final initialization of
> > SMP I can see
> >
> > rtems_interrupt_handler_install(
> >   ARM_GIC_IRQ_SGI_0,
> >   "IPI",
> >   RTEMS_INTERRUPT_UNIQUE,
> >   bsp_inter_processor_interrupt,
> >   NULL
> > );
> >
> > Raspberry Pi 2 does not have the generic interrupt controller.
> >Interrupt routing will have to be handled differently. So I
> > wish to understand how/ where it is used. I suppose this might
> > be the problem.
> >
> >
> >  Sorry, that the documentation is so scattered.  I think we should
> >  move everything into the CPU Architecture Supplement. It would be
> > nice if you can help to improve the documentation since you have a
> > different view point.
> >
> >   You must install the IPI during the system initialization. It is
> >  raised via the _CPU_SMP_Send_interrupt() function, for an example
> > see arm-a9mpcore-smp.c.
> >
> >I could locate the function in  arm-a9mpcore-smp.c. but it would be
> >helpful if I can know where this being called from, a deeper call
> >hierarchy, so that I can ascertain this is a problem. I can see a
> >Send_messgae function call this. But don't know where the send message
> >is being called from.
> >
> >
> >You can run one of the SMP tests on the realview_pbx_a9_qemu_smp BSP on
> >Qemu and set a break point to _CPU_SMP_Send_interrupt() if you want to
> >know how it is used.
> >
> >--
> >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.
> >
> >
> >--
> >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
> >
> >
> >
> >
> >--
> >
> >Rohini Kulkarni
> >
> >
> >
> >
> >--
> >
> >Rohini Kulkarni
>
> --joel
>



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

Re: GSoC 2015 RPi USB Support

2015-08-09 Thread Gedare Bloom 
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
>
>
> macro, linker will throw an error
> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to


 '%wrong
>
>
> driver's name%'. Otherwise with correct name - no


 errors(warnings) and
>
>
> no nexus.content section. How can you explain this??
>>>
>>>
>>>
>>>
>>>
>>> The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a


 bus/mexus,
>>>
>>>
>>> not a regular device driver. I would expect a nexus device for the


 Pi
>>>
>>>
>>> to be in
>>>

 https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835
>>>
>>>
>>> or pointed to by a file in there.
>>>
>>> Look at the configuration for the various bsps in nexus-devices.h


 and
>>>
>>>
>>> then at the source the macros refer to.
>>>
>>> Raspberry Pi source will have to be imported from the FreeBSD tree.
>>
>>
>>
>>
>> Of course, I did it!)
>>
>>


 https://github.com/gtam

Re: GSoC 2015 RPi USB Support

2015-08-09 Thread Gedare Bloom 
The one other thing I will say, to repeat myself, is that I'd like you
to clean-up your code on github so that you have clean commit history
without any merge commits.

Gedare

On Sun, Aug 9, 2015 at 7:09 PM, Gedare Bloom  wrote:
> 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
>>
>>
>> macro, linker will throw an error
>> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to
>
>
> '%wrong
>>
>>
>> driver's name%'. Otherwise with correct name - no
>
>
> errors(warnings) and
>>
>>
>> no nexus.content section. How can you explain this??





 The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a
>
>
> bus/mexus,


 not a regular device driver. I would expect a nexus device for the
>
>
> Pi


 to be in

>
> https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835


 or pointed to by a file in there.