About cache enabling in LWIP port of BBB in RTEMS
Marcos Díaz
marcos.diaz at tallertechnologies.com
Thu Sep 17 20:53:29 UTC 2015
I can only tell you about the boards i tested:
I have a revision A5C board with an XAM3359AZCZ100 microcontroller. The use
of cache together with ethernet makes this break.
I have a revision C board with an AM3358BZCZ100. This does work with cache
and ethernet.
Apparently Ragu has a rev A5 with an AM3358BZCZ100. Cache doesn't work for
him.
After reading this document:
http://elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes
I can say that the boards I have match with that descripcion. Revisions A4,
A4A, A4B have an AM3352 processor,
rev A5A A5B A5C A6 A6A have an XAM3359, and revisions B and C have an
AM3358 processor.
I'm not very sure about what Ragu has, since there it says he has a rev A5
(not mentioned in the document) but with the processor of the newer
revisions (AM3358).
In Ragu's case the checking of the registers for the processor revision
wont do any help, since he has the same processor that in my case works Ok,
but his doesn't.
Hope this clarifies.
On Thu, Sep 17, 2015 at 5:02 PM, Joel Sherrill <joel.sherrill at oarcorp.com>
wrote:
> Can of of you guys start a table/spreadsheet about board
> and SoC revisions and when we think it is broken and when
> it works?
>
> I emailed the BB project lead and he didn't know anything
> off hand but suggested subscribing to beagleboard at googlegroups.com
> and asking there. Someone there may actually have an answer.
>
> --joel
>
> On 9/17/2015 2:05 PM, Marcos Díaz wrote:
>
>> Ragu,
>> I would like you to confirm which revision you have, for this I printed
>> the following registers in the BBB:
>>
>> 0x44E10600 and 0x44E10604
>>
>> The first will print something like:
>> 1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b means rev.A of the
>> microcontroller)
>> 2b94402e for BBB rev C (AM3358BZCZ100) (2b means rev B of the
>> microcontroller)
>>
>> The second register will print something like:
>>
>> 20ff0383 for A5c (this means that this is AM3359)
>> 20fd0383 for C (this means it is an AM3358).
>>
>> Please let me know which are this values in your Board.
>>
>> Thanks!
>>
>>
>>
>> On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz <
>> marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com>> wrote:
>>
>> Yes, sorry about that, There are two registers we can check to see
>> the different revision numbers. I will check it myself once i confirm that
>> the different revisions are the problem (i'm not sure because of what Ragu
>> said). Thanks!
>>
>> On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill <
>> joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>>
>>
>>
>> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>>
>> Yes, in my case the older (that doesn't work) revision is a
>> XAM3359AZCZ100
>>
>> And the rev C (that works well with cache) is
>> AM3358BZCZ100
>>
>>
>> Can we determine that in software?
>>
>> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill <
>> joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com> <mailto:
>> joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>>> wrote:
>>
>>
>>
>> On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
>> marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com> <mailto:
>> marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com>>> wrote:
>> >Hi,
>> >
>> >How did you see the revision number? if you are using
>> u-boot you can
>> >pause the start and write printenv and enter to see
>> that:
>> >
>> >
>> >board=am335x
>> >board_name=A335BNLT
>> >board_rev=00C0
>> >
>> >
>> >This is in my version.
>> >
>> >Please tell me so I can check if is the revision, or
>> perhaps is
>> >something else in u-boot initialization.
>> >
>> >
>> >For the question Joel asked there is a way:
>> >
>> >
>> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>> >
>> >apparently, in the eeprom thorugh i2c it is recorded.
>> But first we must
>> >confirm that is a problem from the revisions, since
>> Ragu has the
>> >problem in a rev C.
>>
>> Does the SoC itself have a revision number we can read?
>> It may be that newer boards have a newer CPU.
>>
>> >Greetings
>> >
>> >
>> >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
>> ><joel.sherrill at oarcorp.com <mailto:
>> joel.sherrill at oarcorp.com> <mailto:joel.sherrill at oarcorp.com <mailto:
>> joel.sherrill at oarcorp.com>>> wrote:
>> >
>> >
>> >
>> >On 9/16/2015 2:41 PM, ragu nath wrote:
>> >
>> >Hi Marcos,
>> >
>> >Great news! I did not find any solution to the issue.
>> I have a REV C
>> >board from element14. Is this the same board you are
>> using? In my
>> >board I saw the issue.
>> >
>> >Does this have anything to do with the patch you
>> submitted [PATCH]
>> >Beaglebone: fix missing clobber in inline assembly.
>> >
>> https://lists.rtems.org/pipermail/devel/2015-September/012531.html
>> >I have not yet tested with this patch.
>> >
>> >The freebsd driver is working with cache disabled. If
>> possible pls
>> >check if it is working with cache enabled in your
>> board.
>> >
>> >
>> >If this is a board revision related issue, is there a
>> way
>> >programmatically to
>> >know which revision the board is? That way the BSP
>> could auto-detect
>> >the right
>> >thing to do. Otherwise, we may be looking at a BSP
>> variant or a build
>> >option.
>> >I would rather avoid those if we can auto-detect.
>> >
>> >--joel
>> >
>> >
>> >Thanks,
>> >Ragunath
>> >
>> >
>> >On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
>> ><marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com> <mailto:
>> marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com>>
>> ><mailto:marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com> <mailto:
>> marcos.diaz at tallertechnologies.com <mailto:
>> marcos.diaz at tallertechnologies.com>>>> wrote:
>> >
>> > Hi Ragu,
>> >I wanted to know if you were able to see something
>> else about the
>> >problem we had in the BBB when using LWIP and enabling
>> cache ( the
>> >program freezes).
>> >I can tell you that here we were using BBB rev. A5C
>> and had this
>> >problem, but now we could test this with a BBB Rev C,
>> and it
>> >successfully works with cache enabled (using the same
>> sdcard in both
>> >boards, one works and the other doesn't).
>> > Greetings
>> >
>> > --
>> >
>> > ______________________________
>> >
>> > <http://www.tallertechnologies.com>
>> >
>> > *
>> > *
>> >
>> > Marcos Díaz
>> >
>> > Software Engineer
>> >
>> > *
>> > *
>> >
>> > San Lorenzo 47, 3rd Floor, Office 5
>> >
>> > Córdoba, Argentina
>> >
>> > *
>> > *
>> >
>> > Phone:+54 351 4217888 / +54 351 4218211/ +54 351
>> 7617452
>> >
>> > Skype:markdiaz22
>> >
>> >
>> >
>> >
>> >
>> >--
>> >ragu
>> >
>> >
>> >--
>> >Joel Sherrill, Ph.D. Director of Research
>> & Development
>> >joel.sherrill at OARcorp.com On-Line Applications
>> Research
>> >Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> >Support Available (256) 722-9985
>> >
>> >
>> >
>> >
>> >--
>> >
>> >______________________________
>> >
>> >
>> >
>> >
>> >Marcos Díaz
>> >
>> >Software Engineer
>> >
>> >
>> >San Lorenzo 47, 3rd Floor, Office 5
>> >
>> >Córdoba, Argentina
>> >
>> >
>> >Phone: +54 351 4217888 / +54 351 4218211/ +54 351
>> 7617452
>> >
>> >Skype: markdiaz22
>>
>> --joel
>>
>>
>>
>>
>> --
>>
>> ______________________________
>>
>> <http://www.tallertechnologies.com>
>>
>> *
>> *
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>> *
>> *
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>> *
>> *
>>
>> Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype:markdiaz22
>>
>>
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research &
>> Development
>> joel.sherrill at OARcorp.com On-Line Applications Research
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available (256) 722-9985
>>
>>
>>
>>
>> --
>>
>> ______________________________
>>
>> <http://www.tallertechnologies.com>
>>
>> *
>> *
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>> *
>> *
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>> *
>> *
>>
>> Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype:markdiaz22
>>
>>
>>
>>
>>
>> --
>>
>> ______________________________
>>
>> <http://www.tallertechnologies.com>
>>
>> *
>> *
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>> *
>> *
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>> *
>> *
>>
>> Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype:markdiaz22
>>
>>
>>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
--
______________________________
<http://www.tallertechnologies.com>
Marcos Díaz
Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
Skype: markdiaz22
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150917/7413dafd/attachment-0002.html>
More information about the devel
mailing list