Re: USB Host and MMC/SD Card Stack

[Sebastian Huber]

On 16/06/15 21:28, Martin Galvan wrote:

Sebastian Huber  wrote:

Which USB and MMC/SD card hardware modules has this chip?  Are they standard 
modules, e.g. EHCI, SDHC or something like this?

 From what I saw, the USB module on the Beaglebone Black is built
around the Mentor musbmhdrc USB OTG controller, which is not EHCI or
OHCI compliant. The MMC/SD module is mostly compliant with SDHCI, with
a few quirks.


Is this Mentor USB stuff supported by FreeBSD?  Writing a new USB 
host/OTG driver is a major task.


--
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.

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

Re: [rtems-libbsd commit] The BPF dev node needs a minor number for tcpdump.

[Sebastian Huber]

This breaks the DHCP client.

On 16/06/15 05:21, Chris Johns wrote:

Module:rtems-libbsd
Branch:master
Commit:50500b5e973a7287e19cac2c260f143ed1a04ead
Changeset: 
http://git.rtems.org/rtems-libbsd/commit/?id=50500b5e973a7287e19cac2c260f143ed1a04ead

Author:Chris Johns 
Date:  Tue Jun 16 13:17:19 2015 +1000

The BPF dev node needs a minor number for tcpdump.

---

  freebsd/sys/net/bpf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freebsd/sys/net/bpf.c b/freebsd/sys/net/bpf.c
index 7a4eaf9..1f9430b 100644
--- a/freebsd/sys/net/bpf.c
+++ b/freebsd/sys/net/bpf.c
@@ -3005,7 +3005,7 @@ bpf_drvinit(void *unused)
/* For compatibility */
make_dev_alias(dev, "bpf0");
  #else /* __rtems__ */
-   rv = IMFS_make_generic_node("/dev/bpf", mode, &bpf_imfs_control, NULL);
+   rv = IMFS_make_generic_node("/dev/bpf0", mode, &bpf_imfs_control, NULL);
BSD_ASSERT(rv == 0);
  #endif /* __rtems__ */
  


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


--
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.

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

Re: [rtems-libbsd commit] Add error() to the BSD program support.

[Sebastian Huber]

On 16/06/15 05:21, Chris Johns wrote:

Module:rtems-libbsd
Branch:master
Commit:b5aca585949aa94d8d254ab4c4e5b4b2f7b1f1d9
Changeset: 
http://git.rtems.org/rtems-libbsd/commit/?id=b5aca585949aa94d8d254ab4c4e5b4b2f7b1f1d9

Author:Chris Johns 
Date:  Tue Jun 16 13:16:37 2015 +1000

Add error() to the BSD program support.

---

  rtemsbsd/include/machine/rtems-bsd-program.h | 11 +++
  rtemsbsd/rtems/rtems-bsd-program.c   | 13 +
  2 files changed, 24 insertions(+)

