date:20160601

Re: Driver complaint to SD Host Controller Specification 3.0

2016-06-01 Thread André Marques


Hello mudit,

Às 09:13 de 30-05-2016, Mudit Jain escreveu:

Hi all,

I have ported the code from the present FreeBSD.

Link : https://github.com/spark1729/rtems-libbsd/commits/rpi_sd_card

Kindly review the same and suggest changes.

The commits are a bit unstructured, the second last one being a huge 
one. I will be breaking it down into smaller and logical patches while 
submitting.


Files changed/added in the three commits are as follows :

freebsd/sys/dev/ofw/ofw_bus.h
freebsd/sys/dev/ofw/ofw_bus_if.c
freebsd/sys/dev/ofw/ofw_bus_if.h
freebsd/sys/dev/ofw/ofw_bus_subr.c
freebsd/sys/dev/ofw/ofw_bus_subr.h

freebsd/sys/sys/queue.h

freebsd/sys/contrib/libfdt/libfdt_env.h
freebsd/sys/dev/fdt/fdt_common.c
freebsd/sys/dev/fdt/fdt_common.h
freebsd/sys/dev/ofw/ofw_bus_subr.c
freebsd/sys/sys/slicer.h

freebsd/sys/dev/mbox/mbox_if.c
freebsd/sys/dev/mbox/mbox_if.h
freebsd/sys/dev/ofw/ofw_if.c
freebsd/sys/dev/ofw/ofw_if.h
freebsd/sys/dev/ofw/ofwvar.h
freebsd/sys/dev/ofw/openfirm.c
freebsd/sys/dev/ofw/openfirm.h
freebsd/sys/dev/sdhci/bcm2835_dma.c
freebsd/sys/dev/sdhci/bcm2835_dma.h
freebsd/sys/dev/sdhci/bcm2835_mbox.c
freebsd/sys/dev/sdhci/bcm2835_mbox.h
freebsd/sys/dev/sdhci/bcm2835_mbox_prop.h
freebsd/sys/dev/sdhci/bcm2835_sdhci.c
freebsd/sys/dev/sdhci/bcm2835_vcbus.h
freebsd/sys/dev/sdhci/sdhci.c
freebsd/sys/dev/sdhci/sdhci.h
freebsd/sys/dev/sdhci/sdhci_if.c
freebsd/sys/dev/sdhci/sdhci_if.h

Files added to the build process [ libbsd_waf.py ]

freebsd/sys/dev/ofw/ofw_bus_if.c
freebsd/sys/dev/ofw/ofw_bus_subr.c
freebsd/sys/dev/fdt/fdt_common.c
freebsd/sys/dev/ofw/ofw_bus_subr.c
freebsd/sys/dev/mbox/mbox_if.c
freebsd/sys/dev/ofw/ofw_if.c
freebsd/sys/dev/ofw/openfirm.c
freebsd/sys/dev/sdhci/bcm2835_dma.c
freebsd/sys/dev/sdhci/bcm2835_mbox.c
freebsd/sys/dev/sdhci/bcm2835_sdhci.c
freebsd/sys/dev/sdhci/sdhci.c
freebsd/sys/dev/sdhci/sdhci_if.c

Errors and how they were resolved :
1.  The *_if.m files were converted into *_if.c and *_if.h using the 
following script : Link 


2.  fdt and ofw support was added as the driver had dependencies on that.
3. /taskqueue_swi_giant/ global is not provided by RTEMS. That was 
solved by adding a new field to the /sdhci slot/ structure - /sdhci_tq/.
4.  BUS_PHYSADDR used in bcm_sdhci.c is a macro defined in 
arm/include/bus.h. This macro is copied bcm_sdhci.c. /


/
Presently the SD driver module is built from bcm_sdhci.c using the 
generic and other functions defined in sdhci.c. However for modularity 
a different


