Re: Automatic LAN Subnet Reassignment

[Imre Kaloz]

Hi Rich,

Basic (v4 only) version of these (as well automatic wan proto detection) was 
implemented and rejected some years ago :)

Both are quite easy to do, that version used the following hotplug script:

===
#!/bin/sh

if [ "$INTERFACE" = "wan" ] && [ "$ACTION" = "ifup" ]
then
# Get subnets for lan and wan
lan_subnet=$(uci get network.lan.ipaddr | cut -d '.' -f3)
wan_subnet=$(ifconfig wan | grep -w "inet" | awk '{print $2}' | cut -d 
':' -f2 | cut -d '.' -f3)

# If subnet is the same, randomize lan IP
if [[ $lan_subnet == $wan_subnet ]]; then
rn=$(awk 'function rn(n) { return int(rand()*n); } BEGIN {{ 
srand(); }{ printf("%d.%d", rn(254), rn(254))}}')
uci set network.lan.ipaddr=10.$rn.1
uci commit network

# Restart network to refresh changes
/etc/init.d/network restart
fi
fi
===

Setup of redirection ran as an init script:

===
#!/bin/sh

START=55
boot() {

lanip=$(uci get network.lan.ipaddr)

grep -q "myrouter.local/$lanip" /etc/config/dhcp
if [ $? -eq 1 ] ; then
# add a redirect myrouter.local to our IP
uci add_list dhcp.@dnsmasq[0].address="/myrouter.local/$lanip"
uci commit dhcp
fi
}
===


Best,
Imre


From: openwrt-adm  on behalf of Rich 
Brown 
Sent: Monday, February 21, 2022 22:38
To: OpenWrt Project Administration; openwrt-devel@lists.openwrt.org
Cc: Richard E. Brown
Subject: Automatic LAN Subnet Reassignment

There is a new RFC on the OpenWrt forum proposing "Automatic LAN Subnet 
Reassignment" 
https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938
 The RFC responds to the advice given at last week's OpenWrt-Adm meeting 
(https://etherpad.wikimedia.org/p/ZlZiTcud3wufcSX9-1jD)

The intent of the proposal is for the default configuration to assign a LAN 
subnet that avoids a conflict with the WAN subnet, and provide a mDNS name such 
at OpenWrt.lan for connections.

I have two requests:

1) Please make comments on the technical merits of the proposal on the OpenWrt 
forum at the link above.

2) If the proposal seems to make sense, please consider the process by which we 
would incorporate this into the main release (likely, not for 22.0x, but 
perhaps the next release?)

Thank you.

Rich



___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-adm

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mwlwifi: remove target dependency

[Imre Kaloz]

Hi Daniel,

FWIW in my opinion we should get back to this topic as soon as you have a 
mwlwifi supported card up and running on any other platform. Right now this 
would introduce a change just to make a different platform's SDK usable for a 
purpose which would get a straight "no" from the developer community if a user 
would have proposed it.

I'm against this change (not that it matters ever since you've stripped 
maintainer roles in the name of democracy).


Imre


From: Daniel Golle 
Sent: Sunday, March 21, 2021 22:17
To: openwrt-devel@lists.openwrt.org
Cc: Imre Kaloz
Subject: [PATCH] mwlwifi: remove target dependency

Users complained that building images for various mvebu Linksys devices
fails when using the ImageBuilder, it complains about the package
'mwlwifi-firmware-88w8964' not being found.

Turns out the package builds fine in mvebu/cortex-a9 images build, but
isn't built at all for arm/cortex-a9 packages. This is because we are
using the SDK for bcm53xx/generic to build packages for arm/cortex-a9,
hence the dependency for @TARGET_mvebu fails.

Remove the target dependency as kmod-mwlwifi as well as firmware
packages actually build fine on all platforms (and people might even
want to use Marvell mPCIe Wifi on non-mvebu platforms).
As a result, the missing 'mwlwifi-firmware-'* packages should become
available for arm/cortex-a9 (and all other platforms).

Signed-off-by: Daniel Golle 
---
See also:
https://forum.openwrt.org/t/recent-imagebuilder-build-issues-for-wrt3200acm-on-master/91802

 package/kernel/mwlwifi/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/kernel/mwlwifi/Makefile b/package/kernel/mwlwifi/Makefile
index 648c826ccb..14973d0010 100644
--- a/package/kernel/mwlwifi/Makefile
+++ b/package/kernel/mwlwifi/Makefile
@@ -28,7 +28,7 @@ include $(INCLUDE_DIR)/package.mk
 define KernelPackage/mwlwifi
   SUBMENU:=Wireless Drivers
   TITLE:=Marvell 88W8864/88W8897/88W8964/88W8997 wireless driver
-  DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT 
@PCI_SUPPORT @TARGET_mvebu
+  DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT 
@PCI_SUPPORT
   FILES:=$(PKG_BUILD_DIR)/mwlwifi.ko
   AUTOLOAD:=$(call AutoLoad,50,mwlwifi)
 endef
@@ -54,7 +54,7 @@ define Package/mwlwifi-firmware-default
   SECTION:=firmware
   CATEGORY:=Firmware
   TITLE:=Marvell $(1) firmware
-  DEPENDS:=+kmod-mwlwifi @TARGET_mvebu
+  DEPENDS:=+kmod-mwlwifi
 endef

 define Package/mwlwifi-firmware/install
--
2.31.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Imre Kaloz]

Hi Paul,

On 2017-10-26 18:16, p...@oranjevos.nl wrote:

Please, could you add some info on what has changed with the new version of the 
patch ?
And, it would be appreciated when the SOB would not use an openwrt.org mail 
address (assuming Imre has another suitable mail available).

Paul


Op 26 okt. 2017, om 17:41 heeft Zoltan HERPAI<wigy...@uid0.hu>  het volgende 
geschreven:

Given that we've decided to sail under the same flag for
the benefit of the whole community, and acknowledge the
achievements of the LEDE project, let's start the final
steps of the merge.

The git and other sources are untouched until the infra merge.

v2: - dismiss bugtracker and forum change
- update uhttpd cert gen
- update banner
- update busybox NSLOOKUP patch

Signed-off-by: Zoltan HERPAI<wigy...@uid0.hu>
Signed-off-by: Imre Kaloz<ka...@openwrt.org>



Please find the changes listed in the description, but left it in above 
as well. As for using another email address, I won't use my personal one 
for this as I don't use this for that, simply as that. This is fully 
following what the merge agreement that has been voted for and got 
accepted defined.



Best,

Imre


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

Re: [OpenWrt-Devel] [LEDE-DEV] Remerge logo ideas

[Imre Kaloz]

On 2017-05-29 13:10, Jamie Stuart wrote:

See another iteration, with:

- correct capitalisation
- antenna to the side (will not work with lowercase ’n’)
- open sans typeface (open source)
- mockups of website header
- accent colours

http://i.imgur.com/ZKtcFXo.png


Nice :) Personally I like the darker color set of the last, but the 
layout of the first the most (when the "signal" is at the end).



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

Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal V2

[Imre Kaloz]

Hi,

On 2017-05-22 03:10, John Crispin wrote:



On 22/05/17 11:02, Rafał Miłecki wrote:

On 05/22/2017 09:40 AM, John Crispin wrote:

*) branding
- the owrt side sees no option of using the lede brand
- a (minor) majority voted for openwrt as a name over lede whilst 
most people said they did not care
- as the last vote had a 100% ACK for a remerge using the owrt brand 
is the only feasible option


Since the project is going to be known/accessible under OpenWrt name 
now, I

want also mbm and Kaloz to share #openwrt and #openwrt-devel privileges.

There were many times op was needed but mbm/Kaloz weren't around.

I was refused/ignored multiple times when asking for that, so I 
wanted to

bring it as this point to be clear. Is that OK for you guys?


i'll add it to V3
Sorry Rafal, don't get me wrong but this isn't true. It might haven't 
been documented well (like quite a few things) but you have been told 
years ago: everyone who has a project cloak has access to everything. 
What have been refused is to make a special exception just for you to 
get it without that.



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

Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal

[Imre Kaloz]

Well hello there,

On 2017-05-11 12:53, Stijn Segers wrote:



While, like most people, I'm happy progress has been made towards a
re-merge, there still seems quite some passive-agressive behaviour
present coming from certain people championing OpenWrt [1] - which, from
where I stand, seemed one of the reasons for starting LEDE. Stifling
'free' speech (recently, even to the point of removing messages about
the pending re-merge on the OpenWrt forums) was another one; clearly,
that one is still very much present as well. One could say old habits
die hard, but it still feels like par for the course. What's up with
that? You want to remerge with the LEDE project, yet you cannot tolerate
any discussion about the actual process on the OpenWrt forums? That's
some fine duplicity right there.


I guess our vocabularies differ quite a bit, given I see no 
passive-aggressive statements there. I hope you just misunderstood the 
ways some things have been worded, as your mail overemphasized certain 
parts to twist the picture. I could very well say you're championing 
yourself but somehow I don't see mails from you sent to any lists nor me 
about questioning the forum moderators' behavior. Of course you could 
have also stepped up and volunteer to be one, but either of these would 
have required more energy then this mail.


Don't get me wrong, I'm not questioning if you're right, but you should 
also be a bit more empathetic and understand a few things.


First of all, forum moderator rights have been given out as we didn't 
have time to do it ourselves. This also means that after the first few 
days we didn't spend our time on monitoring what people with moderator 
rights are doing.


Second, and this might be harder to accept, but to a certain degree when 
the first reply to anything is "OpenWrt is dead, go with LEDE", your 
behavior might generate a hostile reply. Again, I'm not saying this is 
right, I'm saying this is standard human behavior.


Back to my reply you love referring to: for me it seems you are the one 
who can't tolerate the discussion and would like to silence opinions (or 
how they can be expressed) you don't like. You might prefer baroque, I'm 
free to like renaissance.



I can't help but feel very uneasy about this. I'm not implying people
who stuck with OpenWrt don't want the best for the project and community
(most do), but we all know LEDE was created to remedy exactly these (and
other) shortcomings, which made OpenWrt languish to the point it had
come to a standstill. Not only did LEDE try to tackle these problems; it
has succeeded beyond expectation. Developers are more accessible, you
can actually talk to people instead of getting your head bit off,
contributions are booming, and the atmosphere overall is friendly and
helpful. Discussion is encouraged, not repressed Soviet-style.


The reasons of the fork have been discussed quite a few times, and if 
you think any project will be free of internal politics over a decade, 
you might want to look into the history of FOSS projects in general :)


As the rest of your mail is mostly FUD, let's stick to facts if you 
consider replying. As the saying goes, in any relationship, there are 
three sides of the story: his side, her side and the truth.


Both sides have hard feelings about certain topics, but this discussion 
started because we've decided to put those away. I can only ask you to 
try the same instead of sending mails like this.



Thanks,

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

Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal

[Imre Kaloz]

On 2017-05-09 18:29, Philip Prindeville wrote:




I’d like to suggest one more action item to this list if I can.  It would be 
handy to have a single database for user authentication/identification for 
submitting bugs, editing the Wiki, etc.

Previously there were too many places where you had to create an account.  If 
we can’t do “single sign-on”, can we at least do “single sign-up”?

And part of a user’s profile should include their IRC handle (assuming they 
have one).


I agree, SSO would be way more user friendly. We should look into it for 
sure.



Best,

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

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal

[Imre Kaloz]

On 2017-05-08 15:43, Toke Høiland-Jørgensen wrote:

John Crispin  writes:


Hi,

Felix, Imre and myself had 2 calls last week lasting several hours and discussed
the following proposal of conditions for a remerge that we would like to propose
and have people vote on.


Great to hear progress is being made on this! I think the proposal looks
reasonable, generally. A few comments / questions:

- What will this mean for the community rules and the release schedule?
  Will they continue from the current LEDE practices?


- update the landing page to have the same look & feel as the current openwrt
landing page


Well, I like the L of lede-project.org better - but it's not something
worth bikeshedding over, so meh, fine... ;)


Well, the OpenWrt one might be from 2000s, but the LEDE one is from '95 
;) I think the CSS jow did for the OpenWrt forum looks the best TBH :)



*) trademark/sponsorship policy
- review/ack imres trademark policy
- review/ack jows sponsorship policy


Links to these?


On the tm policy: https://openwrt.org/trademark - I guess jow will chime 
in with the location of the sponsorship one, too.





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

Re: [OpenWrt-Devel] [PATCH] packages: Use https instead of git

[Imre Kaloz]

Hi Alexey,

On 2017-02-15 11:11, Alexey Brodkin wrote:

From: Alexey Brodkin 

On some [especially corporate] networks non-standard ports are blocked
and git is one of them. So switch to more convenient https transport.

Signed-off-by: Alexey Brodkin 


Please make this a configuration option instead.


Thanks,

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

[OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Imre Kaloz]

Hi,

Linksys would like to give away 54 Rango (WRT3200ACM) units. Please use 
the relevant post [1] if you want to be one of them.




Cheers,

Imre


[1] https://forum.openwrt.org/viewtopic.php?pid=344315#p344315
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] meetup for beer on Tuesday 11 Oct, Berlin

[Imre Kaloz]

Hi lynxis,

Please use "OpenWrt / LEDE" if you refer both projects. If only the 
second, please stick to "LEDE".



Best,

Imre

On 2016-10-06 17:50, Alexander Couzens wrote:

Hi all,

thanks to the ELCE, a lot of us (OpenWrt LEDE) will be in Berlin next
week.
I would like to invite you to the c-base on Tuesday, 11 Oct, starting at
20:00 to drink something and talk.

The c-base is a broken space station in Berlin, near the train station
Jannowitzbrücke [1] [2].

If you have any questions, please ask me.

Best,
lynxis

[1] https://www.c-base.org/cv50f/core/impressum.html
[2]
https://www.openstreetmap.de/karte.html?zoom=17=52.51298=13.42012=B0



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


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

Re: [OpenWrt-Devel] SSL Cert

[Imre Kaloz]

Hi Thomas,

On Sun, 24 Jul 2016 15:06:18 +0200, Thomas Heil
 wrote:


Hi, Kaloz,

On 24.07.2016 00:09, Hauke Mehrtens wrote:

Hi Kaloz,

could you please change the ssl certificate. With HSTS it is pretty hard
to circumvent the warning.


If you need any help with issue (money or config) let us know.

thomas



Hauke

On 07/22/2016 11:19 PM, Eric Schultz wrote:

Just wanted to let folks know that the SSL cert expired on openwrt.org
 which makes openwrt.org 
inaccessible.

Eric


The cert wasn't under my control (all hail the decentralization some
people were so crazy about). It has been transferred and a new one is
active now.


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

[OpenWrt-Devel] [RFD] Future

[Imre Kaloz]

All,

There was an opportunity for a mini-meetup between Felix, Luka and myself  
in Paris. We openly discussed the recent events. We've concluded that it  
would be beneficial to members of both OpenWrt and LEDE to have a face to  
face meeting in the near future.


On that note, we would like to ask all project members to consider this  
invitation as a way to move forward and resolve our issues.



Signed-off-by: Imre Kaloz <ka...@openwrt.org>
Signed-off-by: Felix Fietkau <n...@nbd.name>
Signed-off-by: Luka Perkov <l...@openwrt.org>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] reboot

