[RESULT] [VOTE] Release Apache NuttX (Incubating) 9.0.0 [RC1]

[Brennan Ashton]

Hi,

The vote closes now as 72hr have passed. The vote PASSES with
8 (+8 non-binding) votes from the PPMC, 0 (+1 binding) vote from the IPMC,
2 (+2 non-binding) votes from the developer community,
0 (+1 non-binding) vote from the other
and no further 0 or -1 votes.

The vote thread:
[1]
https://lists.apache.org/thread.html/r38ffad1d33081c375a0161eeb6eef3a08b8af048c973fddbf9fbc601%40%3Cdev.nuttx.apache.org%3E

I will now bring the vote to gene...@incubator.apache.org to get approval
by the IPMC.
If this vote passes also, the release is accepted and will be published.

Thanks,
Brennan Ashton

[VOTE] Release Apache NuttX (Incubating) 9.0.0 [RC1]

[Brennan Ashton]

Hello all,

This is a call for a vote to release Apache NuttX (Incubating) version
9.0.0.

The Apache NuttX community has voted on and approved a proposal to release
Apache NuttX (Incubating) version 9.0.0.

We now kindly request the Incubator PMC members review and vote on this
incubator release.

NuttX is a real-time operating system (RTOS) with an emphasis on standards
compliance and small footprint. Scalable from 8-bit to 32-bit
microcontroller
environments, the primary governing standards in NuttX are Posix and ANSI
standards. Additional standard APIs from Unix and other common RTOS’s
(such as VxWorks) are adopted for functionality not available under these
standards, or for functionality that is not appropriate for deeply-embedded
environments (such as fork()).

Apache NuttX community vote and result thread:
Result:
https://lists.apache.org/thread.html/rf2361c5e458d993f0b3ccf9559ddf3ef8a7e5c5c55eb1e6d19ed6e1d%40%3Cdev.nuttx.apache.org%3E
Vote:
https://lists.apache.org/thread.html/r38ffad1d33081c375a0161eeb6eef3a08b8af048c973fddbf9fbc601%40%3Cdev.nuttx.apache.org%3E

The release candidates (RC1):
https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.0.0-RC1/

Git tag for the release (RC1):
https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
https://github.com/apache/incubator-nuttx-apps/releases/tag/nuttx-9.0.0-RC1

Hash for the release incubating-nuttx tag:
  725bdfb0e8c704823669d20931fd0a824c462212
Hash for the release incubating-nuttx-apps tag:
  9d4872780f095d7af7414501ccf34ea23d4d565b

Release Notes:
https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.0.0-RC1/ReleaseNotes


The artifacts have been signed with Key :
3554D78458CEB6954B020E12E1B6E30DB05D6280, which can be found in the keys
file:
https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS

Look at here for how to verify this release candidate:
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

The vote will be open for at least 72 hours.

Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Brennan Ashton
Apache NuttX

Re: [VOTE] Release Apache NuttX (Incubating) 9.0.0 [RC1]

[Masayuki Ishikawa]

Hello Brennan and all,

+1

But please note that NuttX now supports 64-bit architectures such as RV64GC
and x86_64. :)

Thanks,
Masayuki


2020年5月1日(金) 16:27 Brennan Ashton :

> Hello all,
>
> This is a call for a vote to release Apache NuttX (Incubating) version
> 9.0.0.
>
> The Apache NuttX community has voted on and approved a proposal to release
> Apache NuttX (Incubating) version 9.0.0.
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> NuttX is a real-time operating system (RTOS) with an emphasis on standards
> compliance and small footprint. Scalable from 8-bit to 32-bit
> microcontroller
> environments, the primary governing standards in NuttX are Posix and ANSI
> standards. Additional standard APIs from Unix and other common RTOS’s
> (such as VxWorks) are adopted for functionality not available under these
> standards, or for functionality that is not appropriate for deeply-embedded
> environments (such as fork()).
>
> Apache NuttX community vote and result thread:
> Result:
>
> https://lists.apache.org/thread.html/rf2361c5e458d993f0b3ccf9559ddf3ef8a7e5c5c55eb1e6d19ed6e1d%40%3Cdev.nuttx.apache.org%3E
> Vote:
>
> https://lists.apache.org/thread.html/r38ffad1d33081c375a0161eeb6eef3a08b8af048c973fddbf9fbc601%40%3Cdev.nuttx.apache.org%3E
>
> The release candidates (RC1):
> https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.0.0-RC1/
>
> Git tag for the release (RC1):
> https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
> https://github.com/apache/incubator-nuttx-apps/releases/tag/nuttx-9.0.0-RC1
>
> Hash for the release incubating-nuttx tag:
>   725bdfb0e8c704823669d20931fd0a824c462212
> Hash for the release incubating-nuttx-apps tag:
>   9d4872780f095d7af7414501ccf34ea23d4d565b
>
> Release Notes:
>
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.0.0-RC1/ReleaseNotes
>
>
> The artifacts have been signed with Key :
> 3554D78458CEB6954B020E12E1B6E30DB05D6280, which can be found in the keys
> file:
> https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS
>
> Look at here for how to verify this release candidate:
>
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>
> The vote will be open for at least 72 hours.
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Brennan Ashton
> Apache NuttX
>