Question :
1. Presently I have just kept the bcm2835 specific code in /dev/sdhci/ 
directory. I don't think that would be ideal, I wanted to discuss the 
positioning of the bcm2835 specific files.
2. Presently the SD driver module is built from bcm_sdhci.c using the 
generic and other functions defined in sdhci.c. Is this fine ?
3. I have used the /.start_actual /in nexus-devices.h for /rpi_dma_res 
/as/0x7e007000. /Is this the correct value ?Link 

Note : I have not added the macro LIBBSP_ARM_RASPBERRYPI_BSP_H to 
bcm2835 specific code. I will be doing that.


waf builds everything that was added successfully.
/
/
Thanks
Mudit



Hello Mudit,

My feedback from a quick skim through your code:

There is already some mailbox support from Yang Quiao's last year GSOC, 
so if anything is missing from his work please improve it.


The ofw bus is not necessary for the sdhci driver in RTEMS, so that can 
be left out.


As Sebastian suggested, you need to follow the FreeBSD port guidelines, 
and also do not replace entire files (e.g..: sdhci.c and sdhci.h).


--André Marques

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

Re: Ada support on gcc-6 broken again

2016-06-01 Thread Jan Sommer


TOFU:

Ok the patch is now in trunk, gcc-6 and gcc-5.
If possible, it would be good to move to the next gcc-6 snapshot when it 
comes available.

Then, gnat should compile again with the rsb-4.12 tools.

Cheers,

  Jan



On Fri, May 27, 2016 at 9:08 AM, Jan Sommer 


wrote:


Am 2016-05-27 14:44, schrieb Joel Sherrill:


On May 27, 2016 7:17 AM, "Jan Sommer" 
wrote:



Hello,

building the current tools (gcc-6) from master with Ada support 
fails.
I will try to post the patch for that to gcc over the weekend (@Joel 
I



hope you don't mind me putting you CC for that).

Please.cc me on it.



Will do.

However as gcc-6.1 was just released a month ago, I guess it won't be



part of an official gcc-release anytime soon.

Is this a patch that impacts just RTEMS specific file(s)? Only this
branch?



Yes it's just changing a couple of lines in s-osinte-rtems.ads.
I haven't tried it with gcc-5 because RSB uses gcc-6 by default, but I
could submit a patch for it too as it won't break anything.



gcc 5, 6 and master probably should have the patch.

4.9 is mated to 4.11 so we would likely be best to not apply it unless 
it

is needed
for 4.11 as well.



It probably should have a gcc ticket.


Could we keep the fix as a patch until the gcc-version of the RSB



includes it natively?

I don't think the RSB builds Ada unless Chris slipped one by me. So 
it

doesn't matter unless it impacts other languages.



That's how I build the Ada compiler atm.
First the standard toolchain, then rtems, then toolchain with 
--with-ada

switch.



I think you can now build standard tool chain with Ada and then RTEMS.
Sebastian worked to get the FreeBSD networking .h files that are from 
POSIX

into newlib. That was the missing piece before and why you needed RTEMS
built in the middle.

If this doesn't work, then we want to know why. It would be a huge
improvement
to be able to do it in one sweep.



But Ada likely does build now with just newlib and not needing RTEMS 
so

adding it to the RSB for the targets it builds ob would be good.


For the current RSB-config rtems is still necessary, but if that 
changes

with the next library upgrade that would be nice.



With any luck, it just got a step easier. :)



Cheers,

   Jan


Best regards,


   Jan
___
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

RTEMS BSD Net on Atmel SAM Board

2016-06-01 Thread Isaac Gutekunst


Hi All,

I'm trying to bring up tHE Atmel SAMV71 Explained Ultra board with networking, 
and can't figure out how to. Does anyone have any quick pointers?



Isaac



To limit potential email traffic, this is my setup as of now:

I've compiled the BSP with --enable-networking, verified by sprinkling #error 
messages in the generated header files that it really was compiled with 
--enable-networkinG.


I've copied the following from the networking supplement:

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,
  NULL,
};



In Init, I call

rtems_bsdnet_initialize_network ();


My overall configuration #defines are as follows:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS   64
#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK512
#define CONFIGURE_MAXIMUM_DRIVERS  20

#define CONFIGURE_SWAPOUT_TASK_PRIORITY2

#define CONFIGURE_INIT_TASK_STACK_SIZE   RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_EXTRA_TASK_STACKS  RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_MAXIMUM_TASKS  rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_BARRIERS   rtems_resource_unlimited (10)
#define CONFIGURE_MAXIMUM_SEMAPHORES rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES rtems_resource_unlimited (4)
#define CONFIGURE_MAXIMUM_PARTITIONS rtems_resource_unlimited (2)
#define CONFIGURE_MAXIMUM_USER_EXTENSIONS8
#define CONFIGURE_MAXIMUM_TIMERS 8
#define CONFIGURE_UNIFIED_WORK_AREAS

#if 1
#define CONFIGURE_MAXIMUM_POSIX_KEYS 16
#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS  16
#define CONFIGURE_MAXIMUM_POSIX_THREADS  10
#define CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES  20
#define CONFIGURE_MAXIMUM_POSIX_MUTEXES  40
#endif

#define CONFIGURE_MICROSECONDS_PER_TICK  1000


#define CONFIGURE_UNIFIED_WORK_AREAS
#define CONFIGURE_UNLIMITED_OBJECTS

#define CONFIGURE_INIT

#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK 1

#include 

#include 
#define CONFIGURE_SHELL_COMMANDS_INIT
#define CONFIGURE_SHELL_COMMANDS_ALL
#include 

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

Re: RTEMS BSD Net on Atmel SAM Board

2016-06-01 Thread Isaac Gutekunst


A brief update: I've updated my configuration from a different example to be a 
bit more complete. It looks like it can't communicate with the PHY.

#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
  static char ethernet_address[6] = { 0x00, 0x04, 0x9F, 0x00, 0x5B, 0x21 };
#endif


static struct rtems_bsdnet_ifconfig netdriver_config = {
RTEMS_BSP_NETWORK_DRIVER_NAME,  /* name */
RTEMS_BSP_NETWORK_DRIVER_ATTACH,/* attach function */
NULL,   /* No more interfaces */
#if (defined (RTEMS_USE_BOOTP))
NULL,   /* BOOTP supplies IP address */
NULL,   /* BOOTP supplies IP net mask */
#else
"192.168.0.140",/* IP address */
"255.255.255.0",/* IP net mask */
#endif /* !RTEMS_USE_BOOTP */
#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
ethernet_address,   /* Ethernet hardware address */
#else
NULL,   /* Driver supplies hardware address */
#endif
0,  /* Use default driver parameters */
0,  /* mtu */
0,  /* rbuf_count */
0,  /* xbuf_count */
0,  /* port */
39   /* irq */
};



struct rtems_bsdnet_config rtems_bsdnet_config = {
&netdriver_config,
NULL,
0,  /* Default network task priority */
16 * 1024, /* Default mbuf capacity */
16 * 1024, /* Default mbuf cluster capacity */
"rtems",/* Host name */
"nodomain.com", /* Domain name */
"192.168.0.14", /* Gateway */
"192.168.0.1",  /* Log host */
{"192.168.0.1"  },  /* Name server(s) */
{"192.168.0.1"  },  /* NTP server(s) */
0,  /* efficiency */
0,  /* udp TX buffer */
0,  /* udp RX buffer */
0,  /* tcp TX buffer */
0,  /* tcp RX buffer */
};


I also added the network shell commands and can ping myself on 192.168.0.140. 
ifconfig atsamv0 shows:

* atsam0 *
Ethernet Address: 48:11:40:20:45:01
Address:192.168.0.140   Broadcast Address:192.168.0.255   Net mask:255.255.255.0
Flags: Up Broadcast Running Simplex Multicast
Send queue limit:50   length:0Dropped:0
-E- TimeOut ReadPhy


This matches the slow blinking of both LEDs at about 0.5Hz.

Isaac

