720MHz beagleboard

[kalyan]

Hi,

when can we expect the beagleboard with 720MHz OMAP3? also would like
to know if this rev'd up OMAP3 will be able to play 1080p movies?

Regards,
Kalyan

[Gerald Coley]

Rev C4 will be a 720MHz version and we plan to start shipping that version in a month, depending on parts availbility. No, it will not be able to do full HD.

 

Gerald

[Robert P. J. Day]

On Sun, 1 Nov 2009, Gerald Coley wrote:

> Rev C4 will be a 720MHz version and we plan to start shipping that
> version in a month, depending on parts availbility. No, it will not
> be able to do full HD.

is there a list of differences between C3 and C4?

rday
--

========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA

Linux Consulting, Training and Kernel Pedantry.

Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================

[Gerald Coley]

Just two. The 720MHz transition and a change in the way we power the USB Host PHY in an attempt to fix the USB PHY noise issue..

 

Gerald

[Robert P. J. Day]

On Sun, 1 Nov 2009, Gerald Coley wrote:

> Just two [diffs between C3 and C4 revs]. The 720MHz transition and a

> change in the way we power the USB Host PHY in an attempt to fix the
> USB PHY noise issue..

in short, nothing of any *functional* difference.

[Gerald Coley]

Basically. It does require a change in UBoot for the power change on the PHY, but no real features are being added.

 

Gerald

[Koen Kooi]

Op 1 nov 2009, om 14:58 heeft Gerald Coley het volgende geschreven:

> Basically. It does require a change in UBoot for the power change on
> the PHY, but no real features are being added.

Will C4 have a new board ID so we can have a single uboot for rev B,
revC1-3 and RevC4?

regards,

Koen

[Gerald Coley]

Of course.

 

Gerald

[Dirk Behme]

Gerald Coley wrote:
> Of course.

:)

Let us know the details as soon as possible.

Thanks

Dirk

[Gerald Coley]

GPIO171 is 1 

GPIO172 is 0

GPIO173 is 1 

[Dirk Behme]

Gerald Coley wrote:
> GPIO171 is 1
> GPIO172 is 0
> GPIO173 is 1

U-Boot patch to detect this for review and test in attachment.

Best regards

Dirk

Btw.: What's about calling "C4" instead revision D?

[Vladimir Pantelic]

Dirk Behme wrote:
> Gerald Coley wrote:
>> GPIO171 is 1
>> GPIO172 is 0
>> GPIO173 is 1
>
> U-Boot patch to detect this for review and test in attachment.
>
> Best regards
>
> Dirk
>
> Btw.: What's about calling "C4" instead revision D?

revD is something else:

> The Rev D version will have the camera interface on it and is scheuled for sometime around May, 2010.
>
> Gerald

[Gerald Coley]

There is a C4 and a RevD. Do you want the current C4 to be Rev D and the D to be C4?

 

Gerald

 

On Tue, Nov 3, 2009 at 12:13 PM, Dirk Behme <dirk....@googlemail.com> wrote:

Gerald Coley wrote:
> GPIO171 is 1
> GPIO172 is 0
> GPIO173 is 1

U-Boot patch to detect this for review and test in attachment.

Best regards

Dirk

Btw.: What's about calling "C4" instead revision D?

> On Sun, Nov 1, 2009 at 11:16 AM, Dirk Behme <dirk....@googlemail.com>wrote:
>
>> Gerald Coley wrote:
>>> Of course.
>> :)
>>
>> Let us know the details as soon as possible.
>>
>> Thanks
>>
>> Dirk
>>
>>> On Sun, Nov 1, 2009 at 8:36 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>>>
>>>> Op 1 nov 2009, om 14:58 heeft Gerald Coley het volgende geschreven:
>>>>
>>>>> Basically. It does require a change in UBoot for the power change on
>>>>> the PHY, but no real features are being added.
>>>> Will C4 have a new board ID so we can have a single uboot for rev B,
>>>> revC1-3 and RevC4?
>>>>
>>>> regards,
>>>>
>>>> Koen
>>>>
>>
>
> >
>

Subject: [PATCH] OMAP3: Beagle: Update board revision detection
From: Dirk Behme <dirk....@googlemail.com>

New BeagleBoard revision C4 uses a new ID.

Known C4 changes:

- Use OMAP3 720MHz devices.
- Change in the way the USB Host PHY is powered.

