i.MX ProcessorsのトピックRe: i.MX53 bare-metal/RTOS Development

i.MX53 bare-metal/RTOS Development

ChrisPonder — Wed, 18 Jan 2012 11:15:22 GMT

Hi, I was wondering if anyone else is doing bare-metal/small RTOS development on the i.MX53 CPU and what tool-chain/RTOS they are using. Thanks

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Fri, 20 Jan 2012 10:22:23 GMT

Are we really the only ones doing bare-bone development on the i.MX53?

Re: i.MX53 bare-metal/RTOS Development

VladanJovanovic — Fri, 20 Jan 2012 13:04:20 GMT

No there's others as well :-)

Codesourcery toolchains are one option. Or then any of the commercial arm compiler providers...

Re: i.MX53 bare-metal/RTOS Development

Felix1z — Fri, 20 Jan 2012 15:47:04 GMT

We're doing GCC/FREERTOS on imx53. i've used K60 port and modified it to support imx53 specifics. GCC is vanilla 4.5.3, binutils vanilla 2.22.

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Mon, 23 Jan 2012 10:59:26 GMT

Yay, not alone! :) Felix, that is exactly what I am trying to do, I don't suppose you have any tips for doing this?

Re: i.MX53 bare-metal/RTOS Development

Felix1z — Mon, 23 Jan 2012 15:20:31 GMT

what are you having issues with? also -- do you have jtag probe?, since it will be your best tool until you'll be convinced, that everything runs smoothly...

Chris Ponder said:

Yay, not alone! :)

Felix, that is exactly what I am trying to do, I don't suppose you have any tips for doing this?

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Mon, 23 Jan 2012 15:39:25 GMT

I guess that was a little vague, sorry. I am only just starting out so many of my questions seem daft. I have a Segger J-Link for JTAG operation and 30-day trials of most of the commercial IDEs. ARM DS-5 doesn't support the J-Link Keil doesn't support the Cortex-A8 Greenhills haven't bothered to get back to me IAR seems ok CrossWorks I have only just started looking at I am at the point of trying the Eclipse/GNU tools using gnuarmeclipse and yagarto. I have tried compiling the K60 project in IAR but the portasm.s throws some register errors: "Error[446]: The selected cpu/core does not support this status register" [82] msr msp, r0 [88] mrs r0, psp [97] msr basepri, r0 [100] msr basepri, r0 [106] msr psp, r0 [115] msr BASEPRI, R0 [125] MSR BASEPRI, R0 [137] msr psp, r0 [139] msr basepri, r0 [151] msr msp, r0 My guess is that it is three different registers msp psp basepri Since R0 is used elsewhere, but I also suspect that porting cannot be as simple as getting this file to compile

Re: i.MX53 bare-metal/RTOS Development

Felix1z — Mon, 23 Jan 2012 16:45:22 GMT

let's start with basics -- j-link will work only if it's newer version, with swd support. best course of action is to acquire gdb server license for it -- this will allow you to debug using gdb. gdb server only works on windows, but you can connect to it from linux box. I prefer do develop using linux, and kdevelop, but it's not a must. if you're new to cross compiling, get yourself any latest arm-elf toolchain -- make sure it's arm-elf and not arm-linux! Since you're developing on bare metal (freertos is still considered as bare metal, since you don't have elf loader/run time linker in it), you need properly linked elf.

i would recommend reading http://download.ronetix.info/toolchains/arm/arm_cross_development_guide.pdf

for start.

As far as commercial ide/compilers -- i would not recommend any one of them... they all have their pros and cons. I've used crossworks for a while -- they have CTL (cross tasking library), that you can use in place of rtos, to have basic threads, but as i said, every one has pros and cons. Today it's much easier to use vanilla gcc toolchain

Re: i.MX53 bare-metal/RTOS Development

Felix1z — Tue, 24 Jan 2012 05:55:55 GMT

P.S. portasm.S is one of the files to be ported to A8... i've used http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.... as my reference for porting.

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 08:41:00 GMT

Thanks Felix, are there any other files I need to look at?

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 10:31:56 GMT

Also, how long did the port take you?

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 11:18:55 GMT

Doh! I have found the porting page:http://www.freertos.org/FreeRTOS-porting-guide.html and the directory structure page:http://www.freertos.org/a00017.html Sorry for the really dumb questions. I would still be interested in how long it took as I have to present an estimate :S

Re: i.MX53 bare-metal/RTOS Development

Felix1z — Tue, 24 Jan 2012 13:05:33 GMT

well, the questions, you're asking, are same for everyone starting new port, so they are not dumb. As for time -- it took about 8 hours with debugging to get perfectly running port. Another 14 hours to get EHCI,FatFS and lwIP added.

It all depends on goals -- i set to this adventure instead of linux, due to need of recovery bootloader, that will understand USB MSD and USB ethernet adapter, and fit in 65k i2c eeprom. After messing for over 2 months with u-boot, i gave up, and wrote my own tiny bootloader, that actually fits in 32k =) -- goal achieved. But my main system application is in linux.