On 06/01/2016 11:46 AM, Isaac Gutekunst wrote:

Hi All,

I'm trying to bring up tHE Atmel SAMV71 Explained Ultra board with networking, 
and can't figure out how to. Does anyone have any quick pointers?



Isaac



To limit potential email traffic, this is my setup as of now:

I've compiled the BSP with --enable-networking, verified by sprinkling #error 
messages in the generated header files that it really was compiled with 
--enable-networkinG.


I've copied the following from the networking supplement:

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,
  NULL,
};



In Init, I call

rtems_bsdnet_initialize_network ();


My overall configuration #defines are as follows:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS   64
#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK512
#define CONFIGURE_MAXIMUM_DRIVERS  20

#define CONFIGURE_SWAPOUT_TASK_PRIORITY2

#define CONFIGURE_INIT_TASK_STACK_SIZE   RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_EXTRA_TASK_STACKS  RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_MAXIMUM_TASKS  rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_BARRIERS   rtems_resource_unlimited (10)
#define CONFIGURE_MAXIMUM_SEMAPHORES rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES rtems_resource_unlimited (4)
#define CONFIGURE_MAXIMUM_PARTITIONS rtems_resource_unlimited (2)
#define CONFIGURE_MAXIMUM_USER_EXTENSIONS8
#define CONFIGURE_MAXIMUM_TIMERS 8
#define CONFIGURE_UNIFIED_WORK_AREAS

#if 1
#define CONFIGURE_MAXIMUM_POSIX_KEYS 16
#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS  16
#define CONFIGURE_MAXIMUM_POSIX_THREADS  10
#define CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES  20
#define CONFIGURE_MAXIMUM_POSIX_MUTEXES  40
#endif

#define CONFIGURE_MICROSECONDS_PER_TICK  1000


#define CONFIGURE_

Re: Serial port programming?

2016-06-01 Thread Michael Westfall

Ah, thanks. That helps.


On Wed, Jun 1, 2016 at 12:17 AM, Chris Johns  wrote:

> On 01/06/2016 01:50, Michael Westfall wrote:
>
>> Can someone point me to a tutorial on how to read and write serial ports
>> under RTEMS?
>>
>
> RTEMS supports termois. There are a number of examples of termios
> programming around. A quick search turned up
> https://en.wikibooks.org/wiki/Serial_Programming/termios. An 'ls /dev' in
> an RTEMS shell will show you the serial ports you have available.
>
> Chris
>



-- 
Mike Westfall
Control Systems Software Engineer
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS BSD Net on Atmel SAM Board

2016-06-01 Thread Isaac Gutekunst


I believe I solved all my problems. Not enough memory. After updating the 
linker script to use SDRAM, everything appears to be working well! (Knock on 
wood).

I've also been reminded that the ping shell command has a memory leak. It 
expects the kernel to free up memory after the command exits. It also appears 
as if doing
a ping -i .001 quickly swamps the system. I feel that it's also running out of 
memory. I'll look into it more tomorrow.


Consider my Ethernet woes solved for now. I'm still curious about these memory 
leaks in ping though.


Isaac


On 06/01/2016 02:06 PM, Isaac Gutekunst wrote:

A brief update: I've updated my configuration from a different example to be a 
bit more complete. It looks like it can't communicate with the PHY.

#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
  static char ethernet_address[6] = { 0x00, 0x04, 0x9F, 0x00, 0x5B, 0x21 };
#endif


static struct rtems_bsdnet_ifconfig netdriver_config = {
RTEMS_BSP_NETWORK_DRIVER_NAME,  /* name */
RTEMS_BSP_NETWORK_DRIVER_ATTACH,/* attach function */
NULL,   /* No more interfaces */
#if (defined (RTEMS_USE_BOOTP))
NULL,   /* BOOTP supplies IP address */
NULL,   /* BOOTP supplies IP net mask */
#else
"192.168.0.140",/* IP address */
"255.255.255.0",/* IP net mask */
#endif /* !RTEMS_USE_BOOTP */
#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
ethernet_address,   /* Ethernet hardware address */
#else
NULL,   /* Driver supplies hardware address */
#endif
0,  /* Use default driver parameters */
0,  /* mtu */
0,  /* rbuf_count */
0,  /* xbuf_count */
0,  /* port */
39   /* irq */
};



struct rtems_bsdnet_config rtems_bsdnet_config = {
&netdriver_config,
NULL,
0,  /* Default network task priority */
16 * 1024, /* Default mbuf capacity */
16 * 1024, /* Default mbuf cluster capacity */
"rtems",/* Host name */
"nodomain.com", /* Domain name */
"192.168.0.14", /* Gateway */
"192.168.0.1",  /* Log host */
{"192.168.0.1"  },  /* Name server(s) */
{"192.168.0.1"  },  /* NTP server(s) */
0,  /* efficiency */
0,  /* udp TX buffer */
0,  /* udp RX buffer */
0,  /* tcp TX buffer */
0,  /* tcp RX buffer */
};


I also added the network shell commands and can ping myself on 192.168.0.140. 
ifconfig atsamv0 shows:

* atsam0 *
Ethernet Address: 48:11:40:20:45:01
Address:192.168.0.140   Broadcast Address:192.168.0.255   Net mask:255.255.255.0
Flags: Up Broadcast Running Simplex Multicast
Send queue limit:50   length:0Dropped:0
-E- TimeOut ReadPhy


This matches the slow blinking of both LEDs at about 0.5Hz.

Isaac

On 06/01/2016 11:46 AM, Isaac Gutekunst wrote:

Hi All,

I'm trying to bring up tHE Atmel SAMV71 Explained Ultra board with networking, 
and can't figure out how to. Does anyone have any quick pointers?



Isaac



To limit potential email traffic, this is my setup as of now:

I've compiled the BSP with --enable-networking, verified by sprinkling #error 
messages in the generated header files that it really was compiled with 
--enable-networkinG.


I've copied the following from the networking supplement:

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,
  NULL,
};



In Init, I call

rtems_bsdnet_initialize_network ();


My overall configuration #defines are as follows:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS   64
#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK512
#define CONFIGURE_MAXIMUM_DRIVERS  20

#define CONFIGURE_SWAPOUT_TASK_PRIORITY2

#define CONFIGURE_INIT_TASK_STACK_SIZE   RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_EXTRA_TASK_STACKS  RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_MAXIMUM_TASKS  rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_BARRIERS   rtems_resource_unlimited (10)
#define CONFIGURE_MAXIMUM_SEMAPHORES rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES rtems_resource_un

Re: RTEMS BSD Net on Atmel SAM Board

2016-06-01 Thread Pavel Pisa

Hello Isaac,

On Wednesday 01 of June 2016 23:09:39 Isaac Gutekunst wrote:
> I believe I solved all my problems. Not enough memory. After updating the
> linker script to use SDRAM, everything appears to be working well! (Knock
> on wood).

I think that SAM V71 setup with 2 MB of external SDRAM is not much
above minimal limit for use of RTEMS with BSD networking.
If the single chip solution with only 128kB of internal SRAM
is considered (may be with additional 128kB which can be borrow
for some buffer from the instruction TCM) then it cannot
be used with libBSD based networking. So it would worth
to consider lwIP. I hope that it would be integrated to
the RTEMS file operations API as part of this year GSoC.
So this option worth to be considered to support
networking on the small systems.

On the other hand, BSD based networking is much more
capable.

Best wishes,

Pavel

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

Re: Driver complaint to SD Host Controller Specification 3.0

Re: Ada support on gcc-6 broken again

RTEMS BSD Net on Atmel SAM Board

Re: RTEMS BSD Net on Atmel SAM Board

Re: Serial port programming?

Re: RTEMS BSD Net on Atmel SAM Board

Re: RTEMS BSD Net on Atmel SAM Board

7 matches

Site Navigation

Mail list logo

Footer information