SATA boot on OMAP5

[Dan MacDonald]

Hi TI!

Any idea if we will be able to boot 'directly' off SATA on Panda's successor instead of having to go via SD card?

There'll be a riot if you can't!

:)

[Joshi, Vikas]

Just curious: how many in community want to boot off of SATA?

                          Just trying to gauge size of the rioters!

Also how many prefer to keep booting from SD?

Or boot over USB / Ethernet?

 

Vikas

[Martin Maurer]

Hello Vikas,

 

i think every interface has its pros and cons.

 

I would keep SD card, because in stand-alone mode, SD card is best in size and prize.

USB goes in same direction, but perhaps a bit more difficult.

 

SATA could be great for speed and availablity for big mediums (like SSD and hd).

 

Ethernet could be nice for certain areas, including development: no need to pull-out SD card, e.g. when trying out a new kernel.

 

Perhaps there could be a mixture, even in todays boards / chips: Small booter to load something from SD card (already there),

but then loading powerful booter for USB (and other available interface), which the loads the final OS.

 

Best regards,

 

Martin

[haunma]

For the official count:  I'd like SATA boot--very useful in low-power server applications.  It's the main reason why my do-everything server at home is a Marvell Sheeva instead of a TI OMAP.

As with so many Panda and (let's call it) Panda5 wishes, this really depends on the intended audience.  TI needs to decide whether Panda5 will remain focused on mobile SW development, or appeal to a somewhat broader audience like Beagleboard.  With Panda, TI's attitude toward the hobbyist / maker communities has ranged from indifference to overt discouragement; this is one reason, IMO, why the Panda community remains so small when compared to Beagle.  Not that the project was a failure--it was very successful in what it set out to do.  It just did not set out to do [much of] what the hobbyists wanted.

The nature of Panda5 may depend on whether OMAP5 becomes a catalog part like OMAP3.  Someone speculated that this happens only with odd-numbered OMAPs :)  Also, Beagle is getting long in the tooth and the time may be ripe to siphon off some of those users with an OMAP5 refresh.  The problem for TI is that the costs and benefits of a Beagle-like project are difficult to quantify.  How do the non-SW-contributing users aid TI's bottom line?

[David Anders]

haunma,

now is the time to post you wish list......(and grievances)

Dave

[David Anders]

On Thursday, August 2, 2012 2:00:56 PM UTC-5, (unknown) wrote:

On Thursday, August 2, 2012 1:19:17 PM UTC-5, David Anders wrote:

haunma,

now is the time to post you wish list......(and grievances)

Dave

 

Grievences,

No SPIDEV support out of the box.  Hobbyist's are not going to want to download and reconfigure a kernel to get it to work, especially with the sketchy instructions to be found via Google.

Apparently Bluetooth still not working, even with the latest Aug PPA release ( https://groups.google.com/forum/#!topic/pandaboard/Pha5A2JIS1c ).

both of these items are related to distro support, if you want to complain about ubuntu not have spidev support, you have to complain to them. this has nothing to do with the actual pandaboard.


 

Wish list,

Some instructions on MUX config so spidev1.[1-3] could be made to work.  Currently the pins seem used by UART1 functions even though SPI CS functions are listed as "primary" functions in the Pandaboard PDF file.  The nested macros and #include header spaghetti has made pin MUXing incomprehensible to me.  The fact that the source tree has broken and circular links makes even a brute force grep -R strategy fail.

sounds like your primary issue is documentation, not functionality.....
 

The problem for TI is that the costs and benefits of a Beagle-like project are difficult to quantify.  How do the non-SW-contributing users aid TI's bottom line?

 

Seems obvious to me, we bought the Pandaboard to use a TI A/D chip in an attempt to do a rapid prototype.  The SPIDEV situation made it not so rapid, but it seems to be ending up OK.   Doing native instead of cross development was a major factor in choosing the Pandaboard ES.

 

At the end of the day, a good idea with a minimal development budget is not all that different from a Hobbyist in terms of support,  I mean was not the Apple I  basically a "hobby" project by Woz?

again your lack of ability to use spidev is more of an issue of not understanding the documentation and the choice of using ubuntu.....

Dave
 

[haunma]

On Thursday, August 2, 2012 11:19:17 AM UTC-7, David Anders wrote:

haunma,

now is the time to post you wish list......(and grievances)

Some of these are really difficult or impossible, but hey, why not aim high? :)