Signed-off-by: Dirk Behme <dirk....@googlemail.com>
---

Note: Due to lack of C4, not tested on C4 yet.

 board/ti/beagle/beagle.c |   66 +++++++++++++++++++++++++++++------------------
 board/ti/beagle/beagle.h |    8 ++++-
 2 files changed, 48 insertions(+), 26 deletions(-)

Index: u-boot-main/board/ti/beagle/beagle.c
===================================================================
--- u-boot-main.orig/board/ti/beagle/beagle.c
+++ u-boot-main/board/ti/beagle/beagle.c
@@ -38,7 +38,7 @@
 #include <asm/mach-types.h>
 #include "beagle.h"

-static int beagle_revision_c;
+static int beagle_revision;

 /*
 * Routine: board_init
@@ -60,41 +60,59 @@ int board_init(void)
 /*
 * Routine: beagle_get_revision
 * Description: Return the revision of the BeagleBoard this code is running on.
- *              If it is a revision Ax/Bx board, this function returns 0,
- *              on a revision C board you will get a 1.
 */
 int beagle_get_revision(void)
 {
-       return beagle_revision_c;
+       return beagle_revision;
 }

 /*
 * Routine: beagle_identify
- * Description: Detect if we are running on a Beagle revision Ax/Bx or
- *              Cx. This can be done by GPIO_171. If this is low, we are
- *              running on a revision C board.
+ * Description: Detect if we are running on a Beagle revision Ax/Bx,
+ *             C2, C3 or Cx (x >= 4). This can be done by reading
+ *             the level of GPIO173, GPIO172 and GPIO171. This should
+ *             result in
+ *             GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx
+ *             GPIO173, GPIO172, GPIO171: 1 1 0 => C1
+ *             GPIO173, GPIO172, GPIO171: 1 0 0 => C3
+ *             GPIO173, GPIO172, GPIO171: 1 0 1 => Cx (x >= 4)
 */
 void beagle_identify(void)
 {
-       beagle_revision_c = 0;
-       if (!omap_request_gpio(171)) {
-               unsigned int val;
-
-               omap_set_gpio_direction(171, 1);
-               val = omap_get_gpio_datain(171);
-               omap_free_gpio(171);
-
-               if (val)
-                       beagle_revision_c = 0;
-               else
-                       beagle_revision_c = 1;
-       }
+       omap_request_gpio(171);
+       omap_request_gpio(172);
+       omap_request_gpio(173);
+       omap_set_gpio_direction(171, 1);
+       omap_set_gpio_direction(172, 1);
+       omap_set_gpio_direction(173, 1);
+
+       beagle_revision = omap_get_gpio_datain(173) << 2 |
+                         omap_get_gpio_datain(172) << 1 |
+                         omap_get_gpio_datain(171);
+       omap_free_gpio(171);
+       omap_free_gpio(172);
+       omap_free_gpio(173);

       printf("Board revision ");
-       if (beagle_revision_c)
-               printf("C\n");
-       else
+
+       printf("0x%02x ", beagle_revision);
+
+       switch (beagle_revision) {
+       case REVISION_AXBX:
               printf("Ax/Bx\n");
+               break;
+       case REVISION_C1:
+               printf("C1\n");
+               break;
+       case REVISION_C3:
+               printf("C3\n");
+               break;
+       case REVISION_C4:
+               printf(">= C4\n");
+               break;
+       default:
+               printf("unknown 0x%02x\n", beagle_revision);
+       }
 }

 /*
@@ -137,7 +155,7 @@ void set_muxconf_regs(void)
 {
       MUX_BEAGLE();

-       if (beagle_revision_c) {
+       if (beagle_revision != REVISION_AXBX) {
               MUX_BEAGLE_C();
       }
 }
Index: u-boot-main/board/ti/beagle/beagle.h
===================================================================
--- u-boot-main.orig/board/ti/beagle/beagle.h
+++ u-boot-main/board/ti/beagle/beagle.h
@@ -33,7 +33,11 @@ const omap3_sysinfo sysinfo = {
 #endif
 };

-#define BOARD_REVISION_MASK    (0x1 << 11)
+/* BeagleBoard revisions */
+#define REVISION_AXBX  0x7
+#define REVISION_C1    0x6
+#define REVISION_C3    0x4
+#define REVISION_C4    0x5

 /*
 * IEN  - Input Enable
@@ -264,7 +268,7 @@ const omap3_sysinfo sysinfo = {
       MUX_VAL(CP(HDQ_SIO),            (IDIS | PTU | EN  | M4)) /*GPIO_170*/\
       MUX_VAL(CP(MCSPI1_CLK),         (IEN  | PTU | EN  | M4)) /*GPIO_171*/\
       MUX_VAL(CP(MCSPI1_SIMO),        (IEN  | PTU | EN  | M4)) /*GPIO_172*/\