Re: [VOTE] Release Apache NuttX (Incubating) 9.0.0 [RC1]

[Nathan Hartman]

On Fri, May 1, 2020 at 3:27 AM Brennan Ashton 
wrote:

> This is a call for a vote to release Apache NuttX (Incubating) version
> 9.0.0.


+1 (non-binding)

Nathan

Re: STM32H7 FDCAN driver

[John Rippetoe]

Hi All,

Since no new files are allowed to come into the repo without ASF 
licenses, I need some direction on how I should go about re-licensing 
two of the files for this driver. The files in question are


arch/arm/src/stm32f7/stm32_can.h  -- This is only copyrighted by Greg. 
Greg, do I have your permission to re-license this under the new ASF 
license?


arch/arm/src/stm32f7/stm32_can.c  -- In addition to Greg, this is also 
copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What 
steps do I need to take for this file?


Thanks,

John

On 4/23/20 4:48 PM, John Rippetoe wrote:


I just realized that the reference I made to an external document in 
my first email didn't actually get linked too. For those interested, 
see below.


[1] 
https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf


- John

On 4/23/20 3:54 PM, John Rippetoe wrote:


Hello All,

I have been working on adding support for the FDCAN peripheral in the 
STM32H7 and have a basic driver working. It's a bit of a hack in some 
places right now, but it follows the same basic structure as the F7 
driver, which was used as a template to start. I should note that I 
have only been testing by using the CAN example program running in 
loopback mode since I do not currently have any external devices to 
test with.


The FDCAN hardware in the H7 is a pretty significant departure from 
the F7 and earlier, so there is some additional functionality that 
the current upper-level CAN driver isn't really setup to support. I 
wanted to bring the community in on my efforts so we could discuss 
those things and decide whether they are worth pursuing. I personally 
have zero prior experience with CAN, so I am not sure what hardware 
features are typically utilized by most developers here.


The biggest difference that sets the H7 FDCAN apart from its 
predecessors is the storage of messages. Unlike previous hardware 
that made use of a fixed number of mailboxes for sending/receiving 
messages, the H7 FDCAN integrates a 10kb segment of memory called the 
Message RAM that is dedicated to the peripheral. All messages, both 
transmitted and received, and filters are stored here. But more 
interestingly, the RAM is dynamically configured by the user during 
the initialization process based on their needs and can be split up 
into a variety of sections. I don't want to get into a lot of detail 
here since I am likely telling people what they already know, so 
interested parties should look at [1] for a great summary of what the 
hardware can do. What I would like to discuss right now is what 
features we want to use and some implementation ideas for them. Since 
the upper-level driver places messages into FIFOs, it is easy to make 
use of the Rx and Tx FIFOs in hardware. The filters will also be 
necessary for the driver to function. Right now, I have created 
kconfig options for configuring the sections in RAM. That allows to 
user to specify what sections they want, how many messages they want 
to store in each section, and how big the messages are expected to be.


So what works right now? In short, the driver currently replicates 
the functionality of the F7 driver. Here is a bullet list


  * Hardware initialization
  * Bit timing
  * Message RAM setup for filters and FIFOs, configurable via kconfig
  * Rx/Tx FIFOs with appropriate interrupts
  * IOCTL calls implemented by F7 driver (no add/del filters)
  * Txready/Txdone functions
  * Functions to send/receive messages within hardware
  * Tx/Rx interrupt enable/disable


What work needs to be done?

  * Settle on what features to implement and a way to represent the
message RAM layout for efficient use by the driver
  * Add support for RTR messages
  * Add support for FD mode
  * Add config option to enable/disable FIFO overwrite (default setup
is to block when full)
  * Add support for bitrate switching?
  * LOTS of testing
  * nxstyle checks
  * licensing since two files are derived from the F7 code that has
non-ASF licenses.


For now, I think the best path forward is to match the feature set of 
existing CAN drivers. That will allow us to get the basics working 
and well tested before moving onto anything that might require us to 
modify the upper-level driver to add more advanced features such as 
bitrate switching. So that means only using the hardware FIFOs for 
now. I think we should allow the user to configure the message RAM 
via kconfig options for maximum flexibility in the future. Even if we 
only add options for the filter and FIFO sections right now, adding 
in additional features later would be much easier with the 
infrastructure in place.  It also lets the user specify exactly what 
they want, removing the need for the driver to hardcode potentially 
stupid assumptions. For filtering, I have currently enabled a single 
bitmask filter to accept all incoming messages. Implementing the 
add/del filter IOC

Re: STM32H7 FDCAN driver

[Gregory Nutt]

Since no new files are allowed to come into the repo without ASF 
licenses, I need some direction on how I should go about re-licensing 
two of the files for this driver. The files in question are


arch/arm/src/stm32f7/stm32_can.h  -- This is only copyrighted by Greg. 
Greg, do I have your permission to re-license this under the new ASF 
license?


arch/arm/src/stm32f7/stm32_can.c  -- In addition to Greg, this is also 
copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What 
steps do I need to take for this file? 


You have my permission on that file where I am the sole copyright 
holder.  I have no idea what to do on the second.  It cannot come into 
the repository, but I have not heard from Paul Patience in years.


Greg

Re: STM32H7 FDCAN driver

[John Rippetoe]

That's unfortunate. Hopefully he is still reachable at that email. What 
options should I present to him if I do get in touch with him?


John

On 5/1/20 3:02 PM, Gregory Nutt wrote:


Since no new files are allowed to come into the repo without ASF 
licenses, I need some direction on how I should go about re-licensing 
two of the files for this driver. The files in question are


arch/arm/src/stm32f7/stm32_can.h  -- This is only copyrighted by 
Greg. Greg, do I have your permission to re-license this under the 
new ASF license?


arch/arm/src/stm32f7/stm32_can.c  -- In addition to Greg, this is 
also copyrighted by Paul Alexander Patience from Omni Hoverboards 
Inc. What steps do I need to take for this file? 


You have my permission on that file where I am the sole copyright 
holder.  I have no idea what to do on the second.  It cannot come into 
the repository, but I have not heard from Paul Patience in years.


Greg


CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Re: STM32H7 FDCAN driver

[Gregory Nutt]

I really would like to answer your questions, but I don't understand the 
Apache licensing position. Its seems ad hoc and arbitrary to me, at 
least for cases outside of the most mundane.


Perhaps we can get some direction from and Apache mentor?

Sorry,
Greg

On 5/1/2020 1:14 PM, John Rippetoe wrote:
That's unfortunate. Hopefully he is still reachable at that email. 
What options should I present to him if I do get in touch with him?


John

On 5/1/20 3:02 PM, Gregory Nutt wrote:


Since no new files are allowed to come into the repo without ASF 
licenses, I need some direction on how I should go about 
re-licensing two of the files for this driver. The files in question 
are


arch/arm/src/stm32f7/stm32_can.h  -- This is only copyrighted by 
Greg. Greg, do I have your permission to re-license this under the 
new ASF license?


arch/arm/src/stm32f7/stm32_can.c  -- In addition to Greg, this is 
also copyrighted by Paul Alexander Patience from Omni Hoverboards 
Inc. What steps do I need to take for this file? 


You have my permission on that file where I am the sole copyright 
holder.  I have no idea what to do on the second.  It cannot come 
into the repository, but I have not heard from Paul Patience in years.


Greg

