Announcement

Collapse
No announcement yet.

Om + pandaboard + ubuntu

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Om + pandaboard + ubuntu

    I'm planning to make my new carpc embedded linux with OM. I have a few things i haven't work out yet, ie. power, startup/shutdown,..etc. However, one of my biggest concern is the frontend and OM being the only linux compatible FE that i'm interested in running. My question for OM developer is: will OM be able to take advantage of hardware acceleration that is available on the panda board? So that the frontend runs smoothly with good graphic transition...etc.
    Any other possible trouble i may run into running an embedded board?

  • #2
    Originally posted by Punky View Post
    I'm planning to make my new carpc embedded linux with OM. I have a few things i haven't work out yet, ie. power, startup/shutdown,..etc. However, one of my biggest concern is the frontend and OM being the only linux compatible FE that i'm interested in running. My question for OM developer is: will OM be able to take advantage of hardware acceleration that is available on the panda board? So that the frontend runs smoothly with good graphic transition...etc.
    Any other possible trouble i may run into running an embedded board?
    I can't speak for OM of course, but opengl es support may not be complete. We need to get the OM devs one of these development boards so they can work that out.

    for some of the other things (power, etc), check out my worklog for both the all in one (labeled '[insert name of project] worklog' and my own connected car setup. I've got solutions for a lot of the stuff carpc's need and you may find some of that useful.

    Are you going for the always-on concept or just want something smaller?
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

    Comment


    • #3
      It should work with the latest trunk version but I haven't received the hardware yet to test and tweak it. Heather has said they will be sending it to me so support will be there I just can't give an exact date.
      openMobile - An open source C# Front End (why choose openMobile?)
      - Always Recruiting Developers -
      Like what you see? Donations are always welcome

      Comment


      • #4
        Originally posted by tripzero View Post
        I can't speak for OM of course, but opengl es support may not be complete. We need to get the OM devs one of these development boards so they can work that out.

        for some of the other things (power, etc), check out my worklog for both the all in one (labeled '[insert name of project] worklog' and my own connected car setup. I've got solutions for a lot of the stuff carpc's need and you may find some of that useful.

        Are you going for the always-on concept or just want something smaller?
        I've been following your thread since the beginning, and i love the concept. I was also thinking about using the USB-DC psu as well for power supply. How did you connect the board on/off button to the psu? I'm not a fan of soldering a parallel switch onto the existing one, it seems like such a hack job, but looking at it there isn't much of a choice for me at the moment.

        To be honest, my only reason for going this route is because i have a fascination for these tiny boards. For me, they really have no big advantage over the mini itx, except for the small size. I've been researching whether these board has any sort of power data and available sleep state, and so far i've found non for the pandaboard. I'm guessing it'll have at least S1 sleep in ubuntu and power consumption of <5W. I think i'll probably go with S1 sleep instead of always on given my power estimate.


        Originally posted by justchat_1 View Post
        It should work with the latest trunk version but I haven't received the hardware yet to test and tweak it. Heather has said they will be sending it to me so support will be there I just can't give an exact date.
        Maybe, i should hold off on ordering the board, until you guys have a crack at it. Are you going to make a new thread for your pandaboard justchat?

        Comment


        • #5
          Originally posted by Punky View Post
          To be honest, my only reason for going this route is because i have a fascination for these tiny boards. For me, they really have no big advantage over the mini itx, except for the small size. I've been researching whether these board has any sort of power data and available sleep state, and so far i've found non for the pandaboard. I'm guessing it'll have at least S1 sleep in ubuntu and power consumption of <5W. I think i'll probably go with S1 sleep instead of always on given my power estimate.
          CPU sleep states and motherboard sleep states are two different things. S1, S2, S3 are motherboard sleep states. CPU sleep states are manufacturer specific but include Sleep, Deep Sleep, Deeper Sleep, Deeper C4 Sleep (very creative right?). ARM has its equivalents but exactly how much power each use really depends on the hardware, the power supply and the peripherals.

          More info for ARM:
          http://focus.ti.com/docs/training/ca...?sku=OLT109065

          Originally posted by Punky View Post
          Maybe, i should hold off on ordering the board, until you guys have a crack at it. Are you going to make a new thread for your pandaboard justchat?
          I'm not positive what their sending but I had asked for an IGEPv2. Either one is fine with me... its all ARMv7 so if I get everything working with one it should work for anything. Pretty sure I just need to compile the audio backend for ARM and everything should be good to go.

          Either way...I probably won't need to do a thread for it.. just push OM 0.9 (w/embedded support) and let everyone enjoy
          openMobile - An open source C# Front End (why choose openMobile?)
          - Always Recruiting Developers -
          Like what you see? Donations are always welcome

          Comment


          • #6
            Originally posted by Punky View Post
            How did you connect the board on/off button to the psu?
            I didn't worry about the on/off button. I plan on running 24/7 and letting software power down the device if I drop below 11.3V on my battery. Also doing software CPU scaling will help. I should be able to turn off accessories and scale the cpu to ~150MHz when the car is off. If you don't care about always on, just have software power down the device when it sees the ignition go off. The cool thing about the dcdcusb is that it has a usb connection so you can read stuff like that in software.
            Former author of LinuxICE, nghost, nobdy.
            Current author of Automotive Message Broker (AMB).
            Works on Tizen IVI. Does not represent anyone or anything but himself.

            Comment


            • #7
              Originally posted by tripzero View Post
              I plan on running 24/7 and letting software power down the device if I drop below 11.3V on my battery. Also doing software CPU scaling will help. I should be able to turn off accessories and scale the cpu to ~150MHz when the car is off. If you don't care about always on, just have software power down the device when it sees the ignition go off. The cool thing about the dcdcusb is that it has a usb connection so you can read stuff like that in software.
              +1 this is the same concept as setcpu and similar on android phones to improve battery life. You can underclock the CPU when the car is off (running on battery) and overclock it when the internal temps are cool enough and your running off the alternator. OMAP 3+ chipsets can do mp3 decoding at 12Mhz so the possibilities for low power long term standby are pretty big (especially without the drain of GSM or CDMA hardware).
              openMobile - An open source C# Front End (why choose openMobile?)
              - Always Recruiting Developers -
              Like what you see? Donations are always welcome

              Comment


              • #8
                Originally posted by justchat_1 View Post
                +1 this is the same concept as setcpu and similar on android phones to improve battery life. You can underclock the CPU when the car is off (running on battery) and overclock it when the internal temps are cool enough and your running off the alternator. OMAP 3+ chipsets can do mp3 decoding at 12Mhz so the possibilities for low power long term standby are pretty big (especially without the drain of GSM or CDMA hardware).
                I plan on having nobdy be the source for vehicle events such as ignition and power level (as well as a bunch of other needed events: http://pastie.org/1278517). This is something OM on Linux may want to take advantage of.
                Former author of LinuxICE, nghost, nobdy.
                Current author of Automotive Message Broker (AMB).
                Works on Tizen IVI. Does not represent anyone or anything but himself.

                Comment


                • #9
                  Originally posted by justchat_1 View Post
                  CPU sleep states and motherboard sleep states are two different things. S1, S2, S3 are motherboard sleep states. CPU sleep states are manufacturer specific but include Sleep, Deep Sleep, Deeper Sleep, Deeper C4 Sleep (very creative right?). ARM has its equivalents but exactly how much power each use really depends on the hardware, the power supply and the peripherals.

                  More info for ARM:
                  http://focus.ti.com/docs/training/ca...?sku=OLT109065

                  I'm not positive what their sending but I had asked for an IGEPv2. Either one is fine with me... its all ARMv7 so if I get everything working with one it should work for anything. Pretty sure I just need to compile the audio backend for ARM and everything should be good to go.

                  Either way...I probably won't need to do a thread for it.. just push OM 0.9 (w/embedded support) and let everyone enjoy
                  excused me for my lack of embedded processor knowledge because some of these question may be very dumb.

                  1) How do we control these CPU sleep states (everyday average joe)? From the video you've posted, you've got to send some sort of signal to the board which does not sound like something average person would do. Does ubuntu have some sort of built-in power management for embedded board?

                  2) Will any motherboard sleep states be available for these boards?

                  I'm going to order my pandaboard pretty soon here so i can play around with it as much as i can before i'm ready to put it into my car.

                  Originally posted by tripzero View Post
                  I didn't worry about the on/off button. I plan on running 24/7 and letting software power down the device if I drop below 11.3V on my battery. Also doing software CPU scaling will help. I should be able to turn off accessories and scale the cpu to ~150MHz when the car is off. If you don't care about always on, just have software power down the device when it sees the ignition go off. The cool thing about the dcdcusb is that it has a usb connection so you can read stuff like that in software.
                  Originally posted by tripzero View Post
                  I plan on having nobdy be the source for vehicle events such as ignition and power level (as well as a bunch of other needed events: http://pastie.org/1278517). This is something OM on Linux may want to take advantage of.
                  It really depends on how much power the cpu would take if it was to sit around 150mhz during ignition off state. How difficult is software CPU scaling and all the good stuff you're talking about? Keep in mind i program PLC for a living, so i rarely step outside of my IDE when it comes to software programming. I'm also relatively new to linux as well.

                  Comment


                  • #10
                    I went to order one of these board today, but it's on back order until December!! Well that just sucks!

                    Comment


                    • #11
                      Looks like the WL1271 supports WLAN, BT and FM radio...

                      Wonder if FM radio is connected via the Headphone socket as usual, or if like the Motorola Droid, it is missing hardware.

                      Comment


                      • #12
                        Originally posted by Punky View Post
                        It really depends on how much power the cpu would take if it was to sit around 150mhz during ignition off state. How difficult is software CPU scaling and all the good stuff you're talking about? Keep in mind i program PLC for a living, so i rarely step outside of my IDE when it comes to software programming. I'm also relatively new to linux as well.
                        there is a program called CPUFreq that you can use to set the cpu scaling policy. If you put it on "on demand" then it'll clock as low as it can until some application wakes it up. Since very few applications will be doing anything when the car if off, then nothing should wake it up (which is why it's really important that apps be aware of the ignition states).
                        Former author of LinuxICE, nghost, nobdy.
                        Current author of Automotive Message Broker (AMB).
                        Works on Tizen IVI. Does not represent anyone or anything but himself.

                        Comment


                        • #13
                          Originally posted by futaris View Post
                          Looks like the WL1271 supports WLAN, BT and FM radio...

                          Wonder if FM radio is connected via the Headphone socket as usual, or if like the Motorola Droid, it is missing hardware.
                          I never knew this thing is even FM capable. That'll be pretty cool if it did, would be some nice addition for sure.

                          Originally posted by tripzero View Post
                          there is a program called CPUFreq that you can use to set the cpu scaling policy. If you put it on "on demand" then it'll clock as low as it can until some application wakes it up. Since very few applications will be doing anything when the car if off, then nothing should wake it up (which is why it's really important that apps be aware of the ignition states).
                          Thanks for the info! i will definitely try this program once i get the board in December.

                          Comment


                          • #14
                            Originally posted by tripzero View Post
                            there is a program called CPUFreq that you can use to set the cpu scaling policy. If you put it on "on demand" then it'll clock as low as it can until some application wakes it up. Since very few applications will be doing anything when the car if off, then nothing should wake it up (which is why it's really important that apps be aware of the ignition states).
                            This is an area where we really should use android phones for reference. You have two things here, cpu frequency and the cpu governor which can be set to "on demand" but there are quite a few different governors available. Android phone roms have been doing alot of research in this area for what uses the least power when running and on standby to try to maximize battery life.
                            openMobile - An open source C# Front End (why choose openMobile?)
                            - Always Recruiting Developers -
                            Like what you see? Donations are always welcome

                            Comment


                            • #15
                              Originally posted by justchat_1 View Post
                              This is an area where we really should use android phones for reference. You have two things here, cpu frequency and the cpu governor which can be set to "on demand" but there are quite a few different governors available. Android phone roms have been doing alot of research in this area for what uses the least power when running and on standby to try to maximize battery life.
                              A rooted android phone (or in my case n900), is a good option. I had to roll my own kernel for the igep but these phones usually have hacked kernels where people have already done that dirty work.

                              There are several policies that you can make default or change on the fly as needed: Conservative, PowerSave, Performance and Ondemand.

                              Punky, do note that you are likely going to be doing your own custom kernels. It's not hard, but it will take some learning. Also note that reducing the cpu freq doesn't solve all power concerns. If an app is going crazy while the car is off and you clock down to 150MHz, it just means that it's going to take longer for that app to do its crazy things thereby saving little power.
                              Former author of LinuxICE, nghost, nobdy.
                              Current author of Automotive Message Broker (AMB).
                              Works on Tizen IVI. Does not represent anyone or anything but himself.

                              Comment

                              Working...
                              X