[Imre Kaloz]

On Fri, 06 May 2016 12:50:32 +0200, John Crispin  wrote:


the reboot was not meant to be hostile or disruptive to OpenWrt. we are
just code nerds and messed up the politics of the launch at some places,
which in itself shows one of the reasons that motivated the reboot. the
whole idea is to give up our control over parts of the politics and
attract a new generation. a small none elected crowd has been making
decisions that essentially are not ours to make but effect us all. these
decisions have been made largely behind closed doors.


You were part of the "small none elected crowd".


the whole thing started by the workload becoming unbearable on a few. we
felt the need to simply stop or make drastic changes. giving up and just
letting it all bitrot seemed to be the easy way out, but we did feel
that we had a debt to our own heritage. simply leaving seemed bad and
unfair on the community. we decided to get the project back on track
instead.


So instead of exercising your right as a release manager or Felix his as  
the lead developer you've prepared LEDE. And don't tell me you didn't have  
the power, fro example procd and netifd were introduced without voting or  
everyone's agreement for example. Don't get me wrong, we're talking about  
how changes were introduced, not the nature of these changes.



we’ll be the first to agree that things where not peachy at times. this
however does not boil down to one single event, one single person or one
single flamewar. we are just many strong minded people that had
different opinions on many matters. due to the governance rules that we
setup and created and the way in which we managed the project it was
hard to mitigate these problems.


Not true. You had the power, yet you didn't use it. You could have called  
for a vote but you did not.



the reason for not involving everyone at the start is pretty simple and
nerdy. when the idea came up we just looked at who was the most active
in the various software trees the last 6 months and proposed our idea to
the 5 most active core devs and power users. it was a simple choice of
numbers and perceived activity. the feedback was rather overwhelming and
things just picked up a certain momentum leading to the status quo. i
guess the excitement for fixing long standing issues just took over.


Sure, playing democracy is easy if only the ones you agree on have the  
right to be included in decisions.



i have been asked by luka why we consider this a reboot rather than a
fork. i actually had to think about that one. a fork for me means that
one party splits with a second. that was not our intent. we wanted to
split with the errors we have done ourselves in the past and the wrong
management decision that were made at times. the gap between core
developers, power users and endusers had grown way too big. hence i
consider this more a “We are forking ourselves” or as we put it,
rebooting the system.


Again, as RM and LD, plus having the right to call a vote you had all the  
power you could need to make these changes in openwrt. Even the ones you  
turned down but introduced as modernization in LEDE.



to sum it up, my personal reasoning why i endorse this … the now 20 year
olds like social media, github, clouds and what nots. for me to continue
shaping a development and political system that they should use in their
future to run on their routers when i am already double their age is not
ideal. the next generation should be given the freedom to shape their
own future and learn from their mistakes the same way we shaped our
future and learned form our mistakes. i sincerely hope that the reboot
will encourage people to step up and not only have good ideas of what
should be fixed but will start to shape their future themselves


This is so full of political pr it makes me remember "make America great  
again"..




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

Re: [OpenWrt-Devel] Introducing the LEDE project

[Imre Kaloz]

On Thu, 05 May 2016 17:44:43 +0200, Daniel Petre   
wrote:





On 05/05/2016 06:38 PM, Jonathan Bennett wrote:

There is plenty of blame to go around, I think.  Seems like the Lede
guys should have had the decency to at least inform the Openwrt
leadership privately that they were planning this venture.


If i read correctly the feedback from the LEDE guys (and many of the  
people in here) then it seems EVEN THEY did not had any serious real  
feedback since a while ago from the main OpenWrt "headquarters".


So.. what do you do when you ask (probably several times) and do not get  
any answer at all.. ?


They were in charge. When the lead developer and the release manager claim  
they had no power to change the way (yet both procd and netifd got  
introduced without prior discussion or agreement), you know something is  
fishy.



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

Re: [OpenWrt-Devel] Introducing the LEDE project

[Imre Kaloz]

On Thu, 05 May 2016 18:24:09 +0200, Daniel Dickinson  
 wrote:



On 16-05-05 12:21 PM, Jonathan Bennett wrote:
[snip]
> The changes that the Lede guys are suggesting would be welcome,  
but
> splitting the project and community with an ugly fork is very  
much not

> welcome.

Let's just say that there are strong personalities who haven't been
working well together and that this has been a long time coming;  
perhaps
if something like using a mediator had been considered before  
things got