0) Complete programming specifications for all on-chip processors and peripherals, including the graphics accelerator(s), codec engines, coprocessors, DSP / DSP-like blocks, etc.  Which would put us on the road toward...
1) No closed-source binary blobs required for fully accelerated graphics and wireless functions.
2) Choose a more bare-bones and less derivative Linux distribution, like Debian, for official support and let the community build the fancy-shmancy distributions.  Just my pet peeve--I really dislike Ubuntu on anything but grandma's desktop.
3) As far as possible, ship with a SW installation that uses mainline components (kernel, bootloader) and does not rely on a special tree for this, a particular fork for that, and a magic repo for a bunch of things needed to make it all run.

Ok, I will try to put some easier wishes in here too:

4) Lose the DB-9 connector to run the terminal over USB to save space.  It's standard enough at this point.
5) This would delay the release, but I think hobbyists would appreciate an extra board spin if needed to ensure that wifi and bluetooth meet some minimum performance standards.  Ditto for any other rough edges in the HW design, like thermal management.
5.5) If the ES silicon has non-trivial performance issues and you want to get the boards out pronto, perhaps make it clear up-front that the board availability will continue through to the release of non-ES parts and beyond.
6) Could be just my personal fetish, but I think low-power systems are cool and would appreciate a PS design that would accommodate battery power with good efficiency.
7) Would be nice to minimize the maximum thickness with separate USB and network connectors, instead of the high-rise USB+network on Panda.
8) Already mentioned boot, but there must be some way to cut down on the amount of newbie flailing (and associated mailing-list traffic) with getting a bootable system.  More boot options, like SATA, might help with that.  (Marvell OpenRD had a laptop SATA connector right on the board.)  See also #3 above--that's a big part of this too.
9) Definitely keep the same sort of expansion connector (especially the GPMC).  I tend to dislike the 0.1" header arrays, but that may be best for two-layer expansion boards.

On the admin side of things, I think it would be swell if you guys could partner with the Beagleboard folks and leverage that "brand" for the OMAP5 dev board.  You know, make it the designated heir for the Beagleboard XM or whatever.  OTOH I know the first parts will be coming out with the uber-dense BGA requiring special PCBs with laser vias and pixie dust, etc. so there may be obstacles.  I think it would be a big win for the community, though, and excellent publicity.

Mark

[David Anders]

haunma,

On Thursday, August 2, 2012 3:59:27 PM UTC-5, haunma wrote:

On Thursday, August 2, 2012 11:19:17 AM UTC-7, David Anders wrote:

haunma,

now is the time to post you wish list......(and grievances)

Some of these are really difficult or impossible, but hey, why not aim high? :)

0) Complete programming specifications for all on-chip processors and peripherals, including the graphics accelerator(s), codec engines, coprocessors, DSP / DSP-like blocks, etc.  Which would put us on the road toward...

there is some progress being made towards this...
 

1) No closed-source binary blobs required for fully accelerated graphics and wireless functions.

of course the PVR does not belong to TI, so there is very little they can do about that....
 

2) Choose a more bare-bones and less derivative Linux distribution, like Debian, for official support and let the community build the fancy-shmancy distributions.  Just my pet peeve--I really dislike Ubuntu on anything but grandma's desktop.
3) As far as possible, ship with a SW installation that uses mainline components (kernel, bootloader) and does not rely on a special tree for this, a particular fork for that, and a magic repo for a bunch of things needed to make it all run.

initial support in the mainline u-boot and kernel is always going to lag significantly behind developmental trees, but as a comparison, TI's support in mainline kernel for OMAP4 has been better/quicker than any other SoC on the market. in addition, product lines such as the OMAP5 series are so "new" the environment that it is not always possible to have single mainline support tree....
 

Ok, I will try to put some easier wishes in here too:

4) Lose the DB-9 connector to run the terminal over USB to save space.  It's standard enough at this point.
5) This would delay the release, but I think hobbyists would appreciate an extra board spin if needed to ensure that wifi and bluetooth meet some minimum performance standards.  Ditto for any other rough edges in the HW design, like thermal management.
5.5) If the ES silicon has non-trivial performance issues and you want to get the boards out pronto, perhaps make it clear up-front that the board availability will continue through to the release of non-ES parts and beyond.

the whole purpose of the Panda project is to provide extremely advanced access to new technology at as low cost as possible. the very nature of the project and project goals means that the boards that are released will have many many unknown issues....
by ES silicon, i assume you mean "Engineering Sample", if that is indeed what you mean, then please note, Panda has never released products based on engineering samples........

6) Could be just my personal fetish, but I think low-power systems are cool and would appreciate a PS design that would accommodate battery power with good efficiency.

again for the specific goals of the Panda project as a desktop based development platform with early access to technology, it is highly unlikely that any type of battery support would be provided....
 

