• State Accepted Answer
  • Locked Locked
  • Replies 12 replies
  • Subscribers 348 subscribers
  • Views 17547 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to jumpstart an ARM9 board from its SD slot?

Bill Van Horne

I have found a low priced ($47 qty. 1) ARM-A9 Dual Core 1GHz Thin Client board that currently has an Embedded Linux OS along with an RDP 7.1 client.  There is an SD slot used to upgrade this board with different firmware.  Is the process for jumpstarting this type of board generic based upon ARM chip?  The manufacturer says that they are ok with my installing a different Thin Client program than RDP, but due to the small nature of the quantity I would be buying, they aren't particularly interested in helping with the project.

First, does anyone know a different, commercial ARM product in this price range with 3 USB, audio/mike, HDMI, VGA, Ethernet, 512M RAM, 512M Flash, SD slot etc.?  If so, is it programmable to allow new programs to be written to its flash memory?

If a different board is not comparable by price and features, is it possible to experiment with different ways to boot the device using uboot or some other tool?  I'm a complete beginner with ARM, so if the questions have inconsistencies or exhibit a lack of knowledge, please forgive...  The basic goal is to add a different Thin Client (Cendio's ThinLinc) instead of RDP.  I'm comfortable as a programmer, but I've never before tackled anything embedded like this.  The company that makes these boards is Chinese, and there is a huge communication barrier in speaking with their technicians, so I'm hoping that the ARM development community can shed light on this as to whether I need to give up, or whether jumpstarting these boards and reprogramming them is a reasonable proposition

Thanks,

Bill_VH

Parents
  • 0 in reply to Bill Van Horne

    Hi, sorry for following up this late, thanks for the ping jensbauer!

    I read through the notes so far, here are some thoughts:

    • If your board is an Cortex-A9 (ARMv7), then the RaspberryPi image will not work with it (as far as I know) since the RPi is ARMv6
    • Instead, if you are using Arch Linux ARM, I'd try the ARMv7 Multi-Platform image from Downloads | Arch Linux ARM
    • The SD card preparation is important, different boards require different things. If you have so little internal storage (flash), then it is likely that the system can be run from the SD card. In that case usually two partitions are used on the card: one small FAT partition for the boot (uboot needs that, I think), and a large partition for the file system. "dd" is used, because then inside the image the software's distributor can prepare these partitions, and writing it with dd it will create the right partitions for you.
    • Usually looking at the original software image from the manufacturer can give you hints how to modify it to load a different system instead. It's really difficult to do it blindly like now.
    • Another reason why starting from the existing image can be helpful: all ARM boards need their specific kernel support implemented, every board is different. That means that the kernel your manufacturer gives you will work, but the kernel in the community images will probably not! Especially if it's a not-for-sale developer board. Thus you might have better luck keeping the manufacturer's kernel, and switching out the system around it. An example of using the manufacturer's Board Support Package (BSP) and modifying it to run ArchLinux is written up in this blogpost: Enabling Arch Linux ARM on Springboard | VIA Springboard Blog Your experience will definitely be different, but this might give hints!
    • You should check out whether you can just take the original system image by the manufacturer, install it, and modify it to run the thin client that you prefer. This might be the simplest way to set things up.

    Let me know if you need more explanation for any of the points. I'm still just learning this myself by doing it. The more specific you can be about the board the more help you are likely to get.

    Software support for ARM boards is an interesting topic, and that is one area where vendors can distinguish themselves! Personally I would also recommend looking at this aspect when buying a board, not just the price. A board you choose might be $10 cheaper than another one, but in the end could cost much more because of the developer time you have to spend on it.

Reply
  • 0 in reply to Bill Van Horne

    Hi, sorry for following up this late, thanks for the ping jensbauer!

    I read through the notes so far, here are some thoughts:

    • If your board is an Cortex-A9 (ARMv7), then the RaspberryPi image will not work with it (as far as I know) since the RPi is ARMv6
    • Instead, if you are using Arch Linux ARM, I'd try the ARMv7 Multi-Platform image from Downloads | Arch Linux ARM
    • The SD card preparation is important, different boards require different things. If you have so little internal storage (flash), then it is likely that the system can be run from the SD card. In that case usually two partitions are used on the card: one small FAT partition for the boot (uboot needs that, I think), and a large partition for the file system. "dd" is used, because then inside the image the software's distributor can prepare these partitions, and writing it with dd it will create the right partitions for you.
    • Usually looking at the original software image from the manufacturer can give you hints how to modify it to load a different system instead. It's really difficult to do it blindly like now.
    • Another reason why starting from the existing image can be helpful: all ARM boards need their specific kernel support implemented, every board is different. That means that the kernel your manufacturer gives you will work, but the kernel in the community images will probably not! Especially if it's a not-for-sale developer board. Thus you might have better luck keeping the manufacturer's kernel, and switching out the system around it. An example of using the manufacturer's Board Support Package (BSP) and modifying it to run ArchLinux is written up in this blogpost: Enabling Arch Linux ARM on Springboard | VIA Springboard Blog Your experience will definitely be different, but this might give hints!
    • You should check out whether you can just take the original system image by the manufacturer, install it, and modify it to run the thin client that you prefer. This might be the simplest way to set things up.

    Let me know if you need more explanation for any of the points. I'm still just learning this myself by doing it. The more specific you can be about the board the more help you are likely to get.

    Software support for ARM boards is an interesting topic, and that is one area where vendors can distinguish themselves! Personally I would also recommend looking at this aspect when buying a board, not just the price. A board you choose might be $10 cheaper than another one, but in the end could cost much more because of the developer time you have to spend on it.

Children
No data