i.MX53 bare-metal/RTOS Development

[ChrisPonder]

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

[ChrisPonder]

Thanks, I guess I am in for an interesting few weeks :)

[Felix1z]

 It is absolutely impossible to re-implement features like what the Linux stack has from scratch with bare-metal style software

my point precisely -- it never works without hick-ups. 

[RobertSchwebel]

Chris Ponder said:

Does this mena I should be looking at a commercial IP stack?

The i.MX53 wont be used on the faster devices, we will use the i.MX6 single core equivalent which does have Gb Ethernet, hopefully not too big a step in terms of software.

Have you worked with a CPU in the MX53 range before? If you are not absolutely knowing what you are doing, you should reconsider using an operating system. It is absolutely impossible to re-implement features like what the Linux stack has from scratch with bare-metal style software, and so called "commercial IP stacks" are often of so poor quality, that it will cause more pain than anything else.

Redesigning a board for a new RAM in 5 years will be your smallest problem then, I assume. I wouldn't do that.

rsc

[Felix1z]

for your needs i would recommend to look for commercial solution -- IP+RTOS. Even fastest and best performing IP stack will fail with lousy RTOS integration. FreeRTOS is good and light, but there are better ones too. You need to look for something that will support both CortexA8 and A9 cores, with all device drivers and features you need; also make sure that the vendor will provide plenty of support. Having someone with local engineers is huge benefit. With your goals you will spend a lot of time on application design and system integration; so you don't need to spend even more for RTOS/IP porting, debugging, bug fixing... etc. 

[ChrisPonder]

Thanks, this is really helpful. Not sure on the Gb Ethernet bandwidth, one product will use around 200Mbps, others will want 3.5Gbps (HD video) so will have to be heavily compressed to fit. Does this mena I should be looking at a commercial IP stack? The i.MX53 wont be used on the faster devices, we will use the i.MX6 single core equivalent which does have Gb Ethernet, hopefully not too big a step in terms of software. Wow 10Gbps, nice!

[Felix1z]

if you are talking about 1gbps ethernet with 99% throughput you actually need highly specialized ip stack and drivers, zero copy drivers and stack, no latency FIQ based interrupts, carefully planned memory layout and DMA utilization -- based on my experience lwIP is getting messy when it comes to high throughput, low latency requirements. LSO/LRO support is a must (not implemented in lwIP)! Also there is a concern that superjumbo packets may not even fit in internal sram -- those can get till 64000 bytes, and you have 128kb sram for everything.

Personally, I would think twice to choose iMX53 for high speed gigaethernet design... there are specialized network processors out there that are optimized for such task. iMX53 is multimedia processor, and it's good at it.

P.S. i do have experience of designing high performance network devices for up to 10gbps throughput.

P.P.S. you do realize, that you will need external FEC/MDI -- iMX53 has only 10/100...

[ChrisPonder]

Noooo! lwIP seems really popular so I was hoping that it would be sufficient for most tasks. None of the research I have done suggests any particular limitations with lwIP. I take it you have some experience of these limitations?

[Felix1z]

in that case it is understandable. But you will need to make highly educated decision about IP stack! lwIP will not be sufficient for most tasks, and better IP stacks will eat more memory, both code and data. 

[ChrisPonder]

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.

[Felix1z]

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.

[ChrisPonder]

lol, thanks :)

[RobertSchwebel]

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

rsc

[ChrisPonder]

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.

[RobertSchwebel]

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

[ChrisPonder]

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 :)

[Felix1z]

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?

[ChrisPonder]

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

[ChrisPonder]

Also, how long did the port take you?

[ChrisPonder]

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

[Felix1z]

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.