Hi
Is anyone interested in taking part in porting UcLinux for use on Xcore processors ?
I am planning to have a go at this and was wondering if there was anyone else interested enough to form up into a group.
Initial development using an XC1 and the XDE.
:ugeek:
UcLinux for XMOS Xcore Processors
-
- Experienced Member
- Posts: 65
- Joined: Fri Dec 18, 2009 1:27 pm
- Location: The Interzone
UcLinux for XMOS Xcore Processors
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
-
- Member++
- Posts: 21
- Joined: Fri Dec 11, 2009 3:42 pm
I'd be interested in using it I don't think I could be of much use coding wise. I have an xk-1 that I can test on.
-
- Active Member
- Posts: 53
- Joined: Sun Dec 13, 2009 5:39 pm
What is you´r plan. I don´t can imaginate any serious linux program running inside 40K of programm and data space. Further you must copy external ram (occupy 2 threads) to internal in order to
execute it. example, 40k for linux ececutable, this mean 10+10k data, 10+10k code that is swapped out every time a annother portion of data/code is accessed. This bring you down at
10Mhz speed. It´s better and cheaper to add external uLinux CPU and RAM and use the XMOS as
coprocessor.
execute it. example, 40k for linux ececutable, this mean 10+10k data, 10+10k code that is swapped out every time a annother portion of data/code is accessed. This bring you down at
10Mhz speed. It´s better and cheaper to add external uLinux CPU and RAM and use the XMOS as
coprocessor.
-
- Respected Member
- Posts: 296
- Joined: Thu Dec 10, 2009 10:33 pm
Indeed I think Linux on an XMOS would be seriously challenging and the result seriously "challenged".
Better to have a tiny ARM + FLASH + RAM for the Linux and surround it with XMOS devices for the fun gadgets.
Better to have a tiny ARM + FLASH + RAM for the Linux and surround it with XMOS devices for the fun gadgets.
-
- Respected Member
- Posts: 377
- Joined: Thu Dec 10, 2009 6:07 pm
On the current generation of processors you will struggle to get anything done within the memory footprint.
You can however use the (cycle-accurate) simulator in the free tools available from xmos.com to simulate arbitrary-sized memory and create a hypothetical architecture as a target. The simulator will run rather slowly for kernel development - but you should be able to get somewhere.
XMOS has internal functional simulators that run a lot faster that we may consider releasing...
You can however use the (cycle-accurate) simulator in the free tools available from xmos.com to simulate arbitrary-sized memory and create a hypothetical architecture as a target. The simulator will run rather slowly for kernel development - but you should be able to get somewhere.
XMOS has internal functional simulators that run a lot faster that we may consider releasing...
-
- Member
- Posts: 15
- Joined: Sun Dec 13, 2009 3:17 am
Hmm, is this an indication that a future generation of XMOS processors will have extensively expanded memory? Hopefully in the not-too-distant future....jonathan wrote:On the current generation of processors you will struggle to get anything done within the memory footprint.
-Mike
-
- Experienced Member
- Posts: 65
- Joined: Fri Dec 18, 2009 1:27 pm
- Location: The Interzone
Rational:-
To be commercially viable over the long term the Xcore needs to appeal to the broader market and compete effectively against the higher end micro-controllers that are already out there. Particulalry in the embedded appliance market. If it keeps to a small niche market (specialist IO engines) and always needs to be embedded with an additional processor it looses a significant degree of competitive advantage.
It is therefore advantageous to XMOS to have product that is capable of piggy backing (standing on the shoulders of giants) on an Open Source OS and already written applications code base that is currently widely used in embeded devices.
uClinux is exactly that Open Source OS. Being used in mass market appliances ranging from Wifi & Network Routers to set top boxes.
Being able to offer revolutionary IO engine capability together with using a potential manufacturers existing code base strategically places the Xcore for mass market take up. This brings down costs for us niche developers and ensures that the product line has longevity. ( I am thinking here of the untimely demise of the transputer and how many of us were left with projects and product that could no longer be supported)
Without sufficient commercial take up silicone will remain expensive and we are developing for a platform that will not last long enough for us to derive the benefits we seek. Given that the device is quite different from others the likely hood of an application porting to another platform should this one be withdrawn is slim.
Objective:-
See if we can port the uClinux embeded OS and its application codebase for use on the Xcore processors. Positioning the Xcore as a viable replacement for other embedded microcontrolers and bringing the revolutionary IO and DSP capabilities to that same market as competitive edge.
Technological competition:-
Current methods to combine specialist IO and DSP with a Microcontroler revolve around using FGPA's with a soft processor core and custom designed IO and DSP. The technology and capability is here now and flexible enough to make of it what you want. (This was the route I was looking to go before stumbling across the Xcore, but may well have to return to this route given discovered limitations)
This route is a little harder for some folk to go and initial costs are higher. Mass market take-up and rapidly advancing technology together with the ability to port designs to other manufacturers products make this route currently best of breed.
Plan:-
At the moment there is'nt one other than a discussion of feasibility here, potentially followed by putting together a group of one or more members to further the objective.
Summary :-
I think you guys have pretty much flagged up the prime limitations. uClinux is small and light weight with an established codebase. So should be ideal as a solution to the above analysis. uClinux is writen specificaly to stay small and work without VM or an MMU.
To get uClinux (or similar) to run on an xcore with the on chip memory sizes is not feasible. A potential solution is to dedicate some resource to realising an MMU with the speed limitations it introduces.
Breaking the design of uClinux to such a degree by adding in MMU would prevent the Xcore port from becoming an additional architecture of the uClinux stable. This means that to adapt uClinux we would have to fork the current version and maintain the variant. Doing this makes it all but impossible to benefit from the ongoing development in the main branch, much less to contribute.
In essence then what we really need is the KB specification for memory converting to MB whilst keeping the price per device the same. Maybe less as volume picks up.
I guess it wouldn't hurt to do the same for the OTP as well as realize this as flash with optional protection. OTP is very limiting not to mention a touch old fashioned.
Final prognosis I guess is that without site of a viable, cost effective, enhanced (memory) product this potential project is dead in the water. (I am not about to commit to a non trivial amount of work for a non existent product that may never be realized and quite frankly am struggling to see why anyone else should. Even though as pointed out the simulator may well handle it. )
Guys, many thanks for your input and wisdom you are indeed, all, stars.
To be commercially viable over the long term the Xcore needs to appeal to the broader market and compete effectively against the higher end micro-controllers that are already out there. Particulalry in the embedded appliance market. If it keeps to a small niche market (specialist IO engines) and always needs to be embedded with an additional processor it looses a significant degree of competitive advantage.
It is therefore advantageous to XMOS to have product that is capable of piggy backing (standing on the shoulders of giants) on an Open Source OS and already written applications code base that is currently widely used in embeded devices.
uClinux is exactly that Open Source OS. Being used in mass market appliances ranging from Wifi & Network Routers to set top boxes.
Being able to offer revolutionary IO engine capability together with using a potential manufacturers existing code base strategically places the Xcore for mass market take up. This brings down costs for us niche developers and ensures that the product line has longevity. ( I am thinking here of the untimely demise of the transputer and how many of us were left with projects and product that could no longer be supported)
Without sufficient commercial take up silicone will remain expensive and we are developing for a platform that will not last long enough for us to derive the benefits we seek. Given that the device is quite different from others the likely hood of an application porting to another platform should this one be withdrawn is slim.
Objective:-
See if we can port the uClinux embeded OS and its application codebase for use on the Xcore processors. Positioning the Xcore as a viable replacement for other embedded microcontrolers and bringing the revolutionary IO and DSP capabilities to that same market as competitive edge.
Technological competition:-
Current methods to combine specialist IO and DSP with a Microcontroler revolve around using FGPA's with a soft processor core and custom designed IO and DSP. The technology and capability is here now and flexible enough to make of it what you want. (This was the route I was looking to go before stumbling across the Xcore, but may well have to return to this route given discovered limitations)
This route is a little harder for some folk to go and initial costs are higher. Mass market take-up and rapidly advancing technology together with the ability to port designs to other manufacturers products make this route currently best of breed.
Plan:-
At the moment there is'nt one other than a discussion of feasibility here, potentially followed by putting together a group of one or more members to further the objective.
Summary :-
I think you guys have pretty much flagged up the prime limitations. uClinux is small and light weight with an established codebase. So should be ideal as a solution to the above analysis. uClinux is writen specificaly to stay small and work without VM or an MMU.
To get uClinux (or similar) to run on an xcore with the on chip memory sizes is not feasible. A potential solution is to dedicate some resource to realising an MMU with the speed limitations it introduces.
Breaking the design of uClinux to such a degree by adding in MMU would prevent the Xcore port from becoming an additional architecture of the uClinux stable. This means that to adapt uClinux we would have to fork the current version and maintain the variant. Doing this makes it all but impossible to benefit from the ongoing development in the main branch, much less to contribute.
In essence then what we really need is the KB specification for memory converting to MB whilst keeping the price per device the same. Maybe less as volume picks up.
I guess it wouldn't hurt to do the same for the OTP as well as realize this as flash with optional protection. OTP is very limiting not to mention a touch old fashioned.
Final prognosis I guess is that without site of a viable, cost effective, enhanced (memory) product this potential project is dead in the water. (I am not about to commit to a non trivial amount of work for a non existent product that may never be realized and quite frankly am struggling to see why anyone else should. Even though as pointed out the simulator may well handle it. )
Guys, many thanks for your input and wisdom you are indeed, all, stars.
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
-
- Active Member
- Posts: 53
- Joined: Sun Dec 13, 2009 5:39 pm
A COTS ARM9 linux module costs less then 50€. From a commercial and programming point of view,
it´s better to have such a cots module with a small cpld, that interfaces the two processors, and
use the XMOS ones as dedicated coprocessors. That´s my personal view of the thing.
I have worked with a network processor, that have 8x 32 bit slave cpu each running at 100Mhz,
one master 32bit cpu, and a interconnection switch times higher that XMOS uses, dedicated LUT and other peripherial (CRC, ...) and, important thing, global memory in addition to the local one.
But even this setup is far superior in performance (and price) and have external DRAM support
(LUT) + DMA, but even for such a CPU, linux is a no go. It´s have a standard bus interface,
and then a PPC is added in order to run linux.
it´s better to have such a cots module with a small cpld, that interfaces the two processors, and
use the XMOS ones as dedicated coprocessors. That´s my personal view of the thing.
I have worked with a network processor, that have 8x 32 bit slave cpu each running at 100Mhz,
one master 32bit cpu, and a interconnection switch times higher that XMOS uses, dedicated LUT and other peripherial (CRC, ...) and, important thing, global memory in addition to the local one.
But even this setup is far superior in performance (and price) and have external DRAM support
(LUT) + DMA, but even for such a CPU, linux is a no go. It´s have a standard bus interface,
and then a PPC is added in order to run linux.
-
- Experienced Member
- Posts: 65
- Joined: Fri Dec 18, 2009 1:27 pm
- Location: The Interzone
I have been doing a quick round robin of SRAM pricing and availability.
Given that most micro-controlers don't have external memory interfaces and that most microprocessors that do are aimed at using much larger quantities of dynamic RAM. SRAM devices have higher prices and are less widely available. Particularly not in larger capacities.
Putting a shed load of memory on all devices is perhaps unrealistic. A little more wouldn't go amiss though on the current devices.
There is a case however to seriously expand the capabilities of at least one device, offering a renamed device based on it.
I was thinking here of suggesting that XMOS add an external memory interface to the L1. It certainly would have enough die space.
An L1 with more on board static ram (which could act as a sort of cache) and an external memory interface that allowed greater Flash and Ram (perhaps DRAM or PSRAM) to be added as needed would be great. I guess it would make it possible to add in memory mapped IO as well.
uCLinux will run with a couple of MB of each.
Given that most micro-controlers don't have external memory interfaces and that most microprocessors that do are aimed at using much larger quantities of dynamic RAM. SRAM devices have higher prices and are less widely available. Particularly not in larger capacities.
Putting a shed load of memory on all devices is perhaps unrealistic. A little more wouldn't go amiss though on the current devices.
There is a case however to seriously expand the capabilities of at least one device, offering a renamed device based on it.
I was thinking here of suggesting that XMOS add an external memory interface to the L1. It certainly would have enough die space.
An L1 with more on board static ram (which could act as a sort of cache) and an external memory interface that allowed greater Flash and Ram (perhaps DRAM or PSRAM) to be added as needed would be great. I guess it would make it possible to add in memory mapped IO as well.
uCLinux will run with a couple of MB of each.
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
-
- XCore Addict
- Posts: 234
- Joined: Thu Dec 10, 2009 11:11 pm
- Location: Newcastle, UK
DrFingersSchaefer wrote: Is anyone interested in taking part in porting UcLinux for use on Xcore processors ?
I am planning to have a go at this and was wondering if there was anyone else interested enough to form up into a group.
A group would be a good idea to pull together peoples ideas
Last edited by TonyD on Wed Dec 30, 2009 9:50 pm, edited 1 time in total.