Support for kernel 3.3 and/or OpenWRT

[Peter Mueller]

I am working on a project that I think the pico-board may be perfect for.  However, the project requires the use of OpenWRT as the Linux "distro".  OpenWRT is currently using a 3.3 kernel, most sources I've found for the pico are 3.1  I've seen the code.google.com area dedicated to a running kernel for the pico, but there are comments indicating that USB does not work.  This would be an issue for us, as we need USB mass storage access.  So my questions are:

1. Does USB work with a Linux 3.3 kernel reliably? 

2. Has there been any work done on creating a kernel patch packages against a 3.3 kernel?  or...

2b. Has there been any work done on getting a pico-specific OpenWRT build?

I'm not afraid to build a package for the pico, but I've found only full kernel builds, not a collection of patches that can be applied to get the pico working.

As far as I can understand it, a board-config file exists, as does a MACH_ identifier, but changes to the memory allocation and PWM are needed.

Thanks for any help

-pete

[Daniel Palmer]

Everything below refers to the 3.3rc6 tree on my google code page..

 

1. Does USB work with a Linux 3.3 kernel reliably? 

I think it depends on the device. I think the atmel datasheets say some stuff about the USB not being great in the high speed mode. For me at least the kernel panics if I try to take lots of photos using a usb webcam (it works for about 10 minutes). I have had a USB bluetooth module plugged in for about a month without any issues though. If the OCHI module gets loaded the kernel panics instantly. I've been busy with work so I haven't had time to work out why.

2. Has there been any work done on creating a kernel patch packages against a 3.3 kernel?  or...

I did have 3.3 working at some point.. so you can probably checkout a commit around that time to get what you want.

2b. Has there been any work done on getting a pico-specific OpenWRT build?

 Not sure, I can't see why it wouldn't work though.

 

I'm not afraid to build a package for the pico, but I've found only full kernel builds, not a collection of patches that can be applied to get the pico working.

Diff a normal kernel tree with the patched one. The differences are very small now.

As far as I can understand it, a board-config file exists, as does a MACH_ identifier, but changes to the memory allocation and PWM are needed.

The MACH id is in the kernel source, the PWM stuff is fixed .. The only things that are needed now are a board file, the phy<->virt memory stuff, some changes to a makefile to make the image get located at the right place in memory. The mainline kernel was pretty broken around 3.3 (for at91), the fixes for those issues should be in my tree though.

[Daniel Palmer]

I mean 3.4rc6

[Nicu Pavel]

> I'm not afraid to build a package for the pico, but I've found only full
> kernel builds, not a collection of patches that can be applied to get the
> pico working.

Look in the current 3.1 source in minibox-picopc-3.1 branch all
patches since v3.1 tag are only for picoSAM9G45.

> As far as I can understand it, a board-config file exists, as does a MACH_
> identifier, but changes to the memory allocation and PWM are needed.

Yes, memory allocation patch is the first thing that's holding us from
being included in mainline. The second thing is that Atmel G45 device
tree doesn't support everything that we need (think MMC is still not done).
I'm not sure why Atmel doesn't make a patch to allow 256Mb since their
devboards do come with 256Mb.

I will probably check Daniel patches and start working on 3.4 kernel soon.

Nicu

[Daniel Palmer]

tree doesn't support everything that we need (think MMC is still not done).

 

MMC == the lower parts of the SD card support? I have everything running with the mainline tree .. even the hardware RNG is supported in the mainline now (it's totally useless ;)). Everything works without device tree too.

Saying that I haven't actually tested SPI or I2C but the drivers are apparently there.

There is a pre-compiled kernel on google code of 3.4rc4 with those drivers (I think) if anyone wants to have a go. 

The biggest issue is crashes with USB .. it could be related to certain USB drivers and sparsemem.. I haven't checked too much because of time and the fact that it's a hard crash with zero output.

[Nicu Pavel]

> MMC == the lower parts of the SD card support? I have everything running
> with the mainline tree .. even the hardware RNG is supported in the mainline
> now (it's totally useless ;)). Everything works without device tree too.
> Saying that I haven't actually tested SPI or I2C but the drivers are
> apparently there.

I think everything should work if you don't use device tree, main
issues that you can't send patches
upstream if your board uses "old style"
I will check with Jean Christophe about the sparsemem.

> There is a pre-compiled kernel on google code of 3.4rc4 with those drivers
> (I think) if anyone wants to have a go.

That's great I'll give it a go.

> The biggest issue is crashes with USB .. it could be related to certain USB
> drivers and sparsemem.. I haven't checked too much because of time and the
> fact that it's a hard crash with zero output.

Going to run our factory test on new kernel to check if it crashes. I
think we are doing direct writes to a USB storage.

Nicu

[Daniel Palmer]

there is only 3.4rc2 on googlecode at the moment,.. I'll just tar up the running kernel from my machine and upload it. Give me 5 minutes :)

[Daniel Palmer]

I think everything should work if you don't use device tree, main
issues that you can't send patches
upstream if your board uses "old style"
I will check with Jean Christophe about the sparsemem.

mmm I don't really see why the device tree thing is so great.. most people will compile a kernel for a single board. I guess it makes atmel's life a bit easier being able to ship a single kernel for most of their boards but that's about it.

I didn't really read up too much on how device tree actually works.. it seems we just need to have at91 bootup upload the compile dsdt(?) to somewhere in memory. Do you think it would be much work to hack it in? We could just compile the dsdt file into the at91boot binary to save having to read another file from SD.

Going to run our factory test on new kernel to check if it crashes. I
think we are doing direct writes to a USB storage.

I can build a kernel with OHCI enabled too if you want? that panics as soon as the module gets loaded .. the issues when using EHCI might be related. 

Cheers,

Daniel

[Nicu Pavel]

>
> I can build a kernel with OHCI enabled too if you want? that panics as soon
> as the module gets loaded .. the issues when using EHCI might be related.

It's ok, going to download the sources anyway so I'll build it to try
different configurations (with/without sparsemem/ohci/ehci etc)

Nicu

[wander]

Hello Daniel. I just tried your kernel build (linux34rc4.tar.gz). It`s works fine for me, but I want to try build my own modules with this kernel. So, please, can you email me a source code and config for this kernel version, or maybe commit number, because the last version from repo isn`t boots.

Thanks.

[Daniel Palmer]

Hi,

I think the last working commit is in the kernel version (i.e. should be visible via uname -a) and I think I posted on the front page too.

My picosam isn't running at the moment (dead SD card) so I can't tell you which commit it was actually running right now.

[wander]

Thank you for reply. I found nesessary commit. Is the .config (in download section) suitable for 3.4rc4?

понедельник, 22 октября 2012 г., 14:49:08 UTC+4 пользователь Daniel написал:

[ddduch...@gmail.com]

H Peter,

 

Were you able to get OpenWRT running on the pico-SAM9G45 ?   With USB support?  We're interested in using that combo in a configuration for a non-profit organization, for use in an emergency communications network (our work is pro bono).

 

I'd appreciate any feedback you can provide.

 

Dave Duchesneau

[Daniel Palmer]

I have the latest 3.4 stable kernel and 3.11 running on the pico now. 3.11 has issues with the MMC (SD card) driver so 3.4 is best for now. My google code page has repos for a patched at91bootstrap and uboot.. and I can upload my 3.4 source at some point if that is any use to you.

USB-wise; It seems to work fine for stuff like USB->converters (I have one running an NFC module) but I still think there are issues if you use anything that is more intensive like cameras etc.

--
You received this message because you are subscribed to the Google Groups "pico-SAM9G45 Mini-Box.com ARM embedded system board" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pico-SAM9G45...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.