Re: JFFS2

2018-07-12 Thread Russell Haley 
While this is maybe not a currently viable alternative, it's most likely
port-able (meaning could be ported) to work with libbsd?

https://en.wikipedia.org/wiki/CHFS

For what it's worth,

Russ

On Thu, Jul 12, 2018 at 1:27 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> for NAND flashes you can use YAFFS2:
>
> https://git.rtems.org/sebh/rtems-yaffs2.git/
>
> You need a license for commercial products:
>
> https://yaffs.net/yaffs-licence-faqs
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: rsb

2018-07-06 Thread Russell Haley 
On Fri, Jul 6, 2018 at 11:59 AM, Russell Haley  wrote:

>
>
> On Fri, Jul 6, 2018 at 11:41 AM, Siddons, David  wrote:
>
>> I just tried again to clone rsb:
>>
>>
>> ~/development/rtems$ git clone git://git.rtems.org/rtems-sour
>> ce-builder.git rsb
>> Cloning into 'rsb'...
>> fatal: repository 'https://git.rtems.org//rtems-source-builder.git/' not
>> found
>>
>
> Interesting that you're git clone command specifies the git protocol
> (git://) bu then searches for "https://git...;. I had that happen once
> because I had done something odd when I attempted to create the local
> repository, but I forget the details...
>
> Russ
>

Sorry, this message was supposed to go to the list.

>
>> Looking at the contents of this link gets:
>>
>>
>> No repositories found
>>
>>
>> I found this same clone command in various places throughout the RTEMS
>> documentation. Am I doing something wrong?
>>
>>
>> Pete.
>>
>>
>>
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Fw: Lua was Re: Quickstart Build instructions

2018-05-07 Thread Russell Haley 
On Mon, Apr 9, 2018 at 11:02 PM, Chris Johns <chr...@rtems.org> wrote:

> On 10/04/2018 15:58, Russell Haley wrote:
> > On Mon, Apr 9, 2018 at 5:53 PM, Chris Johns <chr...@rtems.org
> > <mailto:chr...@rtems.org>> wrote:
> > On 10/04/2018 10:40, Gedare Bloom wrote:
> >     > On Mon, Apr 9, 2018 at 4:17 PM, Russell Haley <
> russ.ha...@gmail.com <mailto:russ.ha...@gmail.com>
> > > <mailto:russ.ha...@gmail.com <mailto:russ.ha...@gmail.com>>>
> wrote:
> > > I'd like to start with getting other Lua scripts
> running. My goal is
> > > to load a library called penlight that's a few dozens
> of files. Is
> > > there a utility for creating and loading resources?
> I'll also look
> > > at compiling the files using the luac compiler, but
> that's outside
> > > of rtems.
> > >
> > > No worries. There is evolving support (pretty mature by now) for
> dynamically
> > > loading object code, if that is what you mean: the Runtime Loader
> (RTL).  I
> > > don't have any experience with it though. Chris Johns is the
> expert on that topic.
> > >
> >
> > The support is based around the standard calls 'dlopen' etc. You can
> load ELF
> > object files. You do need a symbol table in the kernel and a simple
> makefile
> > recipe can be found in the testsuite which works on the sparc
> simulator:
> >
> > https://git.rtems.org/rtems/tree/testsuites/libtests/
> Makefile.am#n319
> > <https://git.rtems.org/rtems/tree/testsuites/libtests/
> Makefile.am#n319>
> >
> >  (search for TEST_dl01 in the Makefile.am if the line has moved)
> >
> > Note, the erc32 sim does not have access to a host's file system so
> you will
> > need to package the object files into a tar file just as the test
> does.
> >
> > Hi Chris, good to hear from you. Yes, the non-filesystem is what I'm
> trying to
> > deal with. Lua can run as C or as Lua scripts. The dlopen support is
> excellent
> > and I'll look into that when I start loading C. There are many fine Lua
> wrappers
> > for some of the best C tools. Since, I'm trying to load lua scripts, the
> tar
> > package sounds like what I need to look at first.
>
> I did wonder what you are loading.
>
> > Lua scripts can be loaded as a 'string' buffer (char array), or from a
> file.
> > Either of those methods can load a text file or a Lua VM binary. Using
> binary is
> > apparently faster to load, but must be compiled for the same
> architecture. The
> > run speed is the same.
>
> Python is similar.
>
> > A simple Lua script to load a second module would look like this:
> >
> > local my_lib = require('mylib.init')
> > local new_val = my_lib.dosomething()
> >
> > The require() function loads the file from a filesystem based on the
> > package.path string. On my windows box, it looks like this:
> >
> > .\?.lua;C:\Program Files (x86)\LuaRocks\lua\?.lua;C:\Program Files
> > (x86)\LuaRocks\lua\?\init.lua;C:\Program Files
> > (x86)\LuaRocks\?.lua;C:\Users\russh\scripts\?\init.lua;C:\
> Users\russh\scripts\?.lua;C:\Users\russh;C:\Program
> > Files (x86)\WinLua\Lua\5.3\bin\?53.dll;
> >
> > So, the require('mylib.init') would get translated so the '.' becomes
> the path
> > separator on the filesystem, and any '?' in the package.path is replaced
> with
> > the package name, eventually landing on C:\Users\russh\scripts\mylib\
> init.lua.
> > Let's see how that translates to RTEMS...
> >
>
> Please keep us updated with your progress.
>

Hi everyone! Just thought I'd keep you posted. What I've learned so far is
that running Lua as an embedded language has it's own quirks. One of the
most interesting is getting and
loading Lua scripts that will comprise the libraries needed to be effective
when writing Lua. While it's possible to just cram the scripts into a C/C++
file, I'm finding encoding and debugging things can be pretty tricky. There
are a few "minifiers" that I'm fumbling with right now, but I just found
one that looks really good called luapak.

Hopefully I'll have something to show for those efforts soon. I'm going to
try packaging a couple of lua only files that I like using and embed them
in a test application.

Cheers,
Russ


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

Re: GSOC'18 project description

2018-04-30 Thread Russell Haley 
On Mon, Apr 30, 2018 at 8:54 PM, Chris Johns <ch...@contemporary.net.au>
wrote:

> On 01/05/2018 08:35, Russell Haley wrote:
> >
> > Hi! I wanted to add that DTrace is an unmatched tool for kernel level
> tracing.
> > It provides "zero" overhead tracing by actually re-writing the in-memory
> process
> > images with instrumented instructions. In FreeBSD, it can be used to
> count
> > individual system calls down to the level that would typically require a
> > debugger (without the debugger overhead).
>
> +1 for dtrace, I would love to see it on RTEMS. It is a clean proven
> design with
> a documented and understood user interface.
>
> > I know I mentioned DTrace a while back on this list, but didn't have much
> > information to provide. Ping me if you want to know more. I'm not an
> expert, but
> > have used it a little to trace system calls on a BBB in FreeBSD.
> >
> > As I have said before, DTrace may be way outside a GSOC project, but
> want to
> > make sure it gets mentioned in the context of this discussion.
>
> I think it is at this point in time. We need to be careful when looking
> into
> packages at integrate deep into RTEMS, if there are tricks with the VM,
> exec, or
> user support via shells etc we tend to struggle.
>

Think of DTrace like a debugger, but it's in the kernel? (I'm sure that
doesn't help).  Too tired to expand  tonight.

Russ

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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

2018-04-14 Thread Russell Haley 
On Thu, Apr 12, 2018 at 11:40 PM, Sebastian Huber <sebastian.huber@embedded-
brains.de> wrote:

> Hello Russell,
>
> - Am 12. Apr 2018 um 23:41 schrieb Russell Haley russ.ha...@gmail.com:
>
> > Hi Sebastian,
> >
> > The Tq website doesn't  seem to provide much detail without giving them
> contact
> > information. Can I ask if you had specific criteria that made you choose
> that
> > board from Tq group?
>
> it was selected by a customer due to its requirements. TQ has usually a
> long product availability.
>

A very reasonable requirement, component end-of-life pain is real. However,
at the last company I worked used Digi ccmx53 soms because they claimed
long hardware support. After a few years it became apparent that Digi would
not support Linux kernel updates and there was no way to get at the
proprietary firmware for sub-components - notably the WiFi radio drivers. I
involuntarily spit on the floor if I hear the name RedPine.

Not that you'll have kernel problems, but I thought I'd share that. They
had settled on Phytec for their IMX SOMs but I don't know what they chose
for their Marvell solutions.

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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

2018-04-12 Thread Russell Haley 
Hi Sebastian,

The Tq website doesn't  seem to provide much detail without giving them contact 
information. Can I ask if you had specific criteria that made you choose that 
board from Tq group?

Thanks
Russ
Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Sebastian Huber
Sent: Thursday, April 12, 2018 1:13 AM
To: JunBeom Kim (EmbedCoreTech); users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

On 12/04/18 10:11, JunBeom Kim (EmbedCoreTech) wrote:
> Please confirm that you completed to test RTEMS on i.MX7D SDB board.
> If you confirm this, I will purchase i.MX7D SDB board.

No, I used this board:

https://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma7x/extb/Main/productdetail/

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

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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

2018-04-11 Thread Russell Haley 
On Mon, Apr 9, 2018 at 6:50 PM, JunBeom Kim (EmbedCoreTech) <
jb...@e-coretech.kr> wrote:

> Dear Sir,
>
> Is there RTEMS users for running RTEMS for PICO-PI-IMX7 board ?
>
> I purchased PICO-PI-IMX7 from Wanboard.
> https://www.wandboard.org/products/android-things/PICO-PI-IMX7/
>
> I am tring to test RTEMS on PICO-PI-IMX7 using RTEMS current version for
> i.MX7D SDB board.
>

Ooooh, this is a sexy little kit...

https://www.variscite.com/products/system-on-module-som/cortex-a7/var-som-mx7-nxp-freescale-imx-7/


>
> On referencing, when I check PICO-PI-IMX7 board, there is u-boot only.
> Also, there is eMMC memory only. (It was headache in first)
> Therefore, I needed additional work for writing your modified u-boot
> and/or for preparing RTEMS image FAT32 storage. Additional work means that
> u-boot writing by dd command and eMMC partition configuration by fdisk
> command after Linux kernel is booting.
>
> At this time, I removed Linux kernel image on eMMC storage and I am ready
> to test RTEMS image only.
> Also, If user use "ums 0 mmc 0" command in u-boot, user can replace RTEMS
> image and dtb file easily on PC(Windows or Linux Desktop).
>
> As I check difference between PICO-PI-IMX7 and i.MX7D SDB, UART debug port
> number is different.
>  - PICO-PI-IMX7 : UART5 (serial4)
>  - i.MX7D SDB : UART1 (serial0)
>
> After I check current RTEMS bsp source, I modified console-config.c due to
> UART port number change in below;
>
> < Original code : for UART1 debug port >
> static imx_uart_context imx_uart_instances[7];
> static imx_uart_context *imx_uart_console = _uart_instances[0];
>
> < Modified code : for UART5 debug port >
> static imx_uart_context imx_uart_instances[7];
> static imx_uart_context *imx_uart_console = _uart_instances[4];
>
> Even though I modified this, there is not any output after running RTEMS.
>
> I am checking UART configuration by FDT.
>
> As I check imx_uart_probe() function of console-config.c, there is
> "chosen" and "stdout-path" keyword in below;
>
> static void imx_uart_probe(void)
> {
>   const void *fdt;
>   int node;
>   int offset;
>   const char *console;
>   size_t i;
>
>   fdt = bsp_fdt_get();
>   node = fdt_path_offset(fdt, "/chosen");
>
>   console = fdt_getprop(fdt, node, "stdout-path", NULL);
>   if (console == NULL) {
> console = "";
>   }
>   ...
> }
>
> I think that there should be declaration for "stdout-path" of "chosen"
> area in dts(including dtsi) source file.
>
> As I check dts files on lastest Linux kernel for both i.MX7D SDB and
> PICO-IMX7, there is not "stdout-path" information of "chosen".
>
> I attached files related with this.
>
>  - i.MX7D SDB : imx7d-sdb.dts with imx7d.dtsi, imx7s.dtsi
>  - PICO-IMX7 : imx7d-pico-pi.dts with imx7d-pico.dtsi, imx7d.dtsi,
> imx7s.dtsi
>
> Because there is blank information for "chosen" in imx7s.dtsi, I added
> "stdout-path" in imx7d-pico-dtsi.
>
> < imx7s.dtsi >
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> /*
>  * The decompressor and also some bootloaders rely on a
>  * pre-existing /chosen node to be available to insert the
>  * command line and merge other ATAGS info.
>  * Also for U-Boot there must be a pre-existing /memory node.
>  */
> chosen {}; ==> "there is not any information for stdout-path"
> memory { device_type = "memory"; };
>   ...
> }
>
> < My modified imx7d-pico.dtsi >
>
> / {
> model = "Technexion Pico i.MX7D Board";
> compatible = "technexion,imx7d-pico", "fsl,imx7d";
>
> memory@8000 {
> reg = <0x8000 0x8000>;
> };
>
> chosen {
> stdout-path = "; ==> "I added stdout-path
> information".
> };
>
>   ...
> }
>
> After I modified imx7d-pico.dtsi, I made imx7d-pico-pi.dtb.
>
> Finally, I tried to run RTEMS using the revised dtb file. But, there is
> not any serial output.
>
> On referencing, there is not JTAG debug port in PICO board, It is very
> difficult to debug current RTEMS for i.MX7D.
>
> If there is mistake in my trial step, please let me know that.
>
> Best Regards,
> JunBeom Kim
> ~~
> President / EmbedCoreTech
> Phone: +82-31-396-5584
> Fax: +82-504-065-5720
> Mobile:+82-10-6425-5720
> Email: jb...@e-coretech.kr
> Web: www.e-coretech.kr
> ~~
>
>
>
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Fw: Lua was Re: Quickstart Build instructions