Why did you choose to go bare metal route?

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 13:24:39 GMT

Thanks :) About three days for you then, cool. So did you use FreeRTOS for your bootloader? We are pushing for bare metal because we don't need all the nice functionality of Linux. We don't need a GUI, a file system or mouse/keyboard support. Our application is purely embedded with the processor shovelling data from an FPGA to the network plus some control and configuration tasks. Ideally we want to get away with no external DDR and an OS that loads into internal RAM whilst still doing high speed IP networking etc. This saves the problems with DDR obsolesence and if we pick the right flash format we will avoid that obsolesence as well while minimising load time and cost :)

Re: i.MX53 bare-metal/RTOS Development

RobertSchwebel — Tue, 24 Jan 2012 13:38:09 GMT

Hi Chris,

Can you elaborate the reasons why you want to run bare metal software on MX53? Note that Linux runs nicely, and if you like, you can get preempt-rt support as well. So taken the complexity behind a machine in the MX53 league, I wouldn't start with bare metal.

Best regards,

Robert

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 13:57:56 GMT

The details of how we ended up at i.MX53 bare-metal are somewhat complex. But the two clinchers for me were that we don't need the features and even the smallest Linux I have seen (uCLinux) will not fit into the internal RAM. Our products tend to have quite long production lives, of the order of 15 years for some and the need to re-layout every couple of years to accomodate changing Flash and DDR RAM footprints is not ideal.

Re: i.MX53 bare-metal/RTOS Development

RobertSchwebel — Tue, 24 Jan 2012 14:33:02 GMT

Ok, then you won't have any other choice. However, good luck with fighting against the complexity of the chip :-)

rsc

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 14:53:22 GMT

lol, thanks :)

Re: i.MX53 bare-metal/RTOS Development

Felix1z — Tue, 24 Jan 2012 15:33:31 GMT

Chris, after looking on your replies, why do you need i.MX53 then? there are cheap cortex-m4 devices with network, plenty of flash/ram and ready freertos port (k60 for example).

And to answer your question -- yes, FreeRTOS runs as my recovery bootloader.

Re: i.MX53 bare-metal/RTOS Development

ChrisPonder — Tue, 24 Jan 2012 16:51:48 GMT

lol Felix :) I am defining the core structure all our future products and product updates will use. Some of them currently use an 8MHz PIC others are capable of filling 100Mbps Ethernet and in the future will have a good go at filling up 1Gbps Ethernet. The theory behind the process is that we use a single CPU family (ARM) and FPGA vendor to minimise inventory, design time and toolchain. For this to actually be of any benefit in the engineering of new products there needs to be a commonality of firmware. Despite the diversity of bandwidth requirements the actual tasks are remarkably the same for all of our products. Thus we are aiming for one firmware with drivers and platform includes. This means I have to define an OS, CPU and tool-chain that work in the biggest/fastest and fit in the smallest. The i.MX535 has sufficient internal RAM to run an RTOS with IP stack and has the performance for our fastest products. By going through the process for the Cortex-A8 if we decided to use an M4 for the smallest devices it will be well understood and we will be sure that we can use the same firmware for the higher performance units and how to do it.