Openwrt repository?

[Paul Carmichael]

My power supply failed ie; the voltage dropped, which has resulted in a complete re-install. Seeing as I lost everything, I've forgotten which is the correct repository in the Openwrt tree. Someone told me before, but I can't find the message now.

Cheers.

Paul.

[Andrew Scheller]

You don't say which version of OpenWRT you're using, but I wonder if
you mean this? (which AFAIK is correct for bb-bin-1.4)
http://sites.google.com/site/bifferboard/Home/howto/install-opkg-files

Lurch

> --
> You received this because you are subscribed to the "Bifferboard" Google
> group - honest!
> To unsubscribe from this group, send email to
> bifferboard...@googlegroups.com

[biff...@yahoo.co.uk]

It's recommended to compile from source, I just updated the
instructions recently:
http://sites.google.com/site/bifferboard/openwrt-svn

By some coincidence, 3 hours ago my init script fix seems to have been
applied:
https://dev.openwrt.org/browser/trunk/target/linux/rdc/base-files/lib/preinit

So try to hold back the disbelief, but the OpenWrt tarball build
actually works now, with kernel 2.6.30.10, however don't expect any of
the functionality I added to 2.6.30.5 to be there, but might be useful
if you want basic Samba NAS setup or whatever. I'm not saying it does
anything useful, but it should boot.

Oh yes, and you still need to follow my instructions above, because
you need console and NULL devices.

I have this setup running over ubifs on the on-board flash, but the
setup's far too complicated to document at the moment, but will do at
some point. I really want to know why I can't get JFFS working
though, still haven't figured that one out.

regards,
Biff.

On Feb 4, 12:25 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> You don't say which version of OpenWRT you're using, but I wonder if

> you mean this? (which AFAIK is correct for bb-bin-1.4)http://sites.google.com/site/bifferboard/Home/howto/install-opkg-files
>
> Lurch

[Andrew Scheller]

> By some coincidence, 3 hours ago my init script fix seems to have been
> applied:
> https://dev.openwrt.org/browser/trunk/target/linux/rdc/base-files/lib/preinit

https://dev.openwrt.org/browser/trunk/target/linux/rdc/base-files/lib/preinit/05_set_ether_mac_rdc#L18
Should line 18 be:
[ "$mac1" = "FF:FF:FF:FF:FF:FF" -o "$mac1" = "0:0:0:0:0:0" ] && unset mac1
(i.e. -o "$mac1" instead of -o "$mac0")
I'm not a OpenWRT developer, so wouldn't know who/how to contact!

> So try to hold back the disbelief, but the OpenWrt tarball build
> actually works now, with kernel 2.6.30.10,

Cool, you finally got there, congrats! :) Something else for me to
look at if I find time...

Lurch

[biff...@yahoo.co.uk]

On Feb 4, 1:24 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> > By some coincidence, 3 hours ago my init script fix seems to have been
> > applied:

> >https://dev.openwrt.org/browser/trunk/target/linux/rdc/base-files/lib...
>
> https://dev.openwrt.org/browser/trunk/target/linux/rdc/base-files/lib...

> Should line 18 be:
> [ "$mac1" = "FF:FF:FF:FF:FF:FF" -o "$mac1" = "0:0:0:0:0:0" ] && unset mac1
> (i.e. -o "$mac1" instead of -o "$mac0")
> I'm not a OpenWRT developer, so wouldn't know who/how to contact!

I'd forward it, but devs only want patches, anything else tends to get
dropped on the floor (hint, hint)

Biff.

[Andrew Scheller]

>> I'm not a OpenWRT developer, so wouldn't know who/how to contact!
>
> I'd forward it, but devs only want patches, anything else tends to get
> dropped on the floor (hint, hint)

I can't create a patch, cos I don't have the source code on my
machine. But it's basically:
trunk/target/linux/rdc/base-files/lib/preinit/05_set_ether_mac_rdc
- [ "$mac1" = "FF:FF:FF:FF:FF:FF" -o "$mac0" =

"0:0:0:0:0:0" ] && unset mac1

+ [ "$mac1" = "FF:FF:FF:FF:FF:FF" -o "$mac1" =

"0:0:0:0:0:0" ] && unset mac1

*If* I play around with openwrt-svn at the weekend, then I may create a patch.

Lurch

[Edson Freitas]

I dont know if the correction is already avaliable to the community, but see:

https://dev.openwrt.org/ticket/11155
https://dev.openwrt.org/changeset/31030

About 15 minutes between the announcement and the corrective action.
(No, I am not involved in any way with the openwrt development team).

Maybe I was lucky and the message was received by a good developer in
a good day, or I was sucessfull in my attemp to describe the problem and
the solution in a very clear way, or even both..

But imho this experience shows that you can yes contribute to the
development of openwrt (or any other community software) and expect
good return, taking account that anything you can do when reporting the
bug can help alleviate a probably overwhelmed group.

Hope this can encourage you and others seeing this message :-)

Edson.

[biff...@yahoo.co.uk]

This:
https://dev.openwrt.org/ticket/7840

And this:
https://dev.openwrt.org/ticket/7732

Is rather more typical of my experiences.

Note that I spend an entire evening figuring out which revision (and
which developer) introduced the error. I email the developer (nbd),
and tell him about it, requesting that he fix it, because basically
everyone sees this oops (even if it's cosmetic).

He does me the favour of not even replying to my email, and applies
similar patch about 12 months later, not even a word of thanks,
nothing.

Do you honestly think this project is any way to support customers?
Sorry, but they don't really seem to give a f***. Of course I don't
mind people not doing work for me, after all, why should I demand
people fix things I want to see fixed? What I mind is when I do all
the bloody work, and give them the solution on a plate pretty much and
I get a kick in the teeth for my efforts.

Yes, there are some 'nice' developers, and jow is indeed one of them
(I've had help from him before), but they are few and far between in
my experience.

regards,
Biff.

On Mar 22, 2:43 am, Edson Freitas <edson....@gmail.com> wrote:
> I dont know if the correction is already avaliable to the community, but
> see:
>

> https://dev.openwrt.org/ticket/11155https://dev.openwrt.org/changeset/31030

[Edson Freitas]

Well not really a good experience, sorry for that. Maybe this happened
without the developer being aware at all, at least I hope so...

But think yourself switching to a new job, only to find a co-worker able of things
like steal your work as the lighter ones, and "very" aware of what he is doing...
Believe-me, if for some reason you need to work with this kind of people, it's far
more pleasant doing this very far away :-)  :'-(  :-)

Back to the point, you need to take account that what you proposed to change
(see "where" you are changing things) is a lot more complex than a simple
change in a script, with great potential to produce big problems if not completely
understood. And as you said, purely cosmetic (as opposed to my one).

I will not be surprised if the developer simply archived the ticket taking in mind
dealing with it "a little" latter. And by the lack of credits or even the thanks, could
be simply someone thinking this make no difference (he is wrong). The fact is,
your enhancement finally was incorporated, and like I said, by happy, could be
worse ;-)

regards,
Edson.

[biff...@yahoo.co.uk]

On Mar 22, 11:01 pm, Edson Freitas <edson....@gmail.com> wrote:
> Well not really a good experience, sorry for that. Maybe this happened
> without the developer being aware at all, at least I hope so...

I'm sure he was perfectly aware. He can't possibly be that stupid and
still be developing OpenWrt, but there is a 10% chance you are right.

> But think yourself switching to a new job, only to find a co-worker able of
> things
> like steal your work as the lighter ones, and "very" aware of what he is
> doing...
> Believe-me, if for some reason you need to work with this kind of people,
> it's far
> more pleasant doing this very far away :-)  :'-(  :-)

Well, yes, I suppose so.

> Back to the point, you need to take account that what you proposed to change
> (see "where" you are changing things) is a lot more complex than a simple
> change in a script, with great potential to produce big problems if not
> completely
> understood. And as you said, purely cosmetic (as opposed to my one).

I understood it 100%. An oops is an oops, even if purely cosmetic.
You cannot live with that, if only because people will continually ask
you if it is actually a problem, and it looks like sh*t.. But if what
you are saying is true, there's a great opportunity for the developer
to actually explain this to me, instead of just ignoring me.

> I will not be surprised if the developer simply archived the ticket taking
> in mind
> dealing with it "a little" latter. And by the lack of credits or even the
> thanks, could

I dunno, maybe I'm just different from other people, but when I see
someone making an effort on something I'm involved with I like to
encourage that even if it's just with a couple of words rather than
actions, and this has got nothing to do with Bifferos the 'business',
I had the same attitude when I was developing open-source stuff purely
for fun. Does it really take so much of one's day, I mean the 10
seconds or so it takes to say 'sorry I'm too busy to fix that any time
soon'? For some people yes. The lack of thanks isn't a big deal for
me, so don't focus on that. Credits are also not a big problem. I
just want to see the software working. I hate it when people can't
get the easy things right - the one-line fixes that make a big
difference to the user's lives, and cost so little to add. It's lame.

> be simply someone thinking this make no difference (he is wrong). The fact
> is,
> your enhancement finally was incorporated, and like I said, by happy, could
> be
> worse ;-)

It wasn't my enhancement, my defect was a dup of another defect, and
the other defect was eventually fixed. I wasn't asking for any
enhancement. I was asking the guy who broke the code to back out his
change so the RDC kernel stopped oopsing, and even then, only for
RDC. I didn't think that was a big ask.

When you've got developers who won't back out their breakages until 12
months after they've been pointed out to them, it's time to fork. I
didn't want to, but I had little choice, either that or keep a set of
patches, on what is effectively a set of patches itself. Now that'll
make your head spin....

regards,
Biff.

[Edson Freitas]

Em quinta-feira, 22 de março de 2012 21h00min33s UTC-3, biff...@yahoo.co.uk escreveu:

I'm sure he was perfectly aware.  He can't possibly be that stupid and
still be developing OpenWrt, but there is a 10% chance you are right.

This can be simply a case of dropped the ball, or things could be happen in ways or conditions we can't figure out. By this imho not so little possibility, to avoid the risk of being unfair, I prefer not to throw him/they into the fire yet, based solely on this occurrence.

Of course, if instead you have a collection of bad experiences...

I understood it 100%.  An oops is an oops, even if purely cosmetic. 

You understood. Mainly thinking about what you said on the next lines: you spend an entire evening to find out the problem and be sure of this. Whoever takes the task of applying a patch will choice spend his time trying to archive this also by itself (year pinpointing helps a lot, but still rests the uncertainty factors), instead of direct the available effort to solve another problems. Will it be worth it? How much time? It's a matter of judgment.

 

You cannot live with that, if only because people will continually ask
you if it is actually a problem, and it looks like sh*t..   

This is a really good point, I by myself didn't think about this until now, even despite talking to you. Did he? (See what Jow said at #7732, and only when incited to do that). As I saw, the impact was purely cosmetic..
 

But if what you are saying is true, there's a great opportunity for the
developer to actually explain this to me, instead of just ignoring me.

Year, I agree with this.

I dunno, maybe I'm just different from other people, but when I see 

someone making an effort ...

 

People "are" different. I'm glad when I see someone who pays attention to the effort spend by the others and truly cares giving some kind of incentive (not always regarding to retribution), but as far as I can see this is not the predominant behavior, so I tend to see this less as a flaw and more as they just think differently (but honestly, I don't feel I'm the best guy to judge this right now).

I was asking the guy who broke the code to back out his 
change so the RDC kernel stopped oopsing, and even then, only for
RDC.  I didn't think that was a big ask.

Breaking code is an unavoidable part of the development, you can't treat this like a someones fault, or you will make lives miserable. Imho once detected, must be treated like any other enhancement in the software, even the impact of backing changes must be evaluated and weighed against other needs (of course, I'm not talking about "business" way then I say "like other").
 

When you've got developers who won't back out their breakages until 12 
months after they've been pointed out to them, it's time to fork. I 
didn't want to, but I had little choice, either that or keep a set of
patches, on what is effectively a set of patches itself.  Now that'll
make your head spin....

Why? I didn't say you have no reasons to make a fork, it appears you have valid ones, but unless planning to stick with another distribution, you can't deny that there are benefits in keeping openwrt closer enough. That's why I tried to encourage you at first place.

See my case: I need packages not available in the default installation, and the versions found in the binary repository where not compatible.

So I decided to download and compile the bb repository. Got some errors about stdc++ (change behavior of the gcc compiler, in somewhat recent release). Work around, got some more errors, and I started to search for alternatives: the one who was successful was a merge between bb (mainly your patches) and the current openwrt development tree.

Almost successful, if I didn't track the problem relative to the script in preinit. A little less of persistence, and I would give up. Now I am able to compile the packages without any problems, in a fully updated arch distro, and I'm very happy with this. As a note: I haven't tried the compilation of bb against other distributions, but given the nature of the errors, it's likely they are (or will be) affected also.

I don't spend much time trying to understand the philosophy behind openwrt, but as far as I can see, the big gain in keeping closer is in taking advantage of the community effort to adapt his distribution to this kind of changes. Besides, obviously, updated packages.

That said..hummm...patches over patches..
Eventually done, I don't dislike too much ;-)

Regards,

Edson.

[Andrew Scheller]

On 4 February 2010 13:24, Andrew Scheller <ya...@loowis.durge.org> wrote:
> https://dev.openwrt.org/browser/trunk/target/linux/rdc/base-files/lib/preinit/05_set_ether_mac_rdc#L18
> Should line 18 be:
> [ "$mac1" = "FF:FF:FF:FF:FF:FF" -o "$mac1" = "0:0:0:0:0:0" ] && unset mac1
> (i.e. -o "$mac1" instead of -o "$mac0")
> I'm not a OpenWRT developer, so wouldn't know who/how to contact!

I'd completely forgotten about this, so I checked and the same error
is still in trunk! So I've now submitted it as
https://dev.openwrt.org/ticket/11166

No reply yet...

Lurch

[Edson Freitas]

On 24 March 2012 08h42min01s UTC-3, Andrew Scheller wrote:

No reply yet...

Lurch

 

 Yes. After see the way the only feedback was send on tickets presented by Biff in this talk, how the solution itself was made, and Biff's frustration indicating that there is a whole unknown (to me) history, I'm convinced that they have a weak feedback system.

On the other hand, take account that openwrt is maintained mainly (solely?) by a community of developers, and developers like most, ahamm, to develop. Feedback is a weight, not an opportunity. The cool is to develop. You will be assimilated (sorry the joke, wrt guys!).

Seriously now, I'm still thinking that the closer the better, so imho the best thing to do is send anyway the patch/error description, following by some sort of forgetting it. This way, you can expect a proximity of only - eh, ahamm - 20 months of gaps to close. I now, I now, I'm pushing a lot..

About using a more recent version of openwrt, I did the merge but don't know yet how stable it is, it boots all right but I'm conscious it's only the beginning. Right now, I'm playing with root over usb, but once finished I pretend to do some more tests to see if at least the software that I want runs without problems. I don't know if I can be helpful to you Biff, the merge procedure was surprising simple, so I imagine the only thing I can do, if it will be helpful in any way, is report how my system is going on or test some specific software. Will it?

[biff...@yahoo.co.uk]

We could just concentrate on Buildroot, the base project from which
OpenWrt is derived, which (although I didn't solve my problem) appears
to have a different development structure, that might be more suited
to the needs of the Bifferboard community:
http://lists.busybox.net/pipermail/buildroot/2012-March/050757.html

This has the potential to support 1MB devices as well as 8MB ones with
the same toolchain and rootfs preparation scripts, something OpenWrt
will never do, but the drawback is that we'd need to do some work to
get the JFFS support for the Bifferboard into there (flash map and so
on).

Still, I like not only the attitude of the developers, but also the
way the code is structured. It's trying to do all the things I'd like
to see (there is a check-box for RTAI support!), even if it's not
succeeding all the time.

regards,
Biff.

[Andrew Scheller]

> We could just concentrate on Buildroot, the base project from which

"We" or "Biff" ? ;-)

> OpenWrt is derived, which (although I didn't solve my problem) appears
> to have a different development structure, that might be more suited
> to the needs of the Bifferboard community:

I've no familiarity with Buildroot, but it seems much more geared
towards building minimal standalone "static images", whereas OpenWRT
seems much more focused on package-management and having lots of
available packages?
Which I guess kinda makes OpenWRT a middle-ground between Buildroot
and Slackware?

> http://lists.busybox.net/pipermail/buildroot/2012-March/050757.html

Interesting series of discussions, which I had no idea you were
working on. Thanks for posting the link :)

> This has the potential to support 1MB devices as well as 8MB ones with
> the same toolchain and rootfs preparation scripts, something OpenWrt

Is the proportion of 1MB boards sold/in-use enough to make that worth
worrying about? Given how little a brand new 8MB board costs...

> will never do, but the drawback is that we'd need to do some work to
> get the JFFS support for the Bifferboard into there (flash map and so
> on).

I guess that's something only you'd be able to do - doesn't seem to be
any other kernel hackers in the Bifferboard community.
i.e. it's up to you to judge if the effort is worth it.

> Still, I like not only the attitude of the developers, but also the

Yeah, I guess that's a BIG help :)

> way the code is structured.  It's trying to do all the things I'd like
> to see (there is a check-box for RTAI support!), even if it's not
> succeeding all the time.

It certainly seems much easier to configure Buildroot than Openwrt...

The decision is obviously yours to make, but IMHO you ought to weigh
up if the advantages of switching to buildroot outweigh the
disadvantages of switching the "current development system" for
BifferBoard yet again...
Ideally both would be supported, but as you're only a
one-man-developer that's obviously not a reasonable expectation.

Lurch

[biff...@yahoo.co.uk]

On Mar 25, 1:48 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> > We could just concentrate on Buildroot, the base project from which
>
> "We" or "Biff" ?  ;-)

We :).

> I've no familiarity with Buildroot, but it seems much more geared
> towards building minimal standalone "static images", whereas OpenWRT

Not really the case IMHO.

> seems much more focused on package-management and having lots of
> available packages?

But buildroot still has packages:
http://git.buildroot.net/buildroot/tree/package

> Which I guess kinda makes OpenWRT a middle-ground between Buildroot
> and Slackware?

Yes, but it all depends on which has the packages you want, rather
than how many packages there are. There are people in the buildroot
community *interested* in RTAI, whereas there's nobody interested from
the OpenWrt camp.

> >http://lists.busybox.net/pipermail/buildroot/2012-March/050757.html
>
> Interesting series of discussions, which I had no idea you were
> working on. Thanks for posting the link :)

Welcome :).

> > This has the potential to support 1MB devices as well as 8MB ones with
> > the same toolchain and rootfs preparation scripts, something OpenWrt
>
> Is the proportion of 1MB boards sold/in-use enough to make that worth
> worrying about? Given how little a brand new 8MB board costs...

- First, it's a fascination of mine which has nothing to do with
commercial consideration.
- Second, the people who brought the 1MB units were the 'early
adopters'. They are rather valuable in terms of technical
contributions.
- Third, some people want to put Biffboot community edition onto the
(1MB) NAS devices. These people are prepared to tinker (or they
wouldn't have done that in the first place). I want to encourage them
by supporting their hardware.
- I personally, tend to use the 1MB devices for my home projects
because they have lower resale value. I've just put together a
central heating controller with web interface, which I've been running
for about a week now. There was no reason to use flash, because I was
happy to just have the thermostat revert to 10 degrees if we have a
power cut, and it simplified the coding!

So, it's not quite as simple as just the commercial considerations,
and the fact that I save less than $1 for switching to 1MB units which
- indeed - is hardly worth it.

> > will never do, but the drawback is that we'd need to do some work to
> > get the JFFS support for the Bifferboard into there (flash map and so
> > on).
>
> I guess that's something only you'd be able to do - doesn't seem to be
> any other kernel hackers in the Bifferboard community.
> i.e. it's up to you to judge if the effort is worth it.

It's hardly rocket science to do that! I'll only do it if the other
problems are sorted out (the one referred to in the thread, for a
start).

> The decision is obviously yours to make, but IMHO you ought to weigh
> up if the advantages of switching to buildroot outweigh the
> disadvantages of switching the "current development system" for
> BifferBoard yet again...
> Ideally both would be supported, but as you're only a
> one-man-developer that's obviously not a reasonable expectation.

Oh, I won't be switching anytime soon. I'm just saying if someone
were to solve the other problems and get a port up and running I'd be
persuaded to contribute patches to that project, because I'd feel it
worthwhile, but the inertia would have to come from someone else.

Biff.

[Andrew Scheller]

>> seems much more focused on package-management and having lots of
>> available packages?
>
> But buildroot still has packages:
> http://git.buildroot.net/buildroot/tree/package

I stand corrected! As I said I've never looked at buildroot before.

> than how many packages there are.  There are people in the buildroot
> community *interested* in RTAI, whereas there's nobody interested from
> the OpenWrt camp.

Presumably that's a human-level decision though, rather than a
project/technology-level decision? (i.e. it's just bad luck that none
of the openwrt developers are interested in RTAI?)
And as it involves kernel-patches, isn't RTAI a bit more than "a package"?

>> Is the proportion of 1MB boards sold/in-use enough to make that worth
>> worrying about? Given how little a brand new 8MB board costs...
> - First, it's a fascination of mine which has nothing to do with
> commercial consideration.

[snip other reasons]

Fair enough ;)

> Oh, I won't be switching anytime soon.  I'm just saying if someone
> were to solve the other problems and get a port up and running I'd be
> persuaded to contribute patches to that project, because I'd feel it
> worthwhile, but the inertia would have to come from someone else.

I see. Am I the only person wondering if the Bifferboard community is
starting to run out of inertia? There seems to be a fruit-themed Linux
board (which doesn't have any on-board flash) which has currently
taken everyone's attention... ;)

Lurch

[nicolas le falher]

>There seems to be a fruit-themed Linux
>board (which doesn't have any on-board flash) which has currently
>taken everyone's attention... ;)

That's right, currently some people refresh distributors website for new arrival of fruit.
A bifferboard with a more powerful cpu / onboard flash would be nice :p.

Nicolas

[Dan]

I second that . A more powerful bifferboard would be great

--
To unsubscribe send email to bifferboard+unsubscribe@​googlegroups.com

[biff...@yahoo.co.uk]

On Mar 25, 5:20 pm, Dan <danarn...@gmail.com> wrote:
> I second that . A more powerful bifferboard would be great

Indeed. For the same price, of course ;-).

[Andrew Scheller]

> I second that . A more powerful bifferboard would be great

...but would come with the danger of giving Rilhas even more crazy ideas ;-D

Lurch

[Nicolas Le Falher]

>...but would come with the danger of giving Rilhas even more crazy ideas ;-D

There are also benefits of having people mad to test the limits :].

Nicolas

[Edson Freitas]

Em domingo, 25 de março de 2012 07h19min04s UTC-3, biff...@yahoo.co.uk escreveu:

We could just concentrate on Buildroot, the base project from which

Nice to know. Until now, I was misunderstanding it solely as a ucrosscompiler. Next time I'll pay more attention on the name :-)

Some months ago i started old plans to expand my knowledge of electronics to the point I'll be able to build complex pcbs, thinking on a future own business. Since them, I spend the (very) majority of my free time in study. I'm still not able to to that, but that's the goal.

Before immersing in this world, I was thinking that the way to build systems for embeddeds was something like linux from scratch, but at second glance, it seems not. Is buildroot philosophy more closer to lfs or to slack/arch? Maybe it's more able to match my own needs.. (oh hell, one more learning curve!)

I'm new to embedded systems, but not so to unix. Kernel hacking is not a black box to me, but today is not a white box as well. Surely I'll need some (a lot of) refresh once I'm ... (OR NO! GOD! 7 YEARS!!! YESTERDAY!!!!) .. some .. time .. without playing with it. At the point that I will be able to connect the dots, if still need, surely I can give some effort to help support JFFS on bifferboard / buildroot (ubi is not the way to go?).

Am I dreaming, or there is someone else feeling something like "sooner, the market of embededs will suddenly expand"?

 

Edson.

[Edson Freitas]

Em domingo, 25 de março de 2012 12h46min23s UTC-3, Andrew Scheller escreveu:

There seems to be a fruit-themed Linux
board (which doesn't have any on-board flash) which has currently
taken everyone's attention... ;)

Animals for software, fruits for hardware. Coincidence, or I missed something?

[Edson Freitas]

I second that!!

[rolf]

And for the same low power consumption. I doubt that, because this
fruit goes with 700 MHz. From my point of view CPU power is not the
most interesting thing with bifferboard. Reliability is my second
point. And for that I need well tested software and a reliable
community.

Rolf

On 25 Mrz., 22:24, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote: