Re: GitHub actions concurrency

[Brennan Ashton]

On Mon, May 24, 2021, 2:09 PM Nathan Hartman 
wrote:

> I noticed this message [1] from Jarek Potiuk to builds@a.o about a new
> concurrency feature of GitHub Actions. Interesting to us?
>
> [1]
> https://mail-archives.apache.org/mod_mbox/www-builds/202105.mbox/%3cCAH067R=0A0oQhn2SghOKmdj561KvXGKjMG6x_ROQqdf=6vs...@mail.gmail.com%3e


I saw the GitHub announcement as well, we will want to move to it, but as
it is an early beta feature I think is makes sense to see how some other
projects like Apache Airflow find it works.

--Brennan

GitHub actions concurrency

[Nathan Hartman]

I noticed this message [1] from Jarek Potiuk to builds@a.o about a new
concurrency feature of GitHub Actions. Interesting to us?

[1] 
https://mail-archives.apache.org/mod_mbox/www-builds/202105.mbox/%3cCAH067R=0A0oQhn2SghOKmdj561KvXGKjMG6x_ROQqdf=6vs...@mail.gmail.com%3e

Cheers,
Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet  wrote:
>
> Hello,
>
> There is a typo in the PCA9555 driver at line 817:
> CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
> CONFIG_PCA9555_INT_NCALLBACKS.

Good catch! Please feel free to open a PR.

> After this we managed to recompile our project using the latest NuttX
> sources, but it fails when trying to init the PHY irq on our STM32F427
> board: We get "unexpected IRQ".
>
> Yes I know that's pretty vague :-)
>
> Is there anything obvious I should have been careful with in this
> domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.

Nathan

Re: (Late) heads-up for new risc-v soc and board

[Abdelatif Guettouche]

Nice work!  Thanks for the contribution!

On Mon, May 24, 2021 at 8:34 PM Janne Rosberg 
wrote:

> Hi Alan,
>
> Yes, it has FPGA “build-in” so you can do very nice processing with that.
> Also 4+1 cores running on 600+Mhz so it’s almost a supercomputer. 😊
> Let’s see what we can squeeze out of it.
> Later on hoping to get SMP config working….
>
> Janne
>
> From: Alan Carvalho de Assis 
> Date: Monday, 24. May 2021 at 22.13
> To: dev@nuttx.apache.org 
> Subject: Re: (Late) heads-up for new risc-v soc and board
> Hi Janne,
>
> Very nice! Kudos!!!
>
> So, this SoC has FPGA integrated on it?
>
> BR,
>
> Alan
>
> On 5/24/21, Janne Rosberg  wrote:
> > Hi all devs,
> >
> > First of all, it’s nice to be back on (public) NuttX development. It’s
> been
> > a while since last time. 😊
> >
> > We are doing porting for MicroChip PolarFire Risc-V SoC and Icicle
> > evaluation board.
> > Basic things already works (uart and gpios) so we can boot to nsh.
> > First PR #3770 is already “pending”
> >
> > If there is anybody who is working on this SoC please let us know so
> that we
> > can combine our work forces…
> > But anyway, we continue with peripheral drivers; I2C already done others
> to
> > follow.
> >
> > This work is was made possible by TII. https://github.com/tiiuae so all
> PR’s
> > are coming from there.
> >
> > Br,
> > Janne
> >
> >
>

Re: (Late) heads-up for new risc-v soc and board

[Janne Rosberg]

Hi Alan,

Yes, it has FPGA “build-in” so you can do very nice processing with that.
Also 4+1 cores running on 600+Mhz so it’s almost a supercomputer. 😊
Let’s see what we can squeeze out of it.
Later on hoping to get SMP config working….

Janne

From: Alan Carvalho de Assis 
Date: Monday, 24. May 2021 at 22.13
To: dev@nuttx.apache.org 
Subject: Re: (Late) heads-up for new risc-v soc and board
Hi Janne,

Very nice! Kudos!!!

So, this SoC has FPGA integrated on it?

BR,

Alan

On 5/24/21, Janne Rosberg  wrote:
> Hi all devs,
>
> First of all, it’s nice to be back on (public) NuttX development. It’s been
> a while since last time. 😊
>
> We are doing porting for MicroChip PolarFire Risc-V SoC and Icicle
> evaluation board.
> Basic things already works (uart and gpios) so we can boot to nsh.
> First PR #3770 is already “pending”
>
> If there is anybody who is working on this SoC please let us know so that we
> can combine our work forces…
> But anyway, we continue with peripheral drivers; I2C already done others to
> follow.
>
> This work is was made possible by TII. https://github.com/tiiuae so all PR’s
> are coming from there.
>
> Br,
> Janne
>
>

Re: (Late) heads-up for new risc-v soc and board

[Alan Carvalho de Assis]

Hi Janne,

Very nice! Kudos!!!

So, this SoC has FPGA integrated on it?

BR,

Alan

On 5/24/21, Janne Rosberg  wrote:
> Hi all devs,
>
> First of all, it’s nice to be back on (public) NuttX development. It’s been
> a while since last time. 😊
>
> We are doing porting for MicroChip PolarFire Risc-V SoC and Icicle
> evaluation board.
> Basic things already works (uart and gpios) so we can boot to nsh.
> First PR #3770 is already “pending”
>
> If there is anybody who is working on this SoC please let us know so that we
> can combine our work forces…
> But anyway, we continue with peripheral drivers; I2C already done others to
> follow.
>
> This work is was made possible by TII. https://github.com/tiiuae so all PR’s
> are coming from there.
>
> Br,
> Janne
>
>

(Late) heads-up for new risc-v soc and board

[Janne Rosberg]

Hi all devs,

First of all, it’s nice to be back on (public) NuttX development. It’s been a 
while since last time. 😊

We are doing porting for MicroChip PolarFire Risc-V SoC and Icicle evaluation 
board.
Basic things already works (uart and gpios) so we can boot to nsh.
First PR #3770 is already “pending”

If there is anybody who is working on this SoC please let us know so that we 
can combine our work forces…
But anyway, we continue with peripheral drivers; I2C already done others to 
follow.

This work is was made possible by TII. https://github.com/tiiuae so all PR’s 
are coming from there.

Br,
Janne

Re: Dev environment

[Nathan Hartman]

On Mon, May 24, 2021 at 1:04 PM Tim Hardisty 
wrote:

> With thanks to Flavio's suggestion (and .json file to point me in the
> right direction) I now have VS Code running under Ubuntu as a full IDE -
> edit/build/debug with Segger jlink all from within VS Code
>
> Had to create custom scripts in the launch.json file to ensure no reset
> on download of nuttx to my sama5d27 otherwise it messed with the
> bootstrap+Uboot config of the processor. Also a bit of faffing to get
> the arm-none-eabi tools from ARM to work (lots of symbolic links needed).
>
> Is this worth documenting and sharing anything anywhere?


Yes!

If you wish to do so, feel free to send a PR. This may be helpful to many
people.

Thanks!

Nathan

Re: Dev environment

[Tim Hardisty]

With thanks to Flavio's suggestion (and .json file to point me in the 
right direction) I now have VS Code running under Ubuntu as a full IDE - 
edit/build/debug with Segger jlink all from within VS Code


Had to create custom scripts in the launch.json file to ensure no reset 
on download of nuttx to my sama5d27 otherwise it messed with the 
bootstrap+Uboot config of the processor. Also a bit of faffing to get 
the arm-none-eabi tools from ARM to work (lots of symbolic links needed).


Is this worth documenting and sharing anything anywhere? I know the 
processor is perhaps a bit obscure, but it might help someone - if so, 
please let me know where/how to best share my information, otherwise I 
will simply document as part of my own project.


Tomorrow will see the start of actually debugging the cause of the 
CANbus driver crashes, but I can now actually do this with proper tools 
at my disposal. And once fixed and proven I will then work out how to do 
pull requests to get the fixes made available...I'm nearly coding in the 
21st century now lol.


On 21/05/2021 20:51, Flavio Castro Alves Filho wrote:

Hello Tim,

I use VSCode with GDB and Segger.

But Ubuntu does not come with GDB. So I use x-pack toolchain to build and debug.

It works well.

Best regards,

Flavio


Em sex., 21 de mai. de 2021 às 13:28, Tim  escreveu:

Eventually got a Linux dev environment up and running (first PC purchased 
failed after a few hours...grrr...now have an Intel i5 NUC for this).  Amazed 
how darn fast compilation is compared to WSL (even on my 3.3GHz Zeon-based 
workstation with the -j6 make option) so that in itself means it was a great 
move! Always liked Linux anyway lol.

Eclipse (latest version) still not playing ball - just won't debug. So I'm 
assuming a platform independent setup issue with it; aka finger trouble :(

I am temporarily using Segger Ozone - worked first time and can finally debug. 
Not sure I like it but hey ho.

As an aside, has anyone got a recommendation of a good, graphical, GDB debugger for 
Linux, that place nicely with NuttX? Not bothered about an IDE as such, and I'm 100% 
happy with building via terminal, but a feature rich and easy to use debugger that looks 
up the source code "thoroughly" is an essential.

But, now I can set breakpoints, I found that lack of debug messages on the 
console was because the .config was sending them to RAM not CONSOLE, because 
that's what is in the sama5d2-xult defconfig file I based my custom config on.

Simple explanation, but is this documented anywhere? Can't find that level of 
syslog stuff using make menuconfig?

Also now, at least, I know that the board is crashing in can_hwinitialize when 
it calls can_putreg(priv, SAM_PMC_PCR, regval)...so next week's task is to find 
out what's up with this (it's not my code).


On 5/12/21, Tim Hardisty  wrote:

From: Alan Carvalho de Assis 

Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig?

  │ -> Build Setup
   │
  │   -> Debug Options
   │
  │ -> Enable Debug Features (DEBUG_FEATURES [=y])
   │
  │   -> CAN Debug Features (DEBUG_CAN [=y])


Indeed I did. And, anyway, even if I hadn't my debug message might
appear but the system would keep running, but it doesn't: it crashes.
I have inserted the while(1) to narrow it down to where it
crashesit is the call to that debug message that does it :(


Try to put a sam_piowrite(PIO_LED_YOURLED, true/false); to between the
caninfo() and the while(1); just for a double check ;-)

By PIO_LED_YOURLED I mean the LED that is turning ON when your board
initializes.

Talking about LEDs... other important thing: normally when NuttX
crashes the board LED start to blink to indicate an issue, is it blinking on 
your

board?

This is a custom board, and no LED such as that. I have removed any LED-
related stuff from the board.h file...is that the issue? Maybe NuttX absolutely
depends on some kind of LED?

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

https://github.com/apache/incubator-nuttx/issues/3769

Le 24/05/2021 à 17:36, Sebastien Lorquet a écrit :

Hello,

There is a typo in the PCA9555 driver at line 817: 
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be 
CONFIG_PCA9555_INT_NCALLBACKS.


After this we managed to recompile our project using the latest NuttX 
sources, but it fails when trying to init the PHY irq on our STM32F427 
board: We get "unexpected IRQ".


Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this 
domain, before I dig the jtag probe to fix it (tomorrow) ?


Sebastien

Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

Hello,

There is a typo in the PCA9555 driver at line 817: 
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be 
CONFIG_PCA9555_INT_NCALLBACKS.


After this we managed to recompile our project using the latest NuttX 
sources, but it fails when trying to init the PHY irq on our STM32F427 
board: We get "unexpected IRQ".


Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this 
domain, before I dig the jtag probe to fix it (tomorrow) ?


Sebastien

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Miguel Wisintainer]

Sometimes show and disappears the nuttx on my ble scan

Enviado do Email para Windows 10

Re: CONFIG_CAN_PASS_STRUCTS disappeared ?

[Sebastien Lorquet]

Okay, thanks.

Sebastien

Le 24/05/2021 à 11:23, Abdelatif Guettouche a écrit :

That option was removed in 9.0, it only affects the SDCC compiler, I
think you can remove it in your case.

Here is a snippet from the release notes.


   * Compatibility Concerns

 - The configuration option CONFIG_CAN_PASS_STRUCT is now
removed.  Previously, it was used (at the cost of breaking standards
support) to support older versions of the SDCC compiler that couldn't
pass structs/unions as functions' parameters.  A newer version of the
compiler has resolved the issue.

On Mon, May 24, 2021 at 10:06 AM Sebastien Lorquet  wrote:

Hello,

Migrating our system from NuttX 7.30 to current trunk

Nothing very bad, just up_arch.h changed to arm_arch.h and it's mostly
compiling fine.

One of our custom drivers use sigqueue, which requires different types
according to CONFIG_CAN_PASS_STRUCTS

This config seems to not exist anymore. Is it implied now? Can I delete
the code that assume absence of this config?

Thanks,

Sebastien

Re: CONFIG_CAN_PASS_STRUCTS disappeared ?

[Abdelatif Guettouche]

That option was removed in 9.0, it only affects the SDCC compiler, I
think you can remove it in your case.

Here is a snippet from the release notes.

>   * Compatibility Concerns

- The configuration option CONFIG_CAN_PASS_STRUCT is now
removed.  Previously, it was used (at the cost of breaking standards
support) to support older versions of the SDCC compiler that couldn't
pass structs/unions as functions' parameters.  A newer version of the
compiler has resolved the issue.

On Mon, May 24, 2021 at 10:06 AM Sebastien Lorquet  wrote:
>
> Hello,
>
> Migrating our system from NuttX 7.30 to current trunk
>
> Nothing very bad, just up_arch.h changed to arm_arch.h and it's mostly
> compiling fine.
>
> One of our custom drivers use sigqueue, which requires different types
> according to CONFIG_CAN_PASS_STRUCTS
>
> This config seems to not exist anymore. Is it implied now? Can I delete
> the code that assume absence of this config?
>
> Thanks,
>
> Sebastien
>

CONFIG_CAN_PASS_STRUCTS disappeared ?

[Sebastien Lorquet]

Hello,

Migrating our system from NuttX 7.30 to current trunk

Nothing very bad, just up_arch.h changed to arm_arch.h and it's mostly 
compiling fine.


One of our custom drivers use sigqueue, which requires different types 
according to CONFIG_CAN_PASS_STRUCTS


This config seems to not exist anymore. Is it implied now? Can I delete 
the code that assume absence of this config?


Thanks,

Sebastien