Re: [OpenWrt-Devel] Monitoring Downlink Queue

[Javier Domingo Cansino]

That is a linux thing, I mean, you need to know how to do that in standard
linux. Openwrt is just a normal linux system. The only difference is that
you are provided with a toolchain to generate customized images.


On Thu, Jan 28, 2016 at 5:10 PM Nimantha Baranasuriya 
wrote:

> Hi,
>
> I am new to OpenWRT and I am working on a research project for which I
> need to monitor and log the number of frames in the downlink queue of the
> WiFi interface of the router every so often. Can someone please help me to
> get this done?
>
> Thank you,
> Nimantha
> ___
> 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] API documentation of ubus

[Javier Domingo Cansino]

The only documentation you have from ubus is
https://wiki.openwrt.org/doc/techref/ubus

Apart from that, you can read procd, rpcd, uhttpd, netifd and ubus itself
to see how to use it. I had plans on further documenting it but still
didn't have time. You are welcome to further document it.

On Sat, Nov 21, 2015 at 11:53 AM Pratik Prajapati <
pratik.prajapat...@gmail.com> wrote:

> Gentle Reminder
>
> On Fri, Nov 20, 2015 at 6:29 PM, Pratik Prajapati <
> pratik.prajapat...@gmail.com> wrote:
>
>> Hi,
>>
>> Is there any API documentation of ubus available?
>>
>> If yes, where can i found those?
>>
>>
> ___
> 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

[OpenWrt-Devel] [PATCH][RPCD] paths: substitute literal with macro

[Javier Domingo Cansino]

Signed-off-by: Javier Domingo Cansino <javier...@gmail.com>
---
 main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/main.c b/main.c
index 3b6841b..7c161b5 100644
--- a/main.c
+++ b/main.c
@@ -74,8 +74,8 @@ int main(int argc, char **argv)
}
}
 
-   if (stat("/var/run/rpcd", ))
-   mkdir("/var/run/rpcd", 0700);
+   if (stat(RPC_UCI_DIR_PREFIX, ))
+   mkdir(RPC_UCI_DIR_PREFIX, 0700);
 
umask(0077);
 
-- 
2.6.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to start

[Javier Domingo Cansino]

Hi,

If you are willing to implement a simple mac protocol, you could start
exploring the Linux kernel code, the network part. There are several
manuals and books around linux networking that could be useful. After that,
you could try to compile an image for any board you are willing to use.

I have supposed you meant real hardware like a linux based implementation.
If you just intend to make a MAC protocol, and don't plan to use Linux, I
am afraid that it's going to be easier, but openwrt just works on top of
Linux (someone correct me if not...).

Also, take into account that openwrt is a set of tools, scripts and
software to create fine grained customized OSes. It uses Linux as it's
kernel, thus the first paragraph I wrote.

Cheers!

On Sat, Oct 31, 2015 at 11:08 PM Pumaridd Pumaridd 
wrote:

> Hi all,
>   I'm new in the world of openwrt. I'm a computer science student and my
> goal is to start implementing simple mac protocol on real hardware.
> I started reading some documentation but I'm loosing... If someone of you
> can help my to find the right direction of my study I will really
> appreciate.
>
> Bye all
>   Pumaridd
> ___
> 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] [PATCH libubox v2] Support broadcast sockets in usock

[Javier Domingo Cansino]

On Mon, Oct 26, 2015 at 2:16 PM John Crispin <blo...@openwrt.org> wrote:

> Hi,
>
> was about to merge this but then ... see inline
>
> On 02/10/2015 15:53, Javier Domingo Cansino wrote:
> > Signed-off-by: Javier Domingo Cansino <javier...@gmail.com>
> > ---
> >  usock.c | 4 +++-
> >  usock.h | 1 +
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/usock.c b/usock.c
> > index 6748ef3..3dd9957 100644
> > --- a/usock.c
> > +++ b/usock.c
> > @@ -42,6 +42,7 @@ static void usock_set_flags(int sock, unsigned int
> type)
> >
> >  static int usock_connect(int type, struct sockaddr *sa, int sa_len, int
> family, int socktype, bool server)
> >  {
> > + const int one = 1;
> >   int sock;
> >
> >   sock = socket(family, socktype, 0);
> > @@ -49,9 +50,10 @@ static int usock_connect(int type, struct sockaddr
> *sa, int sa_len, int family,
> >   return -1;
> >
> >   usock_set_flags(sock, type);
> > + if (socktype != SOCK_STREAM && type & USOCK_BROADCAST)
>
> should it not be
>
> if (socktype == SOCK_DGRAM  ?
>
> John
>

It is more clear with your expression, they have the same effect anyway.

>
> > + setsockopt(sock, SOL_SOCKET, SO_BROADCAST, ,
> sizeof(one));
> >
> >   if (server) {
> > - const int one = 1;
> >   setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, ,
> sizeof(one));
> >
> >   if (!bind(sock, sa, sa_len) &&
> > diff --git a/usock.h b/usock.h
> > index b0b952b..3471f2a 100644
> > --- a/usock.h
> > +++ b/usock.h
> > @@ -26,6 +26,7 @@
> >  #define USOCK_NOCLOEXEC  0x0200
> >  #define USOCK_NONBLOCK   0x0400
> >  #define USOCK_NUMERIC0x0800
> > +#define USOCK_BROADCAST  0x1000
> >  #define USOCK_IPV6ONLY   0x2000
> >  #define USOCK_IPV4ONLY   0x4000
> >  #define USOCK_UNIX   0x8000
> >
>
___
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

[Javier Domingo Cansino]

>
> People report bugs all the time, and if I'm lucky enough to have a bug
> report containing revision information, I want to maximize the
> likelihood of that revision information being useful (even if there are
> some local commits on top of that).
> Any assumptions about users thinking carefully if the revision info that
> they're posting is meaningful enough is flawed. People usually just post
> whatever is in the banner file.
> Often bug reports can be anonymous, or reporters just don't respond
> after posting the ticket. I don't want to compromise any remaining
> usefulness of such tickets.
>
> > Though, I still think that appropriate, meaningful tags will be a
> > better option to just r (which would be just svn legacy).
> > Not sure but probably both options could be used in parallel.
> A fake 'r' value is useless if I can't use it to look up the
> corresponding OpenWrt commit.
>

Supposing we are able to trace the exact base and the modifications, what
would be left?
___
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

[Javier Domingo Cansino]

>
> One way to avoid the ambiguity of the r-number would be to use
> "git describe origin/master" then even if the local master branch has
> commits, you'd get the "upstream" revision number. But, I think it's
> more important to know that there have been local changes.
>

The git-describe two liner I traced that. Anyway, we don't really need a
number from version X because it's meaningless in git.

We've talked about how we would obtain the fork point, and a solution is
been already been stated (take Bruno's, mine, combine them, etc)

It is also clear that we can create tools to make testing PRs directly from
Github/Gitlab avoiding checkouts and just applying the patches, also we are
able to run checks automatically on PRs without intervention.

What is there left?
___
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

[Javier Domingo Cansino]

>
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git anyway :)
>
​
I do use the openwrt mirror github hosts, and I suppose is mirroring that
one.

I think it's already given all the points in Git vs SVN, so I will speak
about self hosting and git interfaces.

I suppose many of you have already worked with Github, Gitlab, gitolite and
gerrit for hosting. I reviewed a book on gitolite a few years ago, I have
been using Github for past 5 years, and made some Gitlab CE self-hosted
instalations.

First of all, I don't like gerrit because of the workflow it imposes and
the limitations compared to Gitlab/Github. gitolite doesn't have a web
interface, is just a git hosting tool, which btw is used for linux dev
since kernel.org was compromised. And gitlab/github are pretty similar.

If you are not willing to change the workflow, nor giving any kind of
enhanced experience, you should probably go with gitolite. It's easy to
manage, and it allows you to manage permissions per-branch, and does even
let you deny pushes depending on the path you modify. Which I have read is
interesting for maintainers. It's a really extensible and complete hosting
tool.

However, I firmly believe that if you are going through any kind of
changing process, you should probably stick with the most accessible tool.

I would propose you installed/hired Gitlab, changed the project to git,
continue with the same workflow, and then decide a proper workflow for your
project while you get accustomed to the new interface. Later, you can
switch to using the gitlab issues / forks / merge requests.

There are tools to migrate issues between systems, so if desired,
historical issues could be maintained.

​I would however not use submodules. You can just rip off the kernel and
treat it as another project, which in my opinion is the best way of
handling multiple projects, rather than including submodules for everything.

Anyway, that last bit it's ok if you want to go with it, from my
experience, I really don't like it, but I have seen project do good with it.


-- 
Javier Domingo Cansino
___
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

[Javier Domingo Cansino]

>
> > since kernel.org  was compromised. And gitlab/github
> > are pretty similar.
>

Sure, just giving some background on where gitolite was being used and the
less-known features it has.

While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
>
You can enforce linear history by denying history rewrites. It's what they
call now protected branches (IIRC), and I think you can really enforce
that. Also, you can create hooks to check for tagging info etc.

I don't fully understand the 'remember to tag revision' thing.

I still believe for our maintenance process it's a bad idea to maintain
> the kernel as a separate git repository. With generic changes, it's easy
> to lose track of what patch has been applied in which branch, and
> syncing them can be annoying with rebases.
> Also, pulling changes is going to be confusing for users as well, since
> we will have to constantly rebase branches.
>

What I had in mind for the kernel consisted on some similar workflow to the
one gitlab uses for their stable branches. You have a branch for each
maintained kernel release, and you have all the commit's cherry-picked from
the master.

Of course, you can always use rebase and apply all the patches in order. It
is possible to have scripts that actually make sure every patch is applied,
letting you substract patch lists, etc.

Making maintainable the support for several different versions of kernel,
each one on it's branch, forking from the official repo.
___
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

[Javier Domingo Cansino]

>
> Right now, the revision number (r) is really useful to figure
> out what particular openwrt version is being used, when people report
> bugs. The commit hash cannot be used as a replacement, since it might be
> one that isn't present in the official repo.
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).
>
The tags would be the major versions and RCs. I don't believe other tags
should be used.

Apart from that, I understand that if someone cloned the SVN repo (full svn
history), created it's own server, and developed on top of a given revision
X, the same problem would arise.

I don't find this as a valid argument because that's up to the user. Either
you fork from official owrt and note down the commit you forked in to give
as a reference, or you provide full access to your source code, where you
can actually see when it forked through git merge-base --fork-point.

And of course, you can always automatically generate with help from
git-describe a relative revision from the fork-point. Anyway, it would be
up to the forkers to decide whether they want to rebase their tree or merge
your tree.

Well, we have per-target kernel patches. Patches from different targets
> might conflict with each other, or might break unrelated targets.
> Dealing with that would mean either carefully reviewing every single
> target patch to avoid negative side effects for other targets, or
> maintaining one branch per target.
> For both variants, the amount of extra work this creates in my opinion
> vastly outweighs the benefits of using git for the kernel tree.
>
> I believe that we could find a mix between per kernel version patches and
per target patches. Probably the best would be to treat the openwrt kernel
as a project forking from linux-stable (I believe it's the tarballs you are
currently using), and use that owrt kernel as a base to apply the per
target patches (at the end, each target has it's own specific patches).

I find it as repackaging the same project with different patches to add
functionality.

I'm open to changing my mind if I see some compelling arguments, but
> right now I believe the extra maintenance cost vastly outweighs the
> potential benefits.
>
My proposal of steps to migrate to git would be.
 1) openwrt to git, maintaining even the workflow as it is, giving time to
deal with all the differences to svn (such as the relative revision
crafting etc).
Once everyone is comfortable with the git based hosting, I would go for 2)
adapting the workflow to the tools git provides. We would be talking there
about how merge requests are handled, web interfaces, etc.
Finally, I would go for step 3) check how we can improve the owrt-kernel
relationship.

Of course, the 3rd step, if based in my idea, doesn't need to be done
before 1/2. Also, steps 1,2 can be done at once.
___
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

[Javier Domingo Cansino]

>
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a reason.
>

This was a way to demonstrate that the forking point is not actually a
problem SVN solves. Not having a similar revision number that collides with
the one used in official repo is now sustained by the fact that you are the
only ones using SVN.

And you think users will actually do that? Based on previous experience,
> I really don't. The way it's set up right now, people can fork as they
> wish and the scripts automatically determining the OpenWrt base version
> will just work.
>
That's the work that needs to be done, although there are plenty forks over
there with a solution to that. I have seen them at least, but I can't
provide code :(, so if someone has a solution that can share, shall
intervene here.

It's not about what you theoretically can do, it's about what users will
> end up doing.
>
That doesn't affect your workflow. At the end you will have the same
problems as you have now because people is already using git to interact
with openwrt. They provide a forking base, and there you go.


> Wow, now you're making it really confusing for everybody involved. Some
> changes live in an external git repo, some changes live as patches, and
> whenever the external repo changes we're supposed to update the revision
> in the OpenWrt tree?
>

I am really sorry but I haven't worked enough with the kernel part as to
say how maintainable would this solution be. I was just giving another
alternative to submodules.

Just in case, my advice here was not to use submodules. It was just a git
advice rather than an openwrt git based advice.


> I haven't seen any proposal that deals with the revision crafting issue
> in a practical and useful way. I also haven't seen many compelling
> arguments about what the practical benefit of these changes would be.
>
> I see repeated claims that assume that having patches in a git repo will
> make it easier to upstream stuff, and I just don't believe those claims
> without a proper explanation.
>
I find this paragraph confusing because I don't really know if you are
referring to the kernel in openwrt, or to openwrt as a whole.

In the first case, I just want to say that it is possible to work with
submodules, but it costs you brain-cpu to do it correctly most of the
times. That's why my advice against submodules. I can further expand if
someone wants to know which solutions I have seen correctly working.

In the second case, from what I do, I would find much easier to have a git
based openwrt, not for git itself (I am already using it), but for the
tools (step 2) and workflows you can have. I expand this below.


> Before you try to convince us to change the workflow, I would really
> like to see a *detailed* explanation of how this would actually help us.
> If you really believe that this would be a good fit, then you will have
> to be a lot more specific about the potential benefits.
>

The benefits of the openwrt git based developing are the next ones, based
on previous experience, using Github as a model, similar applies to Gitlab:
 - Easier to get started with openwrt trivial contributions. If I find a
typo, I can directly from the web interface fork, change and PR to the main
repo.
 - Easier tracking of the status of my patch, the issues I have submitted
and the pending work. This is mostly because UIs/workflows are pretty
complete.
 - Easier way to update my patch, less noise to the list. I always get it
wrong, and resubmitting when it is just some formatting issues is far less
noisy. With github/gitlab, I just have to checkout the branch I am sending
my patch from and do whatever I need to make it
openwrt-contribution-guidelines compliant.
 - Review of my patches. I can actually track if I have done everything
needed to get my patch accepted. Past day I submitted a simple patch to
libubox and I forgot to reorder variable declarations. Also, more clear,
non mailbox dependant patch review, In a glance I can see my patch, the
comments it has, and the conversation about specific lines, even if I am
not suscribed.
 - More user friendly. I know this might not be important for some people,
but most of the users out there willing to help, although not excelent
devs, may be able to help if they have tons of tutorials on how to use the
web interface.
 - Of course, you still can do everything as you already do, you checkout
the branch from the PR and commit it manually, and github/gitlab will
detect you merged that commit and will close the PR.

As you see, these are mostly user experience improvements. Maybe for you
make no difference at all while core developing, but I find those benefits
really worthy. I have seen others state some of them too.

Just to finish, I think this conversion from svn to git doesn't have as
main objective to make your life as core devs easier although it will

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> We currently don't have any tags for mainline trunk, since we usually
> don't directly release from it.
>

I would like to know how you usually release. Can you map a commit to a
release, if you can't, then we may use another simpler method.

$parent-$commit$dirty

That would give you info enought to checkout either the $parent, if you
don't have access to $commit, and to know that something was changed in
$commit.


> How does the script know which one is the right upstream?
>
It's hardcoded in the version script. If remote doesn't exist, I can inject
it temporarily, bad thing is that I would need to fetch upstream to be able
to compare AFAIK. If the remote does exist, I can just generate it from
there (don't need to have latest commit to know where they forked)


> If I see such a string, how do I look up the last OpenWrt commit from
> that? With the revision number, I simply start git log and search for
> @
>
The number of commits are just for people that comes from SVN to feel
comfortable. You don't really need them. You can have the number of
previous commits if you wish, but is not needed really (it might be an
indicative on how much work there is)

We could do fancy things like instead of logging the number of commits, log
the number of diff lines.

$parent-$commit-$difflines$dirty.

However I find this rather disturbing and even privacy compromising.

I think I could provide the proper solution if you tell me what you thing
would be useful for you to have.
___
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

[Javier Domingo Cansino]

>
> I have yet to see an approach for this that actually works and deals
>
with all the common scenarios where people fork OpenWrt and make a few
> local changes.
>
I see I have not enough information on what are the common use cases. For
me, these are the following:
 - User clones openwrt master, makes some work on it and has an issue.
 - Company uses openwrt release as base.
 - Company uses openwrt random commit as base.

Supposing these are the use cases you want to support, please expand if
needed, I can develop a mini script that would check upstream for the
latest commit, and give you a version information string like the one I
showed. Please tell if you want any more information there.


> And I've actually given much thought to the cost and benefits of our
> current workflow vs doing it in git. My main problem is not with the
> part of submodules vs external stuff, it's with the workflow of
> maintaining our kernel changes in a git repo directly instead of having
> patches.


I have to agree that I find pretty clean the current method, although it
can be difficult to with it develop, I understand makes it easier to
maintain it.

However, I am not willing to discuss whether to change the current kernel
patch system to a git branch releases based one, because I haven't used it
enough.

Typo fixes are the least relevant changes. Making it easier to do that
>
kind of change is not a priority, especially if other things are made worse.
>
Let's hope we don't make things worse but different, which might seem worse
at the beginning in comparison to the workflow you have been long
accustomed to.


> We have patchwork for tracking submissions, and people get notified when
> their patches are accepted or rejected.

The interface is not as clean as the github/gitlab one. And people is more
relaxed with responsive and intuitive interfaces.

Less work for the submitter, but more work for testing before
> commit/push => not a good trade-off on my opinion.
>
Let's not make it worse for the tester/committer.

I personally find the pull request workflow very cumbersome. With what
> we have now, I can just 'git am' the ones that look sane, do a final
> test build + review, and then 'git svn dcommit' the result.
> With pull requests, I'd have to take those in a private branch or
> something, then run git pull on my local machine before being able to
> test stuff. Also, this will spam the repo history with annoying merge
> commits unless I do a rebase myself.
>

I can prepare a tool that just cherry-picks changes from the PR so that you
can test them easily. You can also ask the contributor to change the shape
of the commits, and the tool would then replicate again the changes on top
of HEAD.

For the core repo, I'd rather have higher patch quality instead of more
> contributions.
>
I can't make quality better just with git, but we could introduce travis-ci
for basic testing of PRs, to report basic failures that might have slipped
off the contributor (this would come later).

This way my patch from the other day wouldn't have needed to be reviewed
until check-patch had run on it.


> The main bottleneck in core development is not users submitting patches,
> it's patch review and especially testing. In my opinion your suggestions
> make that part harder.
>
With the tools I can create I hope it will be easier to do this, also
because issues and PRs have unique IDs, we could refer to them and make
testing much more controlled. For example, using travis-ci for PRs.


> The work done by core devs is the main bottleneck, so I care about that
> a lot more than making the life of drive-by contributors easier.
>

I agree that the bottlenecks should be reduced. I think I have spotted some
ways we could make a little better these.

I think gitlab/github is a really good choice because if everything in the
development (the repo and the PRs) is done using the same tool, we can have
nice features to help you reduce the bottleneck.

I would love to sort of arrange a trial period to have experience on how
you feel the tools, what command line helpers you would need and overall
feedback on the process to make the tools more adapted to your need.

I believe we should for now concentrate on steps 1-2), git based main repo,
hosted in a service such as gitlab/github.

I can prepare a sample repo where you could interact with a contributor,
not by means of everyone sending stuff to core through there but just a few
during some days.

If you want, before doing this, I can develop the two command lines I spoke
about, so that you can generate the build version info and the
cherrypick/patch checkout tool.
___
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

[Javier Domingo Cansino]

>
> Would it be possible to track the revision number in an automated way even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might address
> the problem.
>

In git you wouldn't need such thing, the way would be to track the forking
point comparing the user history with the upstream master history, and
describing the path. The oneliner I sent before (which I now realize I
split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag
2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.
3) count how many commits are from $tag commit to $parent commit, save it
as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it as
$commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty
___
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

[Javier Domingo Cansino]

So the questions to be answered to provide a build version string are.

- Are you planning to use git tags for something? What are you needs for it?
- What information would you like to have from the build?

Examples: last upstream common commit, current commit, dirtiness,
officialness.

Also, I am looking that you are speaking about nightly tags, I wouldn't
recommend at all having those kind of tags. Nightly tags for build version
string would loose all the meaning, if you intend the build version to be
universal. It all depends on your answers to those two questions
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] libubox/binary.h design proposal

[Javier Domingo Cansino]

Hello,

I have been asked for examples and use cases. Github repo has been updated.

I do also have doubts on if it's worth it. If a library like this existed I
would be definitely using it, make conversions, does take care of
alignment, can manage unaligned data and endianness. etc.

But I am not really sure if someone apart from me would find it interesting
(long time ago I haven't seen a protocol unaligned with different
endianess).

Waiting for your feedback!

/*
 * Syntax for the function is as follows.
 *   %[p][n][a][lb][01r]{i,y,w,d,q,s}
 *
 *   All the characters that don't follow this will be treated as raw chars
 *   to be written as they are.
 *
 * Data type
 *   * i - bit
 *   * y - byte
 *   * w - 2 byte word
 *   * d - 4 byte word
 *   * q - 8 byte word
 *   * s - string without termination (use strlen()+1 in quantity to null)
 *
 * Data value
 *   * 0 - fill the specified space with zeros
 *   * 1 - fill the specified space with ones
 *   * r - fill the specified space with random data
 *
 *   String data type is not valid in this case. When quantity is also
 *   specified, use l/b to separate: %5b0 -> 5 bits of value 0
 *
 * Endianess. No conversion by default
 *   * l - little endian
 *   * b - big endian
 *
 * Alignment. No alignment by default
 *   * a - align this to it's datatype
 * bits are aligned to byte
 *
 * Quantity. One by default
 *   * n - number of same datatype (placed together)
 * this denotes length of string, padded with 0
 *
 * Pointer. Default everything is passed by value
 *   * p - specify that passed parameter is a pointer to value(s)
 *
 *   Obviously, when quantity is specified, and datatype is not bits, p
 *   is required.
 *
 * Some examples:
 *   * %4lw - 4 little endian 2 byte word
 *   * %2i  - 2 bits 'ab' from value b'00ab'
 *   * %2bi - 2 bits 'ab' from value b'00ba'
 *   * %2li - 2 bits 'ab' from value b'ab00'
 *   * %5y
 *
 * Calling functions example:
 * int32_t dw[]=[1,2,3,4]
 *
 * v = writebv("%lw%2i%ay%p4d", 2047, 3, 'n', dw);
 *
 * in a big endian computer
 * // *v = 0xff07c06e0001000200030004
 *
 * struct my_data_t {
 *   uint16_t a;
 *   uint8_t b:2;
 *   uint8_t unused1:6;
 *   uint8_t c;
 *   uint32_t d[4];
 * } *my_data;
 * char letter;
 *
 * // If we want to have all extracted from the blob
 * my_data = readbv(v, "%lw%2i%ay%p4d");
 *
 * // If we just want to extract the char
 * readb(v, "%0w%2l0i%ay%4l0d", );
 *
 * // We have aligned data, but if we removed the 'a' from %ay, we
 * wouldn't have unaligned data and this would still work.
 *
 */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] libubox/binary.h design proposal