CONFIDENTIALITY NOTICE: This communication may contain private, 
confidential and privileged material for the sole use of the intended 
recipient. If you are not the intended recipient, please delete this 
e-mail and any attachments permanently.

Re: STM32H7 FDCAN driver

[John Rippetoe]

I've followed a few of the conversations on here regarding licensing and 
have been a confused as well. It seems like there are a few options, so 
I want to make sure I do things right.


I'll wait for a mentor to chime in when they have a chance. I'm not 
ready to merge yet anyways; I just wanted to get the ball rolling now 
rather than stalling in a PR. Thanks for the help.


John

On 5/1/20 3:25 PM, Gregory Nutt wrote:
I really would like to answer your questions, but I don't understand 
the Apache licensing position. Its seems ad hoc and arbitrary to me, 
at least for cases outside of the most mundane.


Perhaps we can get some direction from and Apache mentor?

Sorry,
Greg

On 5/1/2020 1:14 PM, John Rippetoe wrote:
That's unfortunate. Hopefully he is still reachable at that email. 
What options should I present to him if I do get in touch with him?


John

On 5/1/20 3:02 PM, Gregory Nutt wrote:


Since no new files are allowed to come into the repo without ASF 
licenses, I need some direction on how I should go about 
re-licensing two of the files for this driver. The files in 
question are


arch/arm/src/stm32f7/stm32_can.h  -- This is only copyrighted by 
Greg. Greg, do I have your permission to re-license this under the 
new ASF license?


arch/arm/src/stm32f7/stm32_can.c  -- In addition to Greg, this is 
also copyrighted by Paul Alexander Patience from Omni Hoverboards 
Inc. What steps do I need to take for this file? 


You have my permission on that file where I am the sole copyright 
holder.  I have no idea what to do on the second. It cannot come 
into the repository, but I have not heard from Paul Patience in years.


Greg

CONFIDENTIALITY NOTICE: This communication may contain private, 
confidential and privileged material for the sole use of the intended 
recipient. If you are not the intended recipient, please delete this 
e-mail and any attachments permanently.





CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Re: STM32H7 FDCAN driver

[Gregory Nutt]

I've followed a few of the conversations on here regarding licensing 
and have been a confused as well. It seems like there are a few 
options, so I want to make sure I do things right.


I'll wait for a mentor to chime in when they have a chance. I'm not 
ready to merge yet anyways; I just wanted to get the ball rolling now 
rather than stalling in a PR. Thanks for the help. 


We did do something similar when we created the arch/arm/src/armv8-m 
port.  It started as a clone of the armv8-m port.  We changed all of the 
headers with only my copyright to Apache 2.0.  And all questionable 
headers we copied over with no change.  So I suppose we could generalize 
in this case well.  I would think that the solution would be to bring 
the CAN file in with the existing BSD header.  But let's get 
confirmation on that.


We might also look to see of there is any of Paul's code in the current 
release.  I wrote the original file.  Paul, and many others, contributed 
changes to it.  I don't recall Paul making substantial changes.  Perhaps 
we could quantify that with 'git blame'  may there is no code left by 
Paul in the file after all of these year?


Greg

Re: STM32H7 FDCAN driver

[Nathan Hartman]

On Fri, May 1, 2020 at 3:30 PM John Rippetoe 
wrote:

> I've followed a few of the conversations on here regarding licensing and
> have been a confused as well. It seems like there are a few options, so
> I want to make sure I do things right.


I'm not a mentor but it seems to me that if you can get him to sign an ICLA
then that should eliminate all doubt. But let's wait to hear from a mentor.

Nathan

Re: STM32H7 FDCAN driver

[John Rippetoe]

We might also look to see of there is any of Paul's code in the 
current release.  I wrote the original file.  Paul, and many others, 
contributed changes to it.  I don't recall Paul making substantial 
changes.  Perhaps we could quantify that with 'git blame'  may there 
is no code left by Paul in the file after all of these year?


A quick survey of git blame on stm32/stm32_can.c doesn't show a ton of 
changes by Paul, but some of them still exist in my copy. So probably 
best to proceed with getting him involved.


John

CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Re: STM32H7 FDCAN driver

[John Rippetoe]

Well I feel dumb. I just realized that the MCAN from the samv7 is nearly 
identical to what is used in the STM32H7. That driver already has an ASF 
license plus some of the functionality that my driver is missing. So 
perhaps this won't be an issue after all.


John

On 5/1/20 3:37 PM, Nathan Hartman wrote:

On Fri, May 1, 2020 at 3:30 PM John Rippetoe 
wrote:


I've followed a few of the conversations on here regarding licensing and
have been a confused as well. It seems like there are a few options, so
I want to make sure I do things right.


I'm not a mentor but it seems to me that if you can get him to sign an ICLA
then that should eliminate all doubt. But let's wait to hear from a mentor.

Nathan


CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Accidentally added "doit.sh" file?

[Nathan Hartman]

Commit a86884c615429f837285e214cbfb05a49a725336 adds file:
arch/arm/src/armv8-m/doit.sh

Was that intended to be added?

Cheers
Nathan

Re: Accidentally added "doit.sh" file?

[Gregory Nutt]

Commit a86884c615429f837285e214cbfb05a49a725336 adds file:
arch/arm/src/armv8-m/doit.sh

Was that intended to be added?


Nope it stuck in.  I'll submit a PR to remove it.  ...

PR 942 if you would be so kind to merge.

Re: STM32H7 FDCAN driver

[Justin Mclean]

HI,

> We did do something similar when we created the arch/arm/src/armv8-m port.  
> It started as a clone of the armv8-m port.  We changed all of the headers 
> with only my copyright to Apache 2.0.  And all questionable headers we copied 
> over with no change.  So I suppose we could generalize in this case well.  I 
> would think that the solution would be to bring the CAN file in with the 
> existing BSD header.  But let's get confirmation on that.

That is a good way to approach it (but not the only one).

Thanks,
Justin

Re: STM32H7 FDCAN driver

[Justin Mclean]

HI,

It’s not that every file that gets submitted needs to have an Apache license.

It's only files developed at the ASF by people who have signed ICLAs. If it 
done by people who have not signed ICLA and it’s a new file, it should also 
have a ASF headers, but whoever accepts that PR is ensuring that there are no 
IP issues and takes responsibility for that. For any significant contribution 
it’s best to get an ICLA from the contributor.

If a file has a 3rd party license header DO NOT change it! Even if it Apache 
licensed, the header the ASF uses is different to the ones 3rd parties use.

The only case you can change a header is if the file was part of a software 
grant to the ASF or we have explicit permission from the copyright owner of 
that file (and there may be several) and it that case it best to get them to 
make that change for you.

Other projects are not going to have all of these issues as they a) started at 
the ASF or b) have all committers sign ICLA or similar c) changed the license 
(and all contributors agreed on that) before coming to the ASF.

Thanks,
Justin

Build failed in Jenkins: NuttX-Nightly-Build #113

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 269.34 KB...]
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/nx11

Configuration/Tool: sim/mount

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mount

Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/spiffs

Configuration/Tool: sim/unionfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/unionfs

Configuration/Tool: sim/sixlowpan

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/sixlowpan

Configuration/Tool: sim/configdata

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/configdata

Configuration/Tool: sim/fb

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/fb

Configuration/Tool: sim/nxwm

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/nxwm

Configuration/Tool: sim/rpproxy

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
--2020-05-02 06:42:16--  
https://github.com/OpenAMP/libmetal/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0 
[following]
--2020-05-02 06:42:16--  
https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: 'libmetal.zip'

 0K .. .. .. .. .. 2.60M
50K .. .. .. .. .. 5.44M
   100K .. .. .. .. .. 3.36M
   150K .. .. .. .. .. 4.13M
   200K .. .. .. .. .. 3.10M
   250K .. .. .. .. .. 5.91M
   300K .. .. .. .. .. 9.89M
   350K .. .. .6.85M=0.09s

2020-05-02 06:42:17 (4.23 MB/s) - 'libmetal.zip' saved [384158]

--2020-05-02 06:42:17--  
https://github.com/OpenAMP/open-amp/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/OpenAMP/open-amp/zip/v2020.04.0 
[following]
--2020-05-02 06:42:17--  
https://codeload.github.com/OpenAMP/open-amp/zip/v2020.04.0
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: 'open-amp.zip'

 0K .. .. .. .. .. 3.89M
50K .. ..