Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[www23]

Dear D-link please make accessible to the people of SDK Ubicom
To be able to use firmware from other manufacturers
Open-WRT, etc.
hardware is well done soundly and securely from my point of view
Thanks

[EddieZ]

Dear D-link please make accessible to the people of SDK Ubicom
To be able to use firmware from other manufacturers
Open-WRT, etc.
hardware is well done soundly and securely from my point of view
Thanks

Nice request, but you seem to forget that by opening up the Ubicom platform you will be depriving a company of it's business. It's like asking Microsoft to make Windows OpenSource.

[lizzi555]

It's like asking Microsoft to make Windows OpenSource.

Nice idea 

[www23]

Nice request, but you seem to forget that by opening up the Ubicom platform you will be depriving a company of it's business. It's like asking Microsoft to make Windows OpenSource.

I understand you but Ubicom produces chips and SDK them
explained to those who will buy chips if the SDK problem
except you of course
See examples here that I am referring NETGEAR WNR3500L
Now think that people will choose
SDK Ubicom can buy about $ 3000
for this money to buy to correct others' mistakes?
to other chips easier to get SDK
Now is the time open source
If you do not understand now, then start to lose money
then it will be hard for buyers to return
if you do not believe it themselves and then see
but Microsoft did not release the hardware things
so that is not appropriate comparison
Forgive google translator

[www23]

My DIR-655 of hardware but like Software leaves much to be better

[www23]

you will forgive me that I have made you a lot of problems with the downgraded firmware
but you'll also need to understand when I flashed the firmware 1.3x, and surprised
that the router was suitable only for the garbage I was very upset
most interesting thing that has to heap downgraded the firmware is not possible
you think that this is true?
and you do not block for the future is not stable firmware
fewer problems create for ourselves and for consumers
google translator

[www23]

from you D-Link consumer wants to hear that it will solve the problem as soon as possible
golden rule of business customer is always right even if it is not right
not you pick the user, he chooses you

[Lycan]

I know this is going to upset some, but I'm going to state it anyway.

Yes Open Source is the way things are going. In SOME markets. Fact is D-Link sells to a LARGE community with a diverse user base.

I'd wager that less then 3% of d-link users are even aware of of these forums. I'd wager that even less know what open source is.

We purchased the Ubicom platform because they offered the performance we wanted at the right price. We will have Open Source products in the future, I mean look at the DIR-825_B or any of the DNS products.

[www23]

I know this is going to upset some, but I'm going to state it anyway.

Yes Open Source is the way things are going. In SOME markets. Fact is D-Link sells to a LARGE community with a diverse user base.

I'd wager that less then 3% of d-link users are even aware of of these forums. I'd wager that even less know what open source is.

We purchased the Ubicom platform because they offered the performance we wanted at the right price. We will have Open Source products in the future, I mean look at the DIR-825_B or any of the DNS products.

Thank you for your response
I will not argue Ubicom chip is good but as it turns that the newer SDK so more problems are easier to fix an old SDK?
But you also understand that the consumer does not matter at what SDK firmware is made
and no matter how often it is important to go to a router worked and was reliable

[www23]

Notice I did not say that the products of D-Link bad, problems and other companies have enough, in my first router was the DI-604  I was very pleased with it worked like a clock
bought the DIR-655 too but everything worked ,flashed firmware and started  problems
agree that such a future should not be repeated
Google Translator

[Sammydad1]

I agree...it seems like all the home router companies have issues from time to time....  The marketing people blow smoke and the consumers expect it to work like the marketing people hype it.

When the technical people (enthusiats) try to make them RUN not just walk, thats when the real flaws get exposed and you see about them in these forums....

Then the Marketing people get back involved and try to cover up the mistakes they made before....  Folks like Lycan get caught in the middle and get their ears burned....

Dlink should just come clean and fess up about the no downgrading thing....  It really smells bad.

Dave

[www23]

We purchased the Ubicom platform because they offered the performance we wanted at the right price.

and the stability SDK they offered  right price 

[Lycan]

True.

The downgrade thing is a beast of it's own. Fact is that we're still not even sure why the lock was in place. I mean someone had a reason.
If I had to hazard a guess I'd say that because we've had so much trouble with firmware lately they didn't want to deal with older firmwares that were a problem for sure. So place a downgrade lock so that we know everyone is using the right kernel.
Which would have been fine if the code had worked.
But we have newer firmware with solid performance and it seems to work for almost everyone.
Now that you know you can downgrade, try the new stuff out. Tell me what you think.

