> While I understand the reasoning for your approach, it does not fit
> well into how OpenWrt's targets are organized. All targets using the
> same kernel branch are supposed to use the same kernel version, e.g.
> all targets using a 3.12 kernel are currently supposed to use 3.12.5.
> Then all patches from generic/patches-3.x are expected to be applied
> to the kernel, else things will break. Using a different kernel from
> the OpenWrt default version will eventually cause patches to not apply
> for either the odd target, or the others, because often patch will
> require modifications when going from 3.x.n to 3.x.n+1. Supporting
> both 3.x and 3.x.n+1 is not possible.
> Looking at your patch, I see you are modifying
> target/linux/generic/patches-3.12/880-gateworks_system_controller.patch,
> quite likely because it did not apply to your 3.12.7y. You likely
> broke the build for all other 3.12 targets with that.
> Therefore the only acceptable approach is to backport the appropriate
> changes from upstream and make them apply on top of the default
> OpenWrt 3.12 kernel.

> Since the current raspberry pi target BCM2708  will never be accepted
> upstream (it is there under a different name), a different approach
> would be to not backport the individual commits but rather use
> commit-diffs for the patches, or put the actual new files into
> files[-3.12] and only have patches that actually modify preexisting
> files (usually Makefile/Kconfig files). This would work as you don't
> have to worry about conflicts from upstream.

I made that 880 patch the way it does _not_ brake the build for vanilla kernel 
3.12.x
Now it supports both. But you are right. I didn't check that it works for 
3.x.n.. - but patch 880 is in patches-3.12 - so why should it be used for 3.x.n 
at all?

Current kernel in mainstream does _not_ work. Constant errors with filesystem 
and other issues as well. Maybe that's then better than usable system?
My current patch _does_ modify existing files as you see. It just adds:
target/linux/brcm2708/patches-3.12/001-change-version.patch 
b/target/linux/brcm2708/patches-3.12/001-change-version.patch

And now I noticed that I was sloppy as also config-3.12 from 
target/linux/brcm2708 was missing, so here is new patch that adds that too, 
although, it's useless,
but maybe someone from rpi community finds it useful.

Don't take my work so seriously if it doesn't suite the style of current 
OpenWrt buildroot, I just point out the way how to make the target actually 
working.
I didn't just take part of kernel that fixes sd issues, as this kernel is 
supposed to be used on raspberry pi and when there is a official provider, they 
work
on other issues as well, it's useless to make sd patch, because it's more or 
less going to happen that other things broke too, they propably haven't been
fixing these things in kernel just for fun..? New kernel, upgraded firmware 
allows one to have full potential of rpi with openwrt, including acceleration.
Don't see why all the good in the arch should be disabled.. OpenWrt is great 
distribution in my opinion, but the idea is too keep distribution light.. I 
don't
see why you need to hit the brakes for the hardware, that just doesn't make any 
sense.

And back to the topic, I got drift away from it.. My patch does build a working 
kernel for rpi. Now I have provided a patch for it, so now you know how to make 
it work.
It's strange that so many of you can point the issues in my patch but none can 
do anything about it. Fix it then for all, to me, it seems only problem is with 
generic patch 880.

Signed-off-by: Oskari Rauta <oskari.ra...@gmail.com>

Attachment: openwrt-rpi-kernel-3.12.7y.patch
Description: Binary data

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to