to this point it would have helped.  At this point I'm not sure
there is a
solution unless both sides are willing to bend a little (I'm really  
not
sure who has been flexible and who has not, but as I have said I  
suspect
a large part of the issue is that 'management' (who aren't and  
don't,

really) has overruled those doing the majority of the work and in an
open source project that doesn't fly).

I don't disagree.  I just see the current state of Openwrt/Lede as a
mess for the community.


I agree, I just don't see how the LEDE team could have avoided it
without giving up and accepting the broken status quo.


I hope you realize the LEDE team created most of that status quo.


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

Re: [OpenWrt-Devel] [PATCH 0/4] omap 4.4, ehci, sdcard

[Imre Kaloz]

On Tue, 26 Apr 2016 13:09:15 +0200, John Crispin <blo...@openwrt.org>  
wrote:





On 26/04/2016 13:07, Imre Kaloz wrote:

On Tue, 26 Apr 2016 13:00:40 +0200, John Crispin <blo...@openwrt.org>
wrote:




On 26/04/2016 12:59, Imre Kaloz wrote:

On Tue, 26 Apr 2016 12:55:50 +0200, John Crispin <blo...@openwrt.org>
wrote:


the maintainer of the target does not use patchwork. so they are not
applicable to be listed in patchwork. sorry i normally send an email  
to

the submitter informing him of this. i forgot to do so last night


"the maintainer" was told to ask jk for permissions and jk told him  
john

handles those.


Imre


last i asked you you said you dont use patchwork. and i was never told
after that, that you want to use patchwork. had i only known or been
told.


If I would have said that, why would you tell me to ask jk for an
account? Non sequitur..

Can I get that account then, please?


Imre



sure i assume the account you created is kaloz ?


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

Re: [OpenWrt-Devel] [PATCH 0/4] omap 4.4, ehci, sdcard

[Imre Kaloz]

On Tue, 26 Apr 2016 13:00:40 +0200, John Crispin <blo...@openwrt.org>  
wrote:





On 26/04/2016 12:59, Imre Kaloz wrote:

On Tue, 26 Apr 2016 12:55:50 +0200, John Crispin <blo...@openwrt.org>
wrote:


the maintainer of the target does not use patchwork. so they are not
applicable to be listed in patchwork. sorry i normally send an email to
the submitter informing him of this. i forgot to do so last night


"the maintainer" was told to ask jk for permissions and jk told him john
handles those.


Imre


last i asked you you said you dont use patchwork. and i was never told
after that, that you want to use patchwork. had i only known or been  
told.


If I would have said that, why would you tell me to ask jk for an account?  
Non sequitur..


Can I get that account then, please?


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

Re: [OpenWrt-Devel] [PATCH 0/4] omap 4.4, ehci, sdcard

[Imre Kaloz]

On Tue, 26 Apr 2016 12:55:50 +0200, John Crispin   
wrote:



the maintainer of the target does not use patchwork. so they are not
applicable to be listed in patchwork. sorry i normally send an email to
the submitter informing him of this. i forgot to do so last night


"the maintainer" was told to ask jk for permissions and jk told him john  
handles those.



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

Re: [OpenWrt-Devel] [PATCH 0/8] [ipq806x] Add basic support for Linksys EA8500

[Imre Kaloz]

Hi Adrian,

On Sat, 02 Apr 2016 01:48:22 +0200, Adrian Panella 
wrote:


Hi Imre,

networking seems to be working for me.
So far I have done only basic testing. Can access the router from lan
and wlan.
No permormance test done, though.

If you have a repo you can share with your patchset, I could gladly
compare to take advantage of both works.


I'll have time for this today, but the weird part is that comparing the  
dts I made and the one you submitted I see no difference when it comes to  
ethernet configuration.


Could you post your dmesg and the contents of the devinfo partition?


Thanks,

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

Re: [OpenWrt-Devel] [RFC 1/2] Add support for the apm821xx Device Target

[Imre Kaloz]

On Fri, 01 Apr 2016 15:26:46 +0200, Chris Blake <chrisrblak...@gmail.com>  
wrote:



Hey Imre,

On Fri, Apr 1, 2016 at 7:35 AM, Imre Kaloz <ka...@openwrt.org> wrote:

Hi Chris,

On Fri, 01 Apr 2016 03:46:09 +0200, Chris Blake  
<chrisrblak...@gmail.com>



+CONFIG_BLUESTONE=y



I doubt we support that here.



From my understanding, Bluestone is the dev board for the apm821xx, so
for dependencies shouldn't this be selected?


Nope, as we don't support it.


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

Re: [OpenWrt-Devel] [RFC 2/2] Add support for the Meraki MR24

[Imre Kaloz]

On Fri, 01 Apr 2016 03:46:10 +0200, Chris Blake   
wrote:



This patch adds support for the Meraki MR24 Access point to the apm821xx
target. More info on the device can be found at
https://wiki.openwrt.org/toh/meraki/mr24

Signed-off-by: Chris Blake 



--- /dev/null
+++ b/target/linux/apm821xx/dts/MR24.dts
@@ -0,0 +1,433 @@
+/*
+ * Device Tree Source for Meraki MR24 (Ikarem)
+ *
+ * Copyright (C) 2016 Chris Blake 
+ *
+ * Based on Cisco Meraki GPL Release r23-20150601 MR24 DTS
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   model = "Meraki MR24 Access Point";
+   compatible = "apm,bluestone";


This should be "meraki,ikarem" if that's the codename for the box.

diff --git  
a/target/linux/apm821xx/patches-4.4/700-powerpc_ibm_phy_add_ar8035.patch  
b/target/linux/apm821xx/patches-4.4/700-powerpc_ibm_phy_add_ar8035.patch


diff --git  
a/target/linux/apm821xx/patches-4.4/800-ppc4xx-rng-fix-crash-during-init.patch  
b/target/linux/apm821xx/patches-4.4/800-ppc4xx-rng-fix-crash-during-init.patch


These should be part of "1/2".


Thanks,

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

Re: [OpenWrt-Devel] [RFC 1/2] Add support for the apm821xx Device Target

[Imre Kaloz]

Hi Chris,

On Fri, 01 Apr 2016 03:46:09 +0200, Chris Blake 
wrote:


This adds a new target for PowerPC APM821xx (464-based) boards, as well
as adds support for the booke-wdt watchdog package.

Signed-off-by: Chris Blake 


Not bad at all for first try :)


diff --git a/include/target.mk b/include/target.mk
index 76fbd99..6d036a0 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -253,6 +253,7 @@ ifeq ($(DUMP),1)
 CPU_CFLAGS_8540:=-mcpu=8540
 CPU_CFLAGS_405:=-mcpu=405
 CPU_CFLAGS_440:=-mcpu=440
+CPU_CFLAGS_464:=-mcpu=464
   endif
   ifeq ($(ARCH),sparc)
 CPU_TYPE = sparc


These guys do have an FPU, so please go with CPU_CFLAGS_464fp:=-mcpu=464fp


--- /dev/null
+++ b/target/linux/apm821xx/Makefile
@@ -0,0 +1,30 @@
+#
+# Copyright (C) 2016 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License  
v2.

+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+
+ARCH:=powerpc
+BOARD:=apm821xx
+BOARDNAME:=AppliedMicro APM821xx
+CPU_TYPE:=464


464fp


+FEATURES:=squashfs nand rtc ramdisk


fpu


+CONFIG_BLUESTONE=y


I doubt we support that here.


+CONFIG_BOOKE=y
+CONFIG_BOUNCE=y
+CONFIG_CANYONLANDS=n


"is not set". Please refresh the config file using the buildsystem.


--- /dev/null
+++ b/target/linux/apm821xx/generic/target.mk
@@ -0,0 +1,12 @@
+#
+# Copyright (C) 2016 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License  
v2.

+# See /LICENSE for more information.
+#
+
+BOARDNAME:=Generic
+
+define Target/Description
+   Build firmware images for generic APM821xx based boards.
+endef


There's not reason to create any subtargets for now.




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

Re: [OpenWrt-Devel] [PATCH 0/8] [ipq806x] Add basic support for Linksys EA8500

[Imre Kaloz]

Hi Adrian,

On Fri, 01 Apr 2016 02:35:20 +0200, Adrian Panella   
wrote:



From: Adrian Panella 



This patchset adds support for the Linksys AC2600 EA8500 router.


Does networking work for you? I have a patchset for the ea8500 I didn't  
push because of that.



Thanks,

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

Re: [OpenWrt-Devel] OpenWRT ppc44x target & the APM821XX SoC

[Imre Kaloz]

Hi,

On Thu, 31 Mar 2016 12:19:36 +0200, Chris Blake   
wrote:



Yep, currently my apm821xx target on the repo is based on the 4.4
kernel, and has a few small patches in place for the ar8035 NIC, and a
patch for fixing the Crypto driver for the apm821xx hardware. [0]


Did you try to send these upstream?


I am also aware of another developer working on porting over another
device that uses this SoC, so it would be nice to know which path of
action is recommended as other PPC targets (ex, mpc85xx) have been
branched out in the past.



Apples and oranges ;) The rule of thumb is "as long as there are more
differences than similarities, it should be a separate target".


Awesome, will try and get this all drafted as a proper RFC then,
unless you already have one submitted somewhere for this new target?


Feel free to send an RFC, I won't find time to update mine for at least a  
few more days.



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

Re: [OpenWrt-Devel] OpenWRT ppc44x target & the APM821XX SoC

[Imre Kaloz]

Hi Chris,

On Thu, 31 Mar 2016 01:00:19 +0200, Chris Blake   
wrote:



Quick Question about the ppc44x target. I am currently working on
porting over a PowerPC Device that uses the APM821XX SoC (464-based)
but the closest current target would be ppc44x, which seems to be a
bit outdated and lacks support for some system level integration
(LED's, sysupgrade scripts, etc.). I was able to get OpenWRT up and
running by creating a new device target for this SoC, but I was
curious on the best way to get this merged upstream.

The device in Question is a Cisco Meraki MR24, which has a APM82181
800Mhz SoC, 128MB DDR2 RAM, and 2x Atheros PCIe wireless cards. The
current working code can be found at
https://github.com/riptidewave93/Openwrt-MR24 but I was curious on
which of the following is the best way to move forward:

1. RFC the current code (new device target for this SoC) for review.
2. Create a new apm821xx subtarget for the ppc44x target, and RFC for  
review.

3. Other ideas?


I also have some patches for the APM82181, which I can update to 4.4. Are  
you on 4.4 already?
In any case, the APM82181 is a PPC464 based core, which isn't the same as  
the 44x so it shouldn't be it's subtarget.



I am also aware of another developer working on porting over another
device that uses this SoC, so it would be nice to know which path of
action is recommended as other PPC targets (ex, mpc85xx) have been
branched out in the past.


Apples and oranges ;) The rule of thumb is "as long as there are more  
differences than similarities, it should be a separate target".



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

Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago

[Imre Kaloz]

On Fri, 18 Mar 2016 21:09:35 +0100, John Crispin   
wrote:





On 18/03/2016 21:02, Roman Yeryomin wrote:

On 18 March 2016 at 19:36, John Crispin  wrote:



On 18/03/2016 18:19, Roman Yeryomin wrote:

On 18 March 2016 at 15:32, John Crispin  wrote:


please use this svn server for now. it will be online for 4-6 weeks  
so
that people have time to migrate away from svn. i will send out a  
notice

1 week before we finally turn it of. please start migrating now.


if you do 10 things at once you forget to paste the url :-)

svn://svn.mein.io/openwrt


John, you just made people suffer for 4-6 weeks longer :)




i think you are mistaken, think before you post please.


Sorry, maybe it was way too sarcastic but IMO switching from svn to
git is fairly simple and there is nothing to dramatize.




sound easy to you. ask the person that spent several hours making tracd
work without anon svn last week. various systems that had been running
for years smoothly suddenly went down.


Sorry, but calling a decision sudden when it has been made public 2 years  
ago doesn't sound right. It wasn't my decision to move the public to git,  
now you are blaming that these services stopped running smoothly because  
they were still using public access to resources you decided to declare  
deprecated years ago.


While you like to blame SPOF, this is the prefect example when  
semi-distributed services go down as developers ignore decisions they have  
been part of.



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

Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago

[Imre Kaloz]

On Fri, 18 Mar 2016 03:40:25 +0100, Shankar Unni  
 wrote:



On Wed, Mar 16, 2016 at 1:53 AM, Karl Vogel  wrote:


Doesn't look like the SVN server is back yet either.

Are there any plans to resurrect the anon SVN server? Or should  
everybody

move to git.openwrt.org instead?



Yeah, I've been waiting for this, too (svn.openwrt.org).

It would be good to hear an official word from someone as to whether
this is ever going to come back up (i.e. is this only a delay?), or is
it a final decision to turn it off for good.

If it is going to be turned off for good, it would still be good to
bring it back up for at least a few weeks, to give people time to cut
away from it and transition their work and work flows..


Git is the recommended access to the sources since almost 2 years from now  
[1]. Info on SVN access has been removed from the dev wiki  page almost a  
year ago [2]. You should have planned your transition long ago..



Imre


[1]  
https://dev.openwrt.org/wiki/GetSource?=diff=18_version=17
[2]  
https://dev.openwrt.org/wiki/GetSource?=diff=21_version=22

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

Re: [OpenWrt-Devel] Any fix ETA or other info on the server hardware problems?

[Imre Kaloz]

On Sun, 28 Feb 2016 11:35:42 +0100, Hannu Nyman  wrote:

Ps. the updated downloads.openwrt.org works only half of the time.  
Roughly every second time the page load fails (until yesterday with 503  
error from nginx, today silently with empty page)


It works 100% of the time. You do 15+ concurrent connections, so you are  
getting throttled. Initially nginx replied with 503, it now replies with  
429 - your browser just doesn't handle that.



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

Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices

[Imre Kaloz]

Hi Daniel,

On Wed, 23 Dec 2015 07:58:59 +0100, Daniel Dickinson  
 wrote:


I am reworking this (requiring console login) as couple of packages for  
the packages feed, although it may require an image.mk or packages  
Makefile hook in order to embed an appropriate inittab into the image  
(since the inittab will need to be modified and we need to guarantee the  
correct order of actions; and inittab comes from base-files which is  
last thing done in the packages Makefile).


I hope the other devs will chime in, but FWIW I would make this enabled  
unconditionally across all targets. As we already have a way to do a  
"factory reset" using the reset button, IMHO failsafe should also enforce  
login passwords everywhere, including the serial console.



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

Re: [OpenWrt-Devel] [Patch] ipq806x: add support for Netgear D7800

[Imre Kaloz]

On Wed, 23 Dec 2015 14:12:00 +0100, Tathagata Das   
wrote:





-   r7500)
+   r7500 |\
+   d7800)
nand_do_platform_check $board $1
return $?;
;;
@@ -21,7 +22,8 @@
case "$board" in
AP148 |\
-   r7500)
+   r7500 |\
+   d7800)
nand_do_upgrade "$1"
;;
esac


Please follow the abc, please ;)


Index: trunk/target/linux/ipq806x/base-files/lib/ipq806x.sh
===
--- trunk/target/linux/ipq806x/base-files/lib/ipq806x.sh(revision
47890)
+++ trunk/target/linux/ipq806x/base-files/lib/ipq806x.sh(working
copy)
@@ -23,6 +23,9 @@
*"R7500")
name="r7500"
;;
+   *"D7800")
+   name="d7800"
+   ;;
esac
[ -z "$name" ] && name="unknown"


ditto


Index: trunk/target/linux/ipq806x/base-files/etc/board.d/01_leds
===
--- trunk/target/linux/ipq806x/base-files/etc/board.d/01_leds   (revision
47890)
+++ trunk/target/linux/ipq806x/base-files/etc/board.d/01_leds   (working
copy)
@@ -11,7 +11,8 @@
 board=$(ipq806x_board_name)
case "$board" in
-r7500)
+r7500 |\
+d7800)
ucidef_set_led_usbdev "usb1" "USB 1" "r7500:white:usb1" "1-1"
ucidef_set_led_usbdev "usb2" "USB 2" "r7500:white:usb3" "3-1"
ucidef_set_led_netdev "wan" "WAN" "r7500:white:wan" "eth0"
Index: trunk/target/linux/ipq806x/base-files/etc/board.d/02_network
===
--- trunk/target/linux/ipq806x/base-files/etc/board.d/02_network
(revision 47890)
+++ trunk/target/linux/ipq806x/base-files/etc/board.d/02_network
(working copy)
@@ -13,7 +13,8 @@
case "$board" in
 ap148 |\
-r7500)
+r7500 |\
+d7800)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
;;


ditto


Index:
trunk/target/linux/ipq806x/patches-3.18/801-ARM-qcom-add-Netgear-Nighthawk-X
4-D7800-device-tree.patch
===
---
trunk/target/linux/ipq806x/patches-3.18/801-ARM-qcom-add-Netgear-Nighthawk-X
4-D7800-device-tree.patch   (revision 0)
+++
trunk/target/linux/ipq806x/patches-3.18/801-ARM-qcom-add-Netgear-Nighthawk-X
4-D7800-device-tree.patch   (revision 0)
@@ -0,0 +1,381 @@
+--- a/arch/arm/boot/dts/Makefile   2015-09-22 18:30:09.033530282 +0530
 b/arch/arm/boot/dts/Makefile   2015-09-23 17:06:44.892947581 +0530
+@@ -362,6 +362,7 @@
+   qcom-ipq8064-ap148.dtb \
+   qcom-ipq8064-db149.dtb \
+   qcom-ipq8064-r7500.dtb \
++  qcom-ipq8064-d7800.dtb \
+   qcom-msm8660-surf.dtb \
+   qcom-msm8960-cdp.dtb \
+   qcom-msm8974-sony-xperia-honami.dtb


ditto


+--- a/arch/arm/boot/dts/qcom-ipq8064-d7800.dts 1970-01-01
05:30:00.0 +0530
 b/arch/arm/boot/dts/qcom-ipq8064-d7800.dts 2015-09-23
17:06:45.336947567 +0530
+@@ -0,0 +1,368 @@


This should be qcom-ipq8064-netgear-d7800.dts




++  chosen {
++  bootargs = "rootfstype=squashfs noinitrd";


I doubt this is needed.



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

Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices

[Imre Kaloz]

On Wed, 23 Dec 2015 17:27:37 +0100, Felix Fietkau <n...@openwrt.org> wrote:


On 2015-12-23 16:27, Bastian Bittorf wrote:

* Imre Kaloz <ka...@openwrt.org> [23.12.2015 16:22]:

>I'd hate to have some corner case result in bricked routers for
>people who have no means of recovering from a bad flash.

You can reflash from the bootloader all the time, we are talking
about userland here. IMHO this should be just a normal change, like
dropping telnet. Enforcing login should be on by default, specially
since if one forgets the password they can just reset everything to
defaults keeping the reset button pressed.


I am against asking for a password in failsafe mode:
failsafe is failsafe is failsafe.

You have to run mount_root which does _things_ and can break.

I completely agree with this. Failsafe needs to be robust.


Failsafe can be triggered both locally and through the network and gives  
straight root access. This doesn't make it robust, it makes it insecure.



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

Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices

[Imre Kaloz]

On Wed, 23 Dec 2015 17:32:06 +0100, Bastian Bittorf  
 wrote:


* Daniel Curran-Dickinson  [23.12.2015  
17:27]:

I'm implementing without mount_root - that means passwordless
failsafe unless user has preconfigured passwords in their image.
OTOH if they have configured passwords in their image then they will
be required.


ok, this sounds good.

while we are at it: what about including default private keys for SSH
till the real keys are generated? it can last several minutes on some
routers and it feels like the box is broken. also: if really something
goes wrong during key generating we can at least login.


So make it double unsafe - great idea ;)


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

Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices

[Imre Kaloz]

On Wed, 23 Dec 2015 13:43:14 +0100, Daniel Dickinson  
 wrote:


Oh, and I think that initially this should be default off configuration  
option that people who are able to flash firmware via bootloader in case  
of getting locked out encourage to test before pushing this as default.


I'd hate to have some corner case result in bricked routers for people  
who have no means of recovering from a bad flash.


You can reflash from the bootloader all the time, we are talking about  
userland here. IMHO this should be just a normal change, like dropping  
telnet. Enforcing login should be on by default, specially since if one  
forgets the password they can just reset everything to defaults keeping  
the reset button pressed.



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

Re: [OpenWrt-Devel] [PATCH 0/7] kirkwood: revamp Linksys EA3500 & EA4500 support

[Imre Kaloz]

On Sat, 07 Nov 2015 03:29:07 +0100, Claudio Leite   
wrote:



This patch set reworks support for the Linksys EA3500 and EA4500,
integrating significant amounts of code from the WRT1900AC port.

Previously these two routers were supported by flashing from the
bootloader and setting new boot commands. They can now be flashed
from the Linksys factory firmware and upgraded from within OpenWrt.
This also adds support for the Linksys dual-image firmware layout
and recovery mechanism.

These patches also transition from a single read-write UBIFS to
squashfs on UBI + UBIFS overlay.



Care to send a v2 with my requested changes at [1] and [2]? You don't have  
to handle the old bindings/boardnames, as this will be the first time you  
can flash OpenWrt from the webinterface -- people with old images have to  
have console and flash back to factory and reinstall anyways..



Thanks,

Imre

[1] http://www.spinics.net/lists/arm-kernel/msg458158.html
[2] http://www.spinics.net/lists/arm-kernel/msg458159.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broadcom Wireless AC Driver

[Imre Kaloz]

On Mon, 26 Oct 2015 10:50:41 +0100, John Crispin   
wrote:





This is where your good intentions likely will yield bad results.


intentionally breaking the license/law is not "good intentions" the fact
that he used a anonymous remailer just shows that he knew what he was
doing is wrong.


Agreed. Nuked the 3 attachments form the archives.


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

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Imre Kaloz]

On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
 wrote:




It should be easy possible to get funding from all the companies which
work with OpenWrt. Is this in option?


Not until we have a nonprofit organization as companies can't have tax  
deduction in exchange.. This is pretty much the main issue people from  
said companies brought up at the summit as well.



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

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Imre Kaloz]

On Tue, 13 Oct 2015 12:46:00 +0200, Sorin Burjan   
wrote:



Hello Kaloz,

is there any initiative to create a non-profit organization ?


We're looking into this as well other options ;)


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

Re: [OpenWrt-Devel] [PATCH 0/2] Add ATI IXP PATA driver to x86/64 target

[Imre Kaloz]

On Fri, 25 Sep 2015 10:02:07 +0200, Felix Kaechele  
 wrote:



Hi list,

within the Freifunk project in Germany we currently use very low cost  
thin-clients (FSC Futro S550) for VPN offloading.
Those thin-clients have an internal CF card (1GB) attached to the  
chipset's PATA controller that uses the arcane pata_atiixp driver.

This seems like an ideal storage option for booting the device from.

I would like to enable OpenWrt to boot from this CF card and therefor  
would need this driver to be built into the kernel.


If changes like these to the generic x86_64 target are not desireable  
the other option would be to create an own subtarget specifically for  
this device.


What do you think?


NAK. The x86-64 subtarget is free from legacy stuff and should remain that  
way. Looking at the specs of that thin client it can have either 1 or 2GB  
of ram, so it doesn't make much sense to use it in 64bits anyways. If  
changes are needed to run the generic x86 taget on it, please send patches  
for that.



Cheers,

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

Re: [OpenWrt-Devel] [PATCH 0/3] ipq806x: add NAND flash support

[Imre Kaloz]

On Fri, 07 Aug 2015 20:09:14 +0200, Felix Fietkau n...@openwrt.org wrote:


On 2015-08-07 18:50, Mathieu Olivari wrote:
Actually, I was asking myself the same questions yesterday. I was  
leaning
towards dts for the reasons you mention below as well; the problem is  
on ref
designs, there is no standard layout. The flash layout changes with  
time
(an AP148 with an old boot binary blob will have a different layout  
than the

same AP148 with a new boot image), sometimes with a certain application
(some boots will have an SMEM with 2 kernels  2 rootfs for dual
partitioning). For this reason, and on ref designs, it'd be easier to  
have
one dts and the kernel adapting at run-time, than multiplying the dts  
files

and having to pick the right one based on your current SMEM content.


Well, there's no reason to try to support old versions or nonstandard  
designs upstream. You just have to pick the one you consider upstream  
version. For what you are looking for, you might want to take a look at  
device tree overlays.


I would agree that it's the exception though; on most retail routers,  
you

would have one SMEM per SKU, i.e. one layout per dts.

I'm thinking the most flexible way would probably to have the  
opportunity in

dts to select between dynamic smem partitioning, or regular fixed
partitioning. Not sure if something like this has ever been done in the
past; but we could explore it.

The bcm53xx target in OpenWrt works like that. The mtd driver specifies
two partition parsers, first ofpart, then a custom one.
If ofpart fails to find any partitions, the custom one gets to specify
the layout. We could probably make use of something like that for ipq as
well.


Agreed, but I'm afraid 3rd party vendors will miss-use that as usual.


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

Re: [OpenWrt-Devel] [PATCH 05/13] ramips: use consistent naming scheme for LEDs, for various manufacturers

[Imre Kaloz]

On Sun, 26 Jul 2015 18:24:30 +0200, Piotr Dymacz pep...@gmail.com wrote:


For some boards in ramips (and other targets) naming scheme for LEDs is:
manufacturer:color:led-name, but there are many other boards which  
don't

follow this approach.


The upstream convention is device:color:led-name. So actually, the wrong  
way is where we do the other way around.



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

Re: [OpenWrt-Devel] [PATCH 0/2] mac80211: Update QCA9880 firmware (ath10k)

[Imre Kaloz]

On Thu, 25 Jun 2015 20:59:19 +0200, Matti Laakso malaa...@elisanet.fi  
wrote:




On 22/06/15 20:19, Matti Laakso wrote:
/ These patches backport the new FW API v5 to ath10k
// (upstream commits 8348db2, 53513c3, and dc3632a)
// and change mac80211 to use the new firmware.
//
//
/Could you also update
target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k?
See https://patchwork.ozlabs.org/patch/466945/ and possibly
https://patchwork.ozlabs.org/patch/481472/

Thanks,
Stijn


Hi,

That seems like a burden to maintain. Do I understand correctly that the
device has valid data in the PCIe card EEPROM (so it is not necessary to
create a file with the calibration data in 81_load_ath10k_board_bin),
but the MAC is incorrect? Is the MAC completely bogus (like same for all
devices), or valid but just not what it says on the router cover? If the
latter, I'd like to drop the whole script altogether and just live with
a different MAC.


On the dgl5500 the mac in the eeprom is the same on all devices (and iirc  
it's the default mac the firmware also uses). Patching it to the right one  
in the firmware file is what happens in 82_patch_ath10k.



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

Re: [OpenWrt-Devel] [PATCH 0/2] mac80211: Update QCA9880 firmware (ath10k)

[Imre Kaloz]

On Fri, 26 Jun 2015 10:11:28 +0200, Martin Blumenstingl  
martin.blumensti...@googlemail.com wrote:



Hi Imre,

On the dgl5500 the mac in the eeprom is the same on all devices (and  
iirc
it's the default mac the firmware also uses). Patching it to the right  
one

in the firmware file is what happens in 82_patch_ath10k.

I am not very familiar with ath10k, but why are you not patching the
calibration data instead (like other devices do it in
target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin)?


Because the calibration data is not stored on the flash like on those, but  
on the PCIe card's eeprom.



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

Re: [OpenWrt-Devel] [PATCH v2] generic/4.0: update to 4.0.4

[Imre Kaloz]

On Sun, 24 May 2015 01:51:51 +0200, Daniel Golle dan...@makrotopia.org  
wrote:



Update kernel sources and refresh some patches.

Signed-off-by: Daniel Golle dan...@makrotopia.org


Commited as 45761.


Thanks,

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

Re: [OpenWrt-Devel] [PATCH] generic/4.0: bump to version 4.0

[Imre Kaloz]

On Tue, 21 Apr 2015 09:56:31 +0200, Daniel Golle dan...@makrotopia.org  
wrote:



Linux 4.0 was released on 2014-04-12

Signed-off-by: Daniel Golle dan...@makrotopia.org


Merged in 45559 with refreshing the patches.


Thanks,

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

Re: [OpenWrt-Devel] Dark Destroyer

[Imre Kaloz]

On Wed, 08 Apr 2015 00:51:11 +0200, edgar.sol...@web.de wrote:

i am really wondering if the core devs are following this or even give a  
damn. didn't read anything after John's last mail declaring Dirty  
Diamond the winner. Felix, John, anybody?


Well, given I'm the one to blame for all the older names except for  
Whiterussian, I rather not vote :)


imho
Dark Destroyer sounds like a name a 12ish guy would come up with (not to  
mention how awful Malibu + SoCo sounds). And I don't think we want to  
destroy anything really, we're building here.


Dirty Diamond immediately lines up with the blood diamonds of  
Angola/Congo/etc for me.. Oh, and I actually tasted that recipe.. Well, go  
figure..


Designated Driver fits the best as a name, but it's a mocktail (but at  
least tastes good).


I would (for other obvious reasons) skip DD.
/imho


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

Re: [OpenWrt-Devel] OpenWrt release name

[Imre Kaloz]

On Mon, 06 Apr 2015 12:54:53 +0200, bkil bk.il.hu+ibla_q...@gmail.com  
wrote:



+1 on Designated Driver. Migrating or upgrading to OpenWrt is the
sober choice. I didn't find the other two meaningful or relevant.

I think community polls should be organized in two phases. The first
one should gather ideas, while the second one should gather votes.


I agree with all of the above. Felix, could we make a new poll which  
allows adding new suggestions? We could let it run for a week, then the  
top 3 could make it into the finals.



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

Re: [OpenWrt-Devel] [PATCH v2] [package] mwlwifi: generate TX_STATUS event on transmitting auth, associate, and reallocate responses

[Imre Kaloz]

On Fri, 20 Mar 2015 03:28:23 +0100, Ian Kent ra...@themaw.net wrote:

snip


I think the process is that we should send changes to the component
maintainer, cc OpenWrt-devel, since maintainers might miss the post.

Imre, is this change acceptable, what other changes are needed, should
Pat re-submit this afresh or is what's here OK?


Patches against mwlwifi should be sent there, but a new version has been  
released already which has this fix among a lot of others. I'm waiting for  
a few people who had issues to confirm the test image I've uploaded works  
for them before pushing the changes to trunk.



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

Re: [OpenWrt-Devel] [PATCH] kernel: bump to 3.14.35, 3.18.9, 3.19.1 and 4.0-rc4

[Imre Kaloz]

On Tue, 17 Mar 2015 12:28:44 +0100, Daniel Golle dan...@makrotopia.org  
wrote:



Signed-off-by: Daniel Golle dan...@makrotopia.org
---
 include/kernel-version.mk | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)



A bit hard to think no patches {generic,target} needs refreshing ;) Please  
send a v2 with those included.



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

Re: [OpenWrt-Devel] [PATCH v2] mvebu: set WRT1900AC WAN interface MAC address

[Imre Kaloz]

On Sun, 22 Feb 2015 15:17:14 +0100, Claudio Leite lei...@staticky.com  
wrote:



Toggles the LA bit on the WAN interface.

Signed-off-by: Claudio Leite lei...@staticky.com


Merged in 44508.


Thanks,

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

Re: [OpenWrt-Devel] [PATCH 2/2] mvebu: set default WRT1900AC switch config

[Imre Kaloz]

On Sun, 22 Feb 2015 02:20:21 +0100, Claudio Leite lei...@staticky.com  
wrote:



This sets 'enable_vlan' and thus uses 802.1q
VLANs, but without tagging on either interface.

Signed-off-by: Claudio Leite lei...@staticky.com


Committed as 44509.


Thanks,

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

Re: [OpenWrt-Devel] [PATCH] mvebu: fix WRT1900AC ubinized images

[Imre Kaloz]

On Sat, 14 Feb 2015 18:18:56 +0100, Claudio Leite lei...@staticky.com  
wrote:



The VID header offset must be specified explicitly.

Signed-off-by: Claudio Leite lei...@staticky.com


Added with some more explanation in the commit log as r44455.


Thanks,

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

Re: [OpenWrt-Devel] [PATCH] mvebu: Enable the A385 AP on 3.19

[Imre Kaloz]

On Thu, 05 Feb 2015 15:43:38 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:


In order for the image to be built, some patches need to be ported to  
3.19.


Add the relevant patches. Note that most of them (if not all) should be  
merged

in 3.20, removing the need to carry them on then.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com


Thanks, merged it as 44267.


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

Re: [OpenWrt-Devel] [PATCH v2 0/8] mvebu: Fix flash support and support for A38x

[Imre Kaloz]

Hi Maxime,

On Wed, 04 Feb 2015 15:36:58 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:


snip


It builds up on that to then introduce support for two Armada
385-based evaluations boards from Marvell.

Let me know what you think,
Maxime


Thanks for taking time to do this right :) I've merged them, and except  
for the last patch I've also made sure to do them for 3.19 as well. Please  
send a patch for the 385 db ap support on .19, too.



Cheers,

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

Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash

[Imre Kaloz]

Hi,

On Sun, 25 Jan 2015 18:06:03 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:



Sure, but please implement UBI on NOR as a generic solution.


What do you mean? It already works quite well (with that patch applied
and the NOR sub-profile), so I'm not sure I have to implement
anything, be it generic or not.


I've meant to make it generic, like the squashfs/ubfs/etc images so other  
targets can use it, too.



The A385-RD board has a much smaller SPI-NOR (16MB) though, so we
could use jffs2 there, but I wasn't seeing much point at creating a
whole new layout just for a single board.

I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you
satisfied with the NAND support? Just to know if I can continue to
model the NOR stuff on that.

As I've written in the other mail, I'm mostly happy with it, but please  
make

sure you don't hardcode available profiles but parse them.


If we don't plan on supporting building single sub-profiles like
ar71xx, I'm not even sure that we need to parse anything, we can just
loop over the sub-profiles list in any case.


I think supporting that could be handy so users (and people at Marvell)  
can just build what they want.



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

Re: [OpenWrt-Devel] [PATCH 8/9] mvebu: Add the Armada 385 Reference Design support

[Imre Kaloz]

On Fri, 16 Jan 2015 16:23:43 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:



Hi Imre,

On Wed, Jan 14, 2015 at 12:50:55PM +0100, Imre Kaloz wrote:

On Tue, 13 Jan 2015 16:56:45 +0100, Maxime Ripard
maxime.rip...@free-electrons.com wrote:

++  partition@2 {
++  label = data;
++  reg = 0x60 0xa0;
++  };
+   };
+   };
+

This one should be called rootfs. The image/Makefile change should be  
part

of the UBI on NOR discussion/patch, so please make that one a separate.


You mean a separate patch, right?

Separated from what? The rest of the serie? This patch is pretty
standalone by itself.


Sorry, I wanted to say that one patch should add the partitions and  
another should be the image/Makefile change, given the first is likely to  
be upstreamed.



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

Re: [OpenWrt-Devel] [PATCH 8/9] mvebu: Add the Armada 385 Reference Design support

[Imre Kaloz]

On Fri, 16 Jan 2015 16:52:05 +0100, Thomas Petazzoni  
thomas.petazz...@free-electrons.com wrote:



Dear Imre Kaloz,

On Fri, 16 Jan 2015 16:38:47 +0100, Imre Kaloz wrote:


 Separated from what? The rest of the serie? This patch is pretty
 standalone by itself.

Sorry, I wanted to say that one patch should add the partitions and
another should be the image/Makefile change, given the first is likely  
to

be upstreamed.


I am not sure the specific partitioning used by OpenWRT is something we
want to upstream in the mainline kernel. To me, the choice made by
Maxime of having a separate kernel patch to do that is the right
choice, since we're not sure we want to upstream specifically this
partitioning in mainline.


Judging from the patch mainline has nothing defined, and if it ever will  
have, we'll end up patching that.. Anyways, if Maxime migrates this to the  
MTDSPLIT stuff, we'll have only u-boot and firmware.



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

Re: [OpenWrt-Devel] Is Linksys/Belkin lying (again) about being open source (WRT1200AC router) ?

[Imre Kaloz]

On Wed, 14 Jan 2015 16:05:33 +0100, valent.turko...@gmail.com  
valent.turko...@gmail.com wrote:



Linksys/Belking marketing is again doing one thing and saying another?

This time they say that WRT1200AC router is open source:
http://www.zdnet.com/article/ces-2015-linksys-1200ac-an-inexpensive-open-source-802-11ac-wi-fi-router/

I have tracked progress with WRT1900AC and saw how they failed to give us
open source driver, so I hope that this time they will actually keep  
their

(marketing) promise.


Marvell released a new wifi driver at the end and they are working on  
fixing up the reported bugs.



I really, really, really hope that this time they have reached out and
contacted any of you OpenWrt developers and that we will get truly open
source driver from them.

So please let us know if any of you have heard anything regarding  
WRT1200AC

router and it's drivers.


I'll work on the support for that unit, don't worry :)


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

Re: [OpenWrt-Devel] [RFC] [mvebu] WRT1900AC syscfg as overlay

[Imre Kaloz]

Hi Mark,

On Tue, 13 Jan 2015 22:18:13 +0100, mark milburn  
mark.a.milb...@gmail.com wrote:



I believe this is the appropriate forum for discussing this.  Let me
know if this is not the case.

I think that employing the syscfg partition as the overlayfs is not
useful for this device, and for at least one case, harmful.

The current setup that allows for a primary and alternate firmware
image to be loaded is useful, it adds insurance if you aren't using
the squashfs failsafe.  However:

1.  If a configuration problem prevents the device from booting, or
renders the device effectively inaccessible, booting to the alternate
image may not allow the device to be recovered.  I think this negates
the utility of having an alternate image.



2.  One cannot test two different configurations effectively using two
different boot images.

Provided it does not affect the ability of a user to flash his or her
firmware back to a manufacturer image, I would suggest that mtdparts
be redefined and syscfg removed.


Mainline OpenWrt doesn't use syscfg as the overlay, we only use it to  
store the backup tarfile (if you choose to keep it) upon sysupgrading.



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

Re: [OpenWrt-Devel] [PATCH 2/9] mvebu: Switch to the generic mkuimage macro

[Imre Kaloz]

Thanks, applied in 43969.


Imre

On Tue, 13 Jan 2015 16:56:39 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:



The mvebu image makefile define something almost identical to the generic
implementation found in include/image.mk.

Switch to this implementation.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
 target/linux/mvebu/image/Makefile | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/target/linux/mvebu/image/Makefile  
b/target/linux/mvebu/image/Makefile

index f265dc43d25d..6e00346fe29a 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -24,15 +24,12 @@ KDIR_TMP:=$(KDIR)/tmp
UIMAGE:=$(BIN_DIR)/$(IMG_PREFIX)-uImage
-define Image/Build/MkuImage
-	mkimage -A arm -O linux -T kernel -a $(LOADADDR) -C none -e  
$(LOADADDR) \

-   -n 'ARM OpenWrt Linux-$(LINUX_VERSION)' -d $(1) $(2);
-endef
-
 define Image/Build/DTB
cp $(KDIR)/zImage$(2) $(KDIR)/zImage$(2)-$(1);
cat $(DTS_DIR)/$(1).dtb  $(KDIR)/zImage$(2)-$(1);
-	$(call  
Image/Build/MkuImage,$(KDIR)/zImage$(2)-$(1),$(KDIR)/uImage$(2)-$(1))

+   $(call Image/BuildKernel/MkuImage, \
+   none, $(LOADADDR), $(LOADADDR), \
+   $(KDIR)/zImage$(2)-$(1), $(KDIR)/uImage$(2)-$(1))
cp $(KDIR)/uImage$(2)-$(1) $(UIMAGE)$(2)-$(1);
 endef

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

Re: [OpenWrt-Devel] [PATCH 1/9] mvebu: Replace the padjffs2 call by the generic definition

[Imre Kaloz]

Thanks, applied in 43968.


Imre

On Tue, 13 Jan 2015 16:56:38 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:


The mvebu image Makefile directly calls the padjffs2 utility, while  
there's an

generic make function to do just that. Switch to it

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
 target/linux/mvebu/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/mvebu/image/Makefile  
b/target/linux/mvebu/image/Makefile

index 92571e215342..f265dc43d25d 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -44,7 +44,7 @@ define Image/BuildKernel
 endef
define Image/Build/squashfs
-   $(STAGING_DIR_HOST)/bin/padjffs2 $(KDIR)/root.squashfs 128
+   $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
 	$(foreach nandboard,$(NANDBOARDS),$(call  
Image/Build/UbinizeImage,$(nandboard),,squashfs,$(UBI_OPTS));)

( \
dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \

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

Re: [OpenWrt-Devel] [PATCH 9/9] mvebu: Add Armada 385 DB AP support

[Imre Kaloz]

On Tue, 13 Jan 2015 16:56:46 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:


+diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts  
b/arch/arm/boot/dts/armada-385-db-ap.dts

+index 02db04867d8f..2a58443e2504 100644
+--- a/arch/arm/boot/dts/armada-385-db-ap.dts
 b/arch/arm/boot/dts/armada-385-db-ap.dts
+@@ -134,6 +134,21 @@
+   marvell,nand-keep-config;
+   marvell,nand-enable-arbiter;
+   nand-on-flash-bbt;
++
++  mtd0@ {
++  label = U-Boot;
++  reg = 0x 0x0080;
++  };
++
++  mtd1@0080 {
++  label = uImage;
++  reg = 0x0080 0x0080;
++  };
++
++  mtd2@0100 {
++  label = Root;
++  reg = 0x0100 0x3f00;
++  };
+   };
+   };
+


I think this should be u-boot, kernel and (at least in OpenWrt), ubi.


Thanks,

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

Re: [OpenWrt-Devel] [PATCH 7/9] mvebu: Switch to 3.18

[Imre Kaloz]

Dopped this one, mvebu gained initial 3.18 support in r41232 and already  
uses that by default since r43893.



Imre

On Tue, 13 Jan 2015 16:56:44 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:


The 3.16 kernel introduced support for the A38x SoC family. In order to  
support

them, switch to the newer 3.18 kernel.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
 target/linux/mvebu/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/mvebu/Makefile b/target/linux/mvebu/Makefile
index 8dd0e617143e..724e6ed75e7e 100644
--- a/target/linux/mvebu/Makefile
+++ b/target/linux/mvebu/Makefile
@@ -14,7 +14,7 @@ CPU_TYPE:=cortex-a9
 CPU_SUBTYPE:=vfpv3
 MAINTAINER:=Imre Kaloz ka...@openwrt.org
-KERNEL_PATCHVER:=3.14
+KERNEL_PATCHVER:=3.18
include $(INCLUDE_DIR)/target.mk

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

Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash

[Imre Kaloz]

Maxime,

On Tue, 13 Jan 2015 16:56:40 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:



Some devices out there only have a NOR flash to store the rootfs on.

While using UBI is arguable on this kind of NAND, this is something that  
should

be supported.



Could you explain me, why would we want that? For NOR we use  
squashfs+jffs2 everywhere.



Thanks,

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

Re: [OpenWrt-Devel] [PATCH 8/9] mvebu: Add the Armada 385 Reference Design support

[Imre Kaloz]

On Tue, 13 Jan 2015 16:56:45 +0100, Maxime Ripard
maxime.rip...@free-electrons.com wrote:


++  partition@2 {
++  label = data;
++  reg = 0x60 0xa0;
++  };
+   };
+   };
+


This one should be called rootfs. The image/Makefile change should be  
part of the UBI on NOR discussion/patch, so please make that one a  
separate.



Thanks,

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

Re: [OpenWrt-Devel] [PATCH 4/9] mvebu: Add sub-profiles

[Imre Kaloz]

Hi Maxime,

On Tue, 13 Jan 2015 16:56:41 +0100, Maxime Ripard  
maxime.rip...@free-electrons.com wrote:



+$(eval $(call MultiProfile,Generic,$(PROFILES_LIST)))
+$(eval $(call MultiProfile,Evalboards,$(PROFILES_LIST)))


Profile names should be sourced from the profiles.

-	$(foreach nandboard,$(NANDBOARDS),$(call  
BuildSysupgrade,$(1),$(nandboard));)

+   $(call Image/Build/Profile/$(PROFILE)/BuildSysupgrade,$(1))


UBI and BuildSysUpgrade is there for NAND only.

On boards with nor (unless you come up with a really good reason to hack  
UBI) you should stick to squashfs+jffs2. Also, each NOR based board should  
have firmware partition and use the OpenWrt MTDSPLIT framework and  
should have a single, flashable firmware image file created instead of  
separate uImage+rootfs stuff.



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

Re: [OpenWrt-Devel] [PATCH] Initramfs image copied to bin for malta builds

[Imre Kaloz]

On Mon, 12 Jan 2015 21:36:16 +0100, Eric Schultz  
eschu...@prplfoundation.org wrote:


Malta ramdisk images are no longer copied to output due to a recent  
change.

This change reimplements copying of ramdisk images for Malta builds.


Merged in r43970, thank you.


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

Re: [OpenWrt-Devel] WRT1900AC - Available firmwares ?

[Imre Kaloz]

Hi,

On Thu, 08 Jan 2015 17:36:40 +0100, Fernando Frediani fhfredi...@gmail.com 
wrote:


Hi all,

Does anyone here have a Linksys WRT1900AC (that fiasco that suppose to
be the new generation of WRT54G) ?

I got one a while ago and have been following the firmware development
for it directly with Belkin people and on the URL -
https://github.com/wrt1900ac/opensource/tree/master/Barrier-Breaker but
that showed to be a total failure as they completely abandoned the
project (GitHub latest update is 6 months old and they don' reply to
emails anymore).

Many here might have seen all discussions around the subject during the
initial phase of development especially regarding the open-source
firmware of their wireless driver, which so far (as far as I know)
is/was still a binary.


OpenWrt support the Mamba for over 7 months now, but we didn't have a wireless 
driver. Marvell released an open source driver for that chipset to this list 
just before Christmas.


I have been however looking into the OpenWRT Snapshot and can see the
mvebu folder with similar files than Linksys GitHub -
http://downloads.openwrt.org/snapshots/trunk/mvebu/
Plus with the information on the wiki -
http://wiki.openwrt.org/toh/linksys/wrt1900ac that the wireless driver
has been finally released and the issue 'seems' to be resolved I guess.

Can anyone confirm this one downloaded from OpenWRT works for WRT1900AC
compared to any of the 3 mentioned on the wiki ?


Anyone can edit the wiki so don't take anything there written in stone. Trunk 
works on it, but with any new driver, you can run into issues.


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

Re: [OpenWrt-Devel] WRT1900AC - Available firmwares ?

[Imre Kaloz]

On Thu, 08 Jan 2015 20:10:28 +0100, Fernando Frediani fhfredi...@gmail.com 
wrote:


I have just upgraded it with your firmware. Works fine so far for most
of things. Actually some stuff is better than before.


Glad to hear that :)


I will proceed with more tests, specially the ones I had been doing and
reported back to Belkin a while ago to make sure they are gone.

Is there any GitHub or anywhere to report the findings to ?


If it's related to core stuff, the OpenWrt bug tracker is the way to go, if the 
wifi driver, creating a ticket on github.com/kaloz/mwlwifi is what you're 
looking for.


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

Re: [OpenWrt-Devel] [PATCH][mvebu] WRT1900AC mvneta fix vlan tagging

[Imre Kaloz]

On Wed, 24 Dec 2014 05:07:33 +0100, Mark Milburn mark.a.milb...@gmail.com 
wrote:


This is a 3.14.x backport of:
mvneta: Fix TSO and checksum for non-acceleration vlan traffic

Fixes vlan tagging on SoC interfaces for the WRT1900AC.  Useful
when using mvsw6171 driver.

Here's hoping I didn't foul up the patch format this time.

Signed-off-by: Mark Milburn mark.a.milb...@gmail.com


Mark,

Merged it locally, I'll push it later. Next time please mention the upstream 
commit(s), too :)

For the record, this is 817dbfa5d1bc276a72c1a577310382008e8aca0a + 
2d39d120781a5770573dc6ed672a5a562f541aea.


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

Re: [OpenWrt-Devel] Current state of extroot, how to use it, what about ubi(fs)

[Imre Kaloz]

On Tue, 16 Dec 2014 16:06:27 +0100, Gergely Kiss mail.g...@gmail.com wrote:

Please don't top-post.


Sorry, I haven't read that post earlier.

So, is this simply about mounting an additional UBIFS partition at boot time?

If so, I believe the best solution would be to extend the
functionality of fstab with a simple (shell) script, as suggested in
the fstab wiki:

BTRFS, JFS, *UBI* [...] are not supported in /etc/config/fstab. Use
manual scripting.

Would that be possible?


Regards,
Gergely

On 16 December 2014 at 14:39, Flávio Silveira f...@terra.com.br wrote:


On 16/12/2014 11:23, Gergely Kiss wrote:


Hi Rafał,

please allow me to comment on your 2nd point as I was the one who
recently published the patch to make extroot functionality work with
UBIFS.

It seems that if there isn't rootfs MTD partition,
then the code will look for rootfs UBI volume. The same applies to
the rootfs_data.

That's correct.

But what if my serial flash contains rootfs + rootfs_data
partitions and I still want to use some UBI volume on another flash
(NAND one)?

I'm not sure I understand what you mean here. Are there any devices
out there with multiple flash chips on-board? As far as I know, UBI
cannot work on top of block devices (eg. USB flashes, SD cards), only
raw flash chips so I can't really imagine what exact use-case you
mean. Could you please clarify?


Thanks,
Gergely


On 16 December 2014 at 11:00, Rafał Miłecki zaj...@gmail.com wrote:


I've spent few hours today trying to understand extroot. I've failed :(

Of course I was trying to use wiki pages:
http://wiki.openwrt.org/doc/howto/extroot
http://wiki.openwrt.org/doc/uci/fstab

1) Main question
Is the following sentence true at all?


The configuration of extroot is very simple and is done entirely in
/etc/config/fstab.


It seems that /etc/init.d/fstab uses block umount and block mount
only. I was reading the source code (fstools-2014-12-15/block.c) and
it seems that block mount doesn't really handle extroot at all.

I think some kind of extroot support is provided in block extroot,
but I don't fully understand it. It seems to be looking for partitions
rootfs and then rootfs_data ignoring whatever is set in
/etc/config/fstab. If mount extroot is really supposed to be used,
is there any way to point some external device (without MTD
partitions) as extroot? I got confused.

2) UBI and UBIFS support

I guess it's too new to be documented and I don't understand it much
from the code. It seems that if there isn't rootfs MTD partition,
then the code will look for rootfs UBI volume. The same applies to
the rootfs_data.
But what if my serial flash contains rootfs + rootfs_data
partitions and I still want to use some UBI volume on another flash
(NAND one)?

--
Rafał


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



Hi,

  I think this is where this discussion started and Rafal explains a bit
more about the hardware:
https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029717.html

Regards,
  Flavio


Rafal, what about mtdconcat?


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

Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu

[Imre Kaloz]

Hi,

On Thu, 09 Oct 2014 17:10:25 +0200, Maxime Ripard 
maxime.rip...@free-electrons.com wrote:


This is the second version of my rather big changes to support the
3.16 kernel, and more specifically on the mvebu SoCs.


snip

Thanks for looking into this :) I already had some work done for the same, I'll 
take a look and merge it with your patches.


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

Re: [OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox

[Imre Kaloz]

Hi,

On Thu, 09 Oct 2014 17:59:25 +0200, Maxime Ripard 
maxime.rip...@free-electrons.com wrote:


This patch adds a new profile for the Mirabox, and fixes a few things
along the way, mostly because of the Mirabox NAND page size that
differs from the other mvebu boards (and most of the boards supported
by OpenWRT apparently).


At first look they look fine, except the UBI* options in the profiles. We 
always want to build images for all boards, so I would keep those in the image 
Makefile and keep the profiles for the bare minimum like on other targets.


Cheers,

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

Re: [OpenWrt-Devel] naming for new subtarget in mpc83xx

[Imre Kaloz]

Hi Claudio,

On Tue, 23 Sep 2014 09:44:03 +0200, Claudio Thomas c...@xmodus-systems.de 
wrote:


I would like to add a new device to /target/linux/mpc83xx witch needs a
special kernel.


In what way is it special? Why can't the same kernel support your board as well?

Last time you've said you are going to re-analyse the problem ;)


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

Re: [OpenWrt-Devel] naming for new subtarget in mpc83xx

[Imre Kaloz]

Hi Claudio,

On Tue, 23 Sep 2014 11:10:17 +0200, Claudio Thomas c...@xmodus-systems.de 
wrote:

snip


The RB600/RB300 uses a MPC8377, the XM1700 uses a MPC8306. They are
quite similar, but not equal.


Well, RB333 is MPC8321, RB600 is MPC8323 and we support the MPC8377EWLAN board, 
which is MPC8377E :)


The main problem is, that I need some patches for the MPC8306.
Two examples based on the QE
(http://cache.freescale.com/files/netcomm/doc/ref_manual/QEIWRM.pdf):
* The QUICC Engine Block is different on the MPC8306 comparing to other
MPC83xx, it does not support certain range of snum thread (Table 4-29.
SNUM Table comment 7 on page 297), multiplex timers on page 299.

Another example (/arch/powerpc/platforms/83xx/mpc83xx.h)
 #define MPC837X_SICRL_USB_ULPI 0x5000
 #define MPC837X_SICRL_USBB_MASK0x3000
+#define MPC8306_SICRL_USB_ULPI 0x
+#define MPC8306_SICRL_USB_MASK 0x003C
...
 #define MPC837X_SICRH_SPI_MASK 0x0003
 #define MPC837X_SICRH_SD   0x0001
+#define MPC8306_SICRH_USB_MASK 0x0F00F300
+#define MPC8306_SICRH_USB_ULPI 0x

My conclusion is, that this changes need to have a flag in the config
for the MPC8306 that can not be in the config for the rb600.
I would also appreciate to use only one config, but I don't know how I
could patch the kernel to fit for both.
I'm open for suggestions.


MPC8306 should be the same PowerQUICC II Pro family and seems pretty similar 
to MPC8308. Do you have a patch for the board to check?


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

Re: [OpenWrt-Devel] [RFC] TI/Intel Puma5 target.

[Imre Kaloz]

On Mon, 18 Aug 2014 09:10:24 -0700, Michael Richardson m...@sandelman.ca 
wrote:



José Vázquez ppvazquez...@gmail.com wrote:
 José Vázquez ppvazquez...@gmail.com wrote:  According to the info i
 could find the cpu is a 400MHz arm1176  (ARMv6k) with VFP and C55x
 DSP for VoIP, that runs in big endian mode;  seems that shares some
 features with TI Davinci, OMAP2 and/or Sitara.

 Seems to be too slow to operate enough counters for fq_codel, even if
 somehow it's fast enough to move 100Mb/s+ of traffic.

 I have no idea how much fast it is, and you are right about unable to
 move more than 100Mbps, but take in mind that OpenWRT is very versatile
 and a lot of people use routers for other purposes than routing, as you
 know.  If i had enough skills i would try to port it to kernel 3.3 or
 3.10, but i hadn't (mainly because i don't have enough knowledge of ARM
 and the Puma5 code is a bit strange with a lot of Pal files that i
 don't know what they are).

Sorry, wrong list!!!
Over on the cerowrt-devel list, we are looking for the replacement for the
Netgear 3800 on which to focus fq_codel/bufferbloat work, as the 3800 can't
reach much beyond 50Mb/s, which has become a problem as many have VDSL2/FTTH.


Let's hope the wifi situation gets cleaned up with the WRT1900AC. That has 
enough power for anything you throw at it :)


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

Re: [OpenWrt-Devel] [PATCH] [mpc83xx] add menuconfig-option for rb333 and rb600

[Imre Kaloz]

Hi,

On Fri, 25 Jul 2014 11:34:49 +0200, Claudio Thomas c...@xmodus-systems.de 
wrote:


Hi, as reaction of the following email:
On 15.07.2014 15:05, Claudio Thomas wrote:

Subject: [OpenWrt-Devel] When to use Target Profile or Subtarget

Hi,
I'm adapting the Freescale MPC83xx platform, so that multiple devices
can be selected.
Actually the following boards are in use, but hard-coded over files or
file-patches and not selectable be menuconfig
- RouterBOARD 333
- RouterBOARD 600
This makes it unnecessary difficult to add new devices...

...I've wrote the in the subject mentioned patch (2014-07-21 15:48:12).
Is there a reason why the patch is not committed yet?
Should I change anything, like make only one profile for rb333+rb600 or
is the coding style not as whiched?

I would be glad to adapt the patch to be conform to the needs of OpenWrt.
My goal is, that I would like to add the following boards:
http://www.xmodus-systems.de/en/terminals/routers.html
But to add them, it is necessary that the compilation of the kernelnames
dtbImage.rb600 dtbImage.rb333 needs to be conditional. Actually they
are unconditional.

So, I'm glad to hear your comments what I could make better ob my
changes or maybe also, why I should not change it at all.


I see no technical reason why would it be required to make them conditional nor 
why would it be difficult to add new devices - so what are your problems?


Best regards,

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

Re: [OpenWrt-Devel] Support for Nanostation M2 devices

[Imre Kaloz]

On Tue, 03 Jun 2014 14:28:25 +0200, valent.turko...@gmail.com 
valent.turko...@gmail.com wrote:


Another confirmation that they have switched boards and probably also
SoC, from Ubnt forums:
https://community.ubnt.com/t5/airMAX-General-Discussion/Differencens-between-XM-XW-and-TI-firmwares/td-p/752296/page/2

So nobody from dev team has worked on these new Ubiquiti devices?


Correct, none of us have access to these new versions right now.


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

Re: [OpenWrt-Devel] SoC RT5350F based wireless socket / power plug

[Imre Kaloz]

On Mon, 02 Jun 2014 11:54:33 +0200, Bastian Bittorf bitt...@bluebottle.com 
wrote:


because i was getting a lot of private mails regarding the inside,
here are some pictures. i will get better ones, if the photograph
next to me is in the office again 8-)

http://www.intercity-vpn.de/files/edimax-1101w/
(upload is in progress)


Looks pretty much like this one http://wiki.openwrt.org/toh/hilink/hlk-rm04


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

Re: [OpenWrt-Devel] target rb532 / routerboard

[Imre Kaloz]

On Wed, 09 Apr 2014 14:39:04 +0200, Bastian Bittorf bitt...@bluebottle.com 
wrote:


why is it marked as 'broken'? i just compiled it with
trunk r40422/kernel 3.10.34 and it boots fine.


Because no one tested it since the kernel has been upgraded, and we don't have 
a board to do anymore ;)


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

Re: [OpenWrt-Devel] [PATCH v1] x86_64 kernel config - add ATA drivers to boot vmware images

[Imre Kaloz]

On Wed, 26 Mar 2014 19:31:48 +0100, Jiri Slachta slac...@cesnet.cz wrote:


Hi,

almost the same patch submitted a while ago was rejected. I do not think your 
patch will be accepted, see:

http://patchwork.openwrt.org/patch/4832/

Jiri

On March 26, 2014 6:16:44 PM CET, Darren Lissimore darren.lissim...@gmail.com 
wrote:


I needed to add the ATA drivers to the defalut x86_64 kernel config to
get the
VMware disk images booting.

Tested and verified functioning on VMware Workstation 9.0.3 .


Jiri is right. Please use AHCI.


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

Re: [OpenWrt-Devel] How to split the kernel configuration needed for a particular board?

[Imre Kaloz]

John,

On Tue, 04 Mar 2014 16:21:35 +0100, John Szakmeister j...@szakmeister.net 
wrote:


I'm looking to add support for a board into OpenWRT, and I'm curious
you guys so neatly split the configuration between the top-level, the
architecture, and the boards.  It's an ARM-based board and we plan on
using device tree.  With all the interaction between kernel
selections, I want to make sure I have the correct bits selected.


Generic (even arch specific) option go into 
target/linux/generic/config-$VERSION, and target specific options / overrides 
go into target/linux/$BOARD/config-{default,$VERSION}

Subtarget config options override target config options, target config options 
override generic config options :)


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

Re: [OpenWrt-Devel] [PATCH] [x86_64]: adding ATA GENERIC + PIIX to support IDE HDD

[Imre Kaloz]

On Wed, 05 Feb 2014 15:50:15 +0100, Alexandru Ardelean ardeleana...@gmail.com 
wrote:


Seems that the x86_64 build of OpenWRT hangs on boot in KVM and QEMU.
After looking over the 'target/linux/x86_64' folder in comparison with
'target/linux/x86' I've narrowed it down to just these 2 options
that have to explicitly be set in the config-default file of the
x86_64 build.



NAK. x86_64 won't have legacy support, so please use AHCI on both KVM/QEMU for 
this target.


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

Re: [OpenWrt-Devel] Warnung vor Lötwasser beim TL-WDR4900

[Imre Kaloz]

On Thu, 12 Sep 2013 09:45:59 +0200, Joerg Dorchain jo...@dorchain.net wrote:


On Thu, Sep 12, 2013 at 08:55:29AM +0200, Alina Friedrichsen wrote:

Könnt ihr bitte einen Warnung im Wiki anbringen, dass der Router extrem
empfindlich gegenüber Lötwasser ist? Mir sind dutzende Router
abgeraucht, weil ich zu viel Lötwasser aufgetragen habe. Nur ein ganz
feiner Strich von unten über die Pins. Bei mehr raucht der Router sofort
ab.


Loetwasser? Auf Elektronik?! Nicht gut(tm).

Loetwasser nimmt man fuer starkt verdreckte und korrodierte
Metallteile beim Klempnern (Kupferleitung in Omas feuchtem Keller).
Feineres Material reagiert auf die Mischung aus Zinkoxid,
Salzsaere und Salmiak mit Aufloesung.

Man moechte bitte Elektroniklot mit Flussmittelkern verwenden
(frueher Kolophonium), das reicht fuer Staub und Reste von
Fingerabdruecken. KEIN LOETWASSER.

Evtl. waere ein Hinweis auf einen Loetkurs angebracht. (z.B.
http://www.kemo-electronic.de/de/loetkurs.php)


This is an international list, please stick to english.


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

Re: [OpenWrt-Devel] [PATCH] [RFC] imx61: add support for i.MX6 target

[Imre Kaloz]

On Thu, 11 Apr 2013 05:43:03 +0200, Tim Harvey thar...@gateworks.com wrote:


This adds support for a new target architecture: i.MX61

This is based on the current 3.8.6 kernel with the following additions:
  - PCIe Root Complex driver supporting bridge transactions and MSI
  - DeviceTree support for Gateworks Ventana GW5400
  - SDMA firmware

The kernel is fully device-tree.  The image Makefile creates an Image
Tree Source (ITS) file used by mkimage to produce a Flattened Image Tree
(FIT) image.  This FIT image allows a kernel and compiled Device Tree
compatible with uboot based bootloaders utilizing Device Tree.

The mkits.sh script is copied from mpc83xx which is very useful and should
likely be promoted to the owrt scripts directory.

Comments welcome

Signed-off-by: Tim Harvey thar...@gateworks.com


snip


diff --git a/target/linux/imx61/Makefile b/target/linux/imx61/Makefile
new file mode 100644
index 000..9ebc67b
--- /dev/null
+++ b/target/linux/imx61/Makefile
@@ -0,0 +1,26 @@
+#
+# Copyright (C) 2013 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+
+ARCH:=arm
+BOARD:=imx61
+BOARDNAME:=Freescale IMX61


i.MX61 :)


+FEATURES:=audio display gpio pcie usb usbgadget squashfs targz
+
+CFLAGS:=-Os -pipe -mtune=cortex-a9 -march=armv7-a -mfpu=vfpv3-d16 
-mfloat-abi=softfp
+
+LINUX_VERSION:=3.8.6
+
+include $(INCLUDE_DIR)/target.mk
+
+define Target/Description
+   Freescale IMX61
+endef


i.MX61 :)

snip 


diff --git a/target/linux/imx61/base-files/lib/imx61.sh 
b/target/linux/imx61/base-files/lib/imx61.sh
new file mode 100644
index 000..527330e
--- /dev/null
+++ b/target/linux/imx61/base-files/lib/imx61.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+#
+# Copyright (C) 2013 OpenWrt.org
+#
+
+imx61_board_name() {
+   local machine
+   local name
+
+   machine=$(awk 'BEGIN{FS=[ \t]+:[ \t]} /Hardware/ {print $2}' 
/proc/cpuinfo)
+
+   case $machine in
+   Freescale i.MX6 Quad (Device Tree))
+   name=imx6-dt
+   ;;


If this is the Sabre or the Sabre Lite, naming it that way would probably a 
good idea.


+   *)
+   name=generic;
+   ;;
+   esac
+   
+   echo $name
+}

snip


diff --git a/target/linux/imx61/config-3.8 b/target/linux/imx61/config-3.8
new file mode 100644
index 000..f212a02
--- /dev/null
+++ b/target/linux/imx61/config-3.8
@@ -0,0 +1,503 @@
+CONFIG_ALIGNMENT_TRAP=y
+# CONFIG_AMBA_PL08X is not set
+# CONFIG_ARCH_BCM is not set
+CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
+CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
+CONFIG_ARCH_HAS_CPUFREQ=y
+CONFIG_ARCH_HAS_OPP=y
+CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
+CONFIG_ARCH_MULTIPLATFORM=y
+# CONFIG_ARCH_MULTI_CPU_AUTO is not set
+# CONFIG_ARCH_MULTI_V6 is not set
+CONFIG_ARCH_MULTI_V6_V7=y
+CONFIG_ARCH_MULTI_V7=y
+CONFIG_ARCH_MXC=y
+# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
+CONFIG_ARCH_NR_GPIO=0
+CONFIG_ARCH_REQUIRE_GPIOLIB=y
+# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
+# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
+# CONFIG_ARCH_SUNXI is not set
+CONFIG_ARCH_SUPPORTS_MSI=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_VEXPRESS=y


Why?


+# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
+CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
+# CONFIG_ARCH_VT8500_SINGLE is not set
+CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
+CONFIG_ARM=y
+CONFIG_ARM_AMBA=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y


Doesn't the bootloader fixup it?


+# CONFIG_ARM_CHARLCD is not set
+# CONFIG_ARM_CPU_SUSPEND is not set
+# CONFIG_ARM_ERRATA_430973 is not set
+CONFIG_ARM_ERRATA_720789=y
+CONFIG_ARM_ERRATA_754322=y
+# CONFIG_ARM_ERRATA_754327 is not set
+CONFIG_ARM_ERRATA_764369=y
+CONFIG_ARM_ERRATA_775420=y
+# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
+# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
+# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
+CONFIG_ARM_GIC=y
+CONFIG_ARM_L1_CACHE_SHIFT=6
+CONFIG_ARM_L1_CACHE_SHIFT_6=y
+# CONFIG_ARM_LPAE is not set
+CONFIG_ARM_NR_BANKS=8
+CONFIG_ARM_PATCH_PHYS_VIRT=y
+# CONFIG_ARM_SP805_WATCHDOG is not set
+CONFIG_ARM_THUMB=y
+# CONFIG_ARM_THUMBEE is not set
+CONFIG_ARM_TIMER_SP804=y
+CONFIG_ATA=y
+CONFIG_ATAGS=y


Why does the board need legacy ATAGS support?


+# CONFIG_ATA_SFF is not set
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_CACHE_L2X0=y
+CONFIG_CACHE_PL310=y
+CONFIG_CLKDEV_LOOKUP=y
+CONFIG_CLKSRC_MMIO=y
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_CMDLINE=console=ttymxc1,115200
+CONFIG_CMDLINE_FROM_BOOTLOADER=y
+CONFIG_COMMON_CLK=y
+CONFIG_COMMON_CLK_DEBUG=y
+CONFIG_COMMON_CLK_VERSATILE=y
+CONFIG_COMPACTION=y
+CONFIG_CPU_32v6K=y
+CONFIG_CPU_32v7=y
+CONFIG_CPU_ABRT_EV7=y
+# CONFIG_CPU_BPREDICT_DISABLE is not set
+CONFIG_CPU_CACHE_V7=y
+CONFIG_CPU_CACHE_VIPT=y
+CONFIG_CPU_COPY_V6=y
+CONFIG_CPU_CP15=y

Re: [OpenWrt-Devel] [PATCH] [RFC] imx61: add support for i.MX6 target

[Imre Kaloz]

Hello Tim,

On Fri, 12 Apr 2013 07:13:52 +0200, Tim Harvey thar...@gateworks.com wrote:

snip


Thanks for reviewing Imre!  I'll submit a follow patch after a few days if
there is more discussion.


Okay, I'll help cleaning up that one as well, so we can minimize the changes to 
be reviewed.


Some other areas that may need discussion:
  - we need an OpenWrt dev for a maintainer I assume?


I'm happy to do it. Could you test the target support on the Freescale board as 
well? having support for more boards in a target would make it easier to make 
sure we do things properly.


  - the mkits.sh script (if we go that route) should probably be moved to
generic kernel patches


Or generic/files.


  - the sky2 patch to get its mac addr from device-tree should probably be
moved to generic kernel patches (and the way I'm doing it may very well not
be proper)


I did note that. Such changes should be easily merged upstream as well.



Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LTS Kernel

[Imre Kaloz]

On Wed, 03 Apr 2013 10:08:53 +0200, Rafał Miłecki zaj...@gmail.com wrote:


2013/4/3 Bastian Bittorf bitt...@bluebottle.com:

* sylvain roger rieunier sylvain.roger.rieun...@gmail.com [03.04.2013 09:08]:

maybe it'is a stupid question, but some one why Openwrt didn't use LTS
kernel like in
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git


At the moment the version is raised manually.
Do you want to automatically apply a new Kernel-Version, if the
stable tree updates? (e.g. 3.8.4 to 3.8.5)


I think changing it manually makes sense, we at least know that
generic patches still do apply. Builds won't automatically break for
every target.

I don't think Sylvain was talking about any auto-using the latest
kernel from 3.8 (or other) release. I believe it's about using kernel
version that is longterm support (2.6.34 or 3.0 or 3.2 or 3.4 - see
kernel.org). We still may update from (for example) 3.2.41 to 3.2.42
manually, we just shouldn't use 3.3 as a kernel for AA release. 3.3
isn't longterm support, it's EOL, no more 3.3.X releases (even
security!) are coming.



3.3 has been chosen as AA was meant to be released those days..


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LTS Kernel

[Imre Kaloz]

On Wed, 03 Apr 2013 10:45:01 +0200, Rafał Miłecki zaj...@gmail.com wrote:

snip



3.3 has been chosen as AA was meant to be released those days..


Well, so it seems we assumed two things:
1) AA quick release, according to the plan
2) BB release quick enough to replace AA before 3.3 gets EOL

I'm afraid both assumptions were wrong and shouldn't happen. Privately
I wonder if it's good idea to release AA at all, if it's going to be
using old 3.3 kernel with possible security bugs.



1) I wanted to lead the AA release, but life had different plans. blogic leads 
that now, he knows the plan
2) BB wasn't even on the table back then, I've renamed trunk when the others 
decided to branch AA.

Privately I wasn't a fan of branching, ever, as it always caused similar 
results to the current state. IMHO when we want a release, trunk should calm 
down (!=freeze) and stabilize, and branching should happen only at the time of 
releasing that version.

I wanted predefined 6-monthly release cycles for years now, while others think 
a release should bring something new all the time.

IMHO AA should be released asap, just to get over it, and BB should follow it 
shortly.


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LTS Kernel

[Imre Kaloz]

On Wed, 03 Apr 2013 13:03:15 +0200, Rafał Miłecki zaj...@gmail.com wrote:


2013/4/3 Imre Kaloz ka...@openwrt.org:

On Wed, 03 Apr 2013 10:45:01 +0200, Rafał Miłecki zaj...@gmail.com wrote:

snip




3.3 has been chosen as AA was meant to be released those days..



Well, so it seems we assumed two things:
1) AA quick release, according to the plan
2) BB release quick enough to replace AA before 3.3 gets EOL

I'm afraid both assumptions were wrong and shouldn't happen. Privately
I wonder if it's good idea to release AA at all, if it's going to be
using old 3.3 kernel with possible security bugs.



1) I wanted to lead the AA release, but life had different plans. blogic
leads that now, he knows the plan
2) BB wasn't even on the table back then, I've renamed trunk when the others
decided to branch AA.

Privately I wasn't a fan of branching, ever, as it always caused similar
results to the current state. IMHO when we want a release, trunk should calm
down (!=freeze) and stabilize, and branching should happen only at the time
of releasing that version.

I wanted predefined 6-monthly release cycles for years now, while others
think a release should bring something new all the time.


I'm not going to reinvent the wheel analyzing how hard it is to say
how many features make it worth releasing new version. A lot of big
(and actively developed) projects are using cycling releases now
(including Linux kernel). And come one, OpenWrt is getting a lot of
patches almost daily.
I like 6-monthly (of similar) release cycle, it's just a matter of
fact of finding some ppl leading that releases.



IMHO AA should be released asap, just to get over it, and BB should follow
it shortly.


Agree. We just should make sure to use some LTS kernel. Let's release
AA, pick up the first LTS kernel and use it for BB release.

Sound simple, doesn't it? ;) It always does ;)



BB should be released with the latest kernel if there's no LTS announced yet, 
and BB+1 could use LTS. But for real, I'm not convinced that it makes sense to 
stick to LTS for every release we are going to do.


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2][orion] Add support for 3.7

[Imre Kaloz]

Hi,

On Sat, 23 Feb 2013 16:29:20 +0100, Maarten Bezemer maarten.beze...@gmail.com 
wrote:


It seems that Imre Kaloz (the target maintainer) is not available?
Is it possible that the patch gets reviewed/committed by someone else?


Orion will be moved to DT, so 3.7 support won't be commited at all.


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2][orion] Add support for 3.7

[Imre Kaloz]

On Mon, 25 Feb 2013 11:45:38 +0100, Florian Fainelli flor...@openwrt.org 
wrote:


On 02/25/2013 11:05 AM, Imre Kaloz wrote:

Hi,

On Sat, 23 Feb 2013 16:29:20 +0100, Maarten Bezemer
maarten.beze...@gmail.com wrote:


It seems that Imre Kaloz (the target maintainer) is not available?
Is it possible that the patch gets reviewed/committed by someone else?


Orion will be moved to DT, so 3.7 support won't be commited at all.


Sounds like a good plan and a lot of work at the same time, would not it
be beneficial for users to have an interim 3.7 support for them to test?


I rather not at another outdated kernel. 3.7 doesn't bring any critical feature 
for us.


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] tune kernel commandline for headless/embedded systems / oops=panic panic=10 / panic_on_oom=1

[Imre Kaloz]

On Fri, 04 Jan 2013 16:46:18 +0100, Bastian Bittorf bitt...@bluebottle.com 
wrote:


* Imre Kaloz ka...@openwrt.org [04.01.2013 16:27]:


I'm fine with the idea but not the way you did it, because if you're serial 
attached this gets annoying quite fast. Although we could make this a config option 
and do all kind of magic to set it based on that, I suggest swapping your idea: change 
these through sysctl _after_ a successful boot-up.



the problem is: most routers are in production and not serial
attached - so you have really a problem if a node (rooftop or solar
powered) dies during boot. if you are a developer, you can simple build
your own image and disable this option, all other persons (90%?) like to
have a running/selfrebooting router when the kernel is panic'ing or there
are serious problems.


And those persons likely won't deploy a router with an image that fails to 
boot, right? So what's wrong with setting these values after boot up?


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] tune kernel commandline for headless/embedded systems / oops=panic panic=10 / panic_on_oom=1

[Imre Kaloz]

Hi,

On Thu, 03 Jan 2013 11:57:56 +0100, Bastian Bittorf bitt...@bluebottle.com 
wrote:


oops=panic panic=10 / panic_on_oom=1
Reply-To:
X-Editor: vi http://ex-vi.sourceforge.net/

In our production networks we had issues that some device needed
a manual restart, because there where hanging/panic/oopsing during
boot-time.

We added to the kernel-commandline the args: 'oops=panic panic=10'
like mentioned in this post:

https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016430.html

Now its much better, nearly no manual restarts are needed.
I like to discuss that these changes are a good idea for everybody
and should be standard for headless/embedded systems in production.

If you care about patching away errors, developers (serial attached)
can choose to not include it. also an init/rc-script after boot
can switch this behaviour off.

While we are at this point: 'panic_on_oom' is IMHO also a good choice.


I'm fine with the idea but not the way you did it, because if you're serial 
attached this gets annoying quite fast. Although we could make this a config option 
and do all kind of magic to set it based on that, I suggest swapping your idea: change 
these through sysctl _after_ a successful boot-up.


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] cns3xxx: clean up pcie patches

[Imre Kaloz]

Thanks, merged it in r34132.


Imre

On Fri, 09 Nov 2012 00:46:46 +0100, Tim Harvey thar...@gateworks.com wrote:


Combine two pcie patches (2nd patch undid the 1st patch) together
and refresh the other affected patches

Signed-off-by: Tim Harvey thar...@gateworks.com
---
 .../patches-3.3/055-cns3xxx_pci_iospace_init.patch |   76 
 .../cns3xxx/patches-3.3/104-cns3xxx_gpio.patch |4 +-
 .../cns3xxx/patches-3.3/300-laguna_support.patch   |4 +-
 .../linux/cns3xxx/patches-3.3/470-gpio_irq.patch   |5 +-
 .../patches-3.3/480-cns3xxx_pcie_early_init.patch  |   58 ++--
 5 files changed, 28 insertions(+), 119 deletions(-)
 delete mode 100644 
target/linux/cns3xxx/patches-3.3/055-cns3xxx_pci_iospace_init.patch

diff --git 
a/target/linux/cns3xxx/patches-3.3/055-cns3xxx_pci_iospace_init.patch 
b/target/linux/cns3xxx/patches-3.3/055-cns3xxx_pci_iospace_init.patch
deleted file mode 100644
index e70ef96..000
--- a/target/linux/cns3xxx/patches-3.3/055-cns3xxx_pci_iospace_init.patch
+++ /dev/null
@@ -1,76 +0,0 @@
 a/arch/arm/mach-cns3xxx/cns3420vb.c
-+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
-@@ -32,6 +32,7 @@
- #include asm/mach/time.h
- #include mach/cns3xxx.h
- #include mach/irqs.h
-+#include mach/platform.h
- #include core.h
- #include devices.h
-
-@@ -199,6 +200,8 @@ static void __init cns3420_init(void)
-   cns3xxx_ahci_init();
-   cns3xxx_sdhci_init();
-
-+  cns3xxx_pcie_init(0x3);
-+
-   pm_power_off = cns3xxx_power_off;
- }
-
 a/arch/arm/mach-cns3xxx/core.h
-+++ b/arch/arm/mach-cns3xxx/core.h
-@@ -12,6 +12,8 @@
- #define __CNS3XXX_CORE_H
-
- extern struct sys_timer cns3xxx_timer;
-+extern int cns3xxx_pcie_init(u8 bitmap);
-+extern void cns3xxx_pcie_iotable_init(u8 bitmap);
-
- #ifdef CONFIG_CACHE_L2X0
- void __init cns3xxx_l2x0_init(void);
 a/arch/arm/mach-cns3xxx/pcie.c
-+++ b/arch/arm/mach-cns3xxx/pcie.c
-@@ -365,7 +365,23 @@ static int cns3xxx_pcie_abort_handler(un
-   return 0;
- }
-
--static int __init cns3xxx_pcie_init(void)
-+void __init cns3xxx_pcie_iotable_init(u8 bitmap)
-+{
-+  static int _iotable_init = 0;
-+  int i;
-+
-+  bitmap = ~_iotable_init;
-+  for (i = 0; i  ARRAY_SIZE(cns3xxx_pcie); i++) {
-+  if (!(bitmap  (1  i)))
-+  continue;
-+
-+  iotable_init(cns3xxx_pcie[i].cfg_bases,
-+   ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
-+  }
-+  _iotable_init |= bitmap;
-+}
-+
-+int __init cns3xxx_pcie_init(u8 bitmap)
- {
-   int i;
-
-@@ -375,9 +391,11 @@ static int __init cns3xxx_pcie_init(void
-   hook_fault_code(16 + 6, cns3xxx_pcie_abort_handler, SIGBUS, 0,
-   imprecise external abort);
-
-+  cns3xxx_pcie_iotable_init(bitmap);
-   for (i = 0; i  ARRAY_SIZE(cns3xxx_pcie); i++) {
--  iotable_init(cns3xxx_pcie[i].cfg_bases,
--   ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
-+  if (!(bitmap  (1  i)))
-+  continue;
-+
-   cns3xxx_pcie_check_link(cns3xxx_pcie[i]);
-   cns3xxx_pcie_hw_init(cns3xxx_pcie[i]);
-   pci_common_init(cns3xxx_pcie[i].hw_pci);
-@@ -387,4 +405,3 @@ static int __init cns3xxx_pcie_init(void
-
-   return 0;
- }
--device_initcall(cns3xxx_pcie_init);
diff --git a/target/linux/cns3xxx/patches-3.3/104-cns3xxx_gpio.patch 
b/target/linux/cns3xxx/patches-3.3/104-cns3xxx_gpio.patch
index bda0222..1f0d444 100644
--- a/target/linux/cns3xxx/patches-3.3/104-cns3xxx_gpio.patch
+++ b/target/linux/cns3xxx/patches-3.3/104-cns3xxx_gpio.patch
@@ -1,6 +1,6 @@
 --- a/arch/arm/mach-cns3xxx/cns3420vb.c
 +++ b/arch/arm/mach-cns3xxx/cns3420vb.c
-@@ -216,7 +216,7 @@ static struct map_desc cns3420_io_desc[]
+@@ -213,7 +213,7 @@ static struct map_desc cns3420_io_desc[]
 static void __init cns3420_map_io(void)
  {
@@ -96,7 +96,7 @@
  /* used by entry-macro.S */
 --- a/arch/arm/mach-cns3xxx/core.h
 +++ b/arch/arm/mach-cns3xxx/core.h
-@@ -21,7 +21,7 @@ void __init cns3xxx_l2x0_init(void);
+@@ -19,7 +19,7 @@ void __init cns3xxx_l2x0_init(void);
  static inline void cns3xxx_l2x0_init(void) {}
  #endif /* CONFIG_CACHE_L2X0 */
diff --git a/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch 
b/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch
index e73d7bd..6fa474c 100644
--- a/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch
+++ b/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch
@@ -1,11 +1,13 @@
 --- a/arch/arm/mach-cns3xxx/Kconfig
 +++ b/arch/arm/mach-cns3xxx/Kconfig
-@@ -10,4 +10,12 @@ config MACH_CNS3420VB
+@@ -11,4 +11,14 @@ config MACH_CNS3420VB
  This is a platform with an on-board ARM11 MPCore and has support
  for USB, USB-OTG, MMC/SD/SDIO, SATA, PCI-E, etc.
+config MACH_GW2388
 +  bool Support for Gateworks Laguna Platform
++  select HAVE_ARM_SCU if SMP
++  select MIGHT_HAVE_PCI
 +  help
 +Include support for the Gateworks Laguna 

Re: [OpenWrt-Devel] [PATCH] cns3xxx: Initial support for Hydrogen board

[Imre Kaloz]

Thanks, please see comments / questions below.

On Wed, 07 Nov 2012 17:52:57 +0100, Jon Suphammer j...@pingcom.net wrote:


Add Ping Communication Hydrogen board support.

Signed-off-by: Jon Suphammer j...@pingcom.net
---
 target/linux/cns3xxx/base-files/lib/cns3xxx.sh |   13 +-
 target/linux/cns3xxx/config-3.3|1 +
 .../cns3xxx/files/arch/arm/mach-cns3xxx/hydrogen.c |  363 
 target/linux/cns3xxx/image/Makefile|2 +
 .../cns3xxx/patches-3.3/301-hydrogen_support.patch |   23 ++
 .../patches-3.3/460-cns3xxx_fiq_support.patch  |4 +-
 .../patches-3.3/980-arm_openwrt_machtypes.patch|3 +-
 7 files changed, 401 insertions(+), 8 deletions(-)
 create mode 100644 target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/hydrogen.c
 create mode 100644 target/linux/cns3xxx/patches-3.3/301-hydrogen_support.patch

diff --git a/target/linux/cns3xxx/base-files/lib/cns3xxx.sh 
b/target/linux/cns3xxx/base-files/lib/cns3xxx.sh
index d446777..da27b77 100644
--- a/target/linux/cns3xxx/base-files/lib/cns3xxx.sh
+++ b/target/linux/cns3xxx/base-files/lib/cns3xxx.sh
@@ -4,19 +4,22 @@
 #
cns3xxx_board_name() {
-local machine
-local name
+   local machine
+   local name
-machine=$(awk 'BEGIN{FS=[ \t]+:[ \t]} /Hardware/ {print $2}' 
/proc/cpuinfo)
+   machine=$(awk 'BEGIN{FS=[ \t]+:[ \t]} /Hardware/ {print $2}' 
/proc/cpuinfo)
-case $machine in
+   case $machine in
Gateworks Corporation Laguna*)
name=laguna
;;
+   Ping Communication Hydrogen*)
+   name=hydrogen
+   ;;
*)
name=generic;
;;
esac
-   
+
echo $name
 }


