Hi all,
I have tried to build rtems-builder and rtems following the "Quick Start"
instructions on the web page. It seems I can build executables as I can
find "ticker.exe". However, I cannot run it as shown.
"tar sim" is not recognized; it seems the simulator is not built correctly.
Below is
On Thu, Mar 5, 2015 at 5:29 PM, Joel Sherrill wrote:
>
>
> On 3/5/2015 3:44 PM, Gedare Bloom wrote:
>> Continued...
>>
>> A high-level question I have is whether we want to consider this
>> drvmgr as an externally-supported library, or if it is to be part of
>> RTEMS proper. It makes sense to trea
RPI 2 should not be that bad:
I changed the peripheral register base in raspberrypi.h, changed the
compilation arch flags, commented out the mmu init call, and some samples
seem to work.
I ran ticker and paranoia
Alan
On Thu, Mar 5, 2015 at 7:42 PM, wrote:
> I think this will be possible. I
When I first time configure and make,here comes the error in make :
configure: error: in `/archive/rtems-4.10.2/build-rtems/arm-rtems4.10/c/csb337':
configure: error: C compiler cannot create executables
then I execute the command
$ ln -s /bin/gcc.exe /bin/cc.exe ( copy from Using MS-Windows
On March 5, 2015 3:18:11 PM CST, "桥 杨" wrote:
>With official documents and elinux wiki , we can find lots of details
>of different RPI model. Including chip datasheets , layout, and pin
>definitions etc...
I think we can probe and dynamically adjust for many differences. This happens
on the Mo
On March 5, 2015 6:49:21 PM CST, "alan.cudm...@gmail.com"
wrote:
>Sounds like a good approach.
>
>There is a wealth of code out there, but much of it uses a license that
>is incompatible with RTEMS.
>
>If we did not consider the license, I think we could have graphics,
>USB, network, etc work
Sounds like a good approach.
There is a wealth of code out there, but much of it uses a license that is
incompatible with RTEMS.
If we did not consider the license, I think we could have graphics, USB,
network, etc working pretty quickly.
Good resources here, but not directly useable:
Gra
I think this will be possible. I just tried a few bare metal assembly demos on
the Pi A+ and Pi2 and it looks like even without the published CPU datasheet,
they have things figured out.
For example: An assembly SMP NEON fractal demo:
https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/N
On 3/5/2015 3:44 PM, Gedare Bloom wrote:
> Continued...
>
> A high-level question I have is whether we want to consider this
> drvmgr as an externally-supported library, or if it is to be part of
> RTEMS proper. It makes sense to treat it as third-party code if there
> are other OSs that gaisler
Hi All,
Congratulations on getting accepted as a mentoring organization.
My name is Ragunath. I am currently pursuing my master's degree in
computer science from IIT Kharagpur, India.
My area of interests are operating systems and embedded systems
development. I am interested in working with
RTEM
Continued...
A high-level question I have is whether we want to consider this
drvmgr as an externally-supported library, or if it is to be part of
RTEMS proper. It makes sense to treat it as third-party code if there
are other OSs that gaisler uses the same API for, but if this is
specifically des
With official documents and elinux wiki , we can find lots of details of
different RPI model. Including chip datasheets , layout, and pin definitions
etc...
For the moment, I've got a B and B+. So I think maybe I can start by building
RTEMS and load it with uboot, check out the code for gpio an
Hi
I am going to go back on what I said earlier. The online discussion
seems to indicate that the BCM2836 has the same peripherals
as the BCM2835 on the previous Pi Models. But they are at
physical address 0x3F00 rather than the 0x2000.
The CPU core is a different ARM level.
Since people
On 05-03-2015 16:46, Joel Sherrill wrote:
On 3/5/2015 10:40 AM, Alan Cudmore wrote:
The list below is still pretty good.
Items 1 - 3 were done by Andre last summer, but we still don't have them
in the git repository. The RTEMS I2C API has changed and we were going
to try to move the I2C impleme
On 3/5/2015 10:55 AM, Alan Cudmore wrote:
> On 3/5/2015 11:46 AM, Joel Sherrill wrote:
>> On 3/5/2015 10:40 AM, Alan Cudmore wrote:
>>> The list below is still pretty good.
>>> Items 1 - 3 were done by Andre last summer, but we still don't have them
>>> in the git repository. The RTEMS I2C API ha
On 3/5/2015 11:46 AM, Joel Sherrill wrote:
On 3/5/2015 10:40 AM, Alan Cudmore wrote:
The list below is still pretty good.
Items 1 - 3 were done by Andre last summer, but we still don't have them
in the git repository. The RTEMS I2C API has changed and we were going
to try to move the I2C implem
On 3/5/2015 10:40 AM, Alan Cudmore wrote:
> The list below is still pretty good.
> Items 1 - 3 were done by Andre last summer, but we still don't have them
> in the git repository. The RTEMS I2C API has changed and we were going
> to try to move the I2C implementation to the new Linux based API
The list below is still pretty good.
Items 1 - 3 were done by Andre last summer, but we still don't have them
in the git repository. The RTEMS I2C API has changed and we were going
to try to move the I2C implementation to the new Linux based API.
I still think that having complete Raspberry Pi
---
rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg
b/rtems/config/tools/rtems-gcc-4.8.3-newlib-git-1.cfg
index 297f4e0..a7f1020 100644
--- a/rtems/config/tools/rtems-gcc-4.
On 05/03/15 15:19, Gedare Bloom wrote:
OK. On a related note, I don't like this "MINIMUM" and "MAXIMUM"
terminology I'd prefer HIGHEST and LOWEST, are we stuck with MINIMUM
and MAXIMUM for API compatibility?
In the score files, we can name it as we like, but I am not sure if its
worth to spend
Hello Yang Qiao,
There is the future work listed in that page, and there are some other
project ideas for raspberry pi. There also could be the opportunity to
support the raspberry pi 2.
The original list of open Raspberry Pi projects were:
Peripherals we need to support (in order of increasing d
OK. On a related note, I don't like this "MINIMUM" and "MAXIMUM"
terminology I'd prefer HIGHEST and LOWEST, are we stuck with MINIMUM
and MAXIMUM for API compatibility?
On Thu, Mar 5, 2015 at 2:33 AM, Sebastian Huber
wrote:
> ---
> cpukit/rtems/src/timerserver.c | 2 +-
> cpukit/sco
No errors during configure?
Paste a little more of the make output, it seems like something else
is missing... The cygwin build can be a little bit hit-or-miss,
although I think 4.10 should work...
Gedare
On Wed, Mar 4, 2015 at 11:42 PM, zhengyazhou wrote:
> Thank you for answering me,here is t
Hello ,
I' a 3rd year chinese student studying software engineering (real-time system
and embedded system) in France. I've found the GSOC2015 idea 'Raspberry Pi BSP
' very attractive and I would like to know more about it to prepare my proposal.
Since the wiki page hasn't a concrete introduct
24 matches
Mail list logo