[Javier Domingo Cansino]

After feedback in IRC, I will drop this idea, and try to go the kernel way,
supporting endianess annotated structures with sparse rules checking.

https://lwn.net/Articles/205624/

The motivation is that it's really difficult to keep in sync all the format
strings, and although there may be ways to deal with it, I rather prefer
this other design.

On Mon, Oct 5, 2015 at 10:25 AM Javier Domingo Cansino <javier...@gmail.com>
wrote:

> Hello,
>
> I have been asked for examples and use cases. Github repo has been updated.
>
> I do also have doubts on if it's worth it. If a library like this existed
> I would be definitely using it, make conversions, does take care of
> alignment, can manage unaligned data and endianness. etc.
>
> But I am not really sure if someone apart from me would find it
> interesting (long time ago I haven't seen a protocol unaligned with
> different endianess).
>
> Waiting for your feedback!
>
> /*
>  * Syntax for the function is as follows.
>  *   %[p][n][a][lb][01r]{i,y,w,d,q,s}
>  *
>  *   All the characters that don't follow this will be treated as raw chars
>  *   to be written as they are.
>  *
>  * Data type
>  *   * i - bit
>  *   * y - byte
>  *   * w - 2 byte word
>  *   * d - 4 byte word
>  *   * q - 8 byte word
>  *   * s - string without termination (use strlen()+1 in quantity to null)
>  *
>  * Data value
>  *   * 0 - fill the specified space with zeros
>  *   * 1 - fill the specified space with ones
>  *   * r - fill the specified space with random data
>  *
>  *   String data type is not valid in this case. When quantity is also
>  *   specified, use l/b to separate: %5b0 -> 5 bits of value 0
>  *
>  * Endianess. No conversion by default
>  *   * l - little endian
>  *   * b - big endian
>  *
>  * Alignment. No alignment by default
>  *   * a - align this to it's datatype
>  * bits are aligned to byte
>  *
>  * Quantity. One by default
>  *   * n - number of same datatype (placed together)
>  * this denotes length of string, padded with 0
>  *
>  * Pointer. Default everything is passed by value
>  *   * p - specify that passed parameter is a pointer to value(s)
>  *
>  *   Obviously, when quantity is specified, and datatype is not bits, p
>  *   is required.
>  *
>  * Some examples:
>  *   * %4lw - 4 little endian 2 byte word
>  *   * %2i  - 2 bits 'ab' from value b'00ab'
>  *   * %2bi - 2 bits 'ab' from value b'00ba'
>  *   * %2li - 2 bits 'ab' from value b'ab00'
>  *   * %5y
>  *
>  * Calling functions example:
>  * int32_t dw[]=[1,2,3,4]
>  *
>  * v = writebv("%lw%2i%ay%p4d", 2047, 3, 'n', dw);
>  *
>  * in a big endian computer
>  * // *v = 0xff07c06e0001000200030004
>  *
>  * struct my_data_t {
>  *   uint16_t a;
>  *   uint8_t b:2;
>  *   uint8_t unused1:6;
>  *   uint8_t c;
>  *   uint32_t d[4];
>  * } *my_data;
>  * char letter;
>  *
>  * // If we want to have all extracted from the blob
>  * my_data = readbv(v, "%lw%2i%ay%p4d");
>  *
>  * // If we just want to extract the char
>  * readb(v, "%0w%2l0i%ay%4l0d", );
>  *
>  * // We have aligned data, but if we removed the 'a' from %ay, we
>  * wouldn't have unaligned data and this would still work.
>  *
>  */
>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] scripts/checkpatch.pl: Fix deprecation warnings