7) Would be nice to minimize the maximum thickness with separate USB and network connectors, instead of the high-rise USB+network on Panda.
8) Already mentioned boot, but there must be some way to cut down on the amount of newbie flailing (and associated mailing-list traffic) with getting a bootable system.  More boot options, like SATA, might help with that.  (Marvell OpenRD had a laptop SATA connector right on the board.)  See also #3 above--that's a big part of this too.

with regards to the "newbie flailing", the Panda has never been targeted at that market, but there are things we can do to assist in making it easier for them to use panda....
 

9) Definitely keep the same sort of expansion connector (especially the GPMC).  I tend to dislike the 0.1" header arrays, but that may be best for two-layer expansion boards.

On the admin side of things, I think it would be swell if you guys could partner with the Beagleboard folks and leverage that "brand" for the OMAP5 dev board.  You know, make it the designated heir for the Beagleboard XM or whatever.  OTOH I know the first parts will be coming out with the uber-dense BGA requiring special PCBs with laser vias and pixie dust, etc. so there may be obstacles.  I think it would be a big win for the community, though, and excellent publicity.

beagle and panda are two completely different projects with two _extremely_ different goals, and although there is some cross-over between functionality, the overall road map for each is very different....



thanks for the feedback!

 

Mark

[David Anders]

On Thursday, August 2, 2012 4:11:14 PM UTC-5, (unknown) wrote:

On Thursday, August 2, 2012 2:29:44 PM UTC-5, David Anders wrote:

On Thursday, August 2, 2012 2:00:56 PM UTC-5, (unknown) wrote:

On Thursday, August 2, 2012 1:19:17 PM UTC-5, David Anders wrote:

haunma,

now is the time to post you wish list......(and grievances)

Dave

 

Grievences,

No SPIDEV support out of the box.  Hobbyist's are not going to want to download and reconfigure a kernel to get it to work, especially with the sketchy instructions to be found via Google.

Apparently Bluetooth still not working, even with the latest Aug PPA release ( https://groups.google.com/forum/#!topic/pandaboard/Pha5A2JIS1c ).

both of these items are related to distro support, if you want to complain about ubuntu not have spidev support, you have to complain to them. this has nothing to do with the actual pandaboard.

I'm not interested in a pissing contest about who's fault it is, but the J3 pin out ( Table 11: Expansion Connector "A" Pin Definitions (J3) in the OMAP4460 Pandaboard ES System Reference Manual, DOC-21054 ) on page 43of82 in the PDF file,  shows pins 4, 10, 12, 14, 16, 18, & 20  "Primary Function" to be MCSPI1.  

primary function after reset. that doesn't mean that bootloaders, kernel, and kernel drivers don't make changes to the configuration. that is the whole purpose of having the mux features......

 

 

[David Anders]

On Thursday, August 2, 2012 4:39:13 PM UTC-5, (unknown) wrote:

Sorry, apparently a slip of the fingers in Google Groups found a keyboard shortcut to immediately send a message :(

On Thursday, August 2, 2012 2:29:44 PM UTC-5, David Anders wrote:

On Thursday, August 2, 2012 2:00:56 PM UTC-5, (unknown) wrote:

On Thursday, August 2, 2012 1:19:17 PM UTC-5, David Anders wrote:

haunma,

now is the time to post you wish list......(and grievances)

Dave

 

Grievences,

No SPIDEV support out of the box.  Hobbyist's are not going to want to download and reconfigure a kernel to get it to work, especially with the sketchy instructions to be found via Google.

Apparently Bluetooth still not working, even with the latest Aug PPA release ( https://groups.google.com/forum/#!topic/pandaboard/Pha5A2JIS1c ).

both of these items are related to distro support, if you want to complain about ubuntu not have spidev support, you have to complain to them. this has nothing to do with the actual pandaboard.

I'm not interested in a pissing contest about who's fault it is, but the J3 pin out ( Table 11: Expansion Connector "A" Pin Definitions (J3) in the OMAP4460 Pandaboard ES System Reference Manual, DOC-21054 ) on page 43of82 in the PDF file,  shows pins 4, 10, 12, 14, 16, 18, & 20  "Primary Function" to be MCSPI1.  

Also the Pandaboard ES Block Diagram at http://pandaboard.org/content/resources/references shows bidirectional arrows for

" SDMMC2, GPMC McSPI1 I2C4 & UART4 " going to the Generic Expansion connectors (J3,J6).

This suggests it would not unreasonable to expect this support in any kernel purported to be for the Pandaboard ES.

Note that the UART1 that appears to be "stealing" the pins is not shown on the block diagram expansion headers.

because the primary functions are the ones listed. again, just because that is the primary function doesn't mean that something hasn't change the configuration. because there are a large number of combinations of these pins that can be used, there is no possible way to have everyone of them configured in the kernel by default....
 

sounds like your primary issue is documentation, not functionality.....

Obviously if there were decent docs to be found via Google I wouldn't need to be here. 

there are plenty of docs, but based on your comments and your issues, having them written from a specific point of view for people are not familiar with general linux development(or microcontroller development for that matter) is probably warranted....

 

again your lack of ability to use spidev is more of an issue of not understanding the documentation and the choice of using ubuntu.....

Its not a matter of understanding, its a matter of lacking.  I got /dev/spidev1.0 to work just fine following the directions such as they are, but while I can make /dev/spidev1.[1-3] appear, I can't get their chip select pins to change state :(

Since activating the SPIDEV is done by editing arch/arm/mach-omap2/board-omap4panda.c does this not suggest it "belongs" to the Pandaboard developers and not Ubuntu or some other distribution?

again, and again, i'll repeat, since there are an astronomical number of combinations of the pins that can be configured, it makes no sense to even try to configure every one of them in the kernel. if the ubuntu developers wish to set the spi as their default that is there decision, it is not the pandaboard developers choice.



 

Which distribution for Pandaboard ES has working /dev/spidev and Bluetooth?  Please do tell, and I'l use it!

i have been building and testing OE with mainline kernel since 2.6.35, every one of them works find with spidev and bluetooth......

 

The Bluetooth problem is most definitely not a Ubuntu problem, since if I plug in a USB Bluetooth dongle, udev auto-magically makes it work. The Pandaboard ES Bluetooth driver in the 3.4.0 TI PPA release is broken.  There is another thread going trying to fix it:  https://groups.google.com/forum/#!topic/pandaboard/On6_tZG79Kk

yes the PPA is broken as that is a specific release of the TI drivers NOT MAINLINE.

if you use mainline it works fine.....


Dave

 

[David Anders]

this isn't the thread to be discussing this, if you want to post as a new thread, i will continue the discussion

On Thursday, August 2, 2012 5:41:14 PM UTC-5, (unknown) wrote:

From:  http://omapedia.org/wiki/PandaBoard_SPI#Configuring_and_patching_the_kernel

 static void __init panda_spi_devices_init(void) {

      /* muxing pins might be only required if

       * you've connecting 

       * device to CS other than CS0 */

      spi_register_board_info(panda_spi, ARRAY_SIZE(panda_spi));

 }

again, and again, i'll repeat, since there are an astronomical number of combinations of the pins that can be configured, it makes no sense to even try to configure every one of them in the kernel. if the ubuntu developers wish to set the spi as their default that is there decision, it is not the pandaboard developers choice.

How about simply explaining how to add the muxing pin code to this function so CS1, CS2, & CS3 will work?

I've not been able to find where the CS0 mux is setup, but it does work.  Expanding the panda_spi array to make spidev1.[1-3] appear was obvious but they don't work because the CS[1-3] pins don't do anything SPIDEV related.

Had the author of this wiki article explained how to do what is mentioned in the comment I wouldn't need to be here!

I did find this in mux44xx.c:

_OMAP4_MUXENTRY(MCSPI1_CS1, 138, "mcspi1_cs1", "uart1_rx", NULL,

"gpio_138", NULL, NULL, NULL, "safe_mode"),

_OMAP4_MUXENTRY(MCSPI1_CS2, 139, "mcspi1_cs2", "uart1_cts",

"slimbus2_clock", "gpio_139", NULL, NULL, NULL,

"safe_mode"),

_OMAP4_MUXENTRY(MCSPI1_CS3, 140, "mcspi1_cs3", "uart1_rts",

"slimbus2_data", "gpio_140", NULL, NULL, NULL,

"safe_mode"),

But changing the "uart1_", "gpio_ ",  and "slimbus2_ " entries to NULL didn't make any difference.

there are plenty of docs

Where so I find some germane to setting up the mux for mcspi1_cs[1-3]?

 

yes the PPA is broken as that is a specific release of the TI drivers NOT MAINLINE. 

if you use mainline it works fine.....

Where do I get 3.4  "mainline"?  Remember git protocol is blocked here so I need a tarball to download.

 

 

http://www.kernel.org is where you can download the lastest kernel as a tarball.....

Dave

 

[LetoThe2nd]

Hi Dave,

as promised some thoughts from me.

Wishlist to be included: (In rough order of felt importance)

- SATA port, preferable to boot off. Big wish.

- RTC and eventually E2PROM on the board, and an easy way to power them (e.g. battery holder, or the power connector for the battery on a simple two-pin header)

- I2S channels on the expansion headers.

- Some, however small, ROM where at least u-boot could be placed on the board itself instead of needing external storage.

- Mounting holes or something for a cpu/ram heatsink.

Wishlist to be excluded: (also in rough order of felt importance)

- Means of powering the board over usb otg. It just gives us headaches every time because nobody of the first timers understands it or reads the manual. Exchanging the serial DB9 for an usb jack like on the bone is ok, but pleasepleaseplease make sure that the board does _not_ get powered over it so that you can powercycle it _without_ having to break the serial link!

- FM Audio.

- Camera connectors. They're of little use community-wise, because nobody has access to fitting hardware.

- Same holds true for the MIPI display connector.

Some general thoughts:

- If there is an easy way of integrating GPS (like it is already in the chipset or something), then do it.

- Keep the dual dvi/hdmi outputs.

- If the audio I/Os are kept, please make them stereo. And specify them line level only.

I think thats it :)

Greetz Leto

[Dan MacDonald]

On Thu, Aug 2, 2012 at 5:35 AM, Martin Maurer <meinemai...@online.de> wrote:

Hello Vikas,

 

i think every interface has its pros and cons.

 

I would keep SD card, because in stand-alone mode, SD card is best in size and prize.

USB goes in same direction, but perhaps a bit more difficult.

 

SATA could be great for speed and availablity for big mediums (like SSD and hd).

 

Ethernet could be nice for certain areas, including development: no need to pull-out SD card, e.g. when trying out a new kernel.

+1

Forgot to ask about that as I can definitely see me making extensive use of PXE or similar if the OMAP5 boards support it. Please offer ethernet boot too TI!

As others have mentioned already, my only other real big gripe with Panda (and pretty much all other OMAP devices) is the closed source nature of the PVR GPUs they use. Intel GPUs are getting pretty good these days, their drivers are fully open and hardware are usually supported under Linux before or at release so its a shame they don't do us all a favor by licensing their GPU cores to ARM SOC vendors like TI but then again maybe their power requirements aren't cut out for embedded use?

There was some talk on Phoronix a year or two ago about IMGTec/PVR releasing open source PVR drivers but I'm sure the approx release date has been and gone and the site hasn't run any stories making such claims in the last 6 months or so. Have any of the TI team got any juicy nuggets they can share on this matter?

[Olivier Deprez]

omap5 rom code supports booting straight from SATA device like it does for SD

hence a supposedly "panda5" would support booting from SATA if ever it physically implements the SATA interface ....

[Rob Clark]

On Fri, Aug 3, 2012 at 3:56 AM, Dan MacDonald <all...@gmail.com> wrote:
>
>
> On Thu, Aug 2, 2012 at 5:35 AM, Martin Maurer <meinemai...@online.de>
> wrote:
>>
>> Hello Vikas,
>>
>> i think every interface has its pros and cons.
>>
>> I would keep SD card, because in stand-alone mode, SD card is best in size
>> and prize.
>> USB goes in same direction, but perhaps a bit more difficult.
>>
>> SATA could be great for speed and availablity for big mediums (like SSD
>> and hd).
>>
>> Ethernet could be nice for certain areas, including development: no need
>> to pull-out SD card, e.g. when trying out a new kernel.
>
>
> +1
>
> Forgot to ask about that as I can definitely see me making extensive use of
> PXE or similar if the OMAP5 boards support it. Please offer ethernet boot
> too TI!

IIRC, pxe (or at least some form of net boot) works on omap4..
although you probably still need an sd-card w/ u-boot.

> As others have mentioned already, my only other real big gripe with Panda
> (and pretty much all other OMAP devices) is the closed source nature of the
> PVR GPUs they use.

you are preaching to the choir. IMGtec already hears this from us.

btw, http://www.imgtec.com/corporate/contactus.asp

> Intel GPUs are getting pretty good these days, their
> drivers are fully open and hardware are usually supported under Linux before
> or at release so its a shame they don't do us all a favor by licensing their
> GPU cores to ARM SOC vendors like TI but then again maybe their power
> requirements aren't cut out for embedded use?

intel licensing to ARM vendors.. that would be the day that pigs fly :-P

BR,
-R

[Dan MacDonald]

Hi Rob!

On Fri, Aug 3, 2012 at 2:43 PM, Rob Clark <robd...@gmail.com> wrote:

On Fri, Aug 3, 2012 at 3:56 AM, Dan MacDonald <all...@gmail.com> wrote:
>
>
> On Thu, Aug 2, 2012 at 5:35 AM, Martin Maurer <meinemai...@online.de>
> wrote:
>>
>> Hello Vikas,
>>
>> i think every interface has its pros and cons.
>>
>> I would keep SD card, because in stand-alone mode, SD card is best in size
>> and prize.
>> USB goes in same direction, but perhaps a bit more difficult.
>>
>> SATA could be great for speed and availablity for big mediums (like SSD
>> and hd).
>>
>> Ethernet could be nice for certain areas, including development: no need
>> to pull-out SD card, e.g. when trying out a new kernel.
>
>
> +1
>
> Forgot to ask about that as I can definitely see me making extensive use of
> PXE or similar if the OMAP5 boards support it. Please offer ethernet boot
> too TI!

IIRC, pxe (or at least some form of net boot) works on omap4..
although you probably still need an sd-card w/ u-boot.

Thats good to hear
 

> As others have mentioned already, my only other real big gripe with Panda
> (and pretty much all other OMAP devices) is the closed source nature of the
> PVR GPUs they use.

you are preaching to the choir.  IMGtec already hears this from us.

btw, http://www.imgtec.com/corporate/contactus.asp

Yep - I can see that being hit with a danboid power request any time soon!
 

> Intel GPUs are getting pretty good these days, their
> drivers are fully open and hardware are usually supported under Linux before
> or at release so its a shame they don't do us all a favor by licensing their
> GPU cores to ARM SOC vendors like TI but then again maybe their power
> requirements aren't cut out for embedded use?

intel licensing to ARM vendors.. that would be the day that pigs fly :-P

Its really not that far out a suggestion Robert:

http://en.wikipedia.org/wiki/XScale

If you got to choose a GPU for the Panda5, which one would you go for Rob?

[Nicolas Dechesne]

On Fri, Aug 3, 2012 at 3:49 PM, Dan MacDonald <all...@gmail.com> wrote:
>> IIRC, pxe (or at least some form of net boot) works on omap4..
>> although you probably still need an sd-card w/ u-boot.
>
>
> Thats good to hear
>

fwiw http://rsalveti.wordpress.com/2011/07/11/net-booting-with-tftp-and-pxe-with-pandaboard/

[Rob Clark]

you might have noticed that intel sold xscale a long time ago and has
never looked back. Their agenda is clearly x86-everywhere. So yes,
it will be the day that pigs fly :-P

> If you got to choose a GPU for the Panda5, which one would you go for Rob?

Well, since there aren't yet open src drivers for any of them, it is
sort of a moot point. And keep in mind, an SoC is not like a PC.. you
don't just unplug one card from a pci/agp bus and plug in a different
one. Yes there are efforts underway from the open src community on a
few of them, and I expect more to come, but I expect it will be at
least a year or two before any of them are really complete enough to
be providing a somewhat functional gl/gles interface, let alone good
performance. The graphics driver is by far the most complex driver in
a modern SoC (or desktop) today. It is driving the most complex piece
of hw, includes it's own compiler for shader cores (which I think are
the most.. well, bizarre, sort of "cpu" architecture that you have
ever seen).

btw, even intel is using sgx on their current SoC's

BR,
-R

[haunma]

On Thursday, August 2, 2012 2:25:07 PM UTC-7, David Anders wrote:

On Thursday, August 2, 2012 3:59:27 PM UTC-5, haunma wrote:

0) Complete programming specifications for all on-chip processors and peripherals, including the graphics accelerator(s), codec engines, coprocessors, DSP / DSP-like blocks, etc.  Which would put us on the road toward...

