Searching for tester of Linux Kernel drivers

[swahren]

Hi,

i'm currently i try to provide cpufreq support for Freescale i.MX23/i.MX28 into Linux Mainline. Unfortunately i don't have a i.MX23 board to test my code. So i want ask if someone here wants to help me with testing my drivers on a i.MX23 board.

The development process has 3 stages:
1. Implementing mxs power subsystem driver
2. Implementing mxs regulator driver
3. Modify i.MX23/i.MX28 devicetree for cpufreq-dt support

Currently i'm in the first stage and send my first patch series to linux-pm mailing list:

http://marc.info/?l=linux-pm&m=141651453315940&w=2

I imagine that i provide a git repository including my patches and the tester needs to compile the kernel and build the rootfs by himself.

Anyone interested?

Stefan

[lambda]

Hi Stefan,

I'm very interested! (Particularly into everything that brings us closer to mainline support for battery charging.)

I did already build custom kernels/rootfs using OpenWrt in the past, so that part shouldn't be a problem.

Unfortunately I can't commit to any schedule right now.

Which testing would be necessary? It seems you are developening on an i.MX28 board and your code doesn't have any i.MX23 specific parts AFAICS, so why is testing on i.MX23 important?

Harald

[swahren]

Hi Harald,

in the end the mxs power driver could do the battery charging, but there are many code lines to write. Unfortunately i don't any hardware for this use case.

Sounds good and no problem about the time. I will setup the repository and will be happy to receive some feedback. I don't believe that development is finished this year.

I think it would be the best to write here some test scenarios down.

The testing on i.MX23 is important, because i only have a i.MX28. Currently the code isn't specific to i.MX23, but the regulator code is. Btw i don't believe in documents, only in tests.

Stefan

[lambda]

Hi Stefan!

in the end the mxs power driver could do the battery charging, but there are many code lines to write. Unfortunately i don't any hardware for this use case.

I know. If nobody is faster I will write a driver for battery charging myself. Your work would make this easier for me.

Sounds good and no problem about the time. I will setup the repository and will be happy to receive some feedback. I don't believe that development is finished this year.

I think it would be the best to write here some test scenarios down.

Sounds good. Feel free to CC me on any mxs related mails to kernel mailinglists, etc.

The testing on i.MX23 is important, because i only have a i.MX28. Currently the code isn't specific to i.MX23, but the regulator code is. Btw i don't believe in documents, only in tests.

I see your point about documents, but to have the code accepted into mainline there is no need to test the unspecific parts on i.MX23. Of course testing is always a good thing.

Harald

[swahren]

in the end the mxs power driver could do the battery charging, but there are many code lines to write. Unfortunately i don't any hardware for this use case.

I know. If nobody is faster I will write a driver for battery charging myself. Your work would make this easier for me.

A lot of mxs user are interested in battery charging. That would be great.

Sounds good. Feel free to CC me on any mxs related mails to kernel mailinglists, etc.

Sure, if you send me your mail address.

Btw i made a RFC for a mxs ocotp driver, may be you want to test it on i.MX23:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html

It wasn't accepted, but it would be good to know how it works on i.MX23.

[swahren]

Here is the test scenario for fsl_ocotp driver:

• apply the patch series against the last 3.17 or 3.18 Linux kernel
• configure FSL_OCOTP as kernel module ( Device drivers -> Misc devices -> Freescale MXS on-Chip OTP Memory support )
• build a bootable image (bootloader, kernel, devicetree blob, rootfs) as usual
• boot your system with the image
• check if the module is autoloaded
• if it's not loaded modprobe it
• go to directory /sys/devices/soc0/80000000.apb/80000000.apbh/8002c000.ocotp/fuses
• read them out and store them in text file
• unload the module and load the module again
• boot your system into USB recovery mode (special USB A-A cable required)
• start your common OTP tool like bitburner.exe from Freescale
• compare the register and read out values with bitburner

Warning: Don't change any OTP bits with bitburner!

[scout_3pm]

I can and will* setup 2 ( two ) iMX233-OLinuXino boards for You with LiPo batteries and SSH root** access through a public ip and sub-domains to my personal domain.

* - it can happen this weekend, but ONLY if you are serious and will use them ( 10 minutes a week is a use ;-) so no pressure ). Also I can help you with development and testing as I myself am an Embedded Developer and recently + currently working on Kernel Development for Embedded Devices :-) Also our work (me and my colleagues) is pushed to mainline at final stage so could provide some support there too, cause I personally don't have yet direct experience with pushing to mainline ;-) But people around me do and they are always open for talk :-)

** - non-root user login, then sudo or su, key authentication - NOT (ONLY) WITH PASSWORD

The two boards are: MAXI and NANO. Also if you ask, I'm sure Olimex will send you one or two, or even more. They support Developers who contribute to the Open Source Community and/or their Products, which is awesome of their side. Really great attitude.

ps: I'm From EU/BG/SF , if in the region we can meet for fast and more effective communication.

Will check the forum regularly this week

[swahren]

Hi scout_3pm,

thanks for the offer about the iMX233 boards, but i'm not familiar with the OLinuXino hardware including the LiPo batteries.

I'm searching for people, who wants to test with their own hardware. I develop in my spare time for i.MX28 and i don't have the time for another platform.

I will setup the repository and post the test scenario here.

Thanks

Stefan

[scout_3pm]

1
I.e You don't look for Hardware, you look for testers ?

2
Testers with their own hardware OR only testers ?

3
Is this for a commercial project doing it open source ?

You are not very responsive to what i wrote so i will suppose you have a busy work week.

[swahren]

1
I.e You don't look for Hardware, you look for testers ?

Yes

2
Testers with their own hardware OR only testers ?

Testers with a i.MX233

3
Is this for a commercial project doing it open source ?

My intension is to push the driver into Linux Kernel mainline. It's not a commercial project.

You are not very responsive to what i wrote so i will suppose you have a busy work week.

Yes

[scout_3pm]

OK. From your answer turns out my offer for support is not applicable so - Good Luck.
I'm not interested in only testing, but develop and design, which incl testing, but that's different.

[swahren]

OK. From your answer turns out my offer for support is not applicable so - Good Luck.
I'm not interested in only testing, but develop and design, which incl testing, but that's different.

I know testing isn't fun. But for developing the relevant mailing list is a better place.

[scout_3pm]

Push it to staging, NOT mainline; and it will be tested ;-) Good Luck :-)

[swahren]

Push it to staging, NOT mainline; and it will be tested ;-) Good Luck :-)

Thanks for the wishes, but staging isn't a good solution. I think the driver is clear enough. If the code isn't good i need to fix it and not dumping it in staging.

btw: mxs-lradc is in staging since 2012 and we don't know when it's leave.

[scout_3pm]

I don't want to make a discussion about it or take of your time. But this driver is there for more than one reason ;-) (Also) Clear doesn't mean it's tested, ready or safe/secure to be used.