2018-04-09 Thread Russell Haley 
On Mon, Apr 9, 2018 at 5:53 PM, Chris Johns <chr...@rtems.org> wrote:

> On 10/04/2018 10:40, Gedare Bloom wrote:
> > On Mon, Apr 9, 2018 at 4:17 PM, Russell Haley <russ.ha...@gmail.com
> > <mailto:russ.ha...@gmail.com>> wrote:
> > I'd like to start with getting other Lua scripts running. My
> goal is
> > to load a library called penlight that's a few dozens of
> files. Is
> > there a utility for creating and loading resources? I'll
> also look
> > at compiling the files using the luac compiler, but that's
> outside
> > of rtems.
> >
> > No worries. There is evolving support (pretty mature by now) for
> dynamically
> > loading object code, if that is what you mean: the Runtime Loader
> (RTL).  I
> > don't have any experience with it though. Chris Johns is the expert on
> that topic.
> >
>
> The support is based around the standard calls 'dlopen' etc. You can load
> ELF
> object files. You do need a symbol table in the kernel and a simple
> makefile
> recipe can be found in the testsuite which works on the sparc simulator:
>
> https://git.rtems.org/rtems/tree/testsuites/libtests/Makefile.am#n319
>
>  (search for TEST_dl01 in the Makefile.am if the line has moved)
>
> Note, the erc32 sim does not have access to a host's file system so you
> will
> need to package the object files into a tar file just as the test does.
>
Hi Chris, good to hear from you. Yes, the non-filesystem is what I'm trying
to deal with. Lua can run as C or as Lua scripts. The dlopen support is
excellent and I'll look into that when I start loading C. There are many
fine Lua wrappers for some of the best C tools. Since, I'm trying to load
lua scripts, the tar package sounds like what I need to look at first.

