FYI, public proposals can not be accessed unless you provide the link
explicitly.
On Thu, Mar 26, 2015 at 8:14 PM, Ketul Shah wrote:
> Hello all,
>
> I have done improvements of my proposal on melange as per feedback. So
> please review it and I would be happy to hear your comments. My project
>
On 27/03/2015 12:47 am, Joel Sherrill wrote:
> On 03/26/2015 08:41 AM, Gedare Bloom wrote:
>> There are unused fields in the (32-bit) Objects_Id, but none are
>> "reserved". Currently only 2-bits of the API are used, although 4 bits
>> are available. Also, if you're not using RTEMS_MULTIPROCESSING,
Hello all,
I have done improvements of my proposal on melange as per feedback. So
please review it and I would be happy to hear your comments. My project
title is "Beagleboard BSP Improvement" under name : ketul.
Thanks and regards,
ketul
___
devel ma
On Thu, Mar 26, 2015 at 5:07 PM, Daniel Gutson
wrote:
> On Thu, Mar 26, 2015 at 5:16 PM, Martin Galvan
> wrote:
>> ---
>> c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++--
>> c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37
>> --
>> 2 files changed,
I know that this might be a bit eccentric for this list, but I must
say that I commend your enthusiasm. Best of luck!
On Thu, Mar 26, 2015 at 3:09 PM, Yurii Shevtsov wrote:
> Since we are working around the same hardware, we definitely should
> cooperate, share info and ideas. Feel free to ask q
Since we are working around the same hardware, we definitely should
cooperate, share info and ideas. Feel free to ask questions. Inspire
each other!
Off-topic is allowed here, in small portions, of course ;-) I'm sure
we will be a good team!
P.S. Roll-call would be a great start for this thread)
__
> On Mar 26, 2015, at 17:26 , Joel Sherrill wrote:
>
>> I think if 16 bit Harvard architecture (64K instruction / 64K data) targets
>> are no longer supportable then 16 bit should be deprecated and then
>> abandoned. If you can still do a lot with RTEMS in 128K then that useful
>> subset of
Hello Martin,
this is the right and planned change.
What are your results of testing the BSP?
Are there some stability issues or your combination
with HALcogen code and FPU passes tests suites.
Best wishes,
Pavel
On Thursday 26 of March 2015 21:21:26 Martin Galvan wrote:
> ---
>
On 03/26/2015 04:12 PM, Peter Dufault wrote:
On Mar 23, 2015, at 16:23 , Sebastian Huber
wrote:
- Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@gwu.edu:
I guess this is a problem for 16-bit targets? changing the constants
to 16UL and 8UL also should work. A comment should be mad
I should clarify that the terms SPL and MLO seem to be used
interchangeably. So I guess it's pretty much a matter of figuring out
where the internal ROM-based bootloader exactly transfers the "second
stage" bootloader from (i.e. location in memory) and to what location
in the internal SRAM to do
> On Mar 23, 2015, at 16:23 , Sebastian Huber
> wrote:
>
>
>
> - Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@gwu.edu:
>
>> I guess this is a problem for 16-bit targets? changing the constants
>> to 16UL and 8UL also should work. A comment should be made that this
>> is only for
On Thu, Mar 26, 2015 at 5:16 PM, Martin Galvan
wrote:
> ---
> c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++--
> c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37
> --
> 2 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/c/src/lib/lib
I should clarify that the terms SPL and MLO seem to be used
interchangeably. So I guess it's pretty much a matter of figuring out
where the internal ROM-based bootloader exactly transfers the "second
stage" bootloader from (i.e. location in memory) and to what location
in the internal SRAM to do t
---
c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
index e90414a..869cf71 100644
--- a/c/sr
---
c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++--
c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37 --
2 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/c/src/lib/libbsp/arm/tms570/include/tms570.h
b/c/src/lib/libbsp/arm/tms570/includ
I'll definitely check out the AM335x TRM.
Referring to this link
(http://beagleboard.org/project/U-Boot+%28V1%29/), it briefly
elaborates that the U-boot on the Beaglebone consists of two phases.
First phase consists of the SPL which is transferred from eMMC or uSD
(depending on boot switch) and m
On 3/26/2015 2:22 PM, Gedare Bloom wrote:
On Thu, Mar 26, 2015 at 2:18 PM, Joel Sherrill
wrote:
On 03/26/2015 11:35 AM, Jarielle Catbagan wrote:
It looks like the internal ROM-based bootloader looks for a secondary
program loader (SPL) that initializes the necessary devices to
continue the boo
On 3/26/2015 2:18 PM, Joel Sherrill wrote:
On 03/26/2015 11:35 AM, Jarielle Catbagan wrote:
It looks like the internal ROM-based bootloader looks for a secondary
program loader (SPL) that initializes the necessary devices to
continue the boot process and pass control to a third-stage
bootloader.
The lower 5 bits of the SYSBOOT pins determine the order that the ROM
bootloader
will follow when trying to boot from something external (memory or device).
Referring to the schematic (pg6), the default value of SYSBOOT[4:0] is
11100.
Referring to table 26-7 of the TRM, this corresponds to the s
Refer to chapter 26 of this document (AM335x TRM):
http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
for more detail on the booting process of the chip.
Depending on how hard it is to reconfigure the SYSBOOT pins, it may be
simpler to initially try to boot this off the UART. Then once that works,
i
Hi
A patch with Jiri's patch set is waiting list moderator approval.
With that committed, my RSB patches (1) update the newlib
used to the current snapshot and (2) switch sparc gdb to
gdb 7.9 and add Jiri's patch set.
Jiri's patch set enables basic leon2 and leon3 executables
to run with the sim
On 03/26/2015 01:24 PM, Gedare Bloom wrote:
I guess you ran it? Could you post your results when you commit it. :)
:)
I swept through and added all the gdb simulators a while back but
apparently missed pushing this.
I should start posting test reports for all the BSPs I can as we
narrow down
It is combined into one until Chris can work around using the unorderd
dict container on the patch set.
---
rtems/config/4.11/rtems-sparc.bset | 50 --
rtems/config/tools/rtems-gdb-7.9-1.cfg | 2 +-
2 files changed, 48 insertions(+), 4 deletions(-)
mode chang
This includes Joel's patch to dynamically probe for the proper
setting for intptr_t and uintptr_t. This eliminates
many printf() format warnings due to them being incorrectly defined.
---
rtems/config/4.11/rtems-arm.bset | 2 +-
rtems/config/4.11/rtems-avr.bset
I guess you ran it? Could you post your results when you commit it. :)
On Thu, Mar 26, 2015 at 2:22 PM, Joel Sherrill
wrote:
> ---
> tester/rtems/testing/bsps/simsh1-run.mc | 54 ++
> tester/rtems/testing/bsps/simsh1.mc | 56
>
>
---
tester/rtems/testing/bsps/simsh1-run.mc | 54 ++
tester/rtems/testing/bsps/simsh1.mc | 56
tester/rtems/testing/bsps/simsh2-run.mc | 54 ++
tester/rtems/testing/bsps/simsh2.mc | 56
On Thu, Mar 26, 2015 at 2:18 PM, Joel Sherrill
wrote:
> On 03/26/2015 11:35 AM, Jarielle Catbagan wrote:
>>
>> It looks like the internal ROM-based bootloader looks for a secondary
>> program loader (SPL) that initializes the necessary devices to
>> continue the boot process and pass control to a
Right...
I'm catching up on this CPU, I've done a bit more of this on the iMX6,
but it appears
to be quite similar...
Referring to the schematic here:
https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf?raw=true
When the CPU first starts out of a cold reset, it will execute c
On 03/26/2015 11:35 AM, Jarielle Catbagan wrote:
It looks like the internal ROM-based bootloader looks for a secondary
program loader (SPL) that initializes the necessary devices to
continue the boot process and pass control to a third-stage
bootloader. So now I believe it's a matter of finding
Hi
This appears to work for me.
Admittedly I ran this on the gdb arm920 simulator
and pushed a fixed width through it.
If this is a bug, we need to tinker with the test
case to duplicate it.
--joel
/*
* Simple test program -- simplified version of sample test hello.
*/
#include
#include
It looks like the internal ROM-based bootloader looks for a secondary
program loader (SPL) that initializes the necessary devices to
continue the boot process and pass control to a third-stage
bootloader. So now I believe it's a matter of finding whether there
are existing code implementations of
To put things into context in regards to the conversation that I was
having with Ed, Dr. Joel, and Gedare:
I am currently in the process of looking into porting MicroMonitor to
the Beaglebone Black. As indicated by Ed, "[t]he difficulty of the
port will depend on how much existing CPU-initializat
On 03/26/2015 04:23 AM, abd el-hamed Amer wrote:
Dear Dr. Joel sherrill & All,
I have chosen static analysis of stack usage for RTEMS, and I working
now on my proposal. can you advice me about the latest work on this
topic and which parts see it's important to focus in?
This is an idea that
On 03/26/2015 08:41 AM, Gedare Bloom wrote:
There are unused fields in the (32-bit) Objects_Id, but none are
"reserved". Currently only 2-bits of the API are used, although 4 bits
are available. Also, if you're not using RTEMS_MULTIPROCESSING, I
guess none of the node bits are used.
Look at _Ob
Yes this is acceptable, thanks! Please post your patch too.
-Gedare
On Thu, Mar 26, 2015 at 1:07 AM, Rohini Kulkarni wrote:
> Hi All,
>
> I have chosen Raspberry Pi 2 support as my project. I recently received the
> raspberry pi board, but do not have a console set up yet. I have run the the
> he
Upload your official proposal to Google Melange.
I would expect the multicore aspect to be mostly research, and any
implementations for multicore are bonus. You could also consider
implementing something like plist as a future improvement, if it makes
sense to offer.
Since this bug affects previo
There are unused fields in the (32-bit) Objects_Id, but none are
"reserved". Currently only 2-bits of the API are used, although 4 bits
are available. Also, if you're not using RTEMS_MULTIPROCESSING, I
guess none of the node bits are used.
Gedare
On Wed, Mar 25, 2015 at 10:52 PM, Chris Johns wro
Dear Dr. Joel sherrill & All,
I have chosen static analysis of stack usage for RTEMS, and I working now
on my proposal. can you advice me about the latest work on this topic and
which parts see it's important to focus in?
Best Regards,
Abd elhamid
___
On 26/03/15 00:03, Joel Sherrill wrote:
On 03/25/2015 05:41 PM, André Marques wrote:
It is not, only on Sebastian's repository. It was anounced here along
with an USB host stack:
https://lists.rtems.org/pipermail/devel/2014-August/007873.html
Any updates on this?
I work currently on the SMP
39 matches
Mail list logo