there is some progress being made towards this...

That's good to hear.  I've always thought it would be in ImgTec's best interest to open up whatever they need to permit community-developed drivers, or heck, even closed-source-but-not-ImgTec drivers.  Open-source angst aside, it seems like a number of commercial projects have been harmed due to inadequate driver support, GMA500 netbooks being perhaps the highest-profile example--never worked to potential, even in Windows!
 

2) Choose a more bare-bones and less derivative Linux distribution, like Debian, for official support and let the community build the fancy-shmancy distributions.  Just my pet peeve--I really dislike Ubuntu on anything but grandma's desktop.
3) As far as possible, ship with a SW installation that uses mainline components (kernel, bootloader) and does not rely on a special tree for this, a particular fork for that, and a magic repo for a bunch of things needed to make it all run.

initial support in the mainline u-boot and kernel is always going to lag significantly behind developmental trees, but as a comparison, TI's support in mainline kernel for OMAP4 has been better/quicker than any other SoC on the market. in addition, product lines such as the OMAP5 series are so "new" the environment that it is not always possible to have single mainline support tree....

As long as we're stuck with this reality, another suggestion would be to ruthlessly consolidate all online repositories, wikis, and documentation in one place (omappedia?).  Seems like there was quite a bit of user confusion about where to go for the right bits with Pandaboard (perhaps it's better now than in the beginning).

5) This would delay the release, but I think hobbyists would appreciate an extra board spin if needed to ensure that wifi and bluetooth meet some minimum performance standards.  Ditto for any other rough edges in the HW design, like thermal management.
5.5) If the ES silicon has non-trivial performance issues and you want to get the boards out pronto, perhaps make it clear up-front that the board availability will continue through to the release of non-ES parts and beyond.

the whole purpose of the Panda project is to provide extremely advanced access to new technology at as low cost as possible. the very nature of the project and project goals means that the boards that are released will have many many unknown issues....

Well, you did ask for suggestions and grievances, so there they are :)
 

by ES silicon, i assume you mean "Engineering Sample", if that is indeed what you mean, then please note, Panda has never released products based on engineering samples........

(ref. http://www.omappedia.com/wiki/PandaBoard_Revisions)
I forgot exactly what ES stands for--I thought it was Engineering Silicon?  But anyway, many revs of the Pandaboard were using early "ES" versions of the OMAP4 with errata that, e.g., penalized memory performance.  While this is perfectly normal and expected, my point was that it would be good to telegraph to users that the dev board will continue to be updated and supported, that it is not *only* a vehicle for earliest access to the technology.

6) Could be just my personal fetish, but I think low-power systems are cool and would appreciate a PS design that would accommodate battery power with good efficiency.

again for the specific goals of the Panda project as a desktop based development platform with early access to technology, it is highly unlikely that any type of battery support would be provided....

Not thinking of explicit support as such.  But things like the ability to sleep/wake the board from software go a long way toward this.

 

On the admin side of things, I think it would be swell if you guys could partner with the Beagleboard folks and leverage that "brand" for the OMAP5 dev board.  You know, make it the designated heir for the Beagleboard XM or whatever.  OTOH I know the first parts will be coming out with the uber-dense BGA requiring special PCBs with laser vias and pixie dust, etc. so there may be obstacles.  I think it would be a big win for the community, though, and excellent publicity.

beagle and panda are two completely different projects with two _extremely_ different goals, and although there is some cross-over between functionality, the overall road map for each is very different....

Well, yeah.  That kind of gets back to the thrust of my first comment in this thread, doesn't it?

I'm not convinced that Panda5 (or whatever it's called) couldn't serve both sets of goals, but we've argued this to death in a previous thread already.  Given the current state of affairs, it would be super nice if TI could support the BB folks by making a [catalog] OMAP5 available to them on an accelerated schedule, if not *quite* as accelerated as what you're aiming for with Panda5.

thanks for the feedback!

Anytime :)

[David Anders]

On Friday, August 3, 2012 12:57:24 PM UTC-5, haunma wrote:

On Thursday, August 2, 2012 2:25:07 PM UTC-7, David Anders wrote:

On Thursday, August 2, 2012 3:59:27 PM UTC-5, haunma wrote:

0) Complete programming specifications for all on-chip processors and peripherals, including the graphics accelerator(s), codec engines, coprocessors, DSP / DSP-like blocks, etc.  Which would put us on the road toward...

there is some progress being made towards this...

That's good to hear.  I've always thought it would be in ImgTec's best interest to open up whatever they need to permit community-developed drivers, or heck, even closed-source-but-not-ImgTec drivers.  Open-source angst aside, it seems like a number of commercial projects have been harmed due to inadequate driver support, GMA500 netbooks being perhaps the highest-profile example--never worked to potential, even in Windows!

sorry i should have been more clear in my statement. there are plans to slowly start providing more documentation on all of the TI owned IP, the graphics accelerator is not owned by TI.....

 

 

2) Choose a more bare-bones and less derivative Linux distribution, like Debian, for official support and let the community build the fancy-shmancy distributions.  Just my pet peeve--I really dislike Ubuntu on anything but grandma's desktop.
3) As far as possible, ship with a SW installation that uses mainline components (kernel, bootloader) and does not rely on a special tree for this, a particular fork for that, and a magic repo for a bunch of things needed to make it all run.

initial support in the mainline u-boot and kernel is always going to lag significantly behind developmental trees, but as a comparison, TI's support in mainline kernel for OMAP4 has been better/quicker than any other SoC on the market. in addition, product lines such as the OMAP5 series are so "new" the environment that it is not always possible to have single mainline support tree....

