On Tue, 2015-06-30 at 10:09 +0530, Sujay Raj wrote:
> I need to access configurations files the for web server I am porting to
> rtems.
>
> I create a tar archive , that contains the required folders and files ,
> convert it into c source using rtems-bin2c , ( a header file and a c source
> ) and
I need to access configurations files the for web server I am porting to
rtems.
I create a tar archive , that contains the required folders and files ,
convert it into c source using rtems-bin2c , ( a header file and a c source
) and link them with my project.
In the init, I call
sc = Untar_From
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
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
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 t
> On Jun 29, 2015, at 11:27 , Joel Sherrill wrote:
>
> I didn't touch the tools, just the SPARC bsp custom files. This really would
> benefit all bsps but it needs to be tested as it is done and that requires
> running some code on the hardware. So it will be slow moving it into bsps.
>
> The
So, it is empty.
.rtemsroset.bsd.nexus.begin
0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
0x001104bc_bsd__start_set_nexus
.rtemsroset.bsd.nexus.end
0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
On June 29, 2015 10:17:05 AM CDT, Peter Dufault wrote:
>
>> On Jun 29, 2015, at 10:38 , Joel Sherrill
>wrote:
>>
>> The -Map option to ld will show the dependency that pulled in each
>function or data element.. File level without those options.
>>
>> It would be good to know what causes this
> On Jun 29, 2015, at 10:38 , Joel Sherrill wrote:
>
> The -Map option to ld will show the dependency that pulled in each function
> or data element.. File level without those options.
>
> It would be good to know what causes this all to get pulled in.
I’ll try to get to this tonight. I also
On June 29, 2015 9:05:30 AM CDT, Gedare Bloom wrote:
>On Mon, Jun 29, 2015 at 10:02 AM, Peter Dufault
>wrote:
>>
>>> On Jun 29, 2015, at 09:28 , Sebastian Huber
> wrote:
>>>
By only including the RTEMS shell commands I use I reduced the size
>to 1839664 (latest RTEMS) vs 1624684 (September
On Mon, Jun 29, 2015 at 10:02 AM, Peter Dufault wrote:
>
>> On Jun 29, 2015, at 09:28 , Sebastian Huber
>> wrote:
>>
>>> By only including the RTEMS shell commands I use I reduced the size to
>>> 1839664 (latest RTEMS) vs 1624684 (September RTEMS), about a 13% increase,
>>> but at least it fit
> On Jun 29, 2015, at 09:28 , Sebastian Huber
> wrote:
>
>> By only including the RTEMS shell commands I use I reduced the size to
>> 1839664 (latest RTEMS) vs 1624684 (September RTEMS), about a 13% increase,
>> but at least it fits in FLASH.
>>
>> The overhead appears to be mostly all the l
Thanks for the BSP opt that is much better way to control this cache behavior.
On Sun, Jun 28, 2015 at 5:54 AM, ragunath wrote:
> ---
> c/src/lib/libbsp/arm/beagle/configure.ac | 3 +++
> c/src/lib/libbsp/arm/beagle/irq.c | 5 +++--
> c/src/lib/libbsp/arm/beagle/startu
On Sun, Jun 28, 2015 at 11:05 AM, Peter Dufault wrote:
> In updating the Phytec MPC5554 to this mornings build I see a large code size
> increase. It will no longer fit in the 2MB FLASH on the MPC5554, which is a
> problem. Here are the sizes of the binaries, the first one built two days
> ag
Out of curiousity, would upstream freebsd be likely interested in
using the nexus instead of simplebus? That is, should some of this be
commited upstream? Few comments below.
On Sun, Jun 28, 2015 at 5:58 AM, ragunath wrote:
> ---
> @@ -326,6 +342,13 @@ cpsw_debugf(const char *fmt, ...)
> */
>
Fix the style issues that have been mentioned to you before. Also, try
to avoid including #include files that are unnecessary. (I don't know
for sure if any you have are, but this is a general comment.)
On Sat, Jun 27, 2015 at 3:54 PM, Ketul Shah wrote:
> Hello,
>
> I have developed basic ADC dri
On June 29, 2015 8:28:16 AM CDT, Sebastian Huber
wrote:
>
>
>On 29/06/15 15:20, Peter Dufault wrote:
>>> >On Jun 28, 2015, at 11:53 , Joel
>Sherrill wrote:
>>> >
>>There are also a bunch of new shell commands that are pulling in
>new
>>code, that might be a lot of the rest.
>>> >
>>>
On 29/06/15 15:20, Peter Dufault wrote:
>On Jun 28, 2015, at 11:53 , Joel Sherrill wrote:
>
>>There are also a bunch of new shell commands that are pulling in new
>>code, that might be a lot of the rest.
>
>This can be configured down.
>
>But overall, you may want to try per element data and
> On Jun 28, 2015, at 11:53 , Joel Sherrill wrote:
>
>> There are also a bunch of new shell commands that are pulling in new
>> code, that might be a lot of the rest.
>
> This can be configured down.
>
> But overall, you may want to try per element data and function sections on
> the compile
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 tas
21 matches
Mail list logo
