Looking for ARM SoC porting guidelines

Looking for ARM SoC porting guidelines

[Mike Thompson]

I'm working on a port the latest Linux kernel to a Nuvoton N32905 - a very
inexpensive ARM9 based SoC similar to the Freescale iMX23 in many
respects.  My hope is that my code for this SoC will eventually reach the
mainline kernel, but the whole process a fairly daunting task to a kernel
newbie such as myself.

I do have a six year old port of the 2.6.35 kernel to this SoC to help as a
reference, but it's pretty much a rewrite to support devicetree, the common
clock framework, and a myriad of changes needed to get a new SoC supported
in the mainline kernel.  Not to mention all the 2.6.35 code added for this
chip isn't even close to the coding standards for the Kernel.

So far I got the 3.17 kernel running pretty well the baseline peripherals
such as clocks, interrupt controller, UART, GPIO & pin muxing along with
hire level peripherals such as MMC/SD card support, MTD NAND and NOR flash
and USB host support.

As a guide, I've been using other ARM SoCs for examples and a number of
very useful presentations on ARM SoC support from the Free Electron folks.
Although presentations such as the "ARM SoC Linux Support Check-list" are
very useful, they don't go into much detail.

My question is two fold.  Is there detailed information of all the things
that need to be covered in the code to introduce a new ARM SoC into the
kernel?  Then, is there a description of how I start to go about
contributing support for this chip into the Linux kernel? I honestly don't
really know where to begin.

Any advice or pointers would be sincerely appreciated.

Mike Thompson

BTW, my git reposity for this SoC is:
https://github.com/mpthompson/linux/tree/n329
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141112/a1fdae6f/attachment.html 

Looking for ARM SoC porting guidelines

[Maxime Ripard]

Hi Mike,

On Wed, Nov 12, 2014 at 09:45:58PM -0800, Mike Thompson wrote:
> I'm working on a port the latest Linux kernel to a Nuvoton N32905 - a very
> inexpensive ARM9 based SoC similar to the Freescale iMX23 in many
> respects.  My hope is that my code for this SoC will eventually reach the
> mainline kernel, but the whole process a fairly daunting task to a kernel
> newbie such as myself.

Been there... :)

> I do have a six year old port of the 2.6.35 kernel to this SoC to help as a
> reference, but it's pretty much a rewrite to support devicetree, the common
> clock framework, and a myriad of changes needed to get a new SoC supported
> in the mainline kernel.  Not to mention all the 2.6.35 code added for this
> chip isn't even close to the coding standards for the Kernel.
> 
> So far I got the 3.17 kernel running pretty well the baseline peripherals
> such as clocks, interrupt controller, UART, GPIO & pin muxing along with
> hire level peripherals such as MMC/SD card support, MTD NAND and NOR flash
> and USB host support.

Cool!

> As a guide, I've been using other ARM SoCs for examples and a number of
> very useful presentations on ARM SoC support from the Free Electron folks.
> Although presentations such as the "ARM SoC Linux Support Check-list" are
> very useful, they don't go into much detail.
> 
> My question is two fold.  Is there detailed information of all the things
> that need to be covered in the code to introduce a new ARM SoC into the
> kernel?

Usually "enough so that it boots", which means: timers, interrupts,
UARTs, and that's pretty much it.

Any additional feature is of course welcome, but I'd suggest to just
post that for the first set of patches. There will probably
significant changes to make to your base drivers (and I would include
clocks and pinctrl into these drivers), and these will impact any
further developments. You don't want to have too much dependency :)

Start small, then build on top of what's accepted.

> Then, is there a description of how I start to go about contributing
> support for this chip into the Linux kernel? I honestly don't really
> know where to begin.

Like I said, send the minimum amount of patches to have Linux boot an
initramfs on your SoC. Apart from that, there is nothing out of the
ordinary on how to submit patches, everything is detailed in
Documentation/SubmittingPatches. Basically, it will involve sending
patches to the linux-arm-kernel mailing list and the ARM SoC kernel
maintainers. Make sure that everything has no warning in
scripts/checkpatch.pl, and you're good to go.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141113/9792e937/attachment.bin 