As long as we're stuck with this reality, another suggestion would be to ruthlessly consolidate all online repositories, wikis, and documentation in one place (omappedia?).  Seems like there was quite a bit of user confusion about where to go for the right bits with Pandaboard (perhaps it's better now than in the beginning).

this is a valid point which i have presented to TI management on multiple occasions....

 

5) This would delay the release, but I think hobbyists would appreciate an extra board spin if needed to ensure that wifi and bluetooth meet some minimum performance standards.  Ditto for any other rough edges in the HW design, like thermal management.
5.5) If the ES silicon has non-trivial performance issues and you want to get the boards out pronto, perhaps make it clear up-front that the board availability will continue through to the release of non-ES parts and beyond.

the whole purpose of the Panda project is to provide extremely advanced access to new technology at as low cost as possible. the very nature of the project and project goals means that the boards that are released will have many many unknown issues....

Well, you did ask for suggestions and grievances, so there they are :)

indeed i did, but since this is the primary goal of Panda, it would defeat the purpose of the project if we held back the release of the product.....

 

 

by ES silicon, i assume you mean "Engineering Sample", if that is indeed what you mean, then please note, Panda has never released products based on engineering samples........

(ref. http://www.omappedia.com/wiki/PandaBoard_Revisions)
I forgot exactly what ES stands for--I thought it was Engineering Silicon?  But anyway, many revs of the Pandaboard were using early "ES" versions of the OMAP4 with errata that, e.g., penalized memory performance.  While this is perfectly normal and expected, my point was that it would be good to telegraph to users that the dev board will continue to be updated and supported, that it is not *only* a vehicle for earliest access to the technology.

ES is just one of the numbering schemes TI uses for their silicon, it has nothing to do with "Engineering Silicon"....

again since PandaBoard project's primary goal is to get advance access to technology, we can not commit to long term updates and support. PandaBoard is first and foremost a vehicle for earliest access to technology. 

 

6) Could be just my personal fetish, but I think low-power systems are cool and would appreciate a PS design that would accommodate battery power with good efficiency.

again for the specific goals of the Panda project as a desktop based development platform with early access to technology, it is highly unlikely that any type of battery support would be provided....

Not thinking of explicit support as such.  But things like the ability to sleep/wake the board from software go a long way toward this.

that is fully supported on the PandaBoard already.... in fact a large number of companies who do commercial products based on OMAP4 use PandaBoard specifically to test those features.....

 

 

On the admin side of things, I think it would be swell if you guys could partner with the Beagleboard folks and leverage that "brand" for the OMAP5 dev board.  You know, make it the designated heir for the Beagleboard XM or whatever.  OTOH I know the first parts will be coming out with the uber-dense BGA requiring special PCBs with laser vias and pixie dust, etc. so there may be obstacles.  I think it would be a big win for the community, though, and excellent publicity.

beagle and panda are two completely different projects with two _extremely_ different goals, and although there is some cross-over between functionality, the overall road map for each is very different....

Well, yeah.  That kind of gets back to the thrust of my first comment in this thread, doesn't it?

I'm not convinced that Panda5 (or whatever it's called) couldn't serve both sets of goals, but we've argued this to death in a previous thread already.  Given the current state of affairs, it would be super nice if TI could support the BB folks by making a [catalog] OMAP5 available to them on an accelerated schedule, if not *quite* as accelerated as what you're aiming for with Panda5.

hehe, TI hasn't always made the relationship between the different divisions clear to the general public. BeagleBoard - (aka ASP or catalog division) group makes their own decisions. they are the ones who choose to release product variations, whether it is OMAP3, OMAP4, or OMAP5. if you want an OMAP5 BeagleBoard you have to get ASP to do that.....

basically this whole issue revolves around the fact that TI hasn't made a good explanation as to how the BeagleBoard group and the PandaBoard group are related, as well the primary goals of each group.....

[David Anders]

i have responded to your thread....

there are literally hundreds of example pages for beagleboard beagleboard-xm, beaglebone, pandaboard, and other dev boards that discuss how to change pin mux configurations. this isn't something that is specific to pandaboard....

Dave

On Friday, August 3, 2012 8:04:19 AM UTC-5, (unknown) wrote:

I started a thread on this about two weeks ago and got absolutely zero response:

https://groups.google.com/forum/#!topic/pandaboard/WgaBRcO9Znk

Someone else also asked about the same problem in another new thread a few days later and

also got no response, other than me confirming the problem:

https://groups.google.com/forum/#!topic/pandaboard/j_6LMmGC3U8

Your solution would be welcome in either!