bottleneck
Choose style:

Author Topic: Update Packages failure  (Read 18932 times)

0 Members and 1 Guest are viewing this topic.

Offline jmtenny

  • Backer
  • *
  • Posts: 11
  • Thanks: 0
  • Registered : 23/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Update Packages failure
« on: July 14, 2014, 01:58:36 pm »
Not sure if this is a bug or intentional by securifi, but I am unable to update the OpenWRT package lists. Tried both OpenWRT UI and Terminal, but both error out:

From the OpenWRT UI > System > Software > Update Lists I get the following message:

Code: [Select]
Downloading http://downloads.openwrt.org/snapshots/trunk/g2/packages/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/g2/packages/Packages.gz, wget returned 1.

from terminal running opkg update command I get

Code: [Select]
root@AlmondPlus:~# opkg update
Downloading http://downloads.openwrt.org/snapshots/trunk/g2/packages/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/g2/packages/Packages.gz, wget returned 1.
root@AlmondPlus:~#

Offline dbuttke

  • Backer
  • *
  • Posts: 114
  • Thanks: 0
  • Registered : 12/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Update Packages failure
« Reply #1 on: July 14, 2014, 04:46:59 pm »
This may have something to do with the fact that kamikaze seems to be a bit old.
http://downloads.openwrt.org/
   there is no G2 in here either... http://downloads.openwrt.org/snapshots/trunk/


LGNilsson

  • Guest
Re: Update Packages failure
« Reply #2 on: July 14, 2014, 09:19:08 pm »
Currently all the packages available for the Almond+ are part of the firmware. There are no optional downloads at this point in time.

Offline aenertia

  • Backer
  • *
  • Posts: 17
  • Thanks: 1
  • Registered : 02/09/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Update Packages failure
« Reply #3 on: September 02, 2014, 08:05:41 am »
You can change the packages to point at a valid arm arch repository. i.e the kirkwood/freescale SoC is arm5v and in theory binarys should run on the almond+ (still testing, I just got my unit yesterday).

I am not sure where the g2 target appeared (and subsequently diss-appeared too) I don't think i've ever seen it on the public openwrt git/svn tree. So I assumed securifi have an internal tree they are not publishing. Tsk tsk GPL violation guys.


Anyways YMMV but
i.e changing:
Code: [Select]
#src/gz snapshots http://downloads.openwrt.org/snapshots/trunk/g2/packages
to
Code: [Select]
#src/gz snapshots http://downloads.openwrt.org/snapshots/trunk/g2/packages
src/gz snapshots http://downloads.openwrt.org/snapshots/trunk/kirkwood/packages/packages

will give you an ipkg repo that in theory will run binary native on the arm7 soc inside the A+

I am disappointed that there is no GPL source dump yet, and even more disappointed at the ancient 2.6.32 kernel that is included. I thought I might be able to live with binary blobs and backport various improvements from mainline but I am thinking my a+ is going to end up in the scap bin.

Without modern kernels there is no buffer bloat reduction, no decent tc schedulers or SQM. I am hoping that a source code drop and reference sheets for the SoC's inside appear soon. This was part of my Backing pledge.

IANAL but even with a GPL dump with binary blobs tainting it it is going to be uphill work to win back my confidence in the product.

LGNilsson

  • Guest
Re: Update Packages failure
« Reply #4 on: September 02, 2014, 11:49:50 am »
Not ours I'm afraid, it's Cortina's odd link, we just didn't change it.

We haven't released our GPL code yet, but it's coming.

As for Kernels and things, we only have so much to say here, as we're working with an SoC vendor who controls all of this, much like all other router manufacturers.
That said, given sufficient time, we should be moving to a 3.x kernel, but I highly doubt this will happen this year.
« Last Edit: September 02, 2014, 11:53:18 am by Lars »

Offline aenertia

  • Backer
  • *
  • Posts: 17
  • Thanks: 1
  • Registered : 02/09/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Update Packages failure
« Reply #5 on: September 02, 2014, 10:03:13 pm »
Yup I do understand; selecting a SoC with open reference specs and mainline kernel development would have been the solution. There are a few ARM SoC's popping up that are mostly mainline complete (bannaboard/rk3xxx series of ARM). Unfortunately it takes until you go to release and then the support/build issues to come barreling in before decision makers start to understand just how much extra TCO selecting a Shiny bells and whistles SoC with NDA actually ends up costing.

I have been using the ar7xx mip's platforms mostly as my build targets, and I can tell you that compared to blob tainted tree's they are a joy to work with. Not mention the security implementations and ability to properly architect and debug end to end architectures is worth it's weight in gold.


Offline aenertia

  • Backer
  • *
  • Posts: 17
  • Thanks: 1
  • Registered : 02/09/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Update Packages failure
« Reply #6 on: September 02, 2014, 10:06:20 pm »
Cerowrt are looking for to move to a New Arch as MIP's are hitting constraint limits of their age. Especially in Gbit PON links doing proper scheduling with SQM and FQ_CODEL buckets on MIP's is becoming problematic.

Also related, openwrt are starting to look at openvswitch based engine and SDN encorporation; again having open Switch IC's and fabric here would be awesome.

VXLan support would also be wellcome.

LGNilsson

  • Guest
Re: Update Packages failure
« Reply #7 on: September 03, 2014, 06:08:12 am »
Yup I do understand; selecting a SoC with open reference specs and mainline kernel development would have been the solution. There are a few ARM SoC's popping up that are mostly mainline complete (bannaboard/rk3xxx series of ARM). Unfortunately it takes until you go to release and then the support/build issues to come barreling in before decision makers start to understand just how much extra TCO selecting a Shiny bells and whistles SoC with NDA actually ends up costing.

I have been using the ar7xx mip's platforms mostly as my build targets, and I can tell you that compared to blob tainted tree's they are a joy to work with. Not mention the security implementations and ability to properly architect and debug end to end architectures is worth it's weight in gold.

It's not that easy to just pick and chose these things, especially not with regards to what we've created with the Almond+. Even the Realtek based chip we started with, wouldn't have been able to support many of the things you're asking for.
We have a very specific ARM SoC that has been designed for network usage and it has enough interfaces to work with what we need it to do. Picking some random ARM processor wouldn't have worked, as routers are not the same as a smartphone and thus the processors are not the same. We require PCI Express lanes, something that many ARM processors don't have enough of. MIPS wasn't an option at the time and still isn't for a 3x3 MIMO 802.11ac configuration and as such, we settled on what we're using after having compared pros and cons of a wide range of other options.
It's easy to stand at the sidelines making comments and as someone that claims to be familiar with this stuff, you should know better than making random comments before we've even had a chance to do anything more than ship the product.
If you think this is it for the Almond+, then you're sorely mistaken and instead of being negative about everything, maybe it would be better if we try to work together on whatever features you want?
We're not a big company so we're a lot more flexible, but please understand that this also means that we have resource limitations in terms of manpower.
We'd be more than happy to work with you if there's something you want to develop for the Almond+, but your approach isn't one that's going to make you any friends, regardless of which company you're talking to.

Offline aenertia

  • Backer
  • *
  • Posts: 17
  • Thanks: 1
  • Registered : 02/09/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Update Packages failure
« Reply #8 on: September 03, 2014, 09:38:22 am »
Fair enough, I am coming off as ranty and shouty and apologize for that.

I see a heap of potential in the A+ and understand your design decisions were made for measured reasons. As I said the fate of the lifespan of the product likely is going to be in how much Securifi can open the platform up. Getting upstream mainline support for the SoC would be a giant step in that direction.

Some good news being that hopefully the wireless chips will have good working driver support through atheros's ath10k dump. Sacrificing a few features would definitely something I would be willing to pay for a mac80211 compliant OSS driver.

I guess in terms of projects - getting an upstream openwrt build target would probably be number one. I can see you securifi benefiting a lot from just not having to maintain the ipkg repository's even with a hobbled kernel/base build.

LGNilsson

  • Guest
Re: Update Packages failure
« Reply #9 on: September 03, 2014, 12:25:26 pm »
We're pushing for a more up to date OpenWRT build, I had the same concerns as you about this, as the version we're using is old and there's nothing else anyone can say about it.
We've also asked for a more up to date Kernel which we've been told is coming and will most likely end up being 3.4.x from my understanding.

 

Page created in 0.064 seconds with 17 queries.

bottleneck