-       MUX_VAL(CP(MCSPI1_SOMI),        (IEN  | PTD | DIS | M0)) /*McSPI1_SOMI*/\
+       MUX_VAL(CP(MCSPI1_SOMI),        (IEN  | PTU | EN  | M4)) /*GPIO_173*/\
       MUX_VAL(CP(MCSPI1_CS0),         (IEN  | PTD | EN  | M0)) /*McSPI1_CS0*/\
       MUX_VAL(CP(MCSPI1_CS1),         (IDIS | PTD | EN  | M0)) /*McSPI1_CS1*/\
       MUX_VAL(CP(MCSPI1_CS2),         (IDIS | PTD | DIS | M4)) /*GPIO_176*/\

[Koen Kooi]

Op 1 nov 2009, om 19:26 heeft Gerald Coley het volgende geschreven:

> GPIO171 is 1
> GPIO172 is 0
> GPIO173 is 1

Since Dirk is working on this, would it make sense to prepare uboot
for revD as well? Having the ID in there now would save a bit of work
in the future :) We can fix the pinmux when we have actual revD boards
available for testing.

regards,

Koen

[Gerald Coley]

Rev D is:

GPIO171 is 0

GPIO172 is 0
GPIO173 is 0

 

Gerald

[Dirk Behme]

Gerald Coley wrote:
> There is a C4 and a RevD. Do you want the current C4 to be Rev D and the D
> to be C4?

I don't now anything about rev D.

This thread is about a board that was said to have

- Use OMAP3 720MHz devices.
- Change in the way the USB Host PHY is powered.

and ID code

GPIO171 is 1
GPIO172 is 0
GPIO173 is 1

This was said to be called "C4" in this thread.

Looking at the ID decoding which has to be done in SW (have a look to
the patch I sent), what I think we currently have is

GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx

GPIO173, GPIO172, GPIO171: 1 1 0 => C1 (C2?)

GPIO173, GPIO172, GPIO171: 1 0 0 => C3

GPIO173, GPIO172, GPIO171: 1 0 1 => C4 (>= C4?)

which makes it somehow difficult to find a proper name for the SW
#defines and variables. So I was just wondering if a switch to an OMAP
720MHz device (with more RAM?) wouldn't justify a new 'major' number,
i.e. 'D'. This would make the naming for SW macros and variables
easier, too ;)

Best regards

Dirk

[Gerald Coley]

The 720MHz will NOT have more RAM, same as C3, 256MB. Rev D is the next major spin of the board due in April/May timeframe of next year which will have more than you can handle in the way of changes.

 

If everyone chooses to ignore the 720MHZ on C4, as that is all we can get to build these boards, then I guess that is for everyone to chime in on. The HW will be marked C4.

 

Gerald

[Dirk Behme]

Gerald Coley wrote:
> The 720MHz will NOT have more RAM, same as C3, 256MB. Rev D is the next
> major spin of the board due in April/May timeframe of next year which will
> have more than you can handle in the way of changes.
>
> If everyone chooses to ignore the 720MHZ on C4, as that is all we can get to
> build these boards, then I guess that is for everyone to chime in on. The HW
> will be marked C4.

Ok.

Gerald: Do you think

GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx

GPIO173, GPIO172, GPIO171: 1 1 0 => C1, C2

GPIO173, GPIO172, GPIO171: 1 0 0 => C3
GPIO173, GPIO172, GPIO171: 1 0 1 => C4

GPIO173, GPIO172, GPIO171: 0 0 0 => D

this decoding is correct, then?

Koen: While I agree that it would be nice to add rev D (0 0 0), too, I
wonder what might change until April/May and if we shouldn't wait a
little more until things are more settled?

[Gerald Coley]

This looks correct.

 

Gerald

[Koen Kooi]