[Javier Domingo Cansino]

In perl version v5.22, use of unescaped opening braces is deprecated

Signed-off-by: Javier Domingo Cansino <javier...@gmail.com>
---
 scripts/checkpatch.pl | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5e2c0b9..7805333 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2354,8 +2354,8 @@ sub process {
 
 # function brace can't be on same line, except for #defines of do while,
 # or if closed on same line
-   if (($line=~/$Type\s*$Ident\(.*\).*\s{/) and
-   !($line=~/\#\s*define.*do\s{/) and !($line=~/}/)) {
+   if (($line=~/$Type\s*$Ident\(.*\).*\s\{/) and
+   !($line=~/\#\s*define.*do\s\{/) and !($line=~/}/)) {
ERROR("OPEN_BRACE",
  "open brace '{' following function declarations 
go on the next line\n" . $herecurr);
}
@@ -2623,8 +2623,8 @@ sub process {
 ## }
 
 #need space before brace following if, while, etc
-   if (($line =~ /\(.*\){/ && $line !~ /\($Type\){/) ||
-   $line =~ /do{/) {
+   if (($line =~ /\(.*\)\{/ && $line !~ /\($Type\)\{/) ||
+   $line =~ /do\{/) {
ERROR("SPACING",
  "space required before the open brace '{'\n" . 
$herecurr);
}
@@ -2914,7 +2914,7 @@ sub process {
$dstat !~ /^for\s*$Constant$/ &&
# for (...)
$dstat !~ 
/^for\s*$Constant\s+(?:$Ident|-?$Constant)$/ &&   # for (...) bar()
$dstat !~ /^do\s*{/ &&  
# do {...
-   $dstat !~ /^\({/)   
# ({...
+   $dstat !~ /^\(\{/)  
# ({...
{
$ctx =~ s/\n*$//;
my $herectx = $here . "\n";
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] libubox/binary.h design proposal

[Javier Domingo Cansino]

Hello,

I asked Friday on IRC how to write blobs, I was suggested using
blob_raw_put from libubox/blob.h, but as I have to implement a binary
protocol that uses different endianess, non aligned data etc., I think the
best solution is creating a set of helper functions to write/read blobs.

As this is quite generic library, there might already exist some work done
that I am missing (please link!). I would love to have feedback from this
design before typing code.

I have started my work on github[1], which is basically a header file with
the following comment and some prototype ideas. The syntax I have thought
is described there, but it basically follows a printf syntax, allowing raw
chars to be written.

Cheers!

/*
 * Syntax for the function is as follows.
 *   %[n][a][lb][01r]{i,y,w,d,q,s}
 *
 *   All the characters that don't follow this will be treated as raw chars
 *   to be written as they are.
 *
 * Data type
 *   * i - bit
 *   * y - byte
 *   * w - 2 byte word
 *   * d - 4 byte word
 *   * q - 8 byte word
 *   * s - string without termination (use strlen()+1 in quantity to null)
 *
 * Data value
 *   * 0 - fill the specified space with zeros
 *   * 1 - fill the specified space with ones
 *   * r - fill the specified space with random data
 *
 *   String data type is not valid in this case
 *
 * Endianess. No conversion by default
 *   * l - little endian
 *   * b - big endian
 *
 * Alignment. No alignment by default
 *   * a - align this to it's datatype
 * bits are aligned to byte
 *
 * Quantity. One by default
 *   * n - number of same datatype (placed together)
 * this denotes length of string, padded with 0
 *
 * Some examples:
 *   * %4lw - 4 little endian 2 byte word
 *   * %2i  - 2 bits 'ab' from value b'00ab'
 *   * %2bi - 2 bits 'ab' from value b'00ba'
 *   * %2li - 2 bits 'ab' from value b'ab00'
 *
 */


[1] Github branch: https://github.com/txomon/libubox
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] libubox/binary.h design proposal

[Javier Domingo Cansino]

Hi Etienne,

Sorry if I didn't express myself correctly. I meant that I have to create
code to communicate through that protocol. I am not designing a protocol.
Anyway, I was more interested on feedback from similar libraries or about
the design of the library.

Cheers!

On Sun, Oct 4, 2015 at 10:38 PM Etienne Champetier <
champetier.etie...@gmail.com> wrote:

> Hi,
>
> 2015-10-04 22:47 GMT+02:00 Javier Domingo Cansino <javier...@gmail.com>:
>
>> Hello,
>>
>> I asked Friday on IRC how to write blobs, I was suggested using
>> blob_raw_put from libubox/blob.h, but as I have to implement a binary
>> protocol that uses different endianess, non aligned data etc., I think the
>> best solution is creating a set of helper functions to write/read blobs.
>>
>
> I don't know what you really want to do, but have you looked at protobuf?
> https://en.wikipedia.org/wiki/Protocol_Buffers
>
>
>
>>
>> As this is quite generic library, there might already exist some work
>> done that I am missing (please link!). I would love to have feedback from
>> this design before typing code.
>>
>> I have started my work on github[1], which is basically a header file
>> with the following comment and some prototype ideas. The syntax I have
>> thought is described there, but it basically follows a printf syntax,
>> allowing raw chars to be written.
>>
>> Cheers!
>>
>> /*
>>  * Syntax for the function is as follows.
>>  *   %[n][a][lb][01r]{i,y,w,d,q,s}
>>  *
>>  *   All the characters that don't follow this will be treated as raw
>> chars
>>  *   to be written as they are.
>>  *
>>  * Data type
>>  *   * i - bit
>>  *   * y - byte
>>  *   * w - 2 byte word
>>  *   * d - 4 byte word
>>  *   * q - 8 byte word
>>  *   * s - string without termination (use strlen()+1 in quantity to null)
>>  *
>>  * Data value
>>  *   * 0 - fill the specified space with zeros
>>  *   * 1 - fill the specified space with ones
>>  *   * r - fill the specified space with random data
>>  *
>>  *   String data type is not valid in this case
>>  *
>>  * Endianess. No conversion by default
>>  *   * l - little endian
>>  *   * b - big endian
>>  *
>>  * Alignment. No alignment by default
>>  *   * a - align this to it's datatype
>>  * bits are aligned to byte
>>  *
>>  * Quantity. One by default
>>  *   * n - number of same datatype (placed together)
>>  * this denotes length of string, padded with 0
>>  *
>>  * Some examples:
>>  *   * %4lw - 4 little endian 2 byte word
>>  *   * %2i  - 2 bits 'ab' from value b'00ab'
>>  *   * %2bi - 2 bits 'ab' from value b'00ba'
>>  *   * %2li - 2 bits 'ab' from value b'ab00'
>>  *
>>  */
>>
>>
>> [1] Github branch: https://github.com/txomon/libubox
>>
>> ___
>> 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

[OpenWrt-Devel] [PATCH libubox v2] Support broadcast sockets in usock

[Javier Domingo Cansino]

Signed-off-by: Javier Domingo Cansino <javier...@gmail.com>
---
 usock.c | 4 +++-
 usock.h | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/usock.c b/usock.c
index 6748ef3..3dd9957 100644
--- a/usock.c
+++ b/usock.c
@@ -42,6 +42,7 @@ static void usock_set_flags(int sock, unsigned int type)
 
 static int usock_connect(int type, struct sockaddr *sa, int sa_len, int 
family, int socktype, bool server)
 {
+   const int one = 1;
int sock;
 
sock = socket(family, socktype, 0);
@@ -49,9 +50,10 @@ static int usock_connect(int type, struct sockaddr *sa, int 
sa_len, int family,
return -1;
 
usock_set_flags(sock, type);
+   if (socktype != SOCK_STREAM && type & USOCK_BROADCAST)
+   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, , sizeof(one));
 
if (server) {
-   const int one = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, , sizeof(one));
 
if (!bind(sock, sa, sa_len) &&
diff --git a/usock.h b/usock.h
index b0b952b..3471f2a 100644
--- a/usock.h
+++ b/usock.h
@@ -26,6 +26,7 @@
 #define USOCK_NOCLOEXEC0x0200
 #define USOCK_NONBLOCK 0x0400
 #define USOCK_NUMERIC  0x0800
+#define USOCK_BROADCAST0x1000
 #define USOCK_IPV6ONLY 0x2000
 #define USOCK_IPV4ONLY 0x4000
 #define USOCK_UNIX 0x8000
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] UML not working in master

[Javier Domingo Cansino]

Doesn't seem like 3.18 has something that 4.0 or 4.1 have, although it
might be interesting for proper UML support in CC.

I would just submit the patch as it is, to have it included in master ASAP.
Although the migration to any of the 4.x kernels does seem
straightforward...

It's up to you =)

On Sat, Sep 26, 2015 at 11:35 PM Martin Tippmann <martin.tippm...@gmail.com>
wrote:

> 2015-09-26 20:48 GMT+02:00 Javier Domingo Cansino <javier...@gmail.com>:
> > Hi Bastian,
> >
> > I have patched, compiled correctly, and working alright! =)
> >
> > You should really send that patch upstream!
>
> Hi,
>
> it's already fixed in the Kernel since June:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30b11ee9ae23d78de66b9ae315880af17a64ba83
> - But it's not in Kernel 3.18
>
> Maybe it's better to just raise the Kernel version? Or should I submit
> the patch to the list?
>
> regards
> Martin
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] UML not working in master

[Javier Domingo Cansino]

Hi Bastian,

I have patched, compiled correctly, and working alright! =)

You should really send that patch upstream!

On Sat, Sep 26, 2015 at 5:39 PM Bastian Bittorf <bitt...@bluebottle.com>
wrote:

> * Javier Domingo Cansino <javier...@gmail.com> [26.09.2015 13:26]:
> > Hi,
> >
> > I wanted to setup for some tests an environment running uml, and I found
> > it's not compiling on master with default config. The error seems similar
> > to a previous one I found in the bug tracker.
>
> IMHO this is a macro problem and we locally have this fix running:
>
> https://github.com/glycoknob/builder/commit/4dbb2911ec890ff698e1df6cad86584b5628f99f
>
> please test and report, we can send it if it's useful for others too.
>
> bye, bastian
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] UML not working in master

[Javier Domingo Cansino]

Hi,

I wanted to setup for some tests an environment running uml, and I found
it's not compiling on master with default config. The error seems similar
to a previous one I found in the bug tracker.

https://dev.openwrt.org/ticket/870

Is anyone actually maintaining UML or managed to make it work? What other
ways of testing without a device would you propose? I had thought on a qemu
kvm x86 image if there is no other way, but the UML seemed like the most
straightforward to be able to develop in the local machine.

Cheers!

The logs/target/linux/install.txt has the following output:
make[3]: Entering directory '/home/javier/projects/openwrt/target/linux'
make[4]: Entering directory '/home/javier/projects/openwrt/target/linux/uml'
/home/javier/projects/openwrt/scripts/kconfig.pl  +
/home/javier/projects/openwrt/target/linux/generic/config-3.18
/home/javier/projects/openwrt/target/linux/uml/config/x86_64 >
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.target
awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}'
/home/javier/projects/openwrt/.config >>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.target
echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.target
echo "# CONFIG_KALLSYMS_ALL is not set" >>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.target
echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.target
/home/javier/projects/openwrt/scripts/metadata.pl kconfig
/home/javier/projects/openwrt/tmp/.packageinfo
/home/javier/projects/openwrt/.config 3.18 >
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.override
/home/javier/projects/openwrt/scripts/kconfig.pl 'm+' '+'
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.target
/dev/null
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.override
>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config
mv
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.old
grep -v INITRAMFS
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config.old
>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config
echo 'CONFIG_INITRAMFS_SOURCE=""' >>
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config
rm -rf
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/modules
export MAKEFLAGS= ; [ -d
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/user_headers
] || make -C
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21
HOSTCFLAGS="-O2 -I/home/javier/projects/openwrt/staging_dir/host/include
-I/home/javier/projects/openwrt/staging_dir/host/usr/include -Wall
-Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="" ARCH="um"
KBUILD_HAVE_NLS=no CONFIG_SHELL="bash" V='' CC="ccache gcc"
INSTALL_HDR_PATH=/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/user_headers
headers_install
. /home/javier/projects/openwrt/include/shell.sh; grep '=[ym]'
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.config
| LC_ALL=C sort | md5s >
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.vermagic
touch
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21/.configured
rm -f
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/root-uml/init
make -C
/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21
HOSTCFLAGS="-O2 -I/home/javier/projects/openwrt/staging_dir/host/include
-I/home/javier/projects/openwrt/staging_dir/host/usr/include -Wall
-Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="" ARCH="um"
KBUILD_HAVE_NLS=no CONFIG_SHELL="bash" V='' CC="ccache gcc" all modules
make[5]: Entering directory
'/home/javier/projects/openwrt/build_dir/target-x86_64_musl-1.1.11/linux-uml/linux-3.18.21'
scripts/kconfig/conf --silentoldconfig arch/x86/um/Kconfig
net/sched/Kconfig:43: warning: menuconfig statement without prompt
#
# configuration written to .config
#
  CHK include/generated/uapi/linux/version.h
make[6]: 'arch/x86/um/user-offsets.s' is up to date.
  CHK include/config/kernel.release
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
:  CHK

Re: [OpenWrt-Devel] [PATCH] [SIGNED-OFF] Add initial support for WeIO board

[Javier Domingo Cansino]

They will eventually do it, I suppose they where mainly focused on the
release until now =)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Presentation on Linux Containers (LXC)

[Javier Domingo Cansino]

Thanks for sharing!!

On Thu, Jun 25, 2015 at 8:31 PM Eric Schultz eschu...@prplfoundation.org
wrote:

 I wanted to let folks know about an interesting presentation from
 yesterday's global OpenWrt/prpl ecosystem meeting. Luka Perkov presented on
 his work in adding support for Linux Containers (LXC) to OpenWrt, including
 a LuCI interface. The meeting was recorded and posted on YouTube for anyone
 who wants to watch. The video is at https://youtu.be/O729iS5rgkA

 If you're interested in understand how to use LXC on OpenWrt, this is a
 great start!

 Eric

 --
 Eric Schultz, Community Manager, prpl Foundation
 http://www.prplfoundation.org
 eschu...@prplfoundation.org
 cell: 920-539-0404
 skype: ericschultzwi
 @EricPrpl
  ___
 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] wrong configured spam-filter for openwrt-dev

[Javier Domingo Cansino]

AFAIK in kernel they make spam filter by forbidding html emails (just
plaintext), wouldn't it be better to have it like that?

On Fri, May 1, 2015 at 11:44 AM, edgar.sol...@web.de wrote:

 On 30.04.2015 12:48, Bastian Bittorf wrote:
  while sending a mail to openwrt-dev,
  i got this answer, which doesnt make any sense,
  because the list only accepts registered users anyway:
 
  openwrt-devel@lists.openwrt.org: host mail.openwrt.org[78.24.191.176]
  said: 554 5.7.1 Service unavailable; Client host [176.9.57.138] blocked
  using bl.spamcop.net; Blocked - see
 http://www.spamcop.net/bl.shtml?176.9.57.138
  (in reply to RCPT TO command)
 
  so: first check, if the user is 'registered', if not ask do spamchecking.
  who feels responsible for that?
 

 inconvenient, true. but comprehensible as email has no sender
 verification, so anybody could write an email to the list and use your
 address in the FROM: field.

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




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

Re: [OpenWrt-Devel] OpenWrt documentation team

[Javier Domingo Cansino]

As far as I know, regarding documentation, there is no a specific group of
people. I just edit the wiki whenever I see something is not contained and
I can explain it correctly.

On Tue, Apr 14, 2015 at 10:20 PM Eric Schultz eschu...@prplfoundation.org
wrote:

 All,

 I'm looking to improve some of the documentation around OpenWrt,
 particularly related to unique OpenWrt features like jails, procd, uci,
 etc. Before I go around developing that individually, I think it'd be great
 to work collaboratively on this with others. Is there OpenWrt have a team
 focused on developing documentation? I've also only been involved for a
 short time so there could be one that I just hadn't met yet.

 Thanks,

 Eric

 --
 Eric Schultz, Community Manager, prpl Foundation
 http://www.prplfoundation.org
 eschu...@prplfoundation.org
 cell: 920-539-0404
 skype: ericschultzwi
 @EricPrpl
  ___
 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

[OpenWrt-Devel] [PATCH] Simple http server to expose opkg packages and images from bin/

[Javier Domingo Cansino]

I have created a python script to make easily available packages under bin/
easier. I got sick of installing a web server, or move the packages, or
configure it. So I just thought that a python based solution based on the
scripts/ folder would be the best solution.

Hope you like it!

---
 scripts/package-server.py | 50 +++
 1 file changed, 50 insertions(+)
 create mode 100755 scripts/package-server.py

diff --git a/scripts/package-server.py b/scripts/package-server.py
new file mode 100755
index 000..3954781
--- /dev/null
+++ b/scripts/package-server.py
@@ -0,0 +1,50 @@
+#!/usr/bin/env python
+from __future__ import print_function
+import operator
+import os
+import sys
+
+try:
+from SimpleHTTPServer import SimpleHTTPRequestHandler as Handler
+except ImportError:
+from http.server import SimpleHTTPRequestHandler as Handler
+try:
+from SocketServer import TCPServer
+except ImportError:
+from socketserver import TCPServer
+
+PORT = 80
+
+
+def find_last_modification_date(path):
+time = 0
+for root, dirs, files in os.walk(path):
+for path in files:
+_, _, _, _, _, _, _, _, last_m, _ = os.stat(
+os.path.join(root, path))
+time = time if time  last_m else last_m
+return time
+
+
+(dirpath, dirnames, _) = next(os.walk(os.path.join(os.path.dirname(__file__),
+   '../bin')))
+
+m_times = {}
+
+for dir in dirnames:
+path = os.path.join(dirpath, dir)
+m_times[path] = find_last_modification_date(path)
+dir, m_path = sorted(m_times.items(), key=operator.itemgetter(1),
+ reverse=True)[0]
+dir = os.path.relpath(dir)
+print('Selecting', dir, 'as working dir for', m_path, 'modification date.')
+os.chdir(dir)
+
+try:
+httpd = TCPServer((, PORT), Handler)
+except PermissionError:
+
+sys.stderr.write('Permission denied for listening in port %d\n' % PORT)
+sys.exit(1)
+print(HTTP server started at port, PORT)
+httpd.serve_forever()
-- 
2.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH V2] scripts: python based server for opkg packages and .bin

[Javier Domingo Cansino]

This patch adds a small script that will expose the built packages and the
images to ease opkg and sysupgrade use during development. Compatible with
Python2 and Python3.

---
 scripts/package-server.py | 50 +++
 1 file changed, 50 insertions(+)
 create mode 100755 scripts/package-server.py

diff --git a/scripts/package-server.py b/scripts/package-server.py
new file mode 100755
index 000..3954781
--- /dev/null
+++ b/scripts/package-server.py
@@ -0,0 +1,50 @@
+#!/usr/bin/env python
+from __future__ import print_function
+import operator
+import os
+import sys
+
+try:
+from SimpleHTTPServer import SimpleHTTPRequestHandler as Handler
+except ImportError:
+from http.server import SimpleHTTPRequestHandler as Handler
+try:
+from SocketServer import TCPServer
+except ImportError:
+from socketserver import TCPServer
+
+PORT = 80
+
+
+def find_last_modification_date(path):
+time = 0
+for root, dirs, files in os.walk(path):
+for path in files:
+_, _, _, _, _, _, _, _, last_m, _ = os.stat(
+os.path.join(root, path))
+time = time if time  last_m else last_m
+return time
+
+
+(dirpath, dirnames, _) = next(os.walk(os.path.join(os.path.dirname(__file__),
+   '../bin')))
+
+m_times = {}
+
+for dir in dirnames:
+path = os.path.join(dirpath, dir)
+m_times[path] = find_last_modification_date(path)
+dir, m_path = sorted(m_times.items(), key=operator.itemgetter(1),
+ reverse=True)[0]
+dir = os.path.relpath(dir)
+print('Selecting', dir, 'as working dir for', m_path, 'modification date.')
+os.chdir(dir)
+
+try:
+httpd = TCPServer((, PORT), Handler)
+except PermissionError:
+
+sys.stderr.write('Permission denied for listening in port %d\n' % PORT)
+sys.exit(1)
+print(HTTP server started at port, PORT)
+httpd.serve_forever()
-- 
2.3.2

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

Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration

[Javier Domingo Cansino]

Hey!! How long!!!

I have narrowed down the problem to the kernel, as it doesn't even do an
early_printk. I compiled manually the kernel from Xilinx's latest tag, and
substituted it in the SD (leaving the rest of openwrt generated files: fs,
uboot and FSBL), and managed to print some traces till crashing. Therefore,
the problem is the uImage.

John updated kernels a while ago, and I thought that as Xilinx is
submitting patches upstream, maybe there was already enough support
upstream (in one of the latest releases) to avoid a patch. I tested that
but didn't get it working, so I will at the end really need to dissect the
latest Xilinx diff to know the problem.

I haven't been in the kernel world for a long time (and never been good
really) so I will need my time to be able to cleanly divide the patches.
Also, I had thought about the other method, disabling openwrt patches to
find out the problem, but at the end the Xilinx diffs would be needed.

The Xilinx code basically focuses on it's main architectures. Microblaze,
PowerPC and arm now. I could be leaving the microblaze / powerPC out of the
quiz, but I would still need to know what is failing. They have some
driver, as the icap one, and some support for their devices.

If you wish to, I can upload the latest relevant diff I can obtain to
github and we can iterate over it.



On Thu, Mar 12, 2015 at 11:00 PM Roman Yeryomin leroi.li...@gmail.com
wrote:

 Hi!

 Sorry I was not replying. Was busy changing my day job.

 So... your board is configured to use some rsa boot, what is probably
 is some signed image. And u-boot environment is real mess :)
 I suggest you to try configuring to use regular nandboot. AFAIK, you
 can just type nandboot (or whichever storage you use) in u-boot
 console, not changing the environment.

 Regards,
 Roman

 On 22 January 2015 at 02:55, Javier Domingo Cansino javier...@gmail.com
 wrote:
  Ok, I have narrowed the problem to something with the compilation of the
  kernel. I think it's more an incompatibility between xilinx and linux
  patches, because the kernel fails to boot even if build by hand from the
  build_dir.
 
  I will try to split the patch in more digestible parts, and see if I
 catch
  the error... Or maybe disable the openwrt patches and see where they can
 be
  colliding.
 
  On Wed, Jan 21, 2015 at 1:24 AM, Javier Domingo Cansino
  javier...@gmail.com wrote:
 
  After hitting against this wall for a lot, I found a bug in my few lines
  of code, I was creating the uImage file from vmlinux instead of from
  zImage[1].
 
  I am still doing something wrong, because substituting the uImage
  generated from buildroot in the SD card (and leaving the rest of the
 files),
  makes at least the kernel boot, although crashes in sec 0.00, at
 least
  prints booting.
 
  I have discovered that after Starting kernel ... there should be a
  Uncompressing Linux... done, booting the kernel. line. So I am still
 doing
  something wrong on the uImage generation, and I don't know what.
 
  Moreover, I have compiled the uImage like the following, and it get's to
  the kernel panic at least:
  make -j9 HOSTCC=/usr/bin/gcc HOSTCFLAGS= ARCH=arm  CROSS_COMPILE=
  /home/javier/proyectos/master/master-sce/buildroot/output/
 host/usr/bin/arm-buildroot-linux-uclibcgnueabi-
  LOADADDR=0x8000 uImage
 
  If you could tell me which should be the Image/BuildKernel part, I would
  be really appreciate it.
 
  target/linux/zynq/image/Makefile
  ===
 
  include $(TOPDIR)/rules.mk
  include $(INCLUDE_DIR)/image.mk
 
  define Build/Compile
   $(call Build/Compile/Default, zynq_zed.dtb)
  endef
 
  define Image/BuildKernel/Initramfs
   (cd $(TARGET_DIR); \
find . | cpio -o -H newc | gzip -9 $(KDIR)/zedboard-rootfs.cpio.gz
 )
   mkimage -A arm -T ramdisk -C none -d $(KDIR)/zedboard-rootfs.cpio.gz
 \
$(BIN_DIR)/zedboard-uramdisk.image.gz
  endef
 
  define Image/BuildKernel
   mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 \
   -n 'ARM OpenWrt Linux-$(LINUX_VERSION)' \
   -d $(LINUX_DIR)/arch/arm/boot/zImage
 $(BIN_DIR)/zedboard-uImage
  endef
 
  define Image/Prepare
   $(LINUX_DIR)/scripts/dtc/dtc -O dtb \
$(LINUX_DIR)/arch/arm/boot/dts/zynq-zed.dts 
 $(BIN_DIR)/zedboard.dtb
  endef
 
  $(eval $(call BuildImage))
 
  ===
 
  [1] Bug I should have found a lot of time ago:
  https://github.com/txomon/openwrt/commit/5e882bc2f14580f62a6ad78ddc5703
 3d207261f9
 
  Cheers
 
  On Sun, Jun 29, 2014 at 1:35 PM, Javier Domingo Cansino
  javier...@gmail.com wrote:
 
  I have manually executed the boot sequence in the uboot, and the result
  is that it fails on the command bootm loados. Any idea on how to debug
 what
  can be wrong?
 
  Cheers and I will keep searching,
 
  Javier Domingo Cansino
 
  zynq-uboot fatload mmc 0 0x300 uImage
  reading uImage
  4582152 bytes read in 405 ms (10.8 MiB/s)
  zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb
  reading devicetree.dtb

Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration

[Javier Domingo Cansino]

​After hitting against this wall for a lot, I found a bug in my few lines
of code, I was creating the uImage file from vmlinux instead of from
zImage[1].

I am still doing something wrong, because substituting the uImage generated
from buildroot in the SD card (and leaving the rest of the files), makes at
least the kernel boot, although crashes in sec 0.00, at least prints
booting.

I have discovered that after Starting kernel ... there should be a
Uncompressing Linux... done, booting the kernel. line. So I am still
doing something wrong on the uImage generation, and I don't know what.

Moreover, I have compiled the uImage like the following, and it get's to
the kernel panic at least:
make -j9 HOSTCC=/usr/bin/gcc HOSTCFLAGS= ARCH=arm  CROSS_COMPILE=
/home/javier/proyectos/master/master-sce/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-
LOADADDR=0x8000 uImage

If you could tell me which should be the Image/BuildKernel part, I would be
really appreciate it.

target/linux/zynq/image/Makefile
===

include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/image.mk

define Build/Compile
$(call Build/Compile/Default, zynq_zed.dtb)
endef

define Image/BuildKernel/Initramfs
(cd $(TARGET_DIR); \
 find . | cpio -o -H newc | gzip -9 $(KDIR)/zedboard-rootfs.cpio.gz )
mkimage -A arm -T ramdisk -C none -d $(KDIR)/zedboard-rootfs.cpio.gz \
 $(BIN_DIR)/zedboard-uramdisk.image.gz
endef

define Image/BuildKernel
mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 \
-n 'ARM OpenWrt Linux-$(LINUX_VERSION)' \
-d $(LINUX_DIR)/arch/arm/boot/zImage $(BIN_DIR)/zedboard-uImage
endef

define Image/Prepare
$(LINUX_DIR)/scripts/dtc/dtc -O dtb \
 $(LINUX_DIR)/arch/arm/boot/dts/zynq-zed.dts  $(BIN_DIR)/zedboard.dtb
endef

$(eval $(call BuildImage))

===

[1] Bug I should have found a lot of time ago:
https://github.com/txomon/openwrt/commit/5e882bc2f14580f62a6ad78ddc57033d207261f9
​

Cheers

On Sun, Jun 29, 2014 at 1:35 PM, Javier Domingo Cansino javier...@gmail.com
 wrote:

 ​I have manually executed the boot sequence in the uboot, and the result
 is that it fails on the command bootm loados. Any idea on how to debug what
 can be wrong?

 Cheers and I will keep searching,

 Javier Domingo Cansino

 zynq-uboot fatload mmc 0 0x300 uImage
 reading uImage
 4582152 bytes read in 405 ms (10.8 MiB/s)
 zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb
 reading devicetree.dtb
 2739 bytes read in 15 ms (177.7 KiB/s)
 zynq-uboot fatload mmc 0 0x200 uramdisk.image.gz
 reading uramdisk.image.gz
 796339 bytes read in 87 ms (8.7 MiB/s)
 zynq-uboot help bootm
 bootm - boot application image from memory

 Usage:
 bootm [addr [arg ...]]
 - boot application image stored in memory
 passing arguments 'arg ...'; when booting a Linux kernel,
 'arg' can be the address of an initrd image
 When booting a Linux kernel which requires a flat device-tree
 a third argument is required which is the address of the
 device-tree blob. To boot that kernel without an initrd image,
 use a '-' for the second argument. If you do not pass a third
 a bd_info struct will be passed instead

 For the new multi component uImage format (FIT) addresses
 must be extened to include component or configuration unit name:
 addr:subimg_uname - direct component image specification
 addr#conf_uname   - configuration specification
 Use iminfo command to get the list of existing component
 images and configurations.

 Sub-commands to do part of the bootm sequence.  The sub-commands must be
 issued in the order below (it's ok to not issue all sub-commands):
 start [addr [arg ...]]
 loados  - load OS image
 ramdisk - relocate initrd, set env initrd_start/initrd_end
 fdt - relocate flat device tree
 cmdline - OS specific command line processing/setup
 bdt - OS specific bd_t processing
 prep- OS specific prep before relocation or go
 go  - start OS
 zynq-uboot bootm start 0x300 0x200 0x2A0
 ## Booting kernel from Legacy Image at 0300 ...
Image Name:   ARM OpenWrt Linux-3.13.7
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4582088 Bytes = 4.4 MiB
Load Address: 8000
Entry Point:  8000
Verifying Checksum ... OK
 ## Loading init Ramdisk from Legacy Image at 0200 ...
Image Name:
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:796275 Bytes = 777.6 KiB
Load Address: 
Entry Point:  
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 02a0
Booting using the fdt blob at 0x2a0
 zynq-uboot bootm loados
Loading Kernel Image ...




-- 
Javier Domingo Cansino
___
openwrt-devel mailing list
openwrt-devel

Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration

[Javier Domingo Cansino]

I am still stuck on this.

I think that the failing point here is the kernel image load, but the
loading in the part of uboot.

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

Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration

[Javier Domingo Cansino]

​I have manually executed the boot sequence in the uboot, and the result is
that it fails on the command bootm loados. Any idea on how to debug what
can be wrong?

Cheers and I will keep searching,

Javier Domingo Cansino

zynq-uboot fatload mmc 0 0x300 uImage
reading uImage
4582152 bytes read in 405 ms (10.8 MiB/s)
zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb
reading devicetree.dtb
2739 bytes read in 15 ms (177.7 KiB/s)
zynq-uboot fatload mmc 0 0x200 uramdisk.image.gz
reading uramdisk.image.gz
796339 bytes read in 87 ms (8.7 MiB/s)
zynq-uboot help bootm
bootm - boot application image from memory

Usage:
bootm [addr [arg ...]]
- boot application image stored in memory
passing arguments 'arg ...'; when booting a Linux kernel,
'arg' can be the address of an initrd image
When booting a Linux kernel which requires a flat device-tree
a third argument is required which is the address of the
device-tree blob. To boot that kernel without an initrd image,
use a '-' for the second argument. If you do not pass a third
a bd_info struct will be passed instead

For the new multi component uImage format (FIT) addresses
must be extened to include component or configuration unit name:
addr:subimg_uname - direct component image specification
addr#conf_uname   - configuration specification
Use iminfo command to get the list of existing component
images and configurations.

Sub-commands to do part of the bootm sequence.  The sub-commands must be
issued in the order below (it's ok to not issue all sub-commands):
start [addr [arg ...]]
loados  - load OS image
ramdisk - relocate initrd, set env initrd_start/initrd_end
fdt - relocate flat device tree
cmdline - OS specific command line processing/setup
bdt - OS specific bd_t processing
prep- OS specific prep before relocation or go
go  - start OS
zynq-uboot bootm start 0x300 0x200 0x2A0
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   ARM OpenWrt Linux-3.13.7
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4582088 Bytes = 4.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0200 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:796275 Bytes = 777.6 KiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a0
   Booting using the fdt blob at 0x2a0
zynq-uboot bootm loados
   Loading Kernel Image ...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration

[Javier Domingo Cansino]

I have found that I was compiling u-boot with a wrong config. Anyway, I
have advanced now till the next challenge.

same output as before, but now:


## Flattened Device Tree blob at 02a0
   Booting using the fdt blob at 0x2a0
   Loading Kernel Image ... OK
   Loading Ramdisk to 1fa6d000, end 1fb2f649 ... OK
   Loading Device Tree to 1fa69000, end 1fa6cab2 ... OK

Starting kernel
​ ...

So I suppose now there is really something wrong with the kernel. I have
repeated the steps by hand, and now it stops printing after the Starting
kernel ... line.

I have enabled early_prinks, ​and all those things I have been said to. May
it be due to the kernel not printing to the right device? Is there any way
to check that?

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

Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration

[Javier Domingo Cansino]

Hi,

I have tried the buildroot build, and have its output. Still no idea
on what I am doing wrong though...

I think it's something with the way I have packaged the kernel, but
still not coming up with the problem...


--- My failing output
In:serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
Device: zynq_sdhci
Manufacturer ID: 27
OEM: 5048
Name: SD04G
Tran Speed: 5000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit
reading uEnv.txt
** Unable to read file uEnv.txt **
Copying Linux from SD to RAM...
reading uImage
4582152 bytes read in 443 ms (9.9 MiB/s)
reading devicetree.dtb
2739 bytes read in 15 ms (177.7 KiB/s)
reading uramdisk.image.gz
796339 bytes read in 89 ms (8.5 MiB/s)
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   ARM OpenWrt Linux-3.13.7
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4582088 Bytes = 4.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0200 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:796275 Bytes = 777.6 KiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a0
   Booting using the fdt blob at 0x2a0
   Loading Kernel Image ...


--- Buildroot working output
Device: zynq_sdhci
Manufacturer ID: 27
OEM: 5048
Name: SD04G
Tran Speed: 5000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit
reading uEnv.txt
** Unable to read file uEnv.txt **
Copying Linux from SD to RAM...
reading uImage
3593344 bytes read in 349 ms (9.8 MiB/s)
reading devicetree.dtb
7400 bytes read in 16 ms (451.2 KiB/s)
reading uramdisk.image.gz
937093 bytes read in 101 ms (8.8 MiB/s)
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   Linux-3.13.0-xilinx
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3593280 Bytes = 3.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0200 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:937029 Bytes = 915.1 KiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a0
   Booting using the fdt blob at 0x2a0
   Loading Kernel Image ... OK
   Loading Ramdisk to 1fa4a000, end 1fb2ec45 ... OK
   Loading Device Tree to 1fa45000, end 1fa49ce7 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.13.0-xilinx (javier@theoden) (gcc
version 4.7.3 (Buildroot 2014.05-dirty) ) #1 SMP PREEMPT Sun Jun 1
15:28:49 CEST 2014
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Xilinx Zynq
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] PERCPU: Embedded 8 pages/cpu @c1037000 s10688 r8192 d13888 u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 130048
[0.00] Kernel command line: console=ttyPS0,115200
root=/dev/ram rw earlyprintk
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Memory: 506264K/524288K available (4865K kernel code,
310K rwdata, 1708K rodata, 198K init, 5345K bss, 18024K reserved, 0K
highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
[0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc0673818   (6575 kB)
[0.00]   .init : 0xc0674000 - 0xc06a59c0   ( 199 kB)
[0.00]   .data : 0xc06a6000 - 0xc06f3ad0   ( 311 kB)
[0.00].bss : 0xc06f3adc - 0xc0c2c1b0   (5346 kB)

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