Please add only the needed things here, cleanups should come as a separate 
patch.


diff --git a/target/linux/cns3xxx/config-3.3 b/target/linux/cns3xxx/config-3.3
index 6963747..266f84b 100644
--- a/target/linux/cns3xxx/config-3.3
+++ b/target/linux/cns3xxx/config-3.3
@@ -111,6 +111,7 @@ CONFIG_LOCAL_TIMERS=y
 CONFIG_M25PXX_USE_FAST_READ=y
 # CONFIG_MACH_CNS3420VB is not set
 CONFIG_MACH_GW2388=y
+CONFIG_MACH_HYDROGEN=y
 CONFIG_MDIO_BOARDINFO=y
 # CONFIG_MFD_T7L66XB is not set
 CONFIG_MIGHT_HAVE_CACHE_L2X0=y


Ok.


diff --git a/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/hydrogen.c 
b/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/hydrogen.c
new file mode 100644
index 000..37fefff
--- /dev/null
+++ b/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/hydrogen.c
@@ -0,0 +1,363 @@
+/*
+ * Ping Communication Hydrogen
+ *
+ * Copyright 2000 Deep Blue Solutions Ltd
+ * Copyright 2008 ARM Limited
+ * Copyright 2008 Cavium Networks
+ *   Scott Shu
+ * Copyright 2010 MontaVista Software, LLC.
+ *   Anton Vorontsov avoront...@mvista.com
+ * Copyright 2012 Ping Communication
+ *   Jon Suphammer j...@suphammer.net
+ *
+ * This file is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, Version 2, as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/compiler.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/dma-mapping.h
+#include linux/serial_core.h
+#include linux/serial_8250.h
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/physmap.h
+#include linux/mtd/partitions.h
+#include linux/leds.h
+#include linux/spi/spi.h
+#include linux/spi/flash.h
+#include linux/if_ether.h
+#include linux/etherdevice.h
+#include asm/setup.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/time.h
+#include mach/cns3xxx.h
+#include mach/irqs.h
+#include mach/platform.h
+#include asm/hardware/gic.h
+#include core.h
+#include devices.h
+
+#define ARRAY_AND_SIZE(x)  (x), ARRAY_SIZE(x)
+
+static int spi_enable __initdata = 0;
+
+static int __init hydrogen_spi_enable(char *s)
+{
+   spi_enable = 1;
+   return 1;
+}
+__setup (hydrogen_spi, hydrogen_spi_enable);
+
+
+/*
+ * NOR Flash
+ */
+static struct mtd_partition hydrogen_nor_partitions[] = {
+   {
+   .name   = uboot,
+   .size   = SZ_512K,
+   .offset = 0,
+   .mask_flags = MTD_WRITEABLE,
+   }, {
+   .name   = uboot_env,
+   .size   = SZ_128K,
+   .offset = MTDPART_OFS_APPEND,
+   .mask_flags = MTD_WRITEABLE,
+   }, {
+   .name   = staging,
+   .size   = SZ_2M + SZ_1M,
+   .offset = MTDPART_OFS_APPEND,
+   .mask_flags = MTD_WRITEABLE,
+   }, {
+   .name   = kernel,
+   .size   = SZ_2M,
+   .offset = 

Re: [OpenWrt-Devel] [PATCH] cns3xxx: add PPS support for laguna

[Imre Kaloz]

Thanks,

Applied in r34115.


Imre

On Wed, 07 Nov 2012 21:53:48 +0100, Tim Harvey thar...@gateworks.com wrote:


Many Laguna products have on-board GPS with Pulse-per-second (PPS)
support.  This patch adds kernel support (statically) and adds
the platform data in laguna board support.

Signed-off-by: Tim Harvey thar...@gateworks.com
---
 target/linux/cns3xxx/config-3.3|7 +++
 .../cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c   |   20 
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/target/linux/cns3xxx/config-3.3 b/target/linux/cns3xxx/config-3.3
index 6963747..4090b31 100644
--- a/target/linux/cns3xxx/config-3.3
+++ b/target/linux/cns3xxx/config-3.3
@@ -131,6 +131,7 @@ CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NET_VENDOR_CAVIUM=y
 CONFIG_NLS=y
 CONFIG_NR_CPUS=2
+CONFIG_NTP_PPS=y
 CONFIG_OUTER_CACHE=y
 CONFIG_OUTER_CACHE_SYNC=y
 CONFIG_PAGEFLAGS_EXTENDED=y
@@ -143,7 +144,13 @@ CONFIG_PHYLIB=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_PL310_ERRATA_727915=y
 CONFIG_PL310_ERRATA_769419=y
+CONFIG_PPS=y
+CONFIG_PPS_CLIENT_GPIO=y
+# CONFIG_PPS_CLIENT_KTIMER is not set
+# CONFIG_PPS_CLIENT_LDISC is not set
+# CONFIG_PPS_DEBUG is not set
 # CONFIG_PREEMPT_RCU is not set
+# CONFIG_PTP_1588_CLOCK is not set
 CONFIG_RAID_ATTRS=y
 CONFIG_RFS_ACCEL=y
 CONFIG_RPS=y
diff --git a/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c 
b/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c
index 8543183..8b611c5 100644
--- a/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c
+++ b/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c
@@ -36,6 +36,7 @@
 #include linux/spi/spi.h
 #include linux/spi/flash.h
 #include linux/if_ether.h
+#include linux/pps-gpio.h
 #include asm/setup.h
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -581,6 +582,22 @@ static struct platform_device laguna_watchdog = {
 };
/*
+ * GPS PPS
+ */
+static struct pps_gpio_platform_data laguna_pps_data = {
+   .gpio_pin = 0,
+   .gpio_label = GPS_PPS,
+   .assert_falling_edge = 0,
+   .capture_clear = 0,
+};
+
+static struct platform_device laguna_pps_device = {
+   .name = pps-gpio,
+   .id = -1,
+   .dev.platform_data = laguna_pps_data,
+};
+
+/*
  * GPIO
  */
@@ -869,6 +886,9 @@ static int __init laguna_model_setup(void)
(laguna_info.config_bitmap  SPI1_LOAD))
platform_device_register(laguna_spi_controller);
+   if (laguna_info.config2_bitmap  GPS_LOAD)
+   platform_device_register(laguna_pps_device);
+
/*
 * Do any model specific setup not known by the bitmap by 
matching
 *  the first 6 characters of the model name

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH][RFC] uboot-kirkwood: upgrade to 2012.10

[Imre Kaloz]

Hi,

On Tue, 06 Nov 2012 14:13:26 +0100, Daniel Golle dgo...@allnet.de wrote:

snip


U-Boot default env:
mtdparts=mtdparts=orion_nand:0x8@0x0(uboot),0x2@0x8(uboot_env),-@0xa(rootfs)
vs.
arch/arm/mach-kirkwood/iconnect-setup.c:
static struct mtd_partition iconnect_nand_parts[] = {


IMHO u-boot shouldn't do anything with mtdparts...


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] cns3xxx: move PCIe init to subsys init call

[Imre Kaloz]

Tim,

On Wed, 31 Oct 2012 19:28:41 +0100, Tim Harvey thar...@gateworks.com  
wrote:


ARM Linux PCI/PCIe hardware intialization needs to occur before  
device_init
as it does not support hotplug.  I have modeled the cns3xxx PCIe init  
after
other ARM platforms.  Registering it early resolves resource issues  
occuring
during bus enumeration that occur when a device driver is linked static  
in

the kernel.

Instead of passing in a bitmask to enable the 2 available ports, link  
detect

is used to enable ports that have a valid link.


snip

I like this approach a lot :) Commited as r34044.


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2] cns3xxx: move Gateworks GSC to generic patches

[Imre Kaloz]

I think Felix meant it the way I've commited it (eg. added the Kconfig  
symbol to the targets).

I also made it not depend on EXPERIMENTAL but the platforms using it.

Imre

On Thu, 11 Oct 2012 01:51:24 +0200, Tim Harvey thar...@gateworks.com  
wrote:


The Gateworks System Controller (GSC) is an i2c device that provides  
system

level monitoring and control of Gateworks boards.  It is used on several
product families spanning several different target architectures (ixp4xx,
cns3xx, davinci)

Version2 of patch renames module from 'gsp' to 'gsc' and adds OpenWrt  
package

selection for kernel config.

Signed-off-by: Tim Harvey thar...@gateworks.com
---
 package/kernel/modules/hwmon.mk|   15 +
 target/linux/cns3xxx/config-3.3|1 -
 .../patches-3.3/110-gateworks_gsp_support.patch|  339  

 .../880-gateworks_system_controller.patch  |  339  


 4 files changed, 354 insertions(+), 340 deletions(-)
 delete mode 100644  
target/linux/cns3xxx/patches-3.3/110-gateworks_gsp_support.patch
 create mode 100644  
target/linux/generic/patches-3.3/880-gateworks_system_controller.patch


diff --git a/package/kernel/modules/hwmon.mk  
b/package/kernel/modules/hwmon.mk

index d549336..d96cc09 100644
--- a/package/kernel/modules/hwmon.mk
+++ b/package/kernel/modules/hwmon.mk
@@ -190,3 +190,18 @@ define KernelPacakge/hwmon-w83627hf/description
 endef
$(eval $(call KernelPackage,hwmon-w83627hf))
+
+
+define KernelPackage/hwmon-gsc
+  TITLE:=Gateworks System Controller monitoring support
+  KCONFIG:=CONFIG_SENSORS_GSC
+  FILES:=$(LINUX_DIR)/drivers/hwmon/gsc.ko
+  AUTOLOAD:=$(call AutoLoad,50,gsc)
+$(call AddDepends/hwmon,@TARGET_cns3xxx||TARGET_ixp4xx)
+endef
+
+define KernelPacakge/hwmon-gsc/description
+  Kernel module for the Gateworks System Controller chip
+endef
+
+$(eval $(call KernelPackage,hwmon-gsc))
diff --git a/target/linux/cns3xxx/config-3.3  
b/target/linux/cns3xxx/config-3.3

index a6f3bc7..2c0c3b0 100644
--- a/target/linux/cns3xxx/config-3.3
+++ b/target/linux/cns3xxx/config-3.3
@@ -154,7 +154,6 @@ CONFIG_SATA_AHCI_PLATFORM=y
 CONFIG_SCSI=y
 # CONFIG_SCSI_MULTI_LUN is not set
 CONFIG_SENSORS_AD7418=y
-CONFIG_SENSORS_GSP=y
 CONFIG_SERIAL_8250_NR_UARTS=3
 CONFIG_SERIAL_8250_RUNTIME_UARTS=3
 CONFIG_SMP=y
diff --git  
a/target/linux/cns3xxx/patches-3.3/110-gateworks_gsp_support.patch  
b/target/linux/cns3xxx/patches-3.3/110-gateworks_gsp_support.patch

deleted file mode 100644
index 02fbdab..000
--- a/target/linux/cns3xxx/patches-3.3/110-gateworks_gsp_support.patch
+++ /dev/null
@@ -1,339 +0,0 @@
 a/drivers/hwmon/Kconfig
-+++ b/drivers/hwmon/Kconfig
-@@ -423,6 +423,15 @@ config SENSORS_GL520SM
- This driver can also be built as a module.  If so, the module
- will be called gl520sm.
-
-+config SENSORS_GSP
-+  tristate Gateworks System Peripheral
-+  depends on I2C  EXPERIMENTAL
-+  help
-+	  If you say yes here you get support for the Gateworks System  
Peripherals.

-+
-+This driver can also be built as a module. If so, the module
-+will be called gsp.
-+
- config SENSORS_GPIO_FAN
-   tristate GPIO fan
-   depends on GENERIC_GPIO
 a/drivers/hwmon/Makefile
-+++ b/drivers/hwmon/Makefile
-@@ -125,6 +125,7 @@ obj-$(CONFIG_SENSORS_W83L785TS)+= w83l7
- obj-$(CONFIG_SENSORS_W83L786NG)   += w83l786ng.o
- obj-$(CONFIG_SENSORS_WM831X)  += wm831x-hwmon.o
- obj-$(CONFIG_SENSORS_WM8350)  += wm8350-hwmon.o
-+obj-$(CONFIG_SENSORS_GSP) += gsp.o
-
- obj-$(CONFIG_PMBUS)   += pmbus/
-
 /dev/null
-+++ b/drivers/hwmon/gsp.c
-@@ -0,0 +1,308 @@
-+/*
-+ * A hwmon driver for the Gateworks System Peripheral
-+ * Copyright (C) 2009 Gateworks Corporation
-+ *
-+ * Author: Chris Lang cl...@gateworks.com
-+ *
-+ * This program is free software; you can redistribute it and/or modify
-+ * it under the terms of the GNU General Public License,
-+ * as published by the Free Software Foundation - version 2.
-+ */
-+
-+#include linux/module.h
-+#include linux/i2c.h
-+#include linux/hwmon.h
-+#include linux/hwmon-sysfs.h
-+#include linux/err.h
-+#include linux/slab.h
-+
-+#define DRV_VERSION 0.2
-+
-+enum chips { gsp };
-+
-+/* AD7418 registers */
-+#define GSP_REG_TEMP_IN   0x00
-+#define GSP_REG_VIN   0x02
-+#define GSP_REG_3P3   0x05
-+#define GSP_REG_BAT   0x08
-+#define GSP_REG_5P0   0x0b
-+#define GSP_REG_CORE  0x0e
-+#define GSP_REG_CPU1  0x11
-+#define GSP_REG_CPU2  0x14
-+#define GSP_REG_DRAM  0x17
-+#define GSP_REG_EXT_BAT   0x1a
-+#define GSP_REG_IO1   0x1d
-+#define GSP_REG_IO2   0x20
-+#define GSP_REG_PCIE  0x23
-+#define GSP_REG_CURRENT   0x26
-+#define GSP_FAN_0 0x2C
-+#define GSP_FAN_1 0x2E
-+#define GSP_FAN_2 0x30
-+#define GSP_FAN_3 0x32
-+#define GSP_FAN_4 0x34
-+#define 

Re: [OpenWrt-Devel] [PATCH] cns3xxx: fix (really this time) laguna UART config

[Imre Kaloz]

Commited.

On Thu, 11 Oct 2012 10:49:21 +0200, Tim Harvey thar...@gateworks.com  
wrote:



Properly terminate the correct platform resource for laguna UARTs

Signed-off-by: Tim Harvey thar...@gateworks.com
---
 .../cns3xxx/patches-3.3/300-laguna_support.patch   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch  
b/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch

index aca..ee2a604 100644
--- a/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch
+++ b/target/linux/cns3xxx/patches-3.3/300-laguna_support.patch
@@ -356,7 +356,6 @@
 +  .end   = CNS3XXX_UART2_BASE + SZ_4K - 1,
 +  .flags= IORESOURCE_MEM
 +  },
-+  { },
 +};
 +
 +static struct plat_serial8250_port laguna_uart_data[] = {
@@ -388,6 +387,7 @@
 +  .uartclk= 2400,
 +  .type   = PORT_16550A,
 +  },
++  { },
 +};
 +
 +static struct platform_device laguna_uart = {

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel