Moschip MCS8142 SoC

Moschip MCS8142 SoC

[mlweber1 at rockwellcollins.com]

Has anyone happened to work with this Moschip SoC?  I found Linux BSP 
patches for the MCS8140 (OpenWRT 3.3 Kernel plus some initial attempts at 
mainlining around 3.7), however that MCS8140 SoC was a true ARMv5 compared 
to the MCS8142 which seems to be based on a Faraday fa526 ARMv4.  
Another item I'm not to sure about is if the bus and peripheral 
architecture are similar.

Any help is appreciated (reference docs that outline the register 
definition, etc.) .  We're trying to get a 3.x kernel running on this 
target to replace a older 2.6.24 blob that we can't get source for..... 

Matthew L Weber / Sr Software Engineer / Platform SW 
mlweber1 at rockwellcollins.com

Moschip MCS8142 SoC

[Arnd Bergmann]

On Wednesday 04 December 2013, mlweber1 at rockwellcollins.com wrote:
> Has anyone happened to work with this Moschip SoC?  I found Linux BSP 
> patches for the MCS8140 (OpenWRT 3.3 Kernel plus some initial attempts at 
> mainlining around 3.7), however that MCS8140 SoC was a true ARMv5 compared 
> to the MCS8142 which seems to be based on a Faraday fa526 ARMv4.  
> Another item I'm not to sure about is if the bus and peripheral 
> architecture are similar.
> 
> Any help is appreciated (reference docs that outline the register 
> definition, etc.) .  We're trying to get a 3.x kernel running on this 
> target to replace a older 2.6.24 blob that we can't get source for..... 
> 
> Matthew L Weber / Sr Software Engineer / Platform SW 

Hi Matthew,

Florian Fainelli (now on Cc) did the patch series for MCS814x in the past,
see http://lwn.net/Articles/507006/. As far as I understand, MCS8140
and MCS8142 only differ in the CPU core, so the required code is actually
almost identical.
However, I would now recommend doing the port on the latest kernel version,
i.e. 3.13 at this point, for which you would not be able to reuse
much of the code, as we have redone all the interfaces to make it simpler
to add a new platform. Essentially you add separate drivers to 
drivers/irqchip, drivers/clocksource, drivers/clk, arch/arm/include/debug
and drivers/pci/host but won't need any actual code in arch/arm/mach-* any
more at this point.

Jonas Jensen is working on support for the "moxart" platform, which uses
the same fa526 core and which is similar in other regards, so I'd recommend
looking at his code as examples for how to do this the right way.

	Arnd

Moschip MCS8142 SoC

[Arnd Bergmann]

On Friday 06 December 2013, Florian Fainelli wrote:
> I still plan on submitting support for the MCS8140 soon (just need some
> home internet connection),

Ah, cool!

> although due to the major CPU difference we will
> probably have a hard time building the same kernel image for all MCS SoCs.
> At least we should target MULTI_V4 and MULTI_V5.

I was wondering about this: Jonas had some problems with kernels that enable
both ARM9 and FA526 support, IIRC. We didn't get to the bottom of this, but
for all I can tell, the infrastructure should already be there to support
a multiplatform kernel with any combination of ARMv4/v4t/v5 cores enabled.

	Arnd

Moschip MCS8142 SoC

[mlweber1 at rockwellcollins.com]

Arnd Bergmann <arnd@arndb.de> wrote on 12/05/2013 08:31:31 PM:

> From: Arnd Bergmann <arnd@arndb.de>
> To: linux-arm-kernel at lists.infradead.org, Jonas Jensen 
> <jonas.jensen@gmail.com>
> Cc: mlweber1 at rockwellcollins.com, Florian Fainelli <florian@openwrt.org>
> Date: 12/05/2013 08:31 PM
> Subject: Re: Moschip MCS8142 SoC
> 
<snip>

> Florian Fainelli (now on Cc) did the patch series for MCS814x in the 
past,
> see http://lwn.net/Articles/507006/. As far as I understand, MCS8140
> and MCS8142 only differ in the CPU core, so the required code is 
actually
> almost identical.
> However, I would now recommend doing the port on the latest kernel 
version,
> i.e. 3.13 at this point, for which you would not be able to reuse
> much of the code, as we have redone all the interfaces to make it 
simpler
> to add a new platform. Essentially you add separate drivers to 
> drivers/irqchip, drivers/clocksource, drivers/clk, 
arch/arm/include/debug
> and drivers/pci/host but won't need any actual code in arch/arm/mach-* 
any
> more at this point.

The newer FPGA SoC arch(s) we've been working with recently have been 
using 
that.  Nice and clean so I definitely agree that's the way to go. 
Originally
I was hoping that I could get an initial build with 3.3 just to get past 
my
current bug/issue we're working to resolve.... We'll see.

> 
> Jonas Jensen is working on support for the "moxart" platform, which uses
> the same fa526 core and which is similar in other regards, so I'd 
recommend
> looking at his code as examples for how to do this the right way.

Thanks, I'll take a look at (http://lwn.net/Articles/554101/).  I guess in 

some ways this would at least get my chip booting past the initial arch 
related asm stuff and if my DT is setup with the right serial port, the 
console should at least show some output until it dies.

Matt

Moschip MCS8142 SoC

[Arnd Bergmann]

On Friday 06 December 2013, mlweber1 at rockwellcollins.com wrote:
> > Jonas Jensen is working on support for the "moxart" platform, which uses
> > the same fa526 core and which is similar in other regards, so I'd 
> recommend
> > looking at his code as examples for how to do this the right way.
> 
> Thanks, I'll take a look at (http://lwn.net/Articles/554101/).  I guess in 
> 
> some ways this would at least get my chip booting past the initial arch 
> related asm stuff and if my DT is setup with the right serial port, the 
> console should at least show some output until it dies.

A good first step is normally to get debug_ll running first. This requires
the least amount of work and gives you some form of debug output at the
first instruction in the kernel.

	Arnd