StarV3 v1.1.8 build 1704 has been released. [Archive] - Siam Embedded Software Support Forum

tony

11-24-2006, 10:46 AM

The new release can be downloaded from the http://www.star-os.com (http://www.star-os.com/) downloads page.

New to this release is the ability to install onto stock Gateworks Avila GW2348 series of hardware, found here (http://www.gateworks.com/avila_processors.htm). Licenses can be purchased from the www.license-keys.com (http://www.license-keys.com) website much like the X86 releases.

HoeDing

11-24-2006, 11:50 AM

Are you considering adding support for the rest of the 32xx series? They appear to be essentially the same board supporting different combinations of mpci and ethernet.

tony

11-24-2006, 12:17 PM

While we have no hardware to test, there is a possibility that the existing releases will work as-is on the rest of the Avila series, keeping into account the memory restraints. (use the GW2348-2 release on 32MB systems, and GW2348-4 release on 64MB systems).

greg

11-24-2006, 03:07 PM

Had some complaints from customers this week on one AP so I flashed the latest beta ver but the 5.8 backbone link was flakey, jumping all over signal and rate wise. Tried bumping the tx rate on both sides from 18 to 21 and 23 but still not good, dropping packets, etc. Saw the 1.1.8 ver, downloaded it and figured I'd try it. Just tried upgrading a W2 unit to this ver, selected -2 ver. System/Upgrade firmware told me it was incorrect ver and wouldn't continue. From what I can tell, that was the correct ver to try. I don't have 1.1.7 on my home pc and I couldn't find it to download so I put the newest I had on it which was 1.1.4

Any idea what is up with the 802.11a links under the beta? If that was stable, I'd be able to run it on a couple more War AP's. My signal under 1.1.7 was 77/78 and under 1669 was 83-90.

tony

11-24-2006, 03:10 PM

The "-2 and -4" versions are for do-it-yourself Gateworks Avila owners. The upgrades are done using the .pkg file that is included.

greg

11-24-2006, 04:33 PM

Thanks Tony. Are there any changes/enhancements over the prev ver other than being able to install on a bare board?

tony

11-24-2006, 04:40 PM

The change log listed on our website lists the changes since v1.1.7. The primary focus of this release is the Avila support.

pti-andy

11-25-2006, 09:18 AM

I think supporting bare boards is a great idea. Are there plans for the GW2347 as well?

lonnie

11-25-2006, 09:51 AM

We do not have ANY Gateworks specific boards for testing, and we do not plan on having any. Our WAR boards are made by Gateworks BUT they are not the same as they make for everybody else. Surprise, surpise.

Although our image MIGHT work on any Gateworks boards it is left as an exercise for you or Gateworks to determine if our image works on a particular model.

All I can promise is that we support the boards that the image works on. If you need that to be said with no uncertainty --> If the image does NOT work on a particular board it means that board is NOT supported and quite likely will NOT EVER be supported. Adjust your purchasing appropriately.

Do NOT bother me with requests to support ANY unsupported board unless you are planning at least 1,000 units and you will commit to 50% upfront.

**EDIT** I am told this is harsh, but I cannot have any misunderstanding about this later. If a board is supported it will stay supported as long as the design does not change. Do not buy a bunch of boards from anybody unless you know they will run our software. As a note, the boards we sell will always be compatible and will be supported.

There, now people have a choice. Time for me to get back to my manual. I'm almost done the first paragraph.

I think supporting bare boards is a great idea. Are there plans for the GW2347 as well?

tony

11-25-2006, 10:23 AM

Looking at the GW2347 specs, it would seem likely that the GW2348-2 release may work as-is on it. If you are able to test it, please provide feedback.

pti-andy

11-25-2006, 02:14 PM

I may test the GW2347 based on Tony's feeling on it. I assume the flash procedure would be the same as for the GW2348-2?

Based on Lonnie's post I gather that if the image works on the GW2347 then it would be supported?

tony

11-25-2006, 02:47 PM

lonnie

11-25-2006, 06:11 PM

Wow, I need to clarify this even more, so, I guess I have to say: Yes it is supported if it works. If any changes are ever made to the circuit by Gateworks, or they change the bootcode or the flash type and it stops working, then it is no longer supported. Really very simple.

Make sense now? If you buy your boards from others (and they are not VNC WAR boards, made to my specification) then you and the other vendor are the R&D team. Don't expect us to support you with our R&D. Our R&D efforts are 100% on what we are doing.

Having said that, I expect that Gateworks will not make any changes, but I have to be very clear, we are simply not responsible if they do because based on our development plans, we will not have time to create a new image for the "new" boards.

I may test the GW2347 based on Tony's feeling on it. I assume the flash procedure would be the same as for the GW2348-2?

Based on Lonnie's post I gather that if the image works on the GW2347 then it would be supported?

tog

11-25-2006, 07:05 PM

There, now people have a choice. Time for me to get back to my manual. I'm almost done the first paragraph.

I intend to keep purchasing WAR boards, it's not like purchasing a Gateworks Avila board is cheaper than purchasing a custom Gateworks board from Valemount... I'm sure whoever felt it was important to be able to load StarV3 on to generic Gateworks boards appreciates it, though.

May I ask what happened to the manual you mentioned about 6 weeks ago?
I am happy to report that a manual is nearing the stage for release. This has been done by a published writer. I am not yet at liberty to release his name nor his work, but it will happen shortly.

If you are back to having to write the entire manual yourself from scratch I'd encourage you not to even bother and let us just see how our wiki project pans out.

If you do have something that's nearly complete, though...

pti-andy

11-25-2006, 07:56 PM

As long as the GW2347 contains a RedBoot bootrom, the same upgrade procedures will work.

Any platforms that are reported to work will be listed on our website as 'compatible', however our primary focus will still be for the GW2348 series.

Thanks Tony, that's what I was looking for. For the most part, the price of the WAR-2 does not make purchasing your own very attractive but there are some instances where a different form factor may have an application now and then. It is also nice for those that may have these boards in service already with a different OS and want to change. Supporting more platforms can only diversify your market. Good for everyone.

When I get a sec I'll try one out and post the results for you.

-Andy
PTI Wireless

ninedd

11-26-2006, 09:23 PM

For the most part, the price of the WAR-2 does not make purchasing your own very attractive...I agree totally. I hope everyone's done the math and can understand that the best value (both for the individual purchaser, and in the long-term interests of us all) is to buy Valemount made boards with V3 already installed on it. The best way to get even lower prices is to let Lonnie increase volumes more and more, and not to have 100 different guy's trying to buy 10 boards each from 100 different suppliers. That being said, I don't see a downside to also having a version that's installable on as many hardware choices as is practical. :) Win-win.

gunther_01

11-28-2006, 03:29 PM

I finally upgraded one of my WRAPs to V3. A couple of things that seem strange that maybe someone can clarify for me.
WAR2 running 1704 cm-9 AP shows: Q100 -71 -71 18mbps 36mbps
WRAP running 1704 CM-9 client shows: -74sig -95noise 18mbps

Both are set at auto rate. I would think with my signals that I would have 24 to maybe the ocassional 36 on my client. I understand in the wonderfull world of wireless that it doesn't have to be, but shouldn't it be. This is a 6 mile link with 26 or 29db grids and I had steady 24 to 36 data rates when this client was on latest/last V2 stable.

Other comment is... I have never seen a client change data rates in single numbers before. 10,11..16,17,18. I may have missed something from the other beta posts, since I don't look at those too often but, weird:o

Any comments?

gunther_01

11-28-2006, 03:43 PM

Alright I think I can guess the whole data rate one number at a time thing. I am still not sure about my data rate being lower with V3 on the same channel I was on before... Moving around on channels provided me with higher data rates. So maybe I had some interference that V2 wasn't seeing or hearing or figuring on I guess.

Time will tell. I do like the quality meter though. That is just a great addition to this software, and even better now that I have V3 to V3 links. :):D

tog

11-29-2006, 01:33 AM

The current auto-rate behavior displays numbers in between real data rates, so while the radio is actually at 12mbit for example, it might show, 13, 14, 15, 16, etc.

Something to do with the auto-rate algorithm being smoothed out I believe.

I would recommend forcing the transmit rate to 18 or 24 on that link on both sides to make it as absolutely solid as it can be. I don't like using auto-rate.

You may be pleasantly surprised after doing so, I've found that some links that auto-rate liked to set up high at 36 performed way better when forced to 24 or 18 for example. Even in just the built-in throughput test you may be able to tell a bit of difference.

gunther_01

11-29-2006, 06:08 AM

I would force them but I have a weird signal thing around here that makes my backhauls go from -60 to -80 or less. If I force a rate won't I loose connection if my signal drops real low (lower then fixed data rate). My first hop, real short I forced and love it that way. It's extremely stabil with great ping times and throughput. I don't think I can get away with it on this link untill we get a selector for usable data rates in Star-OS. So I can choose what data rates I would like to use and not just force one rate.

Unless Star will drop to rates below the forced rate but won't go higher?

greg

11-29-2006, 06:35 AM

I monitor mine in auto mode to see what they can support. Try some different channels and look for the best signal, then lock the rate a notch or two below what it supports. Trying to compensate for snow and ice conditions. I've not tried locking above that. Locking gives much better performance.

gunther_01

11-29-2006, 06:49 AM

That's just it, unless I force rate to 6 I could loose connection. But doing that I get lower performance.

I personally like how OSbridge lets me select the data rates available to use. I can leave it in auto and select 24,18,12,6 if I want. I prefer to NOT use auto but with these signal swings it's a PITA. It happens on all channels. H or V polarization. H is a little better. Possibly from the humidity of a nearby lake. Maybe it's the nuclear power plant there also:confused: :D

I ran in to this problem with my second PtP in this area. That's partly why I switched to OSb for that backhaul. Once Star let's me graph with SNMP data rates and signal, I can keep an eye on it and maybe fix the rate once I figure out a base line for the units. It just swings at random and I can't see it change without watching the device all day.

tog

11-29-2006, 04:41 PM

Even if your signal is at -80 you should still be able to do 12 or 18mbit.

It's my opinion that 12 and 18mbit rates still provide very decent performance.

When you lock a transmit rate it stays there, it doesn't drop to a lower rate to maintain the connection.

I do agree that the feature where you specify allowed data rates is a good idea. I suggested something along these lines a bit ago. My suggestion was something along the lines of setting the maximum rate. Two reasons for that:
1) Sometimes the rate auto-rate settles on doesn't perform as well as the next rate down
2) If you've set the max rate to 24 when auto-rate was trying to do 36 and 48, 24 is unlikely ever to shift downwards unless there's a catastrophic drop in signal strength. So for all intents and purposes, I would consider it like setting a fixed transmit rate but with benefits.

ninedd

11-29-2006, 11:59 PM

We sometimes see links that shift up and down - I expect because many raidos drop power at higher rates. They'll be happy at 24Mbit, where the radios might be 18db, and the link figures it's got enough signal to switch up. So it goes up to 36Mbit, but that may make both radios drop to 15db, and there goes 6db, so the link then figures it better switch down. :) At least, that's my guess as to what goes on in some cases.

So yes, I'd also like to be able to set a MAX rate, rather than simply a Fixed rate.

mickeym

11-30-2006, 11:54 AM

Flashing one of the GW2348-4 boards per the pdf instructions included in the V3 v1.1.8 build 1704 download - all goes well untill the last step when the error below appears - can anyone - help with why this is not working?

Thanks,
Mickey

RedBoot> load -r -b %{FREEMEMLO} vncos-1.1.8-1704.xscale-war-gw2348-4.bin
Using default protocol (TFTP)
Raw file loaded 0x00029c00-0x006dfe7b, assumed entry at 0x00029c00
RedBoot> fis write -f 0x50000000 -1 0x800000 -b %{FREEMEMLO}
** Error: invalid flag '1'
** Error: no default/non-flag -l <image_length> [-s <data_length>]
[-f <flash_addr>] [-e <entry_point>free
fis init [-f]
fis list [-c] [-d]
fis load [-d] [-b <memory_load_a-f <flash_addr> -l <length>] [name]
fis write -f <flash_addr> -b <mem_base> -

tony

11-30-2006, 01:11 PM

The problem is that the -1 (one) should be a -l (lowercase 'L')

Once the change is done, it should continue without problems.

mickeym

11-30-2006, 01:27 PM

Yes, thinks - I just saw and fixed that - now the process is hanging at the point below and never moving past "from"

RedBoot>
RedBoot> fis write -f 0x50000000 -l 0x800000 -b %{FREEMEMLO}
* CAUTION * about to program FLASH
at 0x50000000..0x507fffff from

tony

11-30-2006, 01:32 PM

What Avila model are you upgrading? Also, can you provide the flash model number.

mickeym

11-30-2006, 02:00 PM

Gw2348-4-a

Js28f128
J3d75
5627a900

tony

11-30-2006, 02:38 PM

Can you provide me the output from the system from the moment you power it on, till the time you hit Ctrl-C for the first time?

The flash type seems to have changed, however it /should/ be compatible with the TE28F128 part used in previous builds.

You may need to contact Gateworks and obtain a new redboot_RAM.srec file from them, and use that one instead of the one we provide.

mickeym

11-30-2006, 06:19 PM

Tony -

Below is the output requested - I did contact Gateworks and could not get a new/different redboot_RAM.srec - we're a bit under the gun here and need to resolve this asap.

Thanks,
Mickey
-------------------------------
+No devices on IDE controller 0

Trying NPE-B...success. Using NPE-B with PHY 0.
Ethernet eth0: MAC address 00:d0:12:02:84:30
IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.3.1

RedBoot(tm) bootstrap and debug environment [ROM]
Gateworks certified release, version 2.02 - built 05:22:19, Mar 3 2006

Platform: Gateworks Avila GW234X (IXP42X 533MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Copyright (C) 2004, 2005 Gateworks Corporation

RAM: 0x00000000-0x04000000, [0x000298b0-0x03fc1000] available
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.
== Executing boot script in 2.500 seconds - enter ^C to abort
^C
RedBoot>
--------------------------------

lonnie

11-30-2006, 06:55 PM

Does that mean they do not have a new ram boot or that they won't give it to you?

mickeym

11-30-2006, 07:07 PM

Spoke to Ron - he said they hadn't verified your new image would flash to this board - he requested and I sent him 1)the last two posts between Tony and me (at that time) 2) a copy of the downloaded redboot_RAM.srec 3) a copy of the HT screen that showed where the flash hung (below)

I'm not sure why I couldn't get a new/different .srec if the flash on the board I have is not what has been used previously.
------------------
RedBoot>
RedBoot> fis write -f 0x50000000 -l 0x800000 -b %{FREEMEMLO}
* CAUTION * about to program FLASH
at 0x50000000..0x507fffff from

tony

11-30-2006, 10:12 PM

I have looked over the information you have posted, and have generated a new redboot_RAM.srec image that may help.

Please try the file located on http://www.star-os.com/redboot.php and let us know if it allows you to complete the upgrade.

mickeym

12-01-2006, 08:02 AM

Tony -

Just tried the new redboot_RAM.srec and the flash hung at the same spot:

RedBoot>
RedBoot> fis write -f 0x50000000 -l 0x800000 -b %{FREEMEMLO}
* CAUTION * about to program FLASH
at 0x50000000..0x507fffff from

Mickey

tony

12-01-2006, 08:39 AM

Can you post or PM me the output from the new redboot_RAM.srec, till just before you issue the 'fis write' command?

tony

12-01-2006, 09:38 AM

I have updated redboot_RAM.srec once again. Please try the new one, from http://www.star-os.com/redboot.php

mickeym

12-01-2006, 01:54 PM

Just got back to the office - below is the output from the first (not latest) redboot_RAM.srec - will download the latest and try a load.

Thanks,
Mickey
----------------
+No devices on IDE controller 0

Trying NPE-B...success. Using NPE-B with PHY 0.
Ethernet eth0: MAC address 00:d0:12:02:84:30
IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.3.1

RedBoot(tm) bootstrap and debug environment [ROM]
Gateworks certified release, version 2.02 - built 05:22:19, Mar 3 2006

Platform: Gateworks Avila GW234X (IXP42X 533MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Copyright (C) 2004, 2005 Gateworks Corporation

RAM: 0x00000000-0x04000000, [0x000298b0-0x03fc1000] available
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.
== Executing boot script in 2.500 seconds - enter ^C to abort
^C
RedBoot>

RedBoot> load redboot_RAM.srec
Using default protocol (TFTP)
Entry point: 0x00100040, address range: 0x00100000-0x0014b9bc
RedBoot>

RedBoot> go
+No devices on IDE controller 0

Trying NPE-B...success. Using NPE-B with PHY 0.
Ethernet eth0: MAC address 00:d0:12:02:84:30
IP: 192.168.3.2/255.255.255.0, Gatrelease, version 2.01 - built 21:58:52, Nov 30
2006

Platform: Gateworks Avila Family (XScale) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x00000000-0x04000000, [0x0016ba90-0x03fc1000] available
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.
== Executing boot script in 2.500 seconds - enter ^C to abort
^C
RedBoot>

RedBoot> load -r -b %{FREEMEMLO} vncos-1.1.9-1713.xscale-war-gw2348-4.bin
Using default protocol (TFTP)
Raw file loaded 0x0016bc00-0x0081ff1f, assumed entry at 0x0016bc00
RedBoot>

load -r -b %{FREEMEMLO} vncos-1.1.9-1713.xscale-war-gw2348-4.bin
Using default protocol (TFTP)
Raw file loaded 0x0016bc00-0x0081ff1f, assumed entry at 0x0016bc00
RedBoot> fis write -f 0x50000000 -l 0x800000 -b %{FREEMEMLO}
* CAUTION * about to program FLASH
at 0x50000000..0x507fffff from
--------------------------------

mickeym

12-01-2006, 02:09 PM

OK - Just tried redboot_RAM.srec #3 and the output from all commands is the same with the same 'hang' after the fis write command

RedBoot> fis write -f 0x50000000 -l 0x800000 -b %{FREEMEMLO}
* CAUTION * about to program FLASH
at 0x50000000..0x507fffff from

tony

12-01-2006, 02:27 PM

That's too bad. I have done about all that can be done on this end without having one of your boards in-hand.

One thing you can try to do is substitute %{FREEMEMLO} with the actual starting address.

For example, if the output shows:
RedBoot> load -r -b %{FREEMEMLO} vncos-1.1.9-1713.xscale-war-gw2348-4.bin
Using default protocol (TFTP)
Raw file loaded 0x0016bc00-0x0081ff1f, assumed entry at 0x0016bc00

Then the starting address would be 0x0016bc00

If this does not work, then we will need a redboot_RAM.srec from Gateworks for the board you are using.

mickeym

12-02-2006, 12:49 AM

Tony -

The substitution in the command did not work.

Yesterday when I talked to GW, they did not / could not give me a redboot_RAM.srec file that will load Star OS - since Valemount is a substantial GW customer and has a direct connection to GW, could you not contact them and get what we need to solve this?

Otherwise, this board has to be RMA'd and you actually don't have support for a do-it-yourself Star OS load, based on GW's current 2348-4 hardware.

Mickey

lonnie

12-02-2006, 08:26 AM

The problem is simple. They need to work out a redboot_RAM.srec that does not fail. At that point StarV3 should load and run. We cannot do anything more until our code is actually loading and attempting to run. Then it becomes our problem.

I do not have the new GW hardware and I will not be buying any. This would get too expensive if I have to buy every new piece of hardware that comes out.

We won't know if our code supports a DIY load until it actually gets loaded, which is for the DIY guy and GW to figure out, so let's not be blaming VNC at this time. I suspect GW will be working on getting this going. They have the hardware, test equipment and the design people right there. Surely they will figure it out.

tony

12-02-2006, 09:16 AM

If Gateworks is unable to / doesn't know how to generate a redboot_RAM.srec release from their current redboot source branch, please see if they can get you a copy of the source code, and we can generate this release RAM for you.

Once redboot fully supports the board you are using, then our image can be finally flashed.

It is unfortunate that the latest board revision breaks our current redboot release.

If by chance they do not want to release the redboot sources (can't see why not), you can provide them with the sources we use, and ask them to verify it with their latest Avila series.

The sources are in an archive named avila-redboot.tar.bz2, located in the source download archive.

mickeym

12-02-2006, 10:09 AM

I'm just trying to get a handle on what's happening or happened here and a bit anxious to not get farther behind on the project that needs a working WAR4.

- Has Valemount sucessfully loaded Star-OS on any generic GW2348-X board using the DIY files ?

- If so, can I get the model & flash model so I can say to GW what has worked before (yours) and what doesn't now (mine) ?

Thanks,
Mickey

go.fast

12-02-2006, 10:32 AM

You should have just bought a war4 board from Lonnie.

mickeym

12-02-2006, 10:56 AM

I always have before and would have gladly this time - if he had stock - buying the 2348 was the last choice - thanks for the helpful suggestion

tony

12-02-2006, 11:28 AM

Yes, StarV3 itself works on standard Avila hardware, and was the basis of our WAR product line. The hardware we get from Gateworks has since been customized to our needs, but the underlying requirements for having it as a supported platform has not changed from what I can tell. We have not had the opportunity to test the latest hardware revisions Gateworks sells to the public, however.

On another note, I have posted (yet another) redboot_RAM.srec for you to try.