Lua scripts can be loaded as a 'string' buffer (char array), or from a
file. Either of those methods can load a text file or a Lua VM binary.
Using binary is apparently faster to load, but must be compiled for the
same architecture. The run speed is the same.

A simple Lua script to load a second module would look like this:

local my_lib = require('mylib.init')
local new_val = my_lib.dosomething()

The require() function loads the file from a filesystem based on the
package.path string. On my windows box, it looks like this:

.\?.lua;C:\Program Files (x86)\LuaRocks\lua\?.lua;C:\Program Files
(x86)\LuaRocks\lua\?\init.lua;C:\Program Files
(x86)\LuaRocks\?.lua;C:\Users\russh\scripts\?\init.lua;C:\Users\russh\scripts\?.lua;C:\Users\russh;C:\Program
Files (x86)\WinLua\Lua\5.3\bin\?53.dll;

So, the require('mylib.init') would get translated so the '.' becomes the
path separator on the filesystem, and any '?' in the package.path is
replaced with the package name, eventually landing on
C:\Users\russh\scripts\mylib\init.lua. Let's see how that translates to
RTEMS...

Thanks!
Russ



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

Re: Fw: Lua was Re: Quickstart Build instructions

2018-04-09 Thread Russell Haley 
On Mon, Apr 9, 2018 at 7:39 AM, Joel Sherrill <j...@rtems.org> wrote:

> Is it building and working now? :)
>

Yes, I'm able to run Lua 5.3 with the sparc erc32 BSP. I'm hoping to clean
it up tonight and share it on the list in the next few days. There is also
a tool by the lua team called srlua to create an executable from lua
scripts (wraps the scripts in a standardized exe) that I'd like to examine,
which may be very effective for my needs. Unfortunately the repo that I
built lua from does not build the luac compiler, which I suspect I will
need at some point...

Russ

>
> On Mon, Apr 9, 2018 at 9:28 AM, Russell Haley <russ.ha...@gmail.com>
> wrote:
>
>> Sorry for the direct mail, Gedare.  The Lua mailing list I'm on
>> automatically forwards to all users in the email because it re-writes the
>> return mail address but leaves the persons name on it. I keep forgetting
>> that rtems mailing list does not.
>>
>> Original question below...
>> Thanks
>> Russ
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>> *From: *Russell Haley <russ.ha...@gmail.com>
>> *Sent: *Sunday, April 8, 2018 10:51 PM
>> *To: *Gedare Bloom
>> *Subject: *Re: Lua was Re: Quickstart Build instructions
>>
>> Thanks for the help! I've managed to load a lua script from a string in
>> my C application. While novel, that in itself isn't very functional. I'll
>> need to figure out how to run other scripts as well as C based components.
>>
>> I'd like to start with getting other Lua scripts running. My goal is to
>> load a library called penlight that's a few dozens of files. Is there a
>> utility for creating and loading resources? I'll also look at compiling the
>> files using the luac compiler, but that's outside of rtems.
>>
>> Very exciting!
>> Russ
>>
>> On Sun, Apr 1, 2018 at 5:24 AM, Gedare Bloom <ged...@rtems.org> wrote:
>>
>>> On Sun, Apr 1, 2018 at 1:52 AM, Russell Haley <russ.ha...@gmail.com>
>>> wrote:
>>> >
>>> >
>>> > On Fri, Mar 30, 2018 at 12:48 PM, Russell Haley <russ.ha...@gmail.com>
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Mar 30, 2018 at 7:54 AM, Joel Sherrill <j...@rtems.org>
>>> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Mar 30, 2018 at 1:05 AM, Russell Haley <russ.ha...@gmail.com
>>> >
>>> >>> wrote:
>>> >>>>
>>> >>>> Thanks Joel. I haven't looped back to test if it was my mistake or
>>> >>>> something else so I'll assume my mistake for now.
>>> >>>>
>>> >>>> Either way, I'm able to build and run the examples_v2 repository
>>> against
>>> >>>> erc32, so... YAY!
>>> >>>>
>>> >>>> I'd like to build Lua 5.3, do I just build the static lib "a" file
>>> and
>>> >>>> include it in a test application? Would that happen in RTEMS proper
>>> or in
>>> >>>> waf? I need sleep now but any suggestions would be grand.
>>> >>>
>>> >>>
>>> >>> Porting Lua was an early GSoC project. Some information is here.:
>>> >>>
>>> >>> https://devel.rtems.org/wiki/Packages/LUA
>>> >>>
>>> >>> That effort predates the RSB but the proper solution would be to have
>>> >>> an RSB recipe for it. My understanding is that it was quite easy to
>>> build
>>> >>> for RTEMS.
>>> >>>
>>> >>> https://github.com/lparam/rtems-liblua appears to be enough to help
>>> you
>>> >>> build it.
>>> >>>
>>> >>> Needs an RSB recipe though. :)
>>> >>
>>> >>
>>> >> That would be great. I've managed to get lua 5.3 built and installed
>>> from
>>> >> the github repo by lparam. I've run out of time but will clean it up
>>> >> tonight. The SGOC link seems to be pointing to a modified/extended
>>> lua build
>>> >> and the link to the source code is dead.
>>> >>
>>> >> I'll try modifying the hello world example tonight as well and see
>>> what I
>>> >> get.
>>> >
>>> >
>>> > So building liblua.a was pretty straightforward as a "Ken" has already
>>> done
>>&g

Re: Lua was Re: Quickstart Build instructions

2018-03-31 Thread Russell Haley 
On Fri, Mar 30, 2018 at 12:48 PM, Russell Haley <russ.ha...@gmail.com>
wrote:

>
>
> On Fri, Mar 30, 2018 at 7:54 AM, Joel Sherrill <j...@rtems.org> wrote:
>
>>
>>
>> On Fri, Mar 30, 2018 at 1:05 AM, Russell Haley <russ.ha...@gmail.com>
>> wrote:
>>
>>> Thanks Joel. I haven't looped back to test if it was my mistake or
>>> something else so I'll assume my mistake for now.
>>>
>>> Either way, I'm able to build and run the examples_v2 repository against
>>> erc32, so... YAY!
>>>
>>> I'd like to build Lua 5.3, do I just build the static lib "a" file and
>>> include it in a test application? Would that happen in RTEMS proper or in
>>> waf? I need sleep now but any suggestions would be grand.
>>>
>>
>> Porting Lua was an early GSoC project. Some information is here.:
>>
>> https://devel.rtems.org/wiki/Packages/LUA
>>
>> That effort predates the RSB but the proper solution would be to have
>> an RSB recipe for it. My understanding is that it was quite easy to build
>> for RTEMS.
>>
>> https://github.com/lparam/rtems-liblua appears to be enough to help you
>> build it.
>>
>> Needs an RSB recipe though. :)
>>
>
> That would be great. I've managed to get lua 5.3 built and installed from
> the github repo by lparam. I've run out of time but will clean it up
> tonight. The SGOC link seems to be pointing to a modified/extended lua
> build and the link to the source code is dead.
>
> I'll try modifying the hello world example tonight as well and see what I
> get.
>

So building liblua.a was pretty straightforward as a "Ken" has already done
the heavy lifting in the makefile. I can call gmake as:

gmake ARCH=sparc-rtems5 BSP=erc32 BSP_BASE=~/development/rtems/5

and "make install" puts liblua.a in the correct directory. But I am getting
a linking errors with my example code that seem to imply a missing math
library? I copied the RTEMS hello example and added the Lua C example from
the Programming in Lua book (4th edition for 5.3). The files and build
output follow.

//test-lua.c
#include 
#include 
#include 
#include 

//This is the reference to the lua interpreter
lua_State* L;

rtems_task Init(
rtems_task_argument ignored
)
{
lua_State *L = luaL_newstate();
luaL_openlibs(L);
char buff[256] = "print('Hello from Lua')";
//Test of basic lua functionality
int error;
error = luaL_loadstring(L, buff);
if(error)
{
fprintf(stderr, "%s\n", lua_tostring(L,-1));
lua_pop(L,1);
}
lua_close(L);
return 0;
}

/* NOTICE: the clock driver is explicitly disabled */
#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM

#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_MAXIMUM_TASKS 1

#define CONFIGURE_INIT
#include 
/* end of file */


#wscript
# Copyright 2018 Russell Haley (russ.ha...@gmail.com)
# Copyright 2013 Gedare Bloom (ged...@rtems.org)
#
# This file's license is 2-clause BSD as in this distribution's LICENSE.2
file.
#

# Waf build script for a Lua test harness
import rtems_waf.rtems as rtems

def build(bld):
rtems.build(bld)

bld.includes = ['.
/home/russellh/development/rtems/5/sparc-rtems5/erc32/lib/include']

bld.read_stlib('lua',
paths=['/home/russellh/development/rtems/5/sparc-rtems5/erc32/lib/'])
bld(features = 'c cprogram',
target = 'test-lua.exe',
source = ['test-lua.c'],
use = 'lua')


#output

russellh@g1 ~/d/e/lua53-test> waf -v
Waf: Entering directory
`/usr/home/russellh/development/examples-v2/build/sparc-rtems5-erc32'
[2/3] Linking ../build/sparc-rtems5-erc32/lua53-test/test-lua.exe
22:33:27 runner ['/home/russellh/development/rtems/5/bin/sparc-rtems5-gcc',
'-qrtems', '-B/home/russellh/development/rtems/5/sparc-rtems5/lib/',
'-B/home/russellh/development/rtems/5/sparc-rtems5/erc32/lib/', '--specs',
'bsp_specs', '-mcpu=cypress', '-mcpu=cypress', '-ffunction-sections',
'-ffunction-sections', '-fdata-sections', '-fdata-sections',
'-Wl,--gc-sections', 'lua53-test/test-lua.c.2.o',
'-o/usr/home/russellh/development/examples-v2/build/sparc-rtems5-erc32/lua53-test/test-lua.exe',
'-Wl,-Bstatic',
'-L/home/russellh/development/rtems/5/sparc-rtems5/erc32/lib', '-llua',
'-Wl,-Bdynamic']
/home/russellh/development/rtems/5/sparc-rtems5/erc32/lib/liblua.a(lobject.o):
In function `numarith':
lobject.c:(.text+0x570): undefined reference to `powf'
lobject.c:(.text+0x598): undefined reference to `floorf'
lobject.c:(.text+0x5c4): undefined reference to `fmodf'
/home/russellh/development/rtems/5/sparc-rtems5/erc32/lib/liblua.a(lvm.o):
In function `luaV_tointeger':
lvm.c:(.text+0x308): undefined reference to `flo

Re: Quickstart Build instructions

2018-03-27 Thread Russell Haley 
On Tue, Mar 27, 2018 at 10:14 PM, Russell Haley <russ.ha...@gmail.com>
wrote:

> Hi, the quick start indicates using ./bootstrap -p, but using said
> parameter only results in the error/hep output. Using ./bootstrap without
> any parameters started the the process for me?
>
> https://docs.rtems.org/branches/master/user/start/index.html
>
> Sorry, I'm tired and forgot half the email:

 I'm attempting to build on FreeBSD 11.

pwd
/usr/home/russellh/development/rtems/kernel/rtems

russellh@g1 ~/d/r/k/rtems> uname -a
FreeBSD g1.highfell.home 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue
Nov 14 06:12:40 UTC 2017
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
amd64
russellh@g1 ~/d/r/k/rtems> ./bootstrap -h

usage: bootstrap [-c|-p|-h] [-q][-v]

options:
-c .. clean, remove all aclocal/autoconf/automake generated files
-h .. display this message and exit
-H .. regenerate headers.am files
-q .. quiet, don't display directories
-v .. verbose, pass -v to autotools

russellh@g1 ~/d/r/k/rtems> ./bootstrap -p
unknown option -p

usage: bootstrap [-c|-p|-h] [-q][-v]

options:
-c .. clean, remove all aclocal/autoconf/automake generated files
-h .. display this message and exit
-H .. regenerate headers.am files
-q .. quiet, don't display directories
-v .. verbose, pass -v to autotools

russellh@g1 ~/d/r/k/rtems>

echo $SHELL
/usr/local/bin/fish


Thanks,
> Russ
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: GSoC'18-Introduction

2018-02-28 Thread Russell Haley 
On Wed, Feb 28, 2018 at 3:24 AM, Udit agarwal  wrote:
> Hi,
> Sorry for late reply, i am having my mid term examinations ongoing.
>
> So as of now, I'm having following two short term tasks:
>   *Adding a check on targets that needs FDT , and then raising an
> error/warning rather then a crash if missing FDT
>   *Implementation of getentropy() on BBB
>
> For the first task, i did debug a bit and found that in case of missing FDT,
> during kernel memory initialization i.e during mi_startup()(here), after few
> iterations the call function (On line 306) raises a
> RTEMS_FATAL_SOURCE_EXCEPTION error which as described here occurs during
> memory access violation. So, wrapping it with a different an exception
> handler, might allow us raise a more specific error regarding missing FDT
> blob. Do let me know if i'm on a right track! Here are the update logs. I
> have wrapped the the mi_startup with multiple printfs for debugging, that
> makes it a bit clumsy but i guess i need to stick to it before getting my
> Jlink segger EDU, probably in few days :0.
>
> For getentropy(), It looks like FreeBSD uses another similar sys call
> read_random as described here. getentropy() seems to be a part of OpenBSD.

FreeBSD uses Fortuna, which is a successor to the Yarrow toolset (an
excellent package for it's day).
https://en.wikipedia.org/wiki/Yarrow_algorithm

> Implementing and Benchmarking SDIO driver seems to be a great project for
> GSoC, but as per its current status (here) , it's partially developed.(the
> webpage seems to be a bit outdated, i'll confirm from their maintainers).
> Till then i'll study more about it's implementation.
> Thank you mentors for your continuous help.

Not sure what you mean by partially developed. The stack has been
committed to the HEAD revision. I have used the MMCCAM SDIO driver on
FreeBSD for the mmc card on a Beaglebone. The code is quite solid and
there is a port for IMX hardware (indicating maturity). Ilya has code
for a Broadcom Wi-Fi chipset here:
https://github.com/kibab/freebsd/tree/mmcam-new/usr.bin/sdiotool.

Regardless of Wi-Fi, you could create an RTEMS image with the standard
SDHC driver sets and an image with CAMMMC stack in place and then
measure the performance of the two. (I say that like I know how libbsd
works but I don't).

As a note, innovative software can sit around in FreeBSD for a
very...long...time before someone comes along and pushes it into the
main code base. There is a huge amount of code that goes dead just
waiting for someone to say "hey, I tested this and it's good." I don't
expect the SDIO driver to die, but I wouldn't go by the wiki.

I'm sorry you haven't received any response on FreeBSD-arm@ about your
Wi-Fi card. Adrian Chadd is the guy to talk to about the Atheros
Hardware Abstraction Layer (which is what holds back your cards
support). I've spoken to him about other cards and most of the code is
there and it just needs to be wired together (I think it says that on
the wiki too).  If you're really keen on getting it supported, start
doing some research on the driver layout and the HAL and ask a
technical question in the same thread. He may pipe up. The other thing
to do is sit on IRC and ask questions. It's a little hit and miss
depending on Time Zones, but the communication is much more open.

Russ

> Regards,
> Udit agarwal
>
> On Wed, Feb 28, 2018 at 10:22 AM, Chris Johns  wrote:
>>
>> On 28/02/2018 15:37, Christian Mauderer wrote:
>> > Yes, seems that I misunderstood it. So OpenOCD will remain on top of the
>> > recommendation list.
>>
>> For open solutions currently it seems so.
>>
>> >
>> >>> As a positive report: I have a quite stable setup with the Segger
>> >>> J-Link
>> >>> EDU.
>> >>
>> >> I do not run Linux and do not put Macs close to hardware so I cannot
>> >> run their
>> >> closed source GDB server. I will stick with a fully open solution I can
>> >> control
>> >> and fix.
>> >
>> > Most of the time I prefere open solutions too. I had some problems with
>> > OpenOCD on another target and bought the J-Link for that one. I only 
>> > re-used
>> > it for the Beagle and it run quite well.
>>
>> Nice. Please add it to the Wiki and some instructions if you feel it is
>> needed.
>> It should be up to users to decide based on their needs and budget.
>>
>> >>
>> >>> The EDU is a affordable variant with the disadvantage that it must
>> >>> only be used for non-commericial purpose.
>> >>
>> >> Ouch, messy. If I am paid to work on open source is that a
>> >> non-commmercial
>> >> purpose or commercial purpose? What if I am paid more for coding and I
>> >> debug for
>> >> free? ;)
>> >
>> > Same problem as allways with licensing. I would expect that GSoC is more
>> > educationall than commercial. But it's an edge case.
>>
>> Agreed.
>>
>> > For my applications I dont have a problem to distinguish because we have
>> > another debugger at work. So I can separate these quite well.
>>
>> For a BBB?

Re: GSoC'18-Introduction

2018-02-26 Thread Russell Haley 
On Mon, Feb 26, 2018 at 12:54 PM, Christian Mauderer <l...@c-mauderer.de> wrote:
> Am 26.02.2018 um 18:01 schrieb Russell Haley:
>> On Mon, Feb 26, 2018 at 12:04 AM, Christian Mauderer
>> <christian.maude...@embedded-brains.de> wrote:
>>> Hello Udit,
>>>
>>> Am 26.02.2018 um 08:30 schrieb Russell Haley:
>>>> On Sun, Feb 25, 2018 at 11:08 PM, Udit agarwal <dev.mada...@gmail.com> 
>>>> wrote:
>>>>> Hi,
>>>>> So, the error turned out to be due to missing dts only, after building the
>>>>> scripts again with FDT, both the I2C sample code(Logs:here),
>>>>> media01(Logs:here) example worked flawlessly, and thus i was able to read
>>>>> sd-card data. What could be my next possible task on libbsd?
>>>
>>> Most of the time, students are encouraged to fix some small bugs or
>>> create some small patches during this phase of GSoC. So you might want
>>> to do that.
>>>
>>> I think there are only few if any (small) open bugs in the RT regarding
>>> libbsd. But the BBB BSP currently lacks a getentropy implementation
>>> based on the hardware random number generator. That could be a nice
>>> small patch and it would increase the strength of any cryptography (like
>>> for example WiFi) on the BBB.
>>>
>>>>> Moreover, I tried building wifi sample app as well, but i have Atheros
>>>>> AR9271(Firmware name:  ath9k_htc/htc_9271-1.4.0.fw) wireless card. 
>>>>> Following
>>>>> sichen's blog posts(here) i tried building support for my wireless card, 
>>>>> but
>>>>> it looks like FreeBSD itself lacks support for this( as mentioned here )
>>>>> Is there any other way, apart from using FreeBSD for generating support 
>>>>> for
>>>>> my wifi card?
>>>>
>>>> I know you said "apart from using FreeBSD" but there is a good chance
>>>> that partial support for your card is lying around in FreeBSD HEAD. If
>>>> you're really keen you could go on the freebsd-...@freebsd.org mailing
>>>> list and ask. Alternatively you pop onto IRC. Adrian and the other
>>>> guys on there are the ones that can help you out.
>>>>
>>>
>>> If FreeBSD doesn't support your dongle, it's quite hard to get it
>>> working. You would either have to write the driver yourself or find some
>>> FreeBSD compatible one. I would say that writing a WiFi driver yourself
>>> would be a project that heavily exceeds a GSoC project. For the other
>>> solution (finding a driver) Russell already gave the best hints: Talk to
>>> the FreeBSD developers. But I would expect that you won't have a quick
>>> success there too.
>>>
>>> So the simplest solution would be to buy some (cheap) WiFi dongle that
>>> is supported or can easily be ported.
>>
>> Even drivers that work need someone to go through and validate their
>> performance. The following is a link to a conversation I had about
>> WiFi drivers (albeit a different radios) with marginal or no support.
>> While my radio was not supported, the original complainants was.
>>
>> http://freebsd.1045724.x6.nabble.com/template/NamlServlet.jtp?macro=search_page=3556680=Beaglebone+Black+%2B+FreeBSD+%2B+USB+WiFi+%3D+WAP=3556680
>
> Yes of course a new driver needs someone to test it too and if some
> fixes are necessary that can be a great GSoC project on it's own. @Udit:
> Please note that if you want to do that as a project we should get at
> least one FreeBSD programmer into the boat.
>
>>
>> While I am unsure of what RTEMS supports, there is also an SDIO driver
>> in FreeBSD that is somewhat new that nobody has properly
>> tested/compared against the original sdhc driver. I was trying to get
>> there but ran out of time (I was using DTrace, RTEMS will have
>> different benchmark tools). The original port was on BBB. An excellent
>> project would be to go and build the original sdhc driver and the new
>> SDIO driver and benchmark them (In FreeBSD, this was done by using two
>> different kernel configs). This driver is also in the process of being
>> adopted to support SDIO WiFi chips, which are wildly popular now.
>
> With the libbsd RTEMS basically should be able to take over new drivers
> quite easily. User space tools are a little harder.
>
> It's really great to hear that there is a SDIO support for FreeBSD in
> preparation.
>
> Russells suggestion could make a nice project too. Porting the new
> driver and comp

Re: GSoC'18-Introduction

2018-02-25 Thread Russell Haley 
On Sun, Feb 25, 2018 at 11:08 PM, Udit agarwal <dev.mada...@gmail.com> wrote:
> Hi,
> So, the error turned out to be due to missing dts only, after building the
> scripts again with FDT, both the I2C sample code(Logs:here),
> media01(Logs:here) example worked flawlessly, and thus i was able to read
> sd-card data. What could be my next possible task on libbsd?
> Moreover, I tried building wifi sample app as well, but i have Atheros
> AR9271(Firmware name:  ath9k_htc/htc_9271-1.4.0.fw) wireless card. Following
> sichen's blog posts(here) i tried building support for my wireless card, but
> it looks like FreeBSD itself lacks support for this( as mentioned here )
> Is there any other way, apart from using FreeBSD for generating support for
> my wifi card?

I know you said "apart from using FreeBSD" but there is a good chance
that partial support for your card is lying around in FreeBSD HEAD. If
you're really keen you could go on the freebsd-...@freebsd.org mailing
list and ask. Alternatively you pop onto IRC. Adrian and the other
guys on there are the ones that can help you out.

For What It's Worth,
Russ

> Moreover, regarding libbsd documentation, i am keeping note of every step,
> and will soon update the document(libbsd.txt).
>
> Thanks,
> Udit Agarwal
>
> On Sun, Feb 25, 2018 at 11:15 PM, Russell Haley <russ.ha...@gmail.com>
> wrote:
>>
>> Sorry for the top post.
>>
>> Dts file in freebsd tree are here. The Dts files are imported from Linux
>> for compatability.
>>
>> https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/
>>
>> Russ
>>
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>   Original Message
>> From: Christian Mauderer
>> Sent: Sunday, February 25, 2018 2:32 AM
>> To: Udit agarwal; Users
>> Subject: Re: GSoC'18-Introduction
>>
>> Am 25.02.2018 um 08:41 schrieb Udit agarwal:
>> > Hi,
>> > I did build libbsd for beagleboneBlack and executed selectpollkqueue01
>> > test successfully.(Logs:here
>> > <https://gist.github.com/madaari/ae7b3334514a9aec3b063eaa3a0dcd05>)
>> > However, while trying to access SD card, media01 test failed with an
>> > error "fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)  " (Logs:here
>> > <https://gist.github.com/madaari/c6d524bc06e896359f9535d90c0a447a>)
>> > I tried debugging the script, by putting printf statements in various
>> > functions, but it seems like it's failing even before entering
>> > test_main().
>> > Also, is there a better method with which we can debug RTEMS scripts?
>> >
>> > Thanks,
>> > Udit Agarwal
>>
>> Hello Udit,
>>
>> it's great that you can already compile and run some of the libbsd
>> examples.
>>
>>
>> Regarding your problem with the SD card: Note that the BBB BSP uses the
>> flattened device tree (at least the libbsd on BBB does). Therefore you
>> have to load a dtb too. My U-Boot boot lines looks like follows:
>>
>> fatload mmc 0 0x8080 rtems-app.img
>> fatload mmc 0 0x8800 am335x-boneblack.dtb
>> bootm 0x8080 - 0x8800
>>
>> I create a SD-Card image with a script that is based on one that is (or
>> was) contained some time back in the BSP. You can have a look here:
>>
>>
>> https://gitlab.com/c-mauderer/rtems-bbb/blob/master/build/create-sdcardimage.sh
>>
>> The script does a lot of things that are not necessary any more (like
>> copying a U-Boot to the SD card). Basically the necessary points would
>> be to create a image and an uEnv.txt (with the lines from 78 to 83). You
>> can use the dtb file that is provided by a FreeBSD or a Linux for BBB.
>>
>>
>> Regarding debugging the application: I would strongly recommend to use
>> some kind of hardware JTAG debugger. Some Beagle Bone variants have an
>> on-board debugger (I think mainly the older white one). For others you
>> can use hardware debuggers like quite a number of adapters supported by
>> OpenOCD (FlySwatter2, simple FTDI-based ones, ...), Segger J-Link (in
>> your case the EDU version) or whatever you find that can debug the BBB.
>>
>> It may be possible to use the libdebugger as a serial debugger. But I
>> never used it so I'm not sure how well you can debug through the libbsd
>> with it. I'm also not sure whether it works for the BBB. Chris Johns
>> added the ARM support some time back. Maybe he can give you any hints if
>> you want to try libdebugger.
>>
>> Best Regards
>>
>> Christian Mauderer
>>
>> >
>> >

Re: GSoC'18-Introduction

2018-02-25 Thread Russell Haley 
Sorry for the top post. 

Dts file in freebsd tree are here. The Dts files are imported from Linux for 
compatability. 

https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Christian Mauderer
Sent: Sunday, February 25, 2018 2:32 AM
To: Udit agarwal; Users
Subject: Re: GSoC'18-Introduction

Am 25.02.2018 um 08:41 schrieb Udit agarwal:
> Hi,
> I did build libbsd for beagleboneBlack and executed selectpollkqueue01
> test successfully.(Logs:here
> )
> However, while trying to access SD card, media01 test failed with an
> error "fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)  " (Logs:here
> )
> I tried debugging the script, by putting printf statements in various
> functions, but it seems like it's failing even before entering test_main().
> Also, is there a better method with which we can debug RTEMS scripts?
> 
> Thanks,
> Udit Agarwal

Hello Udit,

it's great that you can already compile and run some of the libbsd examples.


Regarding your problem with the SD card: Note that the BBB BSP uses the
flattened device tree (at least the libbsd on BBB does). Therefore you
have to load a dtb too. My U-Boot boot lines looks like follows:

fatload mmc 0 0x8080 rtems-app.img
fatload mmc 0 0x8800 am335x-boneblack.dtb
bootm 0x8080 - 0x8800

I create a SD-Card image with a script that is based on one that is (or
was) contained some time back in the BSP. You can have a look here:

https://gitlab.com/c-mauderer/rtems-bbb/blob/master/build/create-sdcardimage.sh

The script does a lot of things that are not necessary any more (like
copying a U-Boot to the SD card). Basically the necessary points would
be to create a image and an uEnv.txt (with the lines from 78 to 83). You
can use the dtb file that is provided by a FreeBSD or a Linux for BBB.


Regarding debugging the application: I would strongly recommend to use
some kind of hardware JTAG debugger. Some Beagle Bone variants have an
on-board debugger (I think mainly the older white one). For others you
can use hardware debuggers like quite a number of adapters supported by
OpenOCD (FlySwatter2, simple FTDI-based ones, ...), Segger J-Link (in
your case the EDU version) or whatever you find that can debug the BBB.

It may be possible to use the libdebugger as a serial debugger. But I
never used it so I'm not sure how well you can debug through the libbsd
with it. I'm also not sure whether it works for the BBB. Chris Johns
added the ARM support some time back. Maybe he can give you any hints if
you want to try libdebugger.

Best Regards

Christian Mauderer

> 
> On Fri, Feb 23, 2018 at 11:25 PM, Christian Mauderer  > wrote:
> 
> Am 23.02.2018 um 05:17 schrieb Udit agarwal:
> > Hi,
> > Thanks for your help mentors,
> > Since last time, I have managed to modify and execute hello world
> > application on both the platforms, my local machine(Ubuntu 14.04) and
> > BeagleBone Black.
> > I have attached the screenshots and patch file as proof and  detailed
> > logs can be found on these(1
> >  >
> and 2
> >  >)
> gists.
> > Moreover, I went through all the mentioned projects, and found a few of
> > them(Like extending support for PRU, integration of networking stack
> > ,porting RTEMS on PocketBeagle etc) really interesting and doable
> > withing the given time constraint!
> > So, i thought of starting off by studying a bit about the networking
> > stack, its implementation etc. Please recommend few resources from where
> > i can explore this.
> >
> > Regards,
> > Udit agarwal
> >
> 
> Hello Udit,
> 
> it's great that you already have build and successfully executed the
> example on BBB.
> 
> Regarding the network stack. First of all: Note that there are at least
> three network stacks in RTEMS:
> 
> 1. The "old" one which is integrated into the RTEMS sources. This one
> exists since quite some time in RTEMS. It is a fork of a really old
> version of the FreeBSD network stack and it has been heavily adapted
> during the time. I think there is a manual regarding this stack on the
> docs.rtems.org . It has only IPv4 support.
> 
> 2. The "new" one which lives in it's own libbsd repository. That one is
> a fork of the latest FreeBSD development version. One of the important
> points during the development has been that the sources should be as
> close as possible to the upstream FreeBSD sources. This makes it simpler
> to keep up to the FreeBSD development. This one can IPv4 and IPv6 and
> should be basically

Re: [ANNOUNCE] RTEMS 4.11.3 Release

2018-02-15 Thread Russell Haley 
Hi chris,

Sorry for the top post, your links for the tickets resolved for 4.11.3 and 
4.11.4 are not valid. ‎You are missing the /4.11/ folder. 

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Chris Johns
Sent: Thursday, February 15, 2018 5:06 PM
To: Users
Subject: [ANNOUNCE] RTEMS 4.11.3 Release

RTEMS 4.11.3

Release: 4.11.3
Date : 15 February 2018
URL : https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/

The RTEMS Project is pleased to announce the release of RTEMS 4.11.3.

Please refer to the RTEMS 4.11 Release wiki page for details of the RTEMS 4.11
series of kernels:

https://devel.rtems.org/wiki/Release/4.11

Tickets resolved in this release are:

https://devel.rtems.org/wiki/Release/4.11.3

If you find an issue please review the tickets for the RTEMS 4.11.4 milestone:

https://devel.rtems.org/milestone/4.11.4

If you wish to report a bug please click on the following list:

https://devel.rtems.org/newticket?version=4.11=4.11.4

We would like to thank all those who have helped create this release by
providing welcomed feedback and bug reports.

To build click on the releases URL listed above and follow the releases
README.txt's "Quick Guide to Building" section.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Re: the difference between posix user and c user

2018-01-11 Thread Russell Haley 
On Wed, Jan 10, 2018 at 8:50 AM, Gedare Bloom  wrote:
> On Thu, Dec 28, 2017 at 9:35 PM, bin.w...@qkmtech.com
>  wrote:
>> is the posix api and the c api used together?
>>
> POSIX and ISO-C tend to go together.
>
> With RTEMS, you can also use ISO-C with the "Classic API", which
> consists of interface functions accessible from C programs as
> described in the "C User Guide".
>
>> sorry . i am also confused about this two things . because i find that when
>> i config the rtems kernel ,there is a option which is  --enable posix.
>>
> Most new development and ports of existing software probably use POSIX
> anyway, except for the simplest applications. This configure option
> was provided historically as a way to avoid compiling the POSIX
> library into an application, but modern compilers are able to remove
> the unused code any way.

I really liked the cleanliness of the "Classic API". Are there
limitations to it? Is there an advantage to the POSIX API other than
compatibility? (I just threw up a little in my mouth)

Is the Classic API going to be fully supported going forward?

Russ

>> 
>> bin.w...@qkmtech.com
>>
>>
>> From: bin.w...@qkmtech.com
>> Date: 2017-12-29 09:25
>> To: Chris Johns; Users
>> Subject: Re: Re: the difference between posix user and c user
>> i google the posix .now i know that posix is the abbreviation of "the
>> Portable Operating System Interface" it is for software compatibility with
>> variants of Unix and other operating systems
>>
>> but you said, "POSIX and the Classic API are both C APIs."
>> than i think the posix is packaged on the basis of the standard C, is it
>> right ?
>> the classic api is the standard c interface , is it right?
>>
>> best wishes
>>
>> 
>> bin.w...@qkmtech.com
>>
>>
>> From: Chris Johns
>> Date: 2017-12-29 02:18
>> To: users
>> Subject: Re: the difference between posix user and c user
>> On 29/12/17 12:00 am, bin.w...@qkmtech.com wrote:
>>> hi everyone:
>>>
>>> i am new to linux and rtems. i do not understand
>>> what the difference between posix user and c user .
>>>
>>> i am confused about these two concept. which condition i should choose
>>> posix ?
>>> which condition i should choose c ?
>>>
>>
>> This is a good question and it is understandable why you do not understand
>> the
>> difference. The reason is specific to RTEMS and relates to it's history.
>>
>> The original RTEMS was written in Ada and C and the C API is what we now
>> call
>> the Classic API. It's manual was called the C User Guide hence the name.
>>
>> The Ada version of RTEMS was removed from the source tree and POSIX came a
>> while
>> later.
>>
>> POSIX and the Classic API are both C APIs. The C User manual is now called
>> the
>> RTEMS Classic API Guide. See:
>>
>> https://docs.rtems.org/
>>
>> Chris
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Random Question

2017-11-28 Thread Russell Haley 
Late night musings:

I don't trust anyone (except everyone that can read this email. tee
hee). My understanding is that cellular modems contain little CPUs
that run unspecified firmware. If I wanted to make my own open source
cellular modem (doesn't have to do LTE), would RTEMS be a good
candidate for that application?

(sorry if I've fired this one off before, I couldn't find it in my
gmail if I did)

Cheers,

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

Re: Filesystem in RTEMS

2017-10-24 Thread Russell Haley 
FreeBSD doesn't have a flash filesystem that I know of, so at one point I
looked into porting CHFS over:

http://chewiefs.sed.hu/

I'm not sure if it still lacks NOR support. FreeBSD, however, doesn't have
flash drivers to support a file system yet. The support it currently has
isn't viable as the error correction code is too rudimentary.

Russ

On Tue, Oct 24, 2017 at 9:01 AM, Russell Haley <russ.ha...@gmail.com> wrote:

>
>
> On Mon, Oct 23, 2017 at 11:42 AM, Joel Sherrill <j...@rtems.org> wrote:
>
>>
>>
>> On Mon, Oct 23, 2017 at 10:37 AM, Russell Haley <russ.ha...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Just wanted to ask about licensing. ‎Jffs2 is expressly GPL code. My
>>> understanding means that the entirety of your work now becomes GPL licensed
>>> because everything is statically linked together in RTEMS. Is this
>>> understanding incorrect?
>>>
>>
>> It is GPLv2 with a linking exception like the GCC language run-times used
>> to use. See
>>
>> https://github.com/atgreen/RTEMS/blob/master/LICENSE.JFFS2
>>
>> and read the last two paragraphs.
>>
>> --joel
>>
>>
> Thanks Joel!
>
> Russ
>
>>
>>> Thanks,
>>> Russ
>>>
>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>> *From: *jameszxj
>>> *Sent: *Monday, October 23, 2017 12:13 AM
>>> *To: *rtems-us...@rtems.org
>>> *Subject: *Re: Filesystem in RTEMS
>>>
>>> I have encountered a problem like this.
>>> I set wrong block size.
>>>
>>> Maybe you can try to change the block size.
>>>
>>> I use jffs2 on xilinx zc7020 board, QSPI
>>> -- Original --
>>> *From: * "Sebastian Huber";<sebastian.hu...@embedded-brains.de>;
>>> *Date: * Mon, Oct 23, 2017 01:07 PM
>>> *To: * "xuelin.t...@qkmtech.com"<xuelin.t...@qkmtech.com>;
>>> *Cc: * "users@rtems.org"<users@rtems.org>;
>>> *Subject: * Re: Filesystem in RTEMS
>>>
>>> On 22/10/17 12:00, xuelin.t...@qkmtech.com wrote:
>>> > I have mounted JFFS2 successfully, according to the return value.
>>> > Yes, it takes some time to do the mounting work.
>>> >
>>> > But, when I downloaded a file like "test.txt" into flash via FTP and
>>> > restarted the system, error came up.
>>>
>>> Unmount the file system before you restart the system.
>>>
>>> >
>>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>>> found at 0x01FC0028: 0xE5DF instead
>>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>>> found at 0x01FC002C: 0xE5DF instead
>>> > <5>JFFS2: Further such events for this erase block will not be printed
>>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>>> found at 0x01FD: 0x000C instead
>>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>>> found at 0x01FD0004: 0xB0B1 instead
>>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>>> found at 0x01FD0008: 0x0054 instead
>>> > <5>JFFS2: Cowardly refusing to erase blocks on filesystem wi
>>> th no valid JFFS2 nodes
>>> > <5>JFFS2: empty_blocks 0, bad_blocks 0, c->nr_blocks 510
>>> > mount failed.
>>> >
>>> > Everything worked well, after erasing the whole flash. But errors came
>>> > up without erasing it.
>>>
>>> Make sure your flash driver works correctly. It must support bytewise
>>> programming.
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Dornierstr. 4
>>> <https://maps.google.com/?q=Dornierstr.+4=gmail=g>,
>>> 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.
>>>
>>> ___
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>>
>>> ___
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Filesystem in RTEMS

2017-10-24 Thread Russell Haley 
On Mon, Oct 23, 2017 at 11:42 AM, Joel Sherrill <j...@rtems.org> wrote:

>
>
> On Mon, Oct 23, 2017 at 10:37 AM, Russell Haley <russ.ha...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Just wanted to ask about licensing. ‎Jffs2 is expressly GPL code. My
>> understanding means that the entirety of your work now becomes GPL licensed
>> because everything is statically linked together in RTEMS. Is this
>> understanding incorrect?
>>
>
> It is GPLv2 with a linking exception like the GCC language run-times used
> to use. See
>
> https://github.com/atgreen/RTEMS/blob/master/LICENSE.JFFS2
>
> and read the last two paragraphs.
>
> --joel
>
>
Thanks Joel!

Russ

>
>> Thanks,
>> Russ
>>
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>> *From: *jameszxj
>> *Sent: *Monday, October 23, 2017 12:13 AM
>> *To: *rtems-us...@rtems.org
>> *Subject: *Re: Filesystem in RTEMS
>>
>> I have encountered a problem like this.
>> I set wrong block size.
>>
>> Maybe you can try to change the block size.
>>
>> I use jffs2 on xilinx zc7020 board, QSPI
>> -- Original --
>> *From: * "Sebastian Huber";<sebastian.hu...@embedded-brains.de>;
>> *Date: * Mon, Oct 23, 2017 01:07 PM
>> *To: * "xuelin.t...@qkmtech.com"<xuelin.t...@qkmtech.com>;
>> *Cc: * "users@rtems.org"<users@rtems.org>;
>> *Subject: * Re: Filesystem in RTEMS
>>
>> On 22/10/17 12:00, xuelin.t...@qkmtech.com wrote:
>> > I have mounted JFFS2 successfully, according to the return value.
>> > Yes, it takes some time to do the mounting work.
>> >
>> > But, when I downloaded a file like "test.txt" into flash via FTP and
>> > restarted the system, error came up.
>>
>> Unmount the file system before you restart the system.
>>
>> >
>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>> found at 0x01FC0028: 0xE5DF instead
>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>> found at 0x01FC002C: 0xE5DF instead
>> > <5>JFFS2: Further such events for this erase block will not be printed
>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>> found at 0x01FD: 0x000C instead
>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>> found at 0x01FD0004: 0xB0B1 instead
>> > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
>> found at 0x01FD0008: 0x0054 instead
>> > <5>JFFS2: Cowardly refusing to erase blocks on filesystem wi
>> th no valid JFFS2 nodes
>> > <5>JFFS2: empty_blocks 0, bad_blocks 0, c->nr_blocks 510
>> > mount failed.
>> >
>> > Everything worked well, after erasing the whole flash. But errors came
>> > up without erasing it.
>>
>> Make sure your flash driver works correctly. It must support bytewise
>> programming.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4
>> <https://maps.google.com/?q=Dornierstr.+4=gmail=g>, 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.
>>
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Filesystem in RTEMS

2017-10-23 Thread Russell Haley 
  Hi,Just wanted to ask about licensing. ‎Jffs2 is expressly GPL code. My understanding means that the entirety of your work now becomes GPL licensed because everything is statically linked together in RTEMS. Is this understanding incorrect?Thanks,RussSent from my BlackBerry 10 smartphone on the Virgin Mobile network.From: jameszxjSent: Monday, October 23, 2017 12:13 AMTo: rtems-us...@rtems.orgSubject: Re:  Filesystem in RTEMSI have encountered a problem like this. I set wrong block size.Maybe you can try to change the block size.I use jffs2 on xilinx zc7020 board, QSPI-- Original --From:  "Sebastian Huber";;Date:  Mon, Oct 23, 2017 01:07 PMTo:  "xuelin.t...@qkmtech.com";Cc:  "users@rtems.org"; Subject:  Re: Filesystem in RTEMSOn 22/10/17 12:00, xuelin.t...@qkmtech.com wrote:> I have mounted JFFS2 successfully, according to the return value.> Yes, it takes some time to do the mounting work.>> But, when I downloaded a file like "test.txt" into flash via FTP and > restarted the system, error came up.Unmount the file system before you restart the system.>> <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FC0028: 0xE5DF instead> <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FC002C: 0xE5DF instead> <5>JFFS2: Further such events for this erase block will not be printed> <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FD: 0x000C instead> <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FD0004: 0xB0B1 instead> <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FD0008: 0x0054 instead> <5>JFFS2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes> <5>JFFS2: empty_blocks 0, bad_blocks 0, c->nr_blocks 510> mount failed.>> Everything worked well, after erasing the whole flash. But errors came > up without erasing it.Make sure your flash driver works correctly. It must support bytewise programming.-- Sebastian Huber, embedded brains GmbHAddress : Dornierstr. 4, D-82178 Puchheim, GermanyPhone   : +49 89 189 47 41-16Fax : +49 89 189 47 41-09E-Mail  : sebastian.hu...@embedded-brains.dePGP : Public key available on request.Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.___users mailing listusers@rtems.orghttp://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Tenth Anniversary of NASA Dawn Launch

2017-09-28 Thread Russell Haley 
I noticed LEON 2 coming up from time to time on this mailing list. Forgive
me because I know only a little about this subject so far. What is the
advantage of running an FPGA/software processor over hardware? Is there an
advantage in space?

Russ

On Thu, Sep 28, 2017 at 10:56 AM, Joel Sherrill <j...@rtems.org> wrote:

> Hi
>
> We made a flyer a few years back about the Dawn mission.
>
> https://www.rtems.com/sites/default/files/Application-Dawn-2011-10.pdf
>
> Looks like we don't know a lot about the framing camera we know runs
> RTEMS beyond it being a LEON2. I recall that the  Technical University
> of Braunschweig developed the camera but a quick google search only
> found other RTEMS systems they had done.
>
> More information on any RTEMS application is of interest though.
>
> Looking for that I was also reminded that I watched the launch on
> the NASA channel.
>
> On Wed, Sep 27, 2017 at 7:27 PM, Russell Haley <russ.ha...@gmail.com>
> wrote:
>
>> What version of rtems is it running? Can you tell us any of the technical
>> details?
>>
>> Russ
>>
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>> *From: *Joel Sherrill
>> *Sent: *Wednesday, September 27, 2017 4:25 PM
>> *To: *rtems-us...@rtems.org
>> *Reply To: *j...@rtems.org
>> *Subject: *Tenth Anniversary of NASA Dawn Launch
>>
>> Hi
>>
>> The RTEMS Community doesn't post enough about the successes of their
>> RTEMS applications so I am passing this one along. Today is the 10th
>> anniversary of the launch of the Dawn space probe.
>>
>> https://en.wikipedia.org/wiki/Dawn_(spacecraft)
>>
>> Dawn is a mission to the asteroid belt. We have learned a lot from this
>> mission.
>>
>> Congratulations to those who worked on this mission!
>>
>> --joel
>>
>>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Tenth Anniversary of NASA Dawn Launch

2017-09-27 Thread Russell Haley 
  What version of rtems is it running? Can you tell us any of the technical details?RussSent from my BlackBerry 10 smartphone on the Virgin Mobile network.From: Joel SherrillSent: Wednesday, September 27, 2017 4:25 PMTo: rtems-us...@rtems.orgReply To: j...@rtems.orgSubject: Tenth Anniversary of NASA Dawn LaunchHiThe RTEMS Community doesn't post enough about the successes of theirRTEMS applications so I am passing this one along. Today is the 10th anniversary of the launch of the Dawn space probe.https://en.wikipedia.org/wiki/Dawn_(spacecraft)Dawn is a mission to the asteroid belt. We have learned a lot from thismission. Congratulations to those who worked on this mission!--joel

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