diff --git a/rtemsbsd/include/machine/rtems-bsd-program.h 
b/rtemsbsd/include/machine/rtems-bsd-program.h
index b2e542e..7c2837e 100644
--- a/rtemsbsd/include/machine/rtems-bsd-program.h
+++ b/rtemsbsd/include/machine/rtems-bsd-program.h
@@ -56,6 +56,9 @@ rtems_bsd_program_call_main(const char *name, int 
(*main)(int, char **),
  void
  rtems_bsd_program_exit(int exit_code) __dead2;
  
+void

+rtems_bsd_program_error(const char *, ...) __attribute__ ((__format__ 
(__printf__, 1, 2)));
+
  const char *
  rtems_bsd_program_get_name(void);
  
@@ -69,14 +72,22 @@ void

  rtems_bsd_program_unlock(void);
  
  #ifndef RTEMS_BSD_PROGRAM_NO_EXIT_WRAP

+  #undef exit


What is the reason for this #undef?


#define exit(code) rtems_bsd_program_exit(code)
  #endif
  
+#ifndef RTEMS_BSD_PROGRAM_NO_ERROR_WRAP

+  #undef error
+  #define error(fmt, ...) rtems_bsd_program_error(fmt, ## __VA_ARGS__)
+#endif
+
  #ifndef RTEMS_BSD_PROGRAM_NO_GETPROGNAME_WRAP
+  #undef getprogname
#define getprogname() rtems_bsd_program_get_name()
  #endif
  
  #ifndef RTEMS_BSD_PROGRAM_NO_PRINTF_WRAP

+  #undef printf
#define printf(...) fprintf(stdout, __VA_ARGS__)
  #endif
  
diff --git a/rtemsbsd/rtems/rtems-bsd-program.c b/rtemsbsd/rtems/rtems-bsd-program.c

index 8edd8f9..7b5920e 100644
--- a/rtemsbsd/rtems/rtems-bsd-program.c
+++ b/rtemsbsd/rtems/rtems-bsd-program.c
@@ -52,6 +52,8 @@
  #include 
  #include 
  
+#include 

+
  struct rtems_bsd_program_control {
void *context;
int exit_code;
@@ -116,6 +118,17 @@ rtems_bsd_program_exit(int exit_code)
panic("unexpected BSD program exit");
  }
  
+void

+rtems_bsd_program_error(const char *fmt, ...)
+{
+  va_list list;
+  va_start(list, fmt);
+  vfprintf(stderr, fmt, list);
+  fprintf(stderr, "\n");
+  va_end(list);
+  rtems_bsd_program_exit(1);
+}
+


It would be nice to keep the style of the files and this is STYLE(9) 
more or less.



  const char *
  rtems_bsd_program_get_name(void)
  {

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


--
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.

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

Re: [rtems-libbsd commit] Add BDS command support headers.

[Sebastian Huber]

On 16/06/15 05:21, Chris Johns wrote:

Module:rtems-libbsd
Branch:master
Commit:affed5e3f586860e2fd97445eaa20674dc4bcd25
Changeset: 
http://git.rtems.org/rtems-libbsd/commit/?id=affed5e3f586860e2fd97445eaa20674dc4bcd25

Author:Chris Johns 
Date:  Tue Jun 16 13:20:15 2015 +1000

Add BDS command support headers.

---

  freebsd/contrib/tcpdump/tcpdump.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/freebsd/contrib/tcpdump/tcpdump.c 
b/freebsd/contrib/tcpdump/tcpdump.c
index 32ffb45..00e44db 100644
--- a/freebsd/contrib/tcpdump/tcpdump.c
+++ b/freebsd/contrib/tcpdump/tcpdump.c
@@ -55,6 +55,8 @@ static const char rcsid[] _U_ =
  #define __need_getopt_newlib
  #include 
  #define setpriority(a, b, c)
+#include 
+#include 


Every RTEMS specific change should be in #ifdef __rtems__ sections. This 
is very helpful if you have to review files. This is missing in a couple 
of files.


There is not much documentation, but at least this is in libbsd.txt:

=== Rules for Modifying FreeBSD Source

Only add lines.  Subtract code by added `#ifndef __rtems__`.  This makes
merging easier in the future.  For example:

---
/* Global variables for the kernel. */

#ifndef __rtems__
/* 1.1 */
extern char kernelname[MAXPATHLEN];
#endif /* __rtems__ */

extern int tick;/* usec per tick (100 / hz) */
---

---
#if defined(_KERNEL) || defined(_WANT_FILE)
#ifdef __rtems__
#include 
#include 
#endif /* __rtems__ */
/*
 * Kernel descriptor table.
 * One entry for each open kernel vnode and socket.
 *
 * Below is the list of locks that protects members in struct file.
 *
 * (f) protected with mtx_lock(mtx_pool_find(fp))
 * (d) cdevpriv_mtx
 * nonenot locked
 */
---

---
extern int profprocs;/* number of process's profiling */
#ifndef __rtems__
extern volatile int ticks;
#else /* __rtems__ */
#include 
#define ticks _Watchdog_Ticks_since_boot
#endif /* __rtems__ */

#endif /* _KERNEL */
---

Add nothing (even blank lines) before or after the `__rtems__` guards.  
Always

include a `__rtems__` in the guards to make searches easy.



--
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.

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

Re: USB Host and MMC/SD Card Stack

[Martin Galvan]

Yes, it is, although the support (more precisely, the host side) was
added recently (and thus it's not yet on RTEMS' libbsd). These are the
files used by the Beaglebone Black:

http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/musb_otg.c?revision=278850&view=markup
http://svnweb.freebsd.org/base/head/sys/arm/ti/am335x/am335x_musb.c?revision=283276&view=markup

Is there an easy way to port these to RTEMS? I'm not sure how much the
BSD driver infrastructure has changed since 8.2.

On Wed, Jun 17, 2015 at 8:07 AM, Sebastian Huber
 wrote:
>
>
> On 16/06/15 21:28, Martin Galvan wrote:
>>
>> Sebastian Huber  wrote:
>>>
>>> Which USB and MMC/SD card hardware modules has this chip?  Are they
>>> standard modules, e.g. EHCI, SDHC or something like this?
>>
>>  From what I saw, the USB module on the Beaglebone Black is built
>> around the Mentor musbmhdrc USB OTG controller, which is not EHCI or
>> OHCI compliant. The MMC/SD module is mostly compliant with SDHCI, with
>> a few quirks.
>
>
> Is this Mentor USB stuff supported by FreeBSD?  Writing a new USB host/OTG
> driver is a major task.
>
> --
> 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.
>



-- 


Martin Galvan

Software Engineer

Taller Technologies Argentina


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: USB Host and MMC/SD Card Stack

[Sebastian Huber]

On 17/06/15 14:26, Martin Galvan wrote:

Yes, it is, although the support (more precisely, the host side) was
added recently (and thus it's not yet on RTEMS' libbsd). These are the
files used by the Beaglebone Black:

http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/musb_otg.c?revision=278850&view=markup
http://svnweb.freebsd.org/base/head/sys/arm/ti/am335x/am335x_musb.c?revision=283276&view=markup


This makes it much easier.



Is there an easy way to port these to RTEMS? I'm not sure how much the
BSD driver infrastructure has changed since 8.2.


It is actually FreeBSD 9.3, but I don't know how the USB stack evolved.



On Wed, Jun 17, 2015 at 8:07 AM, Sebastian Huber
 wrote:


On 16/06/15 21:28, Martin Galvan wrote:

Sebastian Huber  wrote:

Which USB and MMC/SD card hardware modules has this chip?  Are they
standard modules, e.g. EHCI, SDHC or something like this?

  From what I saw, the USB module on the Beaglebone Black is built
around the Mentor musbmhdrc USB OTG controller, which is not EHCI or
OHCI compliant. The MMC/SD module is mostly compliant with SDHCI, with
a few quirks.


Is this Mentor USB stuff supported by FreeBSD?  Writing a new USB host/OTG
driver is a major task.

--
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.






--
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.

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

Re: USB Host and MMC/SD Card Stack

[Martin Galvan]

On Wed, Jun 17, 2015 at 9:49 AM, Sebastian Huber
 wrote:
>>
>> Is there an easy way to port these to RTEMS? I'm not sure how much the
>> BSD driver infrastructure has changed since 8.2.
> It is actually FreeBSD 9.3, but I don't know how the USB stack evolved.

Is the USB stack also 9.3? I seem to recall that only MMC/SD was 9.3,
and USB was 8.

How difficult would it be to update the USB stack? I'm not all that
familiar with libbsd yet, but if it's not too big a task I may give it
a shot.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: USB Host and MMC/SD Card Stack

[Sebastian Huber]

On 17/06/15 15:16, Martin Galvan wrote:

On Wed, Jun 17, 2015 at 9:49 AM, Sebastian Huber
 wrote:

Is there an easy way to port these to RTEMS? I'm not sure how much the
BSD driver infrastructure has changed since 8.2.

It is actually FreeBSD 9.3, but I don't know how the USB stack evolved.

Is the USB stack also 9.3? I seem to recall that only MMC/SD was 9.3,
and USB was 8.

How difficult would it be to update the USB stack? I'm not all that
familiar with libbsd yet, but if it's not too big a task I may give it
a shot.


Its not a good idea to only update subsystems. It makes more sense to 
update everything.


--
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.

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

Fwd: [GSoC Mentors] [GSoC 2015] Mentor Midterm Evaluations 26 June - 3 July

[Joel Sherrill]

This is a reminder to all mentors and students that mid term evaluations
are due shortly.

Students make sure your mentors and the community know your status.

I would like each student to post their goals and status to devel@ so
everyone knows how successful you all are.
-- Forwarded message --
From: "'Carol Smith' via Google Summer of Code Mentors List" <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: Jun 17, 2015 12:43 PM
Subject: [GSoC Mentors] [GSoC 2015] Mentor Midterm Evaluations 26 June - 3
July
To: "Google Summer of Code Mentors List" <
google-summer-of-code-mentors-l...@googlegroups.com>
Cc:

Hi GSoC 2015 Mentors and Org Admins,

Per the program timeline
, starting next
Friday, 26 June you will will be able to submit an evaluation of your
student(s)' progress on their projects thus far.


Here's some important info on midterm evaluations for those not familiar:

Midterm evaluations are done via Melange
. Starting at
19:00 UTC on Friday, 26 June you will be able to submit an evaluation for
your student(s).You can find the evaluation links on your dashboard under
'Evaluations', one for each student you are a mentor for. If you are
curious about who can see evaluations after they are submitted, please
check out the FAQ on Evaluations
.
I have also pre-published the evaluation questions below in this email so
you can prepare. The deadline to submit your evaluation is 19:00 UTC on
Friday, 3 July. For those of you who have participated in evaluations in
previous years, please note that this evaluation window is extended by
three days to include a weekend and gives you more time to submit.

You may not submit your evaluation before or after the evaluation window.
Please ask your org admin to submit your evaluation for you if you
absolutely cannot submit yours on time. There really is no excuse for
missing the submission of a student's evaluation.

You must submit an evaluation for every student you are a mentor for this
year. You may submit, modify, and resubmit an evaluation as many times as
you choose up until the deadline. You must answer all required questions on
the evaluation in order to save submit it.

Please note that failing a student at the midterm evaluation means *this
student is immediately removed from the program.* There is no way to fail a
student at the midterm and have the student continue with the program to
try to "make it up" at the final. If your student fails, your student is
out.

You might find the FLOSS manual on GSoC evaluations
 helpful as well.
There's some excellent wisdom in there from your fellow mentors and org
admins on the evaluation process.

Students must have an evaluation on file from both themselves *and* a
passing evaluation from their mentor(s) in order to receive their midterm
payments.

Finally, a reminder: This year we will not allow any mentor who misses an
evaluation deadline to attend the mentor summit (assuming no one else
submits the evaluation on the mentor's behalf before the deadline either).
Also, any org that misses 2 or more evaluation deadlines (for the midterm,
final, or midterm and final combined) will not be allowed to attend the
mentor summit this year.

Please let me know directly if you have questions or concerns.

Cheers,

Carol

-

   1.

   How many years have you been a mentor for Google Summer of Code (Total -
   this doesn’t have to be consecutive)?
   1.

  This is my first year
  2.

  2-3 years
  3.

  More than 3 years
  2.

   If you answered “2-3 years” or “more than 3 years” as a mentor, what
   years did you participate?
   3.

   How many years have you been a student in Google Summer of Code?
   1.

  I have never been a student
  2.

  1 year
  3.

  2 years
  4.

  3+ years
  4.

   If you answered 2 years or 3+ years, what years did you participate as a
   student?
   5.

   At what point did you first make contact with your student?
   1.

  Before the program was announced
  2.

  After my organization was selected to participate in Google Summer of
  Code
  3.

  During the student application/acceptance phase of the program
  4.

  During the community bonding period
  5.

  After the start of coding
  6.

   How often do you and your student interact?
   1.

  Daily
  2.

  Every few days
  3.

  Weekly
  4.

  Every few weeks
  5.

  Monthly
  6.

  Less than once a month
  7.

   How do you communicate with your student? (Check all that apply)
   1.

  Google+ Hangout
  2.

  Voice (phone, Skype, etc.)
  3.

  IM/IRC
  4.

  

Gcc 5.x or master o. SPARC

[Joel Sherrill]

Hi

I did a quick test last week and my executables hung during init. Does anyone 
have any other experience with a gcx 5.x or newer?
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcc 5.x or master o. SPARC

[Sebastian Huber]

Yes, see also:

https://lists.rtems.org/pipermail/devel/2015-March/010710.html

- Joel Sherrill  schrieb:
> Hi
> 
> I did a quick test last week and my executables hung during init. Does anyone 
> have any other experience with a gcx 5.x or newer?
> --joel
> ___
> 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.huber at embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2015: Raspberry Pi 2 Support

[Rohini Kulkarni]

Hi all,

I have updated my blog to reflect my understanding and attempts for cache
performance issue.

Lately I have been trying around memory attributes for the mm_config_table.
One set of configurations for cacheable memory (inner and outer
levels)ended up reducing performance further ( which I really thought would
improve). So this table set up certainly controls performance.

The results are not improving after turning on cache. So memory sections
are perhaps not even getting cached.
I get a feeling it has got to do with this mm_config_table.

Updates from the github code and blog might help in further discussion.

Link to github code:https://github.com/krohini1593/rtems/tree/rohini

Link to Blog 

Thanks!

On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore 
wrote:

> Hi,
> Some of the code examples may give you some clues. Like this one:
> https://github.com/mrvn/test/blob/master/smp.cc
>
> Or this:
> https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT
>
> If you still can't figure it out, you can always join the raspberrypi.org
> forums and ask on this thread:
> https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904
>
> When it comes to the Pi 2 and SMP, you are our RTEMS expert :)
>
> Thanks,
> Alan
>
>
> On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni 
> wrote:
>
>> Hi,
>>
>> This is regarding Pi 2 SMP support. After powering on, the secondary
>> mailboxes read one of their four mailbox registers and wait for a non-zero
>> content to be written. This content is to be the physical address of the
>> location from where the cores are expected to start execution.
>>
>> I am stuck at figuring out this address. How should I go about
>> understanding this?
>>
>> Thanks!
>> On 3 Jun 2015 19:44, "Gedare Bloom"  wrote:
>>
>>> On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni 
>>> wrote:
>>> > But, I can't say cache configurations have a role here.
>>> >
>>> > I'll push my code to my github project soon.
>>> >
>>> > P.S. The Pi2 board I possess seems to have broken down. It just isn't
>>> > turning on. Unable to test further. Will order one immediately.
>>> >
>>> Ouch. Make sure you put it in a safe space for development, clear of
>>> threats like moisture, static shock, and cats.
>>>
>>> > On 3 Jun 2015 09:03, "Rohini Kulkarni"  wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Alan, your suggestion has resulted in much improvement
>>> >>
>>> >> arm_control=0x1000
>>> >>
>>> >> This has simply worked! Looks like the other cores were taking up
>>> plenty
>>> >> of time.
>>> >> I was aware from references that the other cores run a WFI, but ya,
>>> did
>>> >> not get its impact.
>>> >> Time for each dhrystone has reduced to 7 from 13 and the no of
>>> dhrystones
>>> >> per second also increased.
>>> >>
>>> >> But this is a change only in the config.txt not actually in the boot
>>> code.
>>> >>
>>> >> Thanks
>>> >>
>>> >> Rohini
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore 
>>> >> wrote:
>>> >>>
>>> >>> The caches are being enabled on the RPI 1 BSP. The same code is being
>>> >>> executed by the RPI 2 BSP, but obviously it’s not sufficient for the
>>> cache
>>> >>> setup.
>>> >>> I have been reading through this long thread, and it is very
>>> informative:
>>> >>> https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904
>>> >>>
>>> >>> I am starting to understand the setup that is required to enable
>>> caches
>>> >>> on the RPI 2. For example this message near the bottom of page 3
>>> gives a
>>> >>> good indication of the speedup available by configuring the MMU and
>>> caches
>>> >>> correctly:
>>> >>> Quote from above thread
>>> >>> --
>>> >>> Enabling I/D caches and branch prediction, just like the julia demo
>>> uses,
>>> >>> it takes ~12 seconds, or ~21 fps. It's just one core but also a much
>>> smaller
>>> >>> loop than the julia demo has.
>>> >>>
>>> >>> Enabling the MMU and mapping memory inner/outer write-back, write
>>> >>> allocate and the framebuffer inner write-through, no write allocate
>>> + outer
>>> >>> write-back, write-allocate it takes ~8 seconds, of 32 fps.
>>> >>>
>>> >>> PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2
>>> cache
>>> >>> effect.
>>> >>> -
>>> >>> End of quote
>>> >>>
>>> >>> The person who posted the above comment (mrvn) posted the code here:
>>> >>> https://github.com/mrvn/test/blob/master/mmu.cc
>>> >>>
>>> >>>
>>> >>> Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a
>>> wait
>>> >>> loop always accessing the bus. By putting this option in the
>>> config.txt file
>>> >>> you can put the other cores to sleep, speeding up the code on core 1.
>>> >>>  arm_control=0x1000
>>> >>> It would be worth trying that option to see if the benchmark speeds
>>> up.
>>> >>>
>>> >>>
>>> >>> Alan
>>> >>>
>>> >>> On Jun 2, 2015, at 8:05 AM, Hesham ALMatary <
>>> heshamelmat...@gmail.com>
>>> >>> wrote:
>>> >>>
>>

Re: GSOC 2015: Configuration GUI

[Anand Krishnan]

Hi all,

I've almost prepared the basic layout for the GUI. Also added some dummy
event handlers for File Menu.

Any more suggestions before fetching the options?
Code at : https://github.com/anandkp92/waf/tree/waf/gui

Thanks,
Anand

On Tue, Jun 16, 2015 at 10:45 AM, Anand Krishnan 
wrote:

> Thomas: Apologies. This is the right link:
> https://github.com/anandkp92/waf/blob/waf/gui/menu.py
>
> Thanks for the other input. I'll take care of in-code documentation and
> making the code modular.
>
> I'll work on the tabs next.
>
> Regards,
> Anand
>
>
> On Tue, Jun 16, 2015 at 4:37 AM, Gedare Bloom  wrote:
>
>> I just had one comment from reading the code, it lacks any code-level
>> documentation. Granted it is simple now, but as it grows so should the
>> doc.
>>
>> Also, make sure to watch out for when to break out into more
>> functions/modules. Avoid the pitfall of "one block of code to rule
>> them all"
>>
>> -Gedare
>>
>> On Mon, Jun 15, 2015 at 6:49 PM, Amar Takhar  wrote:
>> > On 2015-06-15 23:52 +0530, Anand Krishnan wrote:
>> >> Hi all,
>> >>
>> >> Currently I have uploaded the first part of the gui - just plain menus
>> (with no
>> >> event handlers yet) to my github: github.com/anandkp92/waf/gui/menu.py
>> . The
>> >> purpose of the GUI is for creating the config.cfg file for "waf
>> config" of the
>> >> waf version of RTEMS.
>> >
>> > Looks good so far.
>> >
>> >
>> >> I think you might need wxpython also to view it right now: http://
>> >> www.pygopar.com/installing-wxpython-3-on-ubuntu14-04/
>> >
>> > Everyone here will be able to sort that out, thanks for the help. :)
>> >
>> >
>> >> The main thing I want to get reviewed on is the code. I am planning to
>> have
>> >> different classes for menus, tabs, groups etc and a main class that
>> creates
>> >> multiple instances of each and puts it all together.
>> >
>> > It seems like a good start.
>> >
>> >
>> >> Correct me if I am wrong:
>> >> For the File options->
>> >> 1) New ->  Opens a new instance with all the configuration options set
>> to
>> >> default again.
>> >
>> > Yes.
>> >
>> >
>> >> 2) Save -> Save the configuration options chosen so far.
>> >
>> > Yes.
>> >
>> >
>> >> 3) Open -> Open a previously saved set of configuration options.
>> >
>> > Yep.
>> >
>> >
>> >> Once this is cleared, I shall move on to implementing these.
>> >
>> > OK.
>> >
>> >
>> >> Please keep in mind this is a very crude version and the first part of
>> many
>> >> parts.
>> >
>> > Right.  Lay out the panes and other UI Details before getting on to
>> actual
>> > options.  I will help you with that.
>> >
>> > You will also need to decide how each option should be displayed.
>> >
>> >
>> > Amar.
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2015: Configuration GUI

[Amar Takhar]

On 2015-06-18 05:57 +0530, Anand Krishnan wrote:
> Hi all,
> 
> I've almost prepared the basic layout for the GUI. Also added some dummy event
> handlers for File Menu.
> 
> Any more suggestions before fetching the options?

This is a great start!

Have you thought about how you are going to lay out the tabs for multiple BSP 
configs + the tag headings?

One option is to do multi-layered tabs along the top.  Another is tabs on the 
top and vertically (left side).


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

Re: [rtems-libbsd commit] The BPF dev node needs a minor number for tcpdump.

[Chris Johns]

On 17/06/2015 9:08 pm, Sebastian Huber wrote:
> This breaks the DHCP client.

I will fix this ...

ruru chris $ ls -las /dev/bpf*
0 crw---  1 root  wheel  0xc Jun  9 10:45 /dev/bpf
0 lrwxr-xr-x  1 root  wheel3 Jun  9 10:45 /dev/bpf0 -> bpf

Looks like we need both.

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

Re: [rtems-libbsd commit] Add error() to the BSD program support.

[Chris Johns]

On 17/06/2015 9:13 pm, Sebastian Huber wrote:
> 
> 
> On 16/06/15 05:21, Chris Johns wrote:
>> Module:rtems-libbsd
>> Branch:master
>> Commit:b5aca585949aa94d8d254ab4c4e5b4b2f7b1f1d9
>> Changeset:
>> http://git.rtems.org/rtems-libbsd/commit/?id=b5aca585949aa94d8d254ab4c4e5b4b2f7b1f1d9
>>
>>
>> Author:Chris Johns 
>> Date:  Tue Jun 16 13:16:37 2015 +1000
>>
>> Add error() to the BSD program support.
>>
>> ---
>>
>>   rtemsbsd/include/machine/rtems-bsd-program.h | 11 +++
>>   rtemsbsd/rtems/rtems-bsd-program.c   | 13 +
>>   2 files changed, 24 insertions(+)
>>
>> diff --git a/rtemsbsd/include/machine/rtems-bsd-program.h
>> b/rtemsbsd/include/machine/rtems-bsd-program.h
>> index b2e542e..7c2837e 100644
>> --- a/rtemsbsd/include/machine/rtems-bsd-program.h
>> +++ b/rtemsbsd/include/machine/rtems-bsd-program.h
>> @@ -56,6 +56,9 @@ rtems_bsd_program_call_main(const char *name, int
>> (*main)(int, char **),
>>   void
>>   rtems_bsd_program_exit(int exit_code) __dead2;
>>   +void
>> +rtems_bsd_program_error(const char *, ...) __attribute__ ((__format__
>> (__printf__, 1, 2)));
>> +
>>   const char *
>>   rtems_bsd_program_get_name(void);
>>   @@ -69,14 +72,22 @@ void
>>   rtems_bsd_program_unlock(void);
>> #ifndef RTEMS_BSD_PROGRAM_NO_EXIT_WRAP
>> +  #undef exit
> 
> What is the reason for this #undef?
> 

I got warnings for printf in tcpdump for some reason so add the undef to
all symbols present.

Does it hurt having it present ?

>> #define exit(code) rtems_bsd_program_exit(code)
>>   #endif
>>   +#ifndef RTEMS_BSD_PROGRAM_NO_ERROR_WRAP
>> +  #undef error
>> +  #define error(fmt, ...) rtems_bsd_program_error(fmt, ## __VA_ARGS__)
>> +#endif
>> +
>>   #ifndef RTEMS_BSD_PROGRAM_NO_GETPROGNAME_WRAP
>> +  #undef getprogname
>> #define getprogname() rtems_bsd_program_get_name()
>>   #endif
>> #ifndef RTEMS_BSD_PROGRAM_NO_PRINTF_WRAP
>> +  #undef printf
>> #define printf(...) fprintf(stdout, __VA_ARGS__)
>>   #endif
>>   diff --git a/rtemsbsd/rtems/rtems-bsd-program.c
>> b/rtemsbsd/rtems/rtems-bsd-program.c
>> index 8edd8f9..7b5920e 100644
>> --- a/rtemsbsd/rtems/rtems-bsd-program.c
>> +++ b/rtemsbsd/rtems/rtems-bsd-program.c
>> @@ -52,6 +52,8 @@
>>   #include 
>>   #include 
>>   +#include 
>> +
>>   struct rtems_bsd_program_control {
>>   void *context;
>>   int exit_code;
>> @@ -116,6 +118,17 @@ rtems_bsd_program_exit(int exit_code)
>>   panic("unexpected BSD program exit");
>>   }
>>   +void
>> +rtems_bsd_program_error(const char *fmt, ...)
>> +{
>> +  va_list list;
>> +  va_start(list, fmt);
>> +  vfprintf(stderr, fmt, list);
>> +  fprintf(stderr, "\n");
>> +  va_end(list);
>> +  rtems_bsd_program_exit(1);
>> +}
>> +
> 
> It would be nice to keep the style of the files and this is STYLE(9)
> more or less.

Sure.

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

Re: [rtems-libbsd commit] Add BDS command support headers.

[Chris Johns]

On 17/06/2015 9:17 pm, Sebastian Huber wrote:
> 
> 
> On 16/06/15 05:21, Chris Johns wrote:
>> Module:rtems-libbsd
>> Branch:master
>> Commit:affed5e3f586860e2fd97445eaa20674dc4bcd25
>> Changeset:
>> http://git.rtems.org/rtems-libbsd/commit/?id=affed5e3f586860e2fd97445eaa20674dc4bcd25
>>
>>
>> Author:Chris Johns 
>> Date:  Tue Jun 16 13:20:15 2015 +1000
>>
>> Add BDS command support headers.
>>
>> ---
>>
>>   freebsd/contrib/tcpdump/tcpdump.c | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/freebsd/contrib/tcpdump/tcpdump.c
>> b/freebsd/contrib/tcpdump/tcpdump.c
>> index 32ffb45..00e44db 100644
>> --- a/freebsd/contrib/tcpdump/tcpdump.c
>> +++ b/freebsd/contrib/tcpdump/tcpdump.c
>> @@ -55,6 +55,8 @@ static const char rcsid[] _U_ =
>>   #define __need_getopt_newlib
>>   #include 
>>   #define setpriority(a, b, c)
>> +#include 
>> +#include 
> 
> Every RTEMS specific change should be in #ifdef __rtems__ sections. This
> is very helpful if you have to review files. This is missing in a couple
> of files.

In tcpdump.c there is '#if __rtems__' and so you are asking these always
be '#ifdef __rtems__' ? I will add the end comment.

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

Re: GSOC 2015: Configuration GUI

[Anand Krishnan]

On Thu, Jun 18, 2015 at 6:18 AM, Amar Takhar  wrote:

> On 2015-06-18 05:57 +0530, Anand Krishnan wrote:
> > Hi all,
> >
> > I've almost prepared the basic layout for the GUI. Also added some dummy
> event
> > handlers for File Menu.
> >
> > Any more suggestions before fetching the options?
>
> This is a great start!
>
> Have you thought about how you are going to lay out the tabs for multiple
> BSP
> configs + the tag headings?
>
> One option is to do multi-layered tabs along the top.  Another is tabs on
> the
> top and vertically (left side).
>
> I'll check it out now and post it when I get some good  results

>
> Amar.
>

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

Re: GSOC 2015: Configuration GUI

[Anand Krishnan]

Hi,


On Thu, Jun 18, 2015 at 10:45 AM, Anand Krishnan 
wrote:

>
>
> On Thu, Jun 18, 2015 at 6:18 AM, Amar Takhar  wrote:
>
>> On 2015-06-18 05:57 +0530, Anand Krishnan wrote:
>> > Hi all,
>> >
>> > I've almost prepared the basic layout for the GUI. Also added some
>> dummy event
>> > handlers for File Menu.
>> >
>> > Any more suggestions before fetching the options?
>>
>> This is a great start!
>>
>> Have you thought about how you are going to lay out the tabs for multiple
>> BSP
>> configs + the tag headings?
>>
>> One option is to do multi-layered tabs along the top.  Another is tabs on
>> the
>> top and vertically (left side).
>>
>> I'll check it out now and post it when I get some good  results
>

I've added the multilayered tabs. I tried both the ways that you mentioned
-> along the top and left. And I felt this was better. But I can revert to
the other one in no time.

link: https://github.com/anandkp92/waf/tree/waf/gui

>
>> Amar.
>>
>
> Thanks,
> Anand
>

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