[www23]

True.

The downgrade thing is a beast of it's own. Fact is that we're still not even sure why the lock was in place. I mean someone had a reason.
If I had to hazard a guess I'd say that because we've had so much trouble with firmware lately they didn't want to deal with older firmwares that were a problem for sure. So place a downgrade lock so that we know everyone is using the right kernel.
Which would have been fine if the code had worked.
But we have newer firmware with solid performance and it seems to work for almost everyone.
Now that you know you can downgrade, try the new stuff out. Tell me what you think.

I had enough to read this so that all understand
http://developer.ubicom.com/documents/ubicom/ultra/sdk_help_full.html
ipBootDecompressor
ipBootDecompressor implements a stand alone executable that has the ability to decompress data that has been compressed using squish or ARJ compression methods. The selection of the compression method is made while configuring a project. The compressed data is resident in the flash and it is decompressed to the SDRAM. The compressed data is the executable image of a project that has been linked to be resident and runnable from the SDRAM. The extry point for this executable is always the first location in the SDRAM. Once BootDecompressor has expanded the compressed data to the SDRAM it transfers control to the first location in the SDRAM thereby transferring control to the project. Selecting the ipBootDecompressor package in the configuration tool automatically triggers the generation of compressed images of project code. The advantage of this is reduced flash sizes. The disadvantage is that boot times will increase as time is spent decompressing the image.

If ipBootDecompressor has been included in a project it is suggested that in ipFile the Compressed Filesystem box should be unchecked. This helps create somewhat smaller flash images.

Article: In-Field Upgrade Control
The SDK supports reliable in-field upgrading of project firmware through a network connection. Four key components are involved:

Upgrade image (the new firmware image).
This must be constructed to include not only the basic firmware, but also additional functions to control the upgrade process after the firmware is uploaded. This file, whose default name is upgrade.bin, is a compressed self-extracting image.
Upload mechanism.
The upgrade image can be transferred to the target device by any mechanism. TFTP is fully supported by the SDK and the Ubicom Device Manager. HTTP requires application-level support in the form of CGIs, examples of which are available in example projects. Any other upload mechanism can be implemented by applications code.
Upgrade mechanism.
The current firmware is effectively replaced by the upgrade firmware in a single atomic operation; i.e. there is no possibility that an error could result in a partial overwrite of the original firmware. If any errors do occur, the original firmware is left intact. To ensure reliability of the upgrade process, the SDK includes checks to avoid these classes of errors:
Power failure during upgrade.
Corruption of image during storage or transmission
Attempts to upgrade to firmware intended for other type of device
Support for reliable upgrading is spread across several SDK and project components: ipHAL, ipUpgrade, upgradec, optionally ipTFTPServer and ipWebSystemUpgrade, and the Ubicom Device Manager tool, UbiDevMan.exe.

Upgrade Configuration
To make a project upgradeable, set the following configuration points:

ipUpgrade:
The ipUpgrade module must be included to enable upgrade support. It is possible to use either the external flash or the external memory as scratch pad area to store the incoming upgrade image.

Under ipUpgrade there is an "Application Identifier" option (UPGRADE_APPLICATION_IDENTIFIER). Set this to a 32-bit number that uniquely identifies the product. This value is stored in the <project>.elf and upgrade.bin file images.

You also need the .elf file from the original factory programming. The path/filename should be specified in the "Reference elf file" node under ipUpgrade. Note: to create the first factory image, "Reference elf file" must be left blank.

 
 

If you want to store the self extracting upgrade image in external memory then enable "Use Extmem" check box under the ip3k node in ipUpgrade. Storing this image in external memory does open up the possibility of losing the upgrade image because of power failure. Enable the "Emergency Upgrade Web Service" node under the "Use Extmem" node if you want an "Emergency Upgrade Web Service" encoded into the <project>.elf and upgrade.bin file images. Refer to In-Field Upgrade Introduction for more details.

During a firmware upgrade, ipUpgrade functions compare the UPGRADE_APPLICATION_IDENTIFIER of an upgrade.bin with the UPGRADE_APPLICATION_IDENTIFIER of the current firmware to ensure that the upgrade is compatible with the current firmware. If the identifiers do not match, an error is raised, and the upgrade fails without changing the current firmware. 

[www23]

I understand that you are not personally blocked the firmware
blocked programmers D-Link or Ubicom
I will wait for new firmware version
1.33 multicast does not work for me