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

See Changes: -- [...truncated 266.23 KB...] Configuration/Tool: sim/sixlowpan

Re: Start of the NuttX 9.0 release cycle

Yes, we are learning how to make the first apache release. Let's get it out and refine the process in the next time. Thanks you making this happen! On Tue, Apr 21, 2020 at 6:12 AM Abdelatif Guettouche wrote: > > > Yes, only if the release don't have any bug, but the software always > > has bug, r

How to define STM32_REGION_MASK?

I'm working on the port to the STM32G474 family and writing the arch/arm/src/stm32/hardware/stm32g47xxx_memorymap.h file, and one of the definitions (I'm following the pattern in other files like this) is: #define STM32_REGION_MASK0xf000 How do I determine what value to put there? Thanks

Re: Start of the NuttX 9.0 release cycle

> Yes, only if the release don't have any bug, but the software always > has bug, right? how people fix the issue? the first step is git clone > the code from github: > 1.Review the difference between the release and master > 2.Review the history to see whether other people already fix the issue >

Re: Start of the NuttX 9.0 release cycle

Yes, he did a great work, this morning for instance he stay up to 5:30AM working on it. So, lets move on with the NuttX 9.0 release and learn from this experience. BR, Alan On 4/20/20, Gregory Nutt wrote: > >> For future 2-month releases, I think that on the branch date, we >> should branch an

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 10:55 AM Gregory Nutt wrote: > I think we owe Abdelatif thanks. What has happened could not have > happened without his contribution. > Thank you Abdelatif! :) -adam -- Adam Feuer

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 1:55 PM Gregory Nutt wrote: > > > For future 2-month releases, I think that on the branch date, we > > should branch and immediately make -rc1 tarballs. > > > > Then the community can test, report bugs/showstoppers, and those will > > be fixed on master and backported to t

RE: sending multiple rows to LCD in one go

>From the putrun/getrun prototype: int (*putrun)(fb_coord_t row, fb_coord_t col, FAR const uint8_t * buffer, size_t npixels); #ifndef CONFIG_LCD_NOGETRUN /* Driver specific getrun function */ int (*getrun)(fb_coord_t row, fb_coord_t col, FAR uint8_t * buffer,

Re: Start of the NuttX 9.0 release cycle

For future 2-month releases, I think that on the branch date, we should branch and immediately make -rc1 tarballs. Then the community can test, report bugs/showstoppers, and those will be fixed on master and backported to the branch. When it seems there are no more showstoppers, make -rc2 tar

Re: sending multiple rows to LCD in one go

I understand your interest in supporting the NX graphics system. No intention to have any effect on that. To be clear: absolutely no change to NX is needed here, so there is no API dictation from LCD driver towards NX. I think LCD devices, as any other hardware device, need a driver for NuttX,

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 1:05 PM Gregory Nutt wrote: > >> I agree that we should not let trivial cosmetic things onto the release > >> branch. We should only permit showstopping, critical bugfixes onto the > >> release branch. It is probably a fair comment that we brought too much > >> unimportan

Re: sending multiple rows to LCD in one go

Didn't quite understood what you mean by "crappy" driver interface. My object is to support the core NuttX graphics system.  Not user kludges to get low level access to drivers.  That is unimportant because it is not on the OS roadmap.  It was a mistake to create those userspace drivers in t

Re: Start of the NuttX 9.0 release cycle

I agree that we should not let trivial cosmetic things onto the release branch. We should only permit showstopping, critical bugfixes onto the release branch. It is probably a fair comment that we brought too much unimportant stuff in and the confuses things. Let's add that to the TIL: Only

Re: sending multiple rows to LCD in one go

Hi Greg, sorry, I didn't quite understood your response. You mentioned NX functions which, when using an LCD driver backend, will ultimately always call info putrun(). To draw a rectangle, for example, you would need one putrun per line. This means multiple SPI/I2C transfers and all communicatio

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 11:21 PM Abdelatif Guettouche wrote: > > > But this process make the end user hard to know what's in the release > > since so many patches enter into the branch after it create. > > > The difference between commit id or order make the user life even more > > harder. > > I

Re: Start of the NuttX 9.0 release cycle

> I agree that we should not let trivial cosmetic things onto the release > branch. We should only permit showstopping, critical bugfixes onto the > release branch. It is probably a fair comment that we brought too much > unimportant stuff in and the confuses things. Let's add that to the > TIL:

Re: Start of the NuttX 9.0 release cycle

> But this process make the end user hard to know what's in the release > since so many patches enter into the branch after it create. > The difference between commit id or order make the user life even more harder. I don't see how so. If someone is interested in a released branch why bother wit

Re: Start of the NuttX 9.0 release cycle

But how we describe 9.0 release? Most people will ask two questiones: 1.When(or commit id) the release branch out from master We know this from the branch creation 2.Which patch we cherry-pick from master after the branch is created This we can get from the pose branch PRs and then the huge

Re: Start of the NuttX 9.0 release cycle

We need to make the release candidate tarballs and put them up for testing/signing, and give people a couple of weeks to test them. I guess we aren't going to make the April 30 release but we're all still learning and trying to figure out the process. Just as we had trouble with other things in

Re: Start of the NuttX 9.0 release cycle

I wouldn't hold up the release because of such issues.  First, it is getting better consideration than when I did the job all by myself.  It is already and improvemtn.  And second, as you say, it is a learning experience.  Let's get the job done for better or worse, create a TIL and get read

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 10:34 PM Gregory Nutt wrote: > > > > Before we vote, how about we rebase the release/9.0 to the latest > > master? There still have many difference between master and > > release/9.0: > > If we rebase, we would have to update the release notes and related > documentation ag

Re: Start of the NuttX 9.0 release cycle

The difference between commit id or order make the user life even more harder. The release tarballs have no GIT information in them.  That information is available on the branch, but AFAIK all users of releases use the tarballs with no git information.  Only the release notes describes what

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 10:34 AM Gregory Nutt wrote: > If we rebase, we would have to update the release notes and related > documentation again. You have to freeze the code somewhere; there will > always be things that are omitted from the release that will have to > wait until the next release.

Re: Start of the NuttX 9.0 release cycle

On Mon, Apr 20, 2020 at 10:47 PM Abdelatif Guettouche wrote: > > > Abdelatif cherry-pick many patches but not all of them from master > > after we create the release branch which make the end user hard to > > know what in the release and what not. > > That actually was on purpose, I only cherry pi

Re: sending multiple rows to LCD in one go

On 4/20/2020 8:45 AM, Gregory Nutt wrote: when working with some LCDs (such as SSD1306 or Sharp Memory LCD) via the LCD driver interface, the putrun() method greatly limits the speed at which you can update the screen, since it imposes one I2C/SPI transfer per putrun(). This type of graphical

Re: Start of the NuttX 9.0 release cycle

> Abdelatif cherry-pick many patches but not all of them from master > after we create the release branch which make the end user hard to > know what in the release and what not. That actually was on purpose, I only cherry picked trivial changes or bug fixes. The somewhat large changes are left t

Re: sending multiple rows to LCD in one go

when working with some LCDs (such as SSD1306 or Sharp Memory LCD) via the LCD driver interface, the putrun() method greatly limits the speed at which you can update the screen, since it imposes one I2C/SPI transfer per putrun(). This type of graphical LCDs typically support sending a transfe

Re: Start of the NuttX 9.0 release cycle

If we rebase, we would have to update the release notes and related documentation again.  You have to freeze the code somewhere; there will always be things that are omitted from the release that will have to wait until the next release.  I would vote that we not rebase the release branch. 

Re: Start of the NuttX 9.0 release cycle

Before we vote, how about we rebase the release/9.0 to the latest master? There still have many difference between master and release/9.0: If we rebase, we would have to update the release notes and related documentation again.  You have to freeze the code somewhere; there will always be th

Re: Start of the NuttX 9.0 release cycle

Before we vote, how about we rebase the release/9.0 to the latest master? There still have many difference between master and release/9.0: git log --oneline apache/master > master.log git log --oneline apache/release/9.0 > release.log diff master.log release.log 1,67c1,10 < f706f5e0e8 boards/imxrt1

Re: Start of the NuttX 9.0 release cycle

I think it's about time we called for a vote. Each vote will last 72h, it's tight for a 30 April release, we don't have much room for another round. I backported last night few more PRs, no functional changes, typos and release notes. I guess the only one remaining is 757. On Sat, Apr 18, 2020 at