<div dir="ltr"><div>Indeed. I did right away verify I can build & run & test everything for the beaglebones and the bbxm from mainline. So that seems to have gone fine.<br><br></div>The supporting tools and RSB stuff I am in contact with Chris about.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 3, 2014 at 10:23 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<div>On 11/3/2014 3:06 PM, Ben Gras wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>All,<br>
<br>
<br>
</div>
<div>Joel merged these and I updated my blog post to reflect the
mainline repo. Thanks Joel!<br>
</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote></span>
Thank you Ben for the nice submission!!!<br>
<br>
Now to make sure it is reproducible from here and we have merged<br>
all the bits into the tools, etc.<div><div class="h5"><br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Nov 3, 2014 at 8:40 PM, Ben
Gras <span dir="ltr"><<a href="mailto:beng@shrike-systems.com" target="_blank">beng@shrike-systems.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>All,<br>
<br>
</div>
I have new patches with some last-minute smoothings added;
removed obsolete beagle.cfg, TODO, and separated the more
generic ARM headers into a separate commit. The new 3
commits are attached (and in my RTEMS github repo).<br>
<br>
Gedare, there is also a diff w.r.t. the previous
submission attached as requested.<br>
<br>
<br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 3, 2014 at 3:01
PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I don't have time to review, but am OK in
principle with committing<br>
this code as it is tested, with the caveat that my
previous comments<br>
be addressed post-merge.<br>
<br>
If you have a diff / commits on top of what you
sent before, I'd be<br>
glad to give those a quick look.<br>
<br>
Thanks for your contribution!<br>
<span><font color="#888888">Gedare<br>
</font></span>
<div>
<div><br>
On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras <<a href="mailto:beng@shrike-systems.com" target="_blank">beng@shrike-systems.com</a>>
wrote:<br>
> All,<br>
><br>
> Ok, as promised, I rebased and re-tested
and have found & included a<br>
> portable way of making the SD card image
(included in sdcard.sh), to be<br>
> merged with RSB (i.e. some of the tools
sdcard.sh relies on are missing in<br>
> mainline RSB). Some of Gedare's initial
feedback is processed thanks to<br>
> Brandon Matthews. It's tested to run on
the original beaglebone, beaglebone<br>
> black and qemu linaro. (The assumption is
it'll run on the bbxm hardware as<br>
> well as it was before rebasing.)<br>
><br>
> The result is split into 2 patches to
show what was Claas's initial work.<br>
> This makes them a bit unreadable for the
final result from the patches<br>
> unfortunately.<br>
><br>
> As before, see<br>
> <a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a><br>
> on how to build all the tools, RTEMS
executables, sdcard images, and run the<br>
> test set from linaro qemu.<br>
><br>
><br>
><br>
> On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras
<<a href="mailto:beng@shrike-systems.com" target="_blank">beng@shrike-systems.com</a>>
wrote:<br>
>><br>
>> All,<br>
>><br>
>> OK, that seems like a fruitful way to
proceed to me.<br>
>><br>
>> Then I will do some minor cleanups,
rebase, do all the tests again, and<br>
>> re-submit. There's just one problem I
know of that I want to fix before the<br>
>> first commit happens, and that is
that the FAT fs made by mtools doesn't<br>
>> boot on the HW it seems. (It does on
the emulator.) A last-minute change -<br>
>> switching to mtools instead of
dosfstools to use to make the SD card image<br>
>> because the latter is so linux-only.<br>
>><br>
>> Stay tuned.<br>
>><br>
>><br>
>><br>
>><br>
>> On Wed, Aug 20, 2014 at 4:20 PM,
Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>
wrote:<br>
>>><br>
>>> Ben, As far as getting this
merged, all of my comments can be done as<br>
>>> a follow-on commit. -Gedare<br>
>>><br>
>>> On Thu, Jul 24, 2014 at 4:28 PM,
Ben Gras <<a href="mailto:beng@shrike-systems.com" target="_blank">beng@shrike-systems.com</a>><br>
>>> wrote:<br>
>>> > Thanks for the fast &
detailed review. Let me get back to it/you.<br>
>>> ><br>
>>> > In the meantime, any other
feedback? From anyone I mean.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Thu, Jul 24, 2014 at 4:45
PM, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>
wrote:<br>
>>> >><br>
>>> >> Hi Ben,<br>
>>> >> Great work. I have a few
comments. I skipped the i2c.h and i2c.c<br>
>>> >> files. Most of my
comments are about style and a few requests to<br>
>>> >> refactor some of the
larger files. The refactoring can be added to<br>
>>> >> your TODO if you like.
Please fix the style issues if it is not a<br>
>>> >> burden.<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/README<br>
>>> >> +$
../claas-rtems/configure
--target=arm-rtems4.11<br>
>>> >>
--enable-rtemsbsp="beaglebonewhite
beagleboardxm"<br>
>>> >> Replace claas-rtems with
rtems. If RSB support is available, make a<br>
>>> >> note about it.<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/TODO<br>
>>> >> [...]<br>
>>> >> open:<br>
>>> >> + . how to handle the
interrupt?<br>
>>> >><br>
>>> >> What does this mean?<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/clock.c<br>
>>> >> Why is the entire file
ifdef'd on ARM_MULTILIB_ARCH_V4?<br>
>>> >><br>
>>> >> It might be sensible to
put the struct definitions in a .h file if<br>
>>> >> these omap registers
might be re-usable.<br>
>>> >><br>
>>> >> +static struct
omap_timer_registers regs_v2 = {<br>
>>> >> This might be better to
put behind an #if IS_AM335X since it is not<br>
>>> >> used otherwise?<br>
>>> >><br>
>>> >> +<br>
>>> >> +<br>
>>> >> +<br>
>>> >> Avoid more than one
blank line in a row.<br>
>>> >><br>
>>> >> +static int done = 0;<br>
>>> >> It would be nice if you
got rid of this, but otherwise give it a more<br>
>>> >> useful name like
"mmio_init_done"<br>
>>> >><br>
>>> >> +static void
beagle_clock_handler_install(rtems_interrupt_handler
isr)<br>
>>> >> + if (sc !=
RTEMS_SUCCESSFUL) {<br>
>>> >> +
rtems_fatal_error_occurred(0xdeadbeef);<br>
>>> >> I think there is some
capabilities in ARM for bsp fatal error codes<br>
>>> >> now. They should be
preferred to be used to help debug these fatal<br>
>>> >> conditions.<br>
>>> >><br>
>>> >> +static inline uint32_t
beagle_clock_nanoseconds_since_last_tick(void)<br>
>>> >> + return (read_frc() -
(uint64_t) last_tick_nanoseconds) * 1000000000<br>
>>> >> / FRCLOCK_HZ;<br>
>>> >> This line is > 80
characters, please break it or shrink it.<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/console/console-config.c<br>
>>> >> +#define
CONSOLE_UART_LSR (*(volatile unsigned int<br>
>>> >>
*)(BSP_CONSOLE_UART_BASE+0x14))<br>
>>> >> Line > 80 characters,
even with the spacing modified.<br>
>>> >><br>
>>> >> +static void
beagle_console_init(void)<br>
>>> >><br>
>>> >> + while
((CONSOLE_SYSS & 1) == 0)<br>
>>> >> + ;<br>
>>> >> Is this a fatal loop or
is it waiting for hardware to clear something?<br>
>>> >><br>
>>> >> + if ((CONSOLE_LSR
& (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT))
==<br>
>>> >> CONSOLE_LSR_THRE) {<br>
>>> >> Again > 80
characters. Is the test logically equivalent
to: if (<br>
>>> >> (CONSOLE_LSR &
CONSOLE_LSR_THRE) == CONSOLE_LSR_THRE)<br>
>>> >><br>
>>> >> + while ((CONSOLE_LSR
& CONSOLE_LSR_TEMT) == 0)<br>
>>> >> + ;<br>
>>> >> Is this a fatal loop or
is it waiting for hardware?<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/include/bsp.h<br>
>>> >> This bsp.h is really
long. Probably it should be refactored into
other<br>
>>> >> headers, including
non-public ones.<br>
>>> >><br>
>>> >> +static inline void
dsb(void)<br>
>>> >> +{<br>
>>> >> + asm
volatile("dsb" : : : "memory");<br>
>>> >> Fix the indentation.<br>
>>> >><br>
>>> >> +static inline void
flush_data_cache(void)<br>
>>> >> Perhaps this should be
using _CPU_cache_flush_entire_data()? Perhaps<br>
>>> >> there is a difference in
that the cache manager code flushes and<br>
>>> >> "cleans" the cache...<br>
>>> >><br>
>>> >> +<br>
>>> >> +<br>
>>> >> +<br>
>>> >> +<br>
>>> >> Excess newlines. Done a
few places in this file.<br>
>>> >><br>
>>> >> The comments following
the defines for various AM33X_INT_ values go<br>
>>> >> off the end of the 80
column character width. Same for some other<br>
>>> >> comments following
defines for OMAP3_TIMER, AM33X_DMTIMER1, and<br>
>>> >> AM335X_TIMER_. And
further below for the CM_ WKUP and
CM_PER_TIMER7<br>
>>> >> defines, and
CLKSEL_TIMER1MS_CLK_SEL_SEL5.<br>
>>> >><br>
>>> >> +#define OMAP3_TCLR_AR
(1 << 1) /* Autoreload or one-shot
mode<br>
>>> >> */<br>
>>> >> +#define OMAP3_TCLR_PRE
(1 << 5) /* Prescaler on */<br>
>>> >> +#define OMAP3_TCLR_PTV
2<br>
>>> >> This PTV is odd compared
to the other defines here. Is it 2 ==
(1<<1),<br>
>>> >> or is there a typo here?<br>
>>> >><br>
>>> >> Tabs are used in the
OMAP3_CM_ defines, it should be space
characters.<br>
>>> >> Also tabs are used in
the read/write actlr, ttbcr, dacr, rrbr0<br>
>>> >> functions and the
refresh_tlb function.<br>
>>> >><br>
>>> >> +/* i2c stuff */<br>
>>> >> +typedef struct {<br>
>>> >> ...<br>
>>> >> +} beagle_i2c;<br>
>>> >> Shouldn't this go in
beagle/include/i2c.h?<br>
>>> >><br>
>>> >> All of this mmu handling
code should be refactored. Where possible, it<br>
>>> >> should use the existing
code in arm-cp15.h<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/include/i2c.h<br>
>>> >> This header defines
static, non-inline functions. This doesn't
make<br>
>>> >> sense.<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/irq.c<br>
>>> >> +static int
irqs_enabled[BSP_INTERRUPT_VECTOR_MAX+1];<br>
>>> >> This is an array of 512
bytes. You could use a bit vector comprising 4<br>
>>> >> unsigned ints for the
same purpose.<br>
>>> >><br>
>>> >> +volatile static int
level = 0;<br>
>>> >> Unused variable?<br>
>>> >><br>
>>> >> +static uint32_t
get_mir_reg(int vector, uint32_t *mask)<br>
>>> >> + if(vector < 0)
while(1) ;<br>
>>> >> Make this a fatal error?<br>
>>> >><br>
>>> >> + if(vector < 32)
return OMAP3_INTCPS_MIR0;<br>
>>> >> + if(vector < 32)
return OMAP3_INTCPS_MIR0;<br>
>>> >> duplicate code.<br>
>>> >><br>
>>> >> + while(1) ;<br>
>>> >> Make this a fatal error?<br>
>>> >><br>
>>> >> +rtems_status_code
bsp_interrupt_facility_initialize(void)<br>
>>> >> +
mmio_write(omap_intr.base +
OMAP3_INTCPS_SYSCONFIG,<br>
>>> >>
OMAP3_SYSCONFIG_AUTOIDLE);<br>
>>> >> Line length > 80.<br>
>>> >><br>
>>> >> +++
b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c<br>
>>> >><br>
>>> >> +//static uint32_t
pagetable[ARM_SECTIONS] __attribute__((aligned<br>
>>> >> (1024*16)));<br>
>>> >> commented-out.. delete
it?<br>
>>> >><br>
>>> >> +BSP_START_TEXT_SECTION
void beagle_setup_mmu_and_cache(void)<br>
>>> >> __attribute__ ((weak));<br>
>>> >> More than 80 characters.<br>
>>> >><br>
>>> >> diff --git
a/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>> >>
b/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>> >> index ab6082e..828fd89
100644<br>
>>> >> ---
a/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>> >> +++
b/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>> >> diff --git
a/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>> >>
b/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>> >> index 6442399..e46fa2b
100644<br>
>>> >> ---
a/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>> >> +++
b/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>> >> Don't include these
changes. Check your tool versions, and if the<br>
>>> >> correct version of tools
does this, provide a separate patch for<br>
>>> >> generated files.<br>
>>> >><br>
>>> >> -Gedare<br>
>>> >><br>
>>> >> On Wed, Jul 23, 2014 at
9:00 PM, Ben Gras <<a href="mailto:beng@shrike-systems.com" target="_blank">beng@shrike-systems.com</a>><br>
>>> >> wrote:<br>
>>> >> > All,<br>
>>> >> ><br>
>>> >> > Full details on how
to reproduce all the work from source<br>
>>> >> > repositories<br>
>>> >> > to<br>
>>> >> > scripts &
utilities to write a complete sd card booting
RTEMS and<br>
>>> >> > test<br>
>>> >> > the<br>
>>> >> > whole thing:<br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> > <a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a><br>
>>> >> ><br>
>>> >> > I am submitting the
attached patch for review for merging. If<br>
>>> >> > accepted<br>
>>> >> > for<br>
>>> >> > merging, please use
the top two commits on<br>
>>> >> ><br>
>>> >> > <a href="https://github.com/bengras/rtems/tree/beaglebone-wip" target="_blank">https://github.com/bengras/rtems/tree/beaglebone-wip</a><br>
>>> >> ><br>
>>> >> > which have the same
net effect but preserve Claas' work because of<br>
>>> >> > the<br>
>>> >> > earlier commit. The
squashed version attached is for more
convenient<br>
>>> >> > review.<br>
>>> >> ><br>
>>> >> > I was ironing out
more wrinkles but given recent interest it
seems<br>
>>> >> > smarter<br>
>>> >> > to merge sooner and
keep polishing from mainline. Nevertheless I<br>
>>> >> > have<br>
>>> >> > put a<br>
>>> >> > lot of work into
getting it into good shape already.<br>
>>> >> ><br>
>>> >> > I have rebased
everything on the very latest master and
verified<br>
>>> >> ><br>
>>> >> > That building all
the tools and utilities from scratch work,
using<br>
>>> >> > the<br>
>>> >> > RTEMS<br>
>>> >> > Source Builder
repository (Ubuntu + FreeBSD).<br>
>>> >> > That building the
beaglebone and bbxm BSPs and linking them with
all<br>
>>> >> > the<br>
>>> >> > testsuite programs
works (Ubuntu + FreeBSD).<br>
>>> >> > That the
beaglexm-emulating linaro qemu executes all of
those tests<br>
>>> >> > properly, invoked
using a single command line with the scripts
in<br>
>>> >> > the<br>
>>> >> > RTEMS<br>
>>> >> > tools repository,
even though not all pass currently (Ubuntu +<br>
>>> >> > FreeBSD).<br>
>>> >> > That loading &
running over JTAG works, both interactively
with gdb<br>
>>> >> > and<br>
>>> >> > in a<br>
>>> >> > batch using gdb and
the test runner.<br>
>>> >> > That running RTEMS
executables using u-boot on the beaglebones
from<br>
>>> >> > sd<br>
>>> >> > card<br>
>>> >> > work; both with and
without MMU enabled at RTEMS start time.<br>
>>> >> > That Claas' earlier
commit builds.<br>
>>> >> ><br>
>>> >> > Thanks so far to
Chris and Brandon for help, support,
instructions<br>
>>> >> > and<br>
>>> >> > advice in various
forms :)<br>
>>> >> ><br>
>>> >> > Test results on
qemu:<br>
>>> >> > Passed: 497
Failed: 3 Timeouts: 1 Invalid: 0<br>
>>> >> ><br>
>>> >> > The test results on
bbxm over jtag (older):<br>
>>> >> > Passed: 475
Failed: 7 Timeouts: 10 Invalid: 0<br>
>>> >> ><br>
>>> >> > I want to iron out
more wrinkles and build support (ethernet) but<br>
>>> >> > giving<br>
>>> >> > the<br>
>>> >> > bsp more exposure
and having it in mainline so i don't have to
keep<br>
>>> >> > rebasing<br>
>>> >> > & testing would
be nice at this point.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> >
_______________________________________________<br>
>>> >> > devel mailing list<br>
>>> >> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>> ><br>
>>> ><br>
>><br>
>><br>
><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div><span class=""><pre cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a href="mailto:joel.sherrill@OARcorp.com" target="_blank">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available <a href="tel:%28256%29%20722-9985" value="+12567229985" target="_blank">(256) 722-9985</a></pre>
</span></div>
</blockquote></div><br></div>