Op 3 nov 2009, om 21:11 heeft Dirk Behme het volgende geschreven:

>
> Gerald Coley wrote:
>> The 720MHz will NOT have more RAM, same as C3, 256MB. Rev D is the
>> next
>> major spin of the board due in April/May timeframe of next year
>> which will
>> have more than you can handle in the way of changes.
>>
>> If everyone chooses to ignore the 720MHZ on C4, as that is all we
>> can get to
>> build these boards, then I guess that is for everyone to chime in
>> on. The HW
>> will be marked C4.
>
> Ok.
>
> Gerald: Do you think
>
> GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx
> GPIO173, GPIO172, GPIO171: 1 1 0 => C1, C2
> GPIO173, GPIO172, GPIO171: 1 0 0 => C3
> GPIO173, GPIO172, GPIO171: 1 0 1 => C4
> GPIO173, GPIO172, GPIO171: 0 0 0 => D
>
> this decoding is correct, then?
>
> Koen: While I agree that it would be nice to add rev D (0 0 0), too, I
> wonder what might change until April/May and if we shouldn't wait a
> little more until things are more settled?

I wouldn't expect the ID to change, but I know the mux needs a few big
changes. My goal is to have rev C4 and rev D detection in upstream
uboot ASAP, not to have a perfect revD experience :)

regards,

Koen

[Dirk Behme]

Updated patch with revD detection for review and testing in attachment.

Thanks

Dirk

[Ian R]

On Nov 1, 9:16 am, Dirk Behme <dirk.be...@googlemail.com> wrote:
> Gerald Coley wrote:
> > Of course.
>
> :)
>
> Let us know the details as soon as possible.
>
> Thanks
>
> Dirk

Hi Dirk

We also need a workaround for an extremely rare NEON corner-case that
can cause processor lockup.

The Cortex-A8 L2 Cache Auxiliary Control Register bit [27] "Load data
forwarding disable" (also known as PLD_FWD) should be set to a 1, as
a workaround which does not add any significant performance impact.

MCR p15, 1, <Rd>, c9, c0, 2 ; Write L2 Cache Auxiliary Control
Register

Note this register can only be written in secure privileged state so
needs to be done via TI's secure world

Many thanks if this can get into any forthcoming u-boot.

[Dirk Behme]

I don't think we are able to switch Beagle into secure privileged
state. I'm not sure if OMAP35x even can be switched into secure mode
(in contrast to OMAP34x). If I'm wrong here, please correct me.

Please send a patch.

Mans: As our NEON expert: Any comments from your side?

Many thanks

Dirk

[Siarhei Siamashka]

A fix for beagleboard is trivial, it can be done by something like this:
http://siarhei.siamashka.name/gitweb/?p=u-boot.git;a=commit;h=fdb8cd6eccadb67425a6f13f1c67b61f51f5aec9

--
Best regards,
Siarhei Siamashka

[Måns Rullgård]

Siarhei Siamashka <siarhei....@gmail.com> writes:

Looks about right as far as your changes go. The asm in that function
is awful, and it's only by luck that it works at all.

--
Måns Rullgård
ma...@mansr.com

[Ian R]

On Nov 9, 1:13 pm, Måns Rullgård <m...@mansr.com> wrote:

> >http://siarhei.siamashka.name/gitweb/?p=u-boot.git;a=commit;h=fdb8cd6...

>
> Looks about right as far as your changes go.  The asm in that function
> is awful, and it's only by luck that it works at all.
>
> --
> Måns Rullgård

> m...@mansr.com

FYI the official ARM erratum number is 725233 "PLD instructions
executed with PLD data forwarding enabled can result in a processor
deadlock" and could be usefully mentioned in any patch

Thanks everyone

[Dirk Behme]

Does anybody had a chance to test this patch on C3 and C4?

Thanks

Dirk

[Gerald Coley]

There are no C4 boards yet.

 

Gerald

 

Thanks

Dirk

--

You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/beagleboard?hl=.

Subject: [PATCH] OMAP3: Beagle: Update board revision detection
From: Dirk Behme <dirk....@googlemail.com>

New BeagleBoard revision C4 uses a new ID.

Known C4 changes:

- Use OMAP3 720MHz devices.
- Change in the way the USB Host PHY is powered.

Signed-off-by: Dirk Behme <dirk....@googlemail.com>
---

