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
I downloaded ArchLinuxARM-2014.01-rpi.img and burned it to a MicroSD with dd. When I look at the MicroSD from another version of Linux, I see what looks like a Linux installation file system. However, when I put the card in the MicroSD slot of the board, and power up the board, the board ignores the MicroSD card and boots its embedded Linux from its Flash. Is there some standard trick for booting a dev board from its MicroSD slot instead of the internal OS on the flash memory?
I thought this would be a low probability first attempt, but am I looking at 100s of potential pitfalls, or just a few? What might be some of the reasons I could experiment with that could be causing the board to not boot from the SD? I didn't see any jumpers on the board. Are keyboard key combinations used to tell dev boards where to try booting from first? Or would the SD card usually be a default boot device if the OS on the card is valid for the hardware?
Thanks for any input you may have!
Bill
It's good to hear your progress; even though you haven't succeeded yet, I am sure you'll get there!
Normally, such devices boot from the SD-card/MicroSD-card by default.
You will need to familiarize yourself with the boot process and how to configure the particular Linux image you've downloaded.
I do not know much about it, but I can say that most of the ready-made images can be modified from a PC (preferrably running Linux already), by editing configuration files in /boot.
-But it's not just editing a text-file, because when the system boots, it often loads binary files only (some of the configuration files are kept as text).
So normally, you would have to ...
On Cubian (debian variant), the binary file I had to work with was called /boot/script.bin
So first thing to do is to back it up...
cp /boot/script.bin /boot/script.bck
Then you need to convert it to a text-file...
bin2fex /boot/script.bin /boot/script.fex
Edit the file...
nano /boot/script.fex
-After saving the file, convert the new .fex file back to binary:
fex2bin /boot/script.fex /boot/script.bin
and then boot on the new conf.
I wish I could give you more details and better help. As I am not a Linux expert, I will recommend a specific ARM-Linux forum for better information, because from here on, I would only be "guessing and hoping".
I've learned a little more since I posted the last reply.
Some devices are shipped with Android (for instance, TV-boxes), and the vendor "locks" the device, so it can not be updated.
An often used "expression" for this is that the device is "bricked". Eg. a cell-phone would be worth the same as a brick, if you can't really do anything with it.
-To unlock or "unbrick" a device, some tools exists. I recommend searching the Web for tools. Also try searching for "Moborobo" and "TPSarky"; these might help unlocking the device if it's locked.
I don't believe the device is locked due to my interaction with the manufacturer. They WANT to sell their boards. Since my last post, I have recently received the files from the device manufacturer which are supposedly the correct ones to burn onto an SD card, to then use to boot the device from the card and not the soldered on Flash. Unfortunately, I have been unsuccessful at booting the device from an SD card which I burned using 'dd' and the boot image file. I also copied the included embedded linux operating system files to the SD card, but still I saw nothing which led me to believe I was booting off of the SD card.
When I power up the device with the SD card in the slot, it boots up like it always does into the UI which allows networking configuration, and then launching an RDP (Remote Desktop Protocol) client. If I were to attach the files they sent to me, do you think you or someone else might be able to give me some advice as to how I need to be burning them onto an SD card to successfully boot the device? My main problem is communication with the company, as the technical people only speak Mandarin. I think this forum may be my best hope for suggestions on what to do with the files they sent me to make a bootable SD card.
Any ideas?
I'm sorry that I've not responded earlier; I've been away for two weeks by now.
Writing the image using the 'dd' utility is correct; I believe you're going forward, even though it (sometimes) might not feel like much. Hang in there; you might be close to getting it running.
I think the people who can help the best, would be Low-level Linux-people. Perhaps imrehg would know.
Hi, sorry for following up this late, thanks for the ping jensbauer!
I read through the notes so far, here are some thoughts:
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.