Looking for ARM SoC porting guidelines

[Mike Thompson]

On Thu, Nov 13, 2014 at 12:40 AM, Maxime Ripard <
maxime.ripard@free-electrons.com> wrote:

> > As a guide, I've been using other ARM SoCs for examples and a number of
> > very useful presentations on ARM SoC support from the Free Electron
> folks.
> > Although presentations such as the "ARM SoC Linux Support Check-list" are
> > very useful, they don't go into much detail.
> >
> > My question is two fold.  Is there detailed information of all the things
> > that need to be covered in the code to introduce a new ARM SoC into the
> > kernel?
>
> Usually "enough so that it boots", which means: timers, interrupts,
> UARTs, and that's pretty much it.
>
> Any additional feature is of course welcome, but I'd suggest to just
> post that for the first set of patches. There will probably
> significant changes to make to your base drivers (and I would include
> clocks and pinctrl into these drivers), and these will impact any
> further developments. You don't want to have too much dependency :)
>
> Start small, then build on top of what's accepted.
>

OK, that is pretty much from what I expected. I'll begin this process soon
as I have added similar base support for the N32926 which is a bigger
brother to the N32905.  I figure it's best to lay the foundation for
multiple chips in the Nuvoton N329 family from the start.

I've been using the iMX23 and iMX26 SoC support as the model for code
placement, naming and such.  These chips are useful in the way they share
drivers similar to what I would like to do.  Are these SoCs known to be
following current best ARM SoC practices for me to follow in their path?

Concerning how I should arrange my code in a git repository, currently
everything is in a single branch.  I guess I'll want to peel out just the
minimal set of drivers from which I'll submit patches and then do the work
on the more advanced SoC drivers in another set of branches so everything
isn't all mixed together.

> Then, is there a description of how I start to go about contributing
> > support for this chip into the Linux kernel? I honestly don't really
> > know where to begin.
>
> Like I said, send the minimum amount of patches to have Linux boot an
> initramfs on your SoC. Apart from that, there is nothing out of the
> ordinary on how to submit patches, everything is detailed in
> Documentation/SubmittingPatches. Basically, it will involve sending
> patches to the linux-arm-kernel mailing list and the ARM SoC kernel
> maintainers. Make sure that everything has no warning in
> scripts/checkpatch.pl, and you're good to go.
>
> Maxime
>

Got it.  Hopefully I'll start with the first set of patches within in the
next few weeks and cross my fingers I'm not chased away with a stick for
being such a newbie :-).

Before submitting the first set of patches, would it be useful for me to
post a link to them here on this mailing list so someone could look them
over as a sanity check before a submission to the linux-arm-kernel mailing
list?  I'm a bit nervous about making a good first impression.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141113/e94df3fb/attachment.html 

Looking for ARM SoC porting guidelines

[Maxime Ripard]

Hi,

On Thu, Nov 13, 2014 at 10:41:25AM -0800, Mike Thompson wrote:
> On Thu, Nov 13, 2014 at 12:40 AM, Maxime Ripard <
> maxime.ripard at free-electrons.com> wrote:
> 
> > > As a guide, I've been using other ARM SoCs for examples and a number of
> > > very useful presentations on ARM SoC support from the Free Electron
> > folks.
> > > Although presentations such as the "ARM SoC Linux Support Check-list" are
> > > very useful, they don't go into much detail.
> > >
> > > My question is two fold.  Is there detailed information of all the things
> > > that need to be covered in the code to introduce a new ARM SoC into the
> > > kernel?
> >
> > Usually "enough so that it boots", which means: timers, interrupts,
> > UARTs, and that's pretty much it.
> >
> > Any additional feature is of course welcome, but I'd suggest to just
> > post that for the first set of patches. There will probably
> > significant changes to make to your base drivers (and I would include
> > clocks and pinctrl into these drivers), and these will impact any
> > further developments. You don't want to have too much dependency :)
> >
> > Start small, then build on top of what's accepted.
> >
> 
> OK, that is pretty much from what I expected. I'll begin this process soon
> as I have added similar base support for the N32926 which is a bigger
> brother to the N32905.  I figure it's best to lay the foundation for
> multiple chips in the Nuvoton N329 family from the start.
> 
> I've been using the iMX23 and iMX26 SoC support as the model for code
> placement, naming and such.  These chips are useful in the way they share
> drivers similar to what I would like to do.  Are these SoCs known to be
> following current best ARM SoC practices for me to follow in their path?

I guess you meant imx28, but yeah, they have a quite good support with
regard to the usual best practices.

However, they do have quite some history that won't be needed. You'd
better start looking at the platforms that were introduced
recently. Off the top of my head, I'd say the amlogic or alpscale SoCs
that have been merged, or not that far.

> Concerning how I should arrange my code in a git repository, currently
> everything is in a single branch.  I guess I'll want to peel out just the
> minimal set of drivers from which I'll submit patches and then do the work
> on the more advanced SoC drivers in another set of branches so everything
> isn't all mixed together.

Yeah, it's up to you, but I guess it's the common workflow. I've
looked into your git repo, and it seems like there's been quite some
work and it has some history already. Don't carry that history when
sending patches, just post the patches to add the current code you
have.

> > Then, is there a description of how I start to go about contributing
> > > support for this chip into the Linux kernel? I honestly don't really
> > > know where to begin.
> >
> > Like I said, send the minimum amount of patches to have Linux boot an
> > initramfs on your SoC. Apart from that, there is nothing out of the
> > ordinary on how to submit patches, everything is detailed in
> > Documentation/SubmittingPatches. Basically, it will involve sending
> > patches to the linux-arm-kernel mailing list and the ARM SoC kernel
> > maintainers. Make sure that everything has no warning in
> > scripts/checkpatch.pl, and you're good to go.
> >
> > Maxime
> >
> 
> Got it.  Hopefully I'll start with the first set of patches within in the
> next few weeks and cross my fingers I'm not chased away with a stick for
> being such a newbie :-).
> 
> Before submitting the first set of patches, would it be useful for me to
> post a link to them here on this mailing list so someone could look them
> over as a sanity check before a submission to the linux-arm-kernel mailing
> list?  I'm a bit nervous about making a good first impression.

Don't worry about this :)

It's completely fine to be a newbie, we've all been there at some
point. People won't flame you if you are one, and will even usually
guide you to stop doing the mistakes you're making. However, you will
piss people off if you ignore these advices and keep doing the same
mistakes over and over again :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141114/4267b0c7/attachment-0001.bin 

Looking for ARM SoC porting guidelines

[Luca Ceresoli]

Dear Mike,

Mike Thompson wrote:
> OK, that is pretty much from what I expected. I'll begin this process
> soon as I have added similar base support for the N32926 which is a
> bigger brother to the N32905.  I figure it's best to lay the foundation
> for multiple chips in the Nuvoton N329 family from the start.

Very interesting. I just started a project using the Nuvoton N32926,
and mainline support in a recent kernel would be very, very
interesting. I'd be glad to join your effort by testing your code, and
possibly contributing.

What bootloader are you using? AFAIK Nuvoton does not provide any sort
of U-Boot, barebox or any other open source bootloader.

Do you have any working configuration for the N32926? Boot+UART, I don't
expect much at this early stage, but I'd like to test it as soon as you
have one.

Oh, and... any plans for supporting the H.264 decoder on the N32926?

Thank you very much for the work you've done so far!

-- 
Luca

Looking for ARM SoC porting guidelines

[Mike Thompson]

On Fri, Nov 14, 2014 at 9:10 AM, Luca Ceresoli <luca@lucaceresoli.net>
wrote:

> Very interesting. I just started a project using the Nuvoton N32926,
> and mainline support in a recent kernel would be very, very
> interesting. I'd be glad to join your effort by testing your code, and
> possibly contributing.
>
> What bootloader are you using? AFAIK Nuvoton does not provide any sort
> of U-Boot, barebox or any other open source bootloader.
>

Correct.  For right now, I'm using the proprietary Nuvoton bootloaders
which are kind of a mess in terms of having to use the 15 year old ARM
Development Suite software to build.  I have a simple script which converts
a Linux Image file and device tree binary into a conprog.bin file that the
Nuvoton can boot with from the existing bootloaders.

Nuvoton is switching to a newer Keil based development environment for
their proprietary bootloader, but that's not a whole lot better.  My hope
is to get some sort of U-boot running by adapting pieces of the proprietary
bootloader, but that's a secondary priority relative to just getting basic
kernel functionality running.

Do you have any working configuration for the N32926? Boot+UART, I don't
> expect much at this early stage, but I'd like to test it as soon as you
> have one.
>

I'm still waiting for my N32926 hardware to arrive to begin a port for it.
Given the work I've done with the N32905 and the similarity between the two
chips at the basic level, I don't anticipate it taking more than a few days
to get it going.  I'll post back here when I have something to try.  At a
minimum it would include the clock framework, clock source, interrupt
driver, UART driver and other basic stuff.

Oh, and... any plans for supporting the H.264 decoder on the N32926?
>

Well, for now I'm working on the basics and the first tier of drivers to
the system so it can boot from NOR/NAND flash, SD cards and have basic USB
connectivity. I already have these items on the N32905.  I don't have any
specific plans beyond that for the N32926, but we'll see. My specific
interest is in the lower-end N32905 because of the opportunity for the chip
in the toy markets and a $3 Linux capable single chip system is really cool
:-).

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141114/2ea7f8bb/attachment.html 

Looking for ARM SoC porting guidelines

[Luca Ceresoli]

Dear Mike,

Mike Thompson wrote:
[...]
> I'm still waiting for my N32926 hardware to arrive to begin a port for
> it.  Given the work I've done with the N32905 and the similarity between
> the two chips at the basic level, I don't anticipate it taking more than
> a few days to get it going.  I'll post back here when I have something
> to try.  At a minimum it would include the clock framework, clock
> source, interrupt driver, UART driver and other basic stuff.
>
>     Oh, and... any plans for supporting the H.264 decoder on the N32926?
>
> Well, for now I'm working on the basics and the first tier of drivers to
> the system so it can boot from NOR/NAND flash, SD cards and have basic
> USB connectivity. I already have these items on the N32905.  I don't
> have any specific plans beyond that for the N32926, but we'll see. My
> specific interest is in the lower-end N32905 because of the opportunity
> for the chip in the toy markets and a $3 Linux capable single chip
> system is really cool :-).

Any news on your project? There seem to be no more commits since several
weeks on your github repository...

-- 
Luca

Looking for ARM SoC porting guidelines

[Mike Thompson]

Hi Luca,

I need to get back to the project.  I got pulled away from the project
during the holidays and haven't had the time to make progress since that
time due to family and work obligations.

I'm currently working on getting a client to help pay for my time working
on this project.  If successful, that will help get things moving much,
much faster.  Crossing my fingers that they go for it.

At least now I have both N32905 and N32926 development boards so I can try
to get a modern kernel for both versions of the SoC.

Mike


On Sun, Feb 1, 2015 at 1:15 AM, Luca Ceresoli <luca@lucaceresoli.net> wrote:

> Dear Mike,
>
> Mike Thompson wrote:
> [...]
>
>> I'm still waiting for my N32926 hardware to arrive to begin a port for
>> it.  Given the work I've done with the N32905 and the similarity between
>> the two chips at the basic level, I don't anticipate it taking more than
>> a few days to get it going.  I'll post back here when I have something
>> to try.  At a minimum it would include the clock framework, clock
>> source, interrupt driver, UART driver and other basic stuff.
>>
>>     Oh, and... any plans for supporting the H.264 decoder on the N32926?
>>
>> Well, for now I'm working on the basics and the first tier of drivers to
>> the system so it can boot from NOR/NAND flash, SD cards and have basic
>> USB connectivity. I already have these items on the N32905.  I don't
>> have any specific plans beyond that for the N32926, but we'll see. My
>> specific interest is in the lower-end N32905 because of the opportunity
>> for the chip in the toy markets and a $3 Linux capable single chip
>> system is really cool :-).
>>
>
> Any news on your project? There seem to be no more commits since several
> weeks on your github repository...
>
> --
> Luca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150202/855eb470/attachment.html