Note: Due to lack of C4, not tested on C4 yet.

 board/ti/beagle/beagle.c |   68 ++++++++++++++++++++++++++++++-----------------
 board/ti/beagle/beagle.h |    9 ++++--
 2 files changed, 51 insertions(+), 26 deletions(-)

Index: u-boot-main/board/ti/beagle/beagle.c
===================================================================
--- u-boot-main.orig/board/ti/beagle/beagle.c
+++ u-boot-main/board/ti/beagle/beagle.c
@@ -38,7 +38,7 @@
 #include <asm/mach-types.h>
 #include "beagle.h"

-static int beagle_revision_c;
+static int beagle_revision;

 /*
 * Routine: board_init

@@ -60,41 +60,61 @@ int board_init(void)

 /*
 * Routine: beagle_get_revision
 * Description: Return the revision of the BeagleBoard this code is running on.
- *              If it is a revision Ax/Bx board, this function returns 0,
- *              on a revision C board you will get a 1.
 */
 int beagle_get_revision(void)
 {
-       return beagle_revision_c;
+       return beagle_revision;
 }

 /*
 * Routine: beagle_identify
- * Description: Detect if we are running on a Beagle revision Ax/Bx or
- *              Cx. This can be done by GPIO_171. If this is low, we are
- *              running on a revision C board.
+ * Description: Detect if we are running on a Beagle revision Ax/Bx,

+ *             C1/2, C3, C4 or D. This can be done by reading

+ *             the level of GPIO173, GPIO172 and GPIO171. This should
+ *             result in

+ *             GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx
+ *             GPIO173, GPIO172, GPIO171: 1 1 0 => C1/2
+ *             GPIO173, GPIO172, GPIO171: 1 0 0 => C3
+ *             GPIO173, GPIO172, GPIO171: 1 0 1 => C4
+ *             GPIO173, GPIO172, GPIO171: 0 0 0 => D

+       switch (beagle_revision) {
+       case REVISION_AXBX:
               printf("Ax/Bx\n");
+               break;
+       case REVISION_C1:

+               printf("C1/2\n");

+               break;
+       case REVISION_C3:
+               printf("C3\n");
+               break;
+       case REVISION_C4:

+               printf("C4\n");
+               break;
+       case REVISION_D:
+               printf("D\n");

+               break;
+       default:
+               printf("unknown 0x%02x\n", beagle_revision);
+       }
 }

 /*

@@ -137,7 +157,7 @@ void set_muxconf_regs(void)

 {
       MUX_BEAGLE();

-       if (beagle_revision_c) {
+       if (beagle_revision != REVISION_AXBX) {
               MUX_BEAGLE_C();
       }
 }
Index: u-boot-main/board/ti/beagle/beagle.h
===================================================================
--- u-boot-main.orig/board/ti/beagle/beagle.h
+++ u-boot-main/board/ti/beagle/beagle.h

@@ -33,7 +33,12 @@ const omap3_sysinfo sysinfo = {

 #endif
 };

-#define BOARD_REVISION_MASK    (0x1 << 11)
+/* BeagleBoard revisions */
+#define REVISION_AXBX  0x7
+#define REVISION_C1    0x6
+#define REVISION_C3    0x4
+#define REVISION_C4    0x5

+#define REVISION_D     0x0

 /*
 * IEN  - Input Enable

@@ -264,7 +269,7 @@ const omap3_sysinfo sysinfo = {

[Søren Steen Christensen]

Hi Dirk,

I just gave the patch a quick review and didn't find any obvious mistakes...

I think it should be fairly safe to send upstream :-)
Søren

> --
>
> You received this message because you are subscribed to the Google
> Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to
> beagleboard...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beagleboard?hl=.
>
>
>

> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.425 / Virus Database: 270.14.59/2494 - Release Date:
> 11/10/09 07:38:00

[Steve]

Works great on my C2 board. C4 board reports back as Ax/Bx.

Steve K.

> [uboot_beagle_revc4_detection_patch.txt4K ]Subject: [PATCH] OMAP3: Beagle: Update board revision detection
> From: Dirk Behme <dirk.be...@googlemail.com>

>
> New BeagleBoard revision C4 uses a new ID.
>
> Known C4 changes:
>
> - Use OMAP3 720MHz devices.
> - Change in the way the USB Host PHY is powered.
>

> Signed-off-by: Dirk Behme <dirk.be...@googlemail.com>

> ---
>
> Note: Due to lack of C4, not tested on C4 yet.
>

>  board/ti/beagle/beagle.c |   68 ++++++++++++++++++++++++++++++-----------------
>  board/ti/beagle/beagle.h |    9 ++++--

>  2 files changed, 51 insertions(+), 26 deletions(-)

>
> Index: u-boot-main/board/ti/beagle/beagle.c
> ===================================================================
> --- u-boot-main.orig/board/ti/beagle/beagle.c
> +++ u-boot-main/board/ti/beagle/beagle.c
> @@ -38,7 +38,7 @@
>  #include <asm/mach-types.h>
>  #include "beagle.h"
>
> -static int beagle_revision_c;
> +static int beagle_revision;
>
>  /*
>   * Routine: board_init

> @@ -60,41 +60,61 @@ int board_init(void)

>  /*
>   * Routine: beagle_get_revision
>   * Description: Return the revision of the BeagleBoard this code is running on.
> - *              If it is a revision Ax/Bx board, this function returns 0,
> - *              on a revision C board you will get a 1.
>   */
>  int beagle_get_revision(void)
>  {
> -       return beagle_revision_c;
> +       return beagle_revision;
>  }
>
>  /*
>   * Routine: beagle_identify
> - * Description: Detect if we are running on a Beagle revision Ax/Bx or
> - *              Cx. This can be done by GPIO_171. If this is low, we are
> - *              running on a revision C board.
> + * Description: Detect if we are running on a Beagle revision Ax/Bx,

> + *             C1/2, C3, C4 or D. This can be done by reading

> + *             the level of GPIO173, GPIO172 and GPIO171. This should
> + *             result in

> + *             GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx
> + *             GPIO173, GPIO172, GPIO171: 1 1 0 => C1/2
> + *             GPIO173, GPIO172, GPIO171: 1 0 0 => C3
> + *             GPIO173, GPIO172, GPIO171: 1 0 1 => C4
> + *             GPIO173, GPIO172, GPIO171: 0 0 0 => D

> +       switch (beagle_revision) {
> +       case REVISION_AXBX:
>                 printf("Ax/Bx\n");
> +               break;
> +       case REVISION_C1:

> +               printf("C1/2\n");

> +               break;
> +       case REVISION_C3:
> +               printf("C3\n");
> +               break;
> +       case REVISION_C4:

> +               printf("C4\n");
> +               break;
> +       case REVISION_D:
> +               printf("D\n");

> +               break;
> +       default:
> +               printf("unknown 0x%02x\n", beagle_revision);
> +       }
>  }
>
>  /*

> @@ -137,7 +157,7 @@ void set_muxconf_regs(void)

>  {
>         MUX_BEAGLE();
>
> -       if (beagle_revision_c) {
> +       if (beagle_revision != REVISION_AXBX) {
>                 MUX_BEAGLE_C();
>         }
>  }
> Index: u-boot-main/board/ti/beagle/beagle.h
> ===================================================================
> --- u-boot-main.orig/board/ti/beagle/beagle.h
> +++ u-boot-main/board/ti/beagle/beagle.h

> @@ -33,7 +33,12 @@ const omap3_sysinfo sysinfo = {

>  #endif
>  };
>
> -#define BOARD_REVISION_MASK    (0x1 << 11)
> +/* BeagleBoard revisions */
> +#define REVISION_AXBX  0x7
> +#define REVISION_C1    0x6
> +#define REVISION_C3    0x4
> +#define REVISION_C4    0x5

> +#define REVISION_D     0x0

>
>  /*
>   * IEN  - Input Enable

> @@ -264,7 +269,7 @@ const omap3_sysinfo sysinfo = {

[Koen Kooi]

So gpio 272 isn't getting set properly?

--

You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[Gerald Coley]

All GPIO pins are set properly on the Rev C4 board.

 

GPIO_171 Hi...............assuming that you activate the internal pullup and set it to an input.

GPIO_172 lo...............assuming that you set it to an input.

GPIO_173 Hi...............assuming that you activate the internal pullup and set it to an input.

 

Gerald

[Dirk Behme]

On 15.12.2009 18:12, Koen Kooi wrote:
> So gpio 272 isn't getting set properly?

It's my understanding that

C4: GPIO173 GPIO172 GPIO171: 1 0 1

and

Ax/Bx: GPIO173 GPIO172 GPIO171: 1 1 1

http://elinux.org/BeagleBoardPinMux#Board_IDs

So two options ;)

a) On Steve's board there is an issue with GPIO172

or

b) Something is wrong with my code in

http://groups.google.com/group/beagleboard/msg/d039898a9bf9afb3

Mmmh??

Btw, many thanks for testing! As usual: Untested code doesn't work...

Best regards

Dirk

>> beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>
>> .

[Dirk Behme]

On 15.12.2009 18:26, Gerald Coley wrote:
> All GPIO pins are set properly on the Rev C4 board.
>
> GPIO_171 Hi...............assuming that you activate the internal pullup and
> set it to an input.
> GPIO_172 lo...............assuming that you set it to an input.
> GPIO_173 Hi...............assuming that you activate the internal pullup and
> set it to an input.

Why different configuration for 172 compared to 171 + 173? I.e. why no
pullup for 172? Is this compatible to older boards?

Until now we had

MUX_VAL(CP(MCSPI1_CLK), (IEN | PTU | EN | M4))
/*GPIO_171*/\
MUX_VAL(CP(MCSPI1_SIMO), (IEN | PTU | EN | M4))
/*GPIO_172*/\
- MUX_VAL(CP(MCSPI1_SOMI), (IEN | PTD | DIS | M0))
/*McSPI1_SOMI*/\
+ MUX_VAL(CP(MCSPI1_SOMI), (IEN | PTU | EN | M4))
/*GPIO_173*/\

with pull up for 172. The two -/+ lines are the changes we made for
Rev C4 detection.

Dirk

>>> beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>
>>> .

>>> For more options, visit this group at
>>> http://groups.google.com/group/beagleboard?hl=en.
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Beagle Board" group.
>> To post to this group, send email to beagl...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>
>> .

[Steve]

Never mind, works fine on C4. I had a C4 hardware issue.

Steve K.

On Nov 10, 10:12 am, Dirk Behme <dirk.be...@googlemail.com> wrote:

> [uboot_beagle_revc4_detection_patch.txt4K ]Subject: [PATCH] OMAP3: Beagle: Update board revision detection
> From: Dirk Behme <dirk.be...@googlemail.com>

>
> New BeagleBoard revision C4 uses a new ID.
>
> Known C4 changes:
>
> - Use OMAP3 720MHz devices.
> - Change in the way the USB Host PHY is powered.
>

> Signed-off-by: Dirk Behme <dirk.be...@googlemail.com>

> ---
>
> Note: Due to lack of C4, not tested on C4 yet.
>

>  board/ti/beagle/beagle.c |   68 ++++++++++++++++++++++++++++++-----------------
>  board/ti/beagle/beagle.h |    9 ++++--

>  2 files changed, 51 insertions(+), 26 deletions(-)

>
> Index: u-boot-main/board/ti/beagle/beagle.c
> ===================================================================
> --- u-boot-main.orig/board/ti/beagle/beagle.c
> +++ u-boot-main/board/ti/beagle/beagle.c
> @@ -38,7 +38,7 @@
>  #include <asm/mach-types.h>
>  #include "beagle.h"
>
> -static int beagle_revision_c;
> +static int beagle_revision;
>
>  /*
>   * Routine: board_init

> @@ -60,41 +60,61 @@ int board_init(void)

>  /*
>   * Routine: beagle_get_revision
>   * Description: Return the revision of the BeagleBoard this code is running on.
> - *              If it is a revision Ax/Bx board, this function returns 0,
> - *              on a revision C board you will get a 1.
>   */
>  int beagle_get_revision(void)
>  {
> -       return beagle_revision_c;
> +       return beagle_revision;
>  }
>
>  /*
>   * Routine: beagle_identify
> - * Description: Detect if we are running on a Beagle revision Ax/Bx or
> - *              Cx. This can be done by GPIO_171. If this is low, we are
> - *              running on a revision C board.
> + * Description: Detect if we are running on a Beagle revision Ax/Bx,

> + *             C1/2, C3, C4 or D. This can be done by reading

> + *             the level of GPIO173, GPIO172 and GPIO171. This should
> + *             result in

> + *             GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx
> + *             GPIO173, GPIO172, GPIO171: 1 1 0 => C1/2
> + *             GPIO173, GPIO172, GPIO171: 1 0 0 => C3
> + *             GPIO173, GPIO172, GPIO171: 1 0 1 => C4
> + *             GPIO173, GPIO172, GPIO171: 0 0 0 => D

> +       switch (beagle_revision) {
> +       case REVISION_AXBX:
>                 printf("Ax/Bx\n");
> +               break;
> +       case REVISION_C1:

> +               printf("C1/2\n");

> +               break;
> +       case REVISION_C3:
> +               printf("C3\n");
> +               break;
> +       case REVISION_C4:

> +               printf("C4\n");
> +               break;
> +       case REVISION_D:
> +               printf("D\n");

> +               break;
> +       default:
> +               printf("unknown 0x%02x\n", beagle_revision);
> +       }
>  }
>
>  /*

> @@ -137,7 +157,7 @@ void set_muxconf_regs(void)

>  {
>         MUX_BEAGLE();
>
> -       if (beagle_revision_c) {
> +       if (beagle_revision != REVISION_AXBX) {
>                 MUX_BEAGLE_C();
>         }
>  }
> Index: u-boot-main/board/ti/beagle/beagle.h
> ===================================================================
> --- u-boot-main.orig/board/ti/beagle/beagle.h
> +++ u-boot-main/board/ti/beagle/beagle.h

> @@ -33,7 +33,12 @@ const omap3_sysinfo sysinfo = {

>  #endif
>  };
>
> -#define BOARD_REVISION_MASK    (0x1 << 11)
> +/* BeagleBoard revisions */
> +#define REVISION_AXBX  0x7
> +#define REVISION_C1    0x6
> +#define REVISION_C3    0x4
> +#define REVISION_C4    0x5

> +#define REVISION_D     0x0

>
>  /*
>   * IEN  - Input Enable

> @@ -264,7 +269,7 @@ const omap3_sysinfo sysinfo = {

[Dirk Behme]

On 15.12.2009 19:03, Steve wrote:
> Never mind, works fine on C4. I had a C4 hardware issue.

Fyi: Now that U-Boot v1 2009.11 is out and merge window is open, I
sent the revision detection patch to U-Boot mailing list:

http://lists.denx.de/pipermail/u-boot/2009-December/065502.html

Just in case anybody is interested, U-Boot v1 2009.11 binary with the
revision detection patch applied in attachment.

Thanks for testing this again,

Dirk

[Jason Kridner]

On Wed, Dec 16, 2009 at 10:57 AM, Dirk Behme <dirk....@googlemail.com> wrote:
> On 15.12.2009 19:03, Steve wrote:
>> Never mind, works fine on C4.  I had a C4 hardware issue.
>
> Fyi: Now that U-Boot v1 2009.11 is out and merge window is open, I
> sent the revision detection patch to U-Boot mailing list:
>
> http://lists.denx.de/pipermail/u-boot/2009-December/065502.html
>
> Just in case anybody is interested, U-Boot v1 2009.11 binary with the
> revision detection patch applied in attachment.
>

What else is expected to be needed to be put in the flash of the Rev C4?
* Gerald requires that the default is that something appears on the
display. Otherwise, people will complain that the display port is
dead. I think doing this with a default environment command should be
fine. I'd prefer a logo, but we may go with a single background
color.
* We likely need similar code for the S-Video port.
* I think we need a couple of diagnostic routines. Possibly something
for audio. The above video tests might be able to be put in as 'diag'
commands as long as they execute by default.
* I'd still like to see the USBTTY patches made suitable and sent
up-stream--and think this is important for the BeagleBoard out-of-box
experience.

Anything else?

[Gerald Coley]

We need to make sure it supports the boot scripts that we currently use as well.

 

Audio has been removed for a while so I am OK either way.

 

Gerald

 

[Seppo Nikkilä]

A word about audio. Based on my calculations today it is possible to
generate +1.258 ppm accurate synchronous audio DAC clocks to the C3
Expansion Connector. The 12.288 MHz on McBSP3_CLKX (pin 8) and the
synchronous 49.152 MHz on McSPI1_CLKX make it possible to interface TI
PCM1792A to Beagleboard in the 192 kS/s 24-bit stereo mode. The clocks
are made by reprogramming DPLL3 and DPLL4. As the result all their
clocks become about 2.4 % faster. I think this should not disturb any
attached modules?