Re: CDC/ACM console data to NuttX corrupted.
Tim, I may be misunderstanding what you are saying– but it may be that you are confusing USB C Power Delivery host or device functionality with USB 2.0 / USB 3.0 data host or device functionality. See this StackExchange question and answer <https://electronics.stackexchange.com/questions/554203/which-usb-spec-actually-defines-support-for-dual-role-device-type-c-or-usb-3-1>. Note that applies to USB 3.0, not USB 2.0. My understanding from reading the FUSB302 data sheet <https://www.onsemi.com/pdf/datasheet/fusb302b-d.pdf> is that it only implements USB C Power Delivery, and all USB 2.0/3.0 data transport connections must pass by the FUSB302 chip. See Figure 1 and the pinout in Figure 4, there are no D+/D- (USB 2.0) or TX1/TX2/RX1/RX2 connections to the FUSB302. So the FUSB302 cannot be the problem. When you switch the FUSB302 to host or device, it's only the USB C Power Delivery mode that switches. The USB2.0 OTG host or device modes are handled 100% in the SAMA5D2 drivers and only handle the data transport, not the Power Delivery mode. Ok, I'll give the CDC/ACM console thing a try and let you know. -adam On Wed, Aug 16, 2023 at 2:22 PM Tim Hardisty wrote: > Just FUSB302. It uses the toggle mode to work out a device or host attach > and the driver (yes, I authored/submitted that) handles the necessary > reconfiguration of the pull ups/downs and then signals, via a poll, to the > application layer (or, in my case, board-level driver code) what has > occurred to allow host power switching. To make it all work, I also added > (and submitted/have had merged) changes to the SAMA5 usb code to allow a > single physical port (A) to act as host or device switched in real time. It > works! Essentially OTG/dual-role functionality on a processor that doesn't > natively support it. > > Because CDC/ACM fundamentally works on my board, I think the FUSB302 stuff > is not to blame. Knowing you had it working as a console is good to know, > so its probably a mis-configuration somewhere, or a side-effect of the > changes I made (but, yes, had submitted so are now part of NuttX so *could* > raise as an issue: but I'd be the one to fix it lol). > > If you have a config that has console on CDC/ACM working to send me that > would be a great reference but only if it's not too much trouble to > (re)create. > > Once (if) I am sure it is not as simple as a config error I will raise is > as an issue but, for now, I'm inclined to think it's down to me. > > If I get nowhere tomorrow morning, I'll email you my config: a second > opinion would be much appreciated! > On 16/08/2023 21:36, Adam Feuer wrote: > > Are you using an FUSB302 with an FUSB340 (USB Switch)? My understanding is > that the FUSB302 only provides USB C power delivery along with a USB2.0/USB > 3.0 connection. That chip doesn't do anything to allow host and device on > the same port. As far as I know that's a function of the SAMA5D27 and the > NuttX drivers. I actually don't know if the SAMA5D2 UDPHS and UHPHS can > function simultaneously, or whether NuttX supports that. Did you get that > working? Or is that the problem you are trying to solve? > > So what's the problem with filing a bug? And didn't you add support for > the FUSB302 into NuttX? > > Anyway... we can talk on email for now. Do you have one that doesn't work? > I'd love it if you can send it to me. > > What I got working was CDC/ACM console and CDC/ECM ethernet over USB on > the same USB connection. Is that relevant to what you're looking for? If so > I can come up with a config that will do that. > > -adam > > On Wed, Aug 16, 2023 at 12:47 PM Tim Hardisty wrote: > >> Hi Adam, >> >> My board is pushing many boundaries as it allows usb host and device to >> coexist on a single physical port using an FUSB302 controller. It means it >> can never be as clear cut as it being a bug to report! >> >> If you happen to have a config that works for this it would be useful for >> sure, but I will plug away at it more tomorrow as the syslog port not >> behaving is probably a big clue. >> >> Regards, >> >> Tim. >> On 16/08/2023 20:13, Adam Feuer wrote: >> >> Hi Tim and Alan, >> >> I tested CDC/ACM when I was doing the CDC/ECM performance increases about >> 18 months ago. It seemed like everything worked fine on the Jupiter Nano, >> the SAMA5D2-XULT. I can put together a config for this again and test it... >> or send me yours, and I will adapt to Jupiter Nano. If we have a config >> that repros the problem, it should be possible to fix. >> >> Will you file a bug report so we can communicate there in public, and tag >> us or send the url by email? >> >> And then post your config there. I'
Re: CDC/ACM console data to NuttX corrupted.
Are you using an FUSB302 with an FUSB340 (USB Switch)? My understanding is that the FUSB302 only provides USB C power delivery along with a USB2.0/USB 3.0 connection. That chip doesn't do anything to allow host and device on the same port. As far as I know that's a function of the SAMA5D27 and the NuttX drivers. I actually don't know if the SAMA5D2 UDPHS and UHPHS can function simultaneously, or whether NuttX supports that. Did you get that working? Or is that the problem you are trying to solve? So what's the problem with filing a bug? And didn't you add support for the FUSB302 into NuttX? Anyway... we can talk on email for now. Do you have one that doesn't work? I'd love it if you can send it to me. What I got working was CDC/ACM console and CDC/ECM ethernet over USB on the same USB connection. Is that relevant to what you're looking for? If so I can come up with a config that will do that. -adam On Wed, Aug 16, 2023 at 12:47 PM Tim Hardisty wrote: > Hi Adam, > > My board is pushing many boundaries as it allows usb host and device to > coexist on a single physical port using an FUSB302 controller. It means it > can never be as clear cut as it being a bug to report! > > If you happen to have a config that works for this it would be useful for > sure, but I will plug away at it more tomorrow as the syslog port not > behaving is probably a big clue. > > Regards, > > Tim. > On 16/08/2023 20:13, Adam Feuer wrote: > > Hi Tim and Alan, > > I tested CDC/ACM when I was doing the CDC/ECM performance increases about > 18 months ago. It seemed like everything worked fine on the Jupiter Nano, > the SAMA5D2-XULT. I can put together a config for this again and test it... > or send me yours, and I will adapt to Jupiter Nano. If we have a config > that repros the problem, it should be possible to fix. > > Will you file a bug report so we can communicate there in public, and tag > us or send the url by email? > > And then post your config there. I'll try it out and try to repro! > > -adam > > On Wed, Aug 16, 2023 at 10:56 AM Alan C. Assis > wrote: > > > Hi Tim, > > On 8/16/23, Tim Hardisty > wrote: > > I am trying to get CDC/ACM working on my custom board so I can have a > USB console. I have finally worked out the arcane set of CONFIG options > needed, found the to-be-expected bugs/inconstencies with some of the > SAMA5 code, that I have worked around for now (most are covered by > disabling debug assertions for now)...and...finally get an NSH prompt on > a Minicom terminal. > > Yay! > > But data transmission TO the board from Minicom is behaving very > > strangely. > > If I want to send '?' - to see what built-in apps I have, I need to type > the '?' four times followed by 4 ENTERs, then I get the expected > response. Eh? > > Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my > console of choice, via serial, for ages. > > This seems very odd - it's 100% OK to the PC but 100% not OK from PC to > board. > > In case it's related...SYSLOG to the original /dev/ttyS1 no longer > works, and playing with SYSLOG configuration, seems to interfere with > the CDC/ACM usb functionality as well by stopping it working if I dare > to try to log to /dev/console! > > Anyone got any suggestions before I scream even louder!!!??? > > > I never saw this behavior before! > > Since you also tested on Windows, it is not something in the computer > messing with /dev/ttyACM0. > > The first thing I noticed is that none board has usbnsh inside > boards/arm/sama5/x/configs/ so probably you are the first one to > test this feature. > > So, start looking what the boards from other arch enable to get USB > CDC/ACM working as console. > And because there is no usbnsh board config for this chip, maybe it > needs more investigation. > > I'm CC Adam, maybe he already tested it on Jupiter Nano board. > > BR, > > Alan > > > -- > > Regards, > > > > Tim Hardisty > > [image: A picture containing text, clipart Description automatically > generated] > > +44 (0) 1305 534535 > > <http://www.jti.uk.com/> > > JTi.uk.com <https://www.jti.uk.com/> > > <https://www.facebook.com/JTinnovations/> > > \JTinnovations <https://www.facebook.com/JTinnovations/> > > JT Innovations Ltd. > > Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK. > > Company number 7619086 > > VAT Registration GB 111 7906 35 > > > -- Adam Feuer
Re: CDC/ACM console data to NuttX corrupted.
Tim, I used the CDC/ACM as the console device. Will you file a bug and put all that in the bug, and then we can communicate there? -adam On Wed, Aug 16, 2023 at 12:25 PM Tim Hardisty wrote: > Thanks for replying Adam. > > Did you try CDC/ACM for console, or just CDC/ACM itself? CDC/ACM does work > fine using the usbserial example app, it's just using it as a console > that's tripping me up. > > I was drafting a different email before this topic, and may have missed > some relevant information as a result. Here's what I'd drafted: > > --- > > I am trying to set my custom SAMA5D2 board up to use a USB console rather > than UART1. UART1 is the default for all other boards in the repo, with no > SAMA5 boards using a serial console that I can find. > > This is what I've tried so far. > > 1) Add CDC/ACM as a USB device. > > When I run the example "usbserial" app, the cdc/acm device is registered > as /dev/ttyACM0 as expected, and I can connect to it from my PC where the > (USB) COM port is correctly instantiated, and characters are exchanged. > > Good! > > I note that /dev/ttyACM0 is not present in the /dev list however, as > usbserial registers it. > > 2) So I added a call to cdcecm_initialize(0, NULL) to my board bringup. > That makes sure that /dev/ttyACM0 is there at start up, but the usbserial > example app is no longer happy as it wants to register the device itself. > OK, no problem, but at least both these show that the fundamental USB + > CDC/ACM stuff works. > > Now to move console to CDC/ACM. I first removed the board_bringup call to > register and init the cdc/acm device as that will conflict. > > 3) Leave UART1 as a console, check the option to select > CONFIG_CDCACM_CONSOLE. This fails (via a DEBUGASSERT) because the attempt > to register the usb device as /dev/console. Error 16 - Device or Resource > Busy. Probably because UART1 has already claimed /dev/console. Fair enough! > > 4) Select the option CONFIG_NO_SERIAL_CONSOLE instead. That's consistent > with a few search hits on how to do this (thanks Alan C. Cassis as ever for > your videos!) > > This trips up because of a #error in sam_lowput.c since no UART or USART > is defined for console (i.e. it really is expecting there to be a serial > console). It's in lowput.c and I've fixed that by comparing to samv7 and, > for now, disabling debug assertions. > > -- > Stopped that email draft at this point and switched tack as I'd found I > could get it to work but with the problem now reported. > > > On 16/08/2023 20:13, Adam Feuer wrote: > > Hi Tim and Alan, > > I tested CDC/ACM when I was doing the CDC/ECM performance increases about > 18 months ago. It seemed like everything worked fine on the Jupiter Nano, > the SAMA5D2-XULT. I can put together a config for this again and test it... > or send me yours, and I will adapt to Jupiter Nano. If we have a config > that repros the problem, it should be possible to fix. > > Will you file a bug report so we can communicate there in public, and tag > us or send the url by email? > > And then post your config there. I'll try it out and try to repro! > > -adam > > On Wed, Aug 16, 2023 at 10:56 AM Alan C. Assis > wrote: > > > Hi Tim, > > On 8/16/23, Tim Hardisty > wrote: > > I am trying to get CDC/ACM working on my custom board so I can have a > USB console. I have finally worked out the arcane set of CONFIG options > needed, found the to-be-expected bugs/inconstencies with some of the > SAMA5 code, that I have worked around for now (most are covered by > disabling debug assertions for now)...and...finally get an NSH prompt on > a Minicom terminal. > > Yay! > > But data transmission TO the board from Minicom is behaving very > > strangely. > > If I want to send '?' - to see what built-in apps I have, I need to type > the '?' four times followed by 4 ENTERs, then I get the expected > response. Eh? > > Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my > console of choice, via serial, for ages. > > This seems very odd - it's 100% OK to the PC but 100% not OK from PC to > board. > > In case it's related...SYSLOG to the original /dev/ttyS1 no longer > works, and playing with SYSLOG configuration, seems to interfere with > the CDC/ACM usb functionality as well by stopping it working if I dare > to try to log to /dev/console! > > Anyone got any suggestions before I scream even louder!!!??? > > > I never saw this behavior before! > > Since you also tested on Windows, it is not something in the computer > messing with /dev/ttyACM0. > > The first thing I noticed is that none board has usbnsh inside > boa
Re: CDC/ACM console data to NuttX corrupted.
Hi Tim and Alan, I tested CDC/ACM when I was doing the CDC/ECM performance increases about 18 months ago. It seemed like everything worked fine on the Jupiter Nano, the SAMA5D2-XULT. I can put together a config for this again and test it... or send me yours, and I will adapt to Jupiter Nano. If we have a config that repros the problem, it should be possible to fix. Will you file a bug report so we can communicate there in public, and tag us or send the url by email? And then post your config there. I'll try it out and try to repro! -adam On Wed, Aug 16, 2023 at 10:56 AM Alan C. Assis wrote: > Hi Tim, > > On 8/16/23, Tim Hardisty wrote: > > I am trying to get CDC/ACM working on my custom board so I can have a > > USB console. I have finally worked out the arcane set of CONFIG options > > needed, found the to-be-expected bugs/inconstencies with some of the > > SAMA5 code, that I have worked around for now (most are covered by > > disabling debug assertions for now)...and...finally get an NSH prompt on > > a Minicom terminal. > > > > Yay! > > > > But data transmission TO the board from Minicom is behaving very > strangely. > > > > If I want to send '?' - to see what built-in apps I have, I need to type > > the '?' four times followed by 4 ENTERs, then I get the expected > > response. Eh? > > > > Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my > > console of choice, via serial, for ages. > > > > This seems very odd - it's 100% OK to the PC but 100% not OK from PC to > > board. > > > > In case it's related...SYSLOG to the original /dev/ttyS1 no longer > > works, and playing with SYSLOG configuration, seems to interfere with > > the CDC/ACM usb functionality as well by stopping it working if I dare > > to try to log to /dev/console! > > > > Anyone got any suggestions before I scream even louder!!!??? > > > > I never saw this behavior before! > > Since you also tested on Windows, it is not something in the computer > messing with /dev/ttyACM0. > > The first thing I noticed is that none board has usbnsh inside > boards/arm/sama5/x/configs/ so probably you are the first one to > test this feature. > > So, start looking what the boards from other arch enable to get USB > CDC/ACM working as console. > And because there is no usbnsh board config for this chip, maybe it > needs more investigation. > > I'm CC Adam, maybe he already tested it on Jupiter Nano board. > > BR, > > Alan > -- Adam Feuer
Re: Requesting a Hackster.io channel
I get a "not authorized" message when accessing the Hackster channel URL above. -adam On Tue, May 9, 2023 at 10:11 AM Alan C. Assis wrote: > Hi Tomek, > > Done! Thank you very much! Now you are an Admin too! > > I think everyone can access the channel: https://www.hackster.io/nuttx > and start to following. > > I'm not sure if the page is already visible, I added a simple Call For > Action pointing to our Apache Community page. > > BR, > > Alan > > On 5/9/23, Tomek CEDRO wrote: > > Alan/DevList: I have account "cederom" at hackster and can help with > > maintenance :-) > > Have a good day :-) > > Tomek > > > > On Tue, May 9, 2023 at 3:03 PM Alan C. Assis wrote: > >> > >> Dear Hackster.io Platform Team, > >> > >> I'm officially requesting the creation of NuttX Channel at Hackster.io > >> platform. > >> > >> As NuttX is part of Apache Software Foundation I'm CC our team members > >> (PMC and Committers) asking for their agreement. > >> > >> Please respond to ALL with +1 or ACK. > >> > >> BR, > >> > >> Alan > > > > > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > -- Adam Feuer
Re: [DISCUSS] NuttX 10.0.0 Release schedule
Alin, Thanks, I would love your help on the next release, I'm looking forward to working together. cheers adam On Wed, Sep 23, 2020 at 11:15 PM Jerpelea, Alin wrote: > HI Brennan, > > The release schedule looks god. > > @Adam Feuer > I want to help you on the next release process if you want > > Regards > Alin > > > -----Original Message- > From: Adam Feuer > Sent: den 23 september 2020 21:13 > To: dev@nuttx.apache.org > Subject: Re: [DISCUSS] NuttX 10.0.0 Release schedule > > Brennan, > > Thanks for doing all this. I'm willing to be release manager for the next > release after 10.0.0. > > -adam > > > On Tue, Sep 22, 2020 at 10:13 PM Brennan Ashton > > wrote: > > > Hey all, we have talked in loose terms about this release, but I think > > it is time we committed, it has been probably too long since our last > > release. > > > > Here is what I would propose for a release schedule: > > > > 09/28/20 -- Master Stability Window (keep the merging of risky PRs > > to a minimum this week) > > 10/03/20 -- Create the 10.0 release branch > > 10/04/20 - 10/12/20 -- Stabilize / test / release notes > > Additionally in this window we need to make a couple CI tweeks to > > handle the new docs off of the release branch (I expect this won't be > > much work, but will be easier with the branch in place) > > 10/12/20 -- Tag RC0 and call for PPMC / Community Vote > > 10/15/20 (or when we have the votes) Call for IPMC Vote or create a > > new RC if needed to address issues > > 10/23/20 (Pending votes and RC0 issues) -- Release RC0 > > 10/24/20 -- Update site and announce (we have to wait for download > > mirrors to sync). > > > > I know that is almost a month, but that is usually about how long it > > takes for the whole process, but realistically there is only a week or > > so where we are aiming to slow down and stabilize the master branch. > > The rest of it is testing, documenting, voting, and waiting time. > > > > I can be the release manager again for this one. But it would be great > > if someone else jumps in for the release after and I will try to > > document things a bit more to make the process easier. We will need > > to have more than one release manage to graduate, there are other > > projects that have run into this. > > > > --Brennan > > > > > -- > Adam Feuer > -- Adam Feuer
Re: [DISCUSS] NuttX 10.0.0 Release schedule
Brennan, Thanks for doing all this. I'm willing to be release manager for the next release after 10.0.0. -adam On Tue, Sep 22, 2020 at 10:13 PM Brennan Ashton wrote: > Hey all, we have talked in loose terms about this release, but I think > it is time we committed, it has been probably too long since our last > release. > > Here is what I would propose for a release schedule: > > 09/28/20 -- Master Stability Window (keep the merging of risky PRs > to a minimum this week) > 10/03/20 -- Create the 10.0 release branch > 10/04/20 - 10/12/20 -- Stabilize / test / release notes > Additionally in this window we need to make a couple CI tweeks to > handle the new docs off of the release branch (I expect this won't be > much work, but will be easier with the branch in place) > 10/12/20 -- Tag RC0 and call for PPMC / Community Vote > 10/15/20 (or when we have the votes) Call for IPMC Vote or create a > new RC if needed to address issues > 10/23/20 (Pending votes and RC0 issues) -- Release RC0 > 10/24/20 -- Update site and announce (we have to wait for download > mirrors to sync). > > I know that is almost a month, but that is usually about how long it > takes for the whole process, but realistically there is only a week or > so where we are aiming to slow down and stabilize the master branch. > The rest of it is testing, documenting, voting, and waiting time. > > I can be the release manager again for this one. But it would be great > if someone else jumps in for the release after and I will try to > document things a bit more to make the process easier. We will need > to have more than one release manage to graduate, there are other > projects that have run into this. > > --Brennan > -- Adam Feuer
Re: Next release?
Nathan, There's still some work needed in getting install docs working and verified for a widely supported board (STM Nucleo 144 is the one we chose). It will probably be done this week. -adam On Sun, Sep 13, 2020 at 9:54 AM Nathan Hartman wrote: > Hi folks, > > There have been many big changes since the last release including work > focused on reducing memory footprint, a major overhaul of the > documentation, and countless other things. > > We should get the next release started sometime soon. Is there anything in > particular that we should wait on before proceeding? > > Cheers, > Nathan > -- Adam Feuer
Re: NuttX SDXC / exFAT support
This is an MIT-licensed exFAT implementation for Arduinos. Maybe it can be adapted? https://github.com/greiman/SdFat-beta -adam On Wed, Sep 2, 2020 at 9:53 PM Pelle Windestam < pelle.windes...@tagmaster.com> wrote: > > > > Hi everyone, > > > > > > Is there any support for high capacity SD-cards in NuttX, i.e. larger > > > than 32GB? I have done some research online and it seems that for > > > those sizes, SDXC cards using the exFAT file system is required. I > > > have looked through the code and cannot find anything indicating > > > support for either SDXC or exFAT. But I thought I would check in with > > > you guys in case I am missing something. > > > > > > > AFAIK there is not support to SDXC neither exFAT on NuttX. Although there > > exist exFAT support on Linux kernel introduced around version 5.4, I > think > > exFAT is covered by Patents, so it could be an issue. It appears you > need to > > be part of OIN (Open Invention Network) to get rid of patent issues: > > > > > https://www.techradar.com/news/microsoft-is-bringing-its-exfat-patents-to- > > linux-and-open-source > > > > So, instead of discussing how you could implement it, I want to asked > > you: "Why do you want SDXC and exFAT at first place?" > > The reason for asking about this is that we had customers who tried to use > 32GB+ SD-cards in our products, and they wondered why it was not working. > So, this is just an investigation from my side what our capabilities are. > We never tested with such large SD-cards ourselves. > > > Perhaps you could say you want a low cost and big storage solution. > > > > If this is the case, take a look at eMMC option. Ivan from Barin Sports > used > > this solution in their product and I think it better option for big > storage, > > low cost and will avoid you facing some issues with the Microsoft in the > > future. > > > > BTW, if you still thinking about exFAT on NuttX, you should implement it > > following the specification > > ( > https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification) > > or if you don't have issue releasing all your company code as GPL, you > can > > port the exfat-linux project: > > > > https://github.com/arter97/exfat-linux > > > I do not think we will go that path right now, but it would be nice to > have the support of course so you could throw pretty much any SD-card into > the game without thinking about such compatibility issues. Something for > the long TODO-in-the-future list! > > //Pelle > -- Adam Feuer
Re: NuttX project on Hackaday
Super cool, Matias! :) On Thu, Aug 20, 2020 at 1:21 PM Matias N. wrote: > Thank you!! > > On Thu, Aug 20, 2020, at 17:14, Alan Carvalho de Assis wrote: > > WOW!!! > > > > Kudos Matias! Very nice project! > > > > It's inspiring! > > > > BR, > > > > Alan > > > > On 8/20/20, Gregory Nutt wrote: > > > Matias' bike computer project is featured on Hackaday: > > > > https://hackaday.com/2020/08/20/bike-computer-powers-on-long-after-your-legs-give-out/ > > > > > > Also interesting, but off topic, ESP32 Altair Emulator: > > > > https://hackaday.com/2020/08/20/esp32-altair-emulator-gets-split-personality/ > > > > > > > > > -- Adam Feuer
Re: Keyboard FeatherWing
Matias, Thanks for the help. It was an incorrect master clock setting for the board. I updated the Giant Board clock settings, and while I still can't fully boot NuttX, but I am getting some logging lines and stack traces on the serial port now. No garbage. :) -adam On Wed, Aug 19, 2020 at 10:41 PM Adam Feuer wrote: > Matias, > > Thanks, I have a logic analyzer and will try that when I pick it up again. > The weird thing about this is that I can use U-Boot on the serial console > on the Giant Board – it knows how to use the UART correctly. But NuttX > doesn't. > > Ah, that might be it– the two boards run at different frequencies. I am > trying to use a nuttx.bin compiled for the SAMA5-XULT. I will check out the > clock configuration and make one specifically for the Giant Board and its > frequency. > > -adam > > On Wed, Aug 19, 2020 at 10:32 PM Matias N. wrote: > >> When I had this problem of the serial giving garbage I used a logic >> analyzer with pulseview and then try to hunt for a baud rate on the uart >> protocol decoder which would give a valid interpretation. Often I found the >> rate to be a multiple of the expected one which helped me figure out what >> was set incorrectly. >> >> But yeah, without real debugging it will be painful to use. >> >> Best, >> Matias >> > > > -- > Adam Feuer > -- Adam Feuer
Re: Keyboard FeatherWing
Matias, Thanks, I have a logic analyzer and will try that when I pick it up again. The weird thing about this is that I can use U-Boot on the serial console on the Giant Board – it knows how to use the UART correctly. But NuttX doesn't. Ah, that might be it– the two boards run at different frequencies. I am trying to use a nuttx.bin compiled for the SAMA5-XULT. I will check out the clock configuration and make one specifically for the Giant Board and its frequency. -adam On Wed, Aug 19, 2020 at 10:32 PM Matias N. wrote: > When I had this problem of the serial giving garbage I used a logic > analyzer with pulseview and then try to hunt for a baud rate on the uart > protocol decoder which would give a valid interpretation. Often I found the > rate to be a multiple of the expected one which helped me figure out what > was set incorrectly. > > But yeah, without real debugging it will be painful to use. > > Best, > Matias > -- Adam Feuer
Re: Keyboard FeatherWing
I worked on the Giant Board some more today. Its lack of JTAG debugging is maddening. I can't get the console UART1 to work, so I'm not sure how to proceed. I'm just guessing, and swapping SD cards a lot. Urgh. I think it has something to do with the device tree that the Giant Board uses with U-Boot. I can compile, debug, and run just fine on the SAMA5D2-XULT board. But the SD Card that boots that board into NuttX just gives me garbage on the serial line, maybe because of the clock divider being different. The SAMA5D2-XULT boot.bin and u-boot.bin don't use a device tree. If you have any ideas I'd like to know them. I'm stuck. -adam On Wed, Aug 19, 2020 at 10:55 AM Adam Feuer wrote: > Greg, > > That keyboard/screen combo looks pretty cool. I'll see if I can come up > with a use for it. :) > > -adam > > On Wed, Aug 19, 2020 at 10:52 AM Adam Feuer wrote: > >> Greg, Matias, >> >> Yes, I'm still working on NuttX for Giant Board, and the ACME RoadRunner >> <https://www.acmesystems.it/roadrunner>... should have something to show >> soon. >> >> -adam >> >> On Wed, Aug 19, 2020 at 10:33 AM Matias N. wrote: >> >>> Just looked up the Giant Board. Seems also a good target for Linux+NuttX >>> framework presented at the workshop. >>> >>> On Wed, Aug 19, 2020, at 12:36, Gregory Nutt wrote: >>> > Adam, >>> > >>> > Are you still working a the Giant Board? This would be a good >>> companion >>> > board: >>> > >>> https://www.tindie.com/products/arturo182/keyboard-featherwing-qwerty-keyboard-26-lcd/ >>> > >>> > There is a "Solder Party" channel forum on discord.com. Groguard >>> > discusses using the Giant Boards with the keyboard FeatherWing there. >>> > >>> > That could be a lot of fun. I am considering one myself, but I have >>> no >>> > feather boards to drive it. >>> > >>> > >>> >> >> >> -- >> Adam Feuer >> > > > -- > Adam Feuer > -- Adam Feuer
Re: Keyboard FeatherWing
Greg, That keyboard/screen combo looks pretty cool. I'll see if I can come up with a use for it. :) -adam On Wed, Aug 19, 2020 at 10:52 AM Adam Feuer wrote: > Greg, Matias, > > Yes, I'm still working on NuttX for Giant Board, and the ACME RoadRunner > <https://www.acmesystems.it/roadrunner>... should have something to show > soon. > > -adam > > On Wed, Aug 19, 2020 at 10:33 AM Matias N. wrote: > >> Just looked up the Giant Board. Seems also a good target for Linux+NuttX >> framework presented at the workshop. >> >> On Wed, Aug 19, 2020, at 12:36, Gregory Nutt wrote: >> > Adam, >> > >> > Are you still working a the Giant Board? This would be a good >> companion >> > board: >> > >> https://www.tindie.com/products/arturo182/keyboard-featherwing-qwerty-keyboard-26-lcd/ >> > >> > There is a "Solder Party" channel forum on discord.com. Groguard >> > discusses using the Giant Boards with the keyboard FeatherWing there. >> > >> > That could be a lot of fun. I am considering one myself, but I have no >> > feather boards to drive it. >> > >> > >> > > > -- > Adam Feuer > -- Adam Feuer
Re: Keyboard FeatherWing
Greg, Matias, Yes, I'm still working on NuttX for Giant Board, and the ACME RoadRunner <https://www.acmesystems.it/roadrunner>... should have something to show soon. -adam On Wed, Aug 19, 2020 at 10:33 AM Matias N. wrote: > Just looked up the Giant Board. Seems also a good target for Linux+NuttX > framework presented at the workshop. > > On Wed, Aug 19, 2020, at 12:36, Gregory Nutt wrote: > > Adam, > > > > Are you still working a the Giant Board? This would be a good companion > > board: > > > https://www.tindie.com/products/arturo182/keyboard-featherwing-qwerty-keyboard-26-lcd/ > > > > There is a "Solder Party" channel forum on discord.com. Groguard > > discusses using the Giant Boards with the keyboard FeatherWing there. > > > > That could be a lot of fun. I am considering one myself, but I have no > > feather boards to drive it. > > > > > -- Adam Feuer
Re: Roadmap?
Thanks for catching that Abdelatif. I moved the NuttX project board here: https://github.com/apache/incubator-nuttx/projects/2 We can delete it if we don't like it. -adam On Wed, Aug 12, 2020 at 11:43 AM Adam Feuer wrote: > On Wed, Aug 12, 2020 at 11:40 AM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > >> Was it intentional to create it in Apache's and not here: >> https://github.com/apache/incubator-nuttx/projects? > > > Oops. No. :) I'll move it or recreate it there. > > -adam > -- Adam Feuer
Re: Roadmap?
On Wed, Aug 12, 2020 at 11:40 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Was it intentional to create it in Apache's and not here: > https://github.com/apache/incubator-nuttx/projects? Oops. No. :) I'll move it or recreate it there. -adam
Re: Roadmap?
Well I just made a board for us: https://github.com/orgs/apache/projects/13 If we don't like it we can delete it. I added the items from the wiki list as cards in Future, we should really convert them to issues and add more description to them. We can add the issues that we're working on to the current quarter if we want. I don't know what the columns should be so I just added quarters (Q3 2020, Q4 2020, etc.) like Github has. If anyone has a better idea for this let me know. I changed the wiki page to point to this. -adam On Wed, Aug 12, 2020 at 11:25 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > Seems doable. Does anyone have any objections to me creating a board like > this for NuttX? > > Not from me, I think with Github's projects (or milestones) and > consistent labeling of issues and PRs people would have a better > overview. > Anyone can then follow the development of the feature of interest. > > On Wed, Aug 12, 2020 at 7:04 PM Gregory Nutt wrote: > > > > > > > I made a wiki page with the raw list of things that people are asking > for > > > in this thread: > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap > > > > > > Check it out, add anything I missed, and correct errors I made. > > > > > > Maybe the next step would be to try to complete this list, then maybe > > > prioritize it, connecting it with releases and the things people have > > > energy working on and collaborating together on? > > > > > > If what you want to put here doesn't fit on the page, make a child > page. :) > > We probably should also include all Github Issues that are listed as > > enhancements. > -- Adam Feuer
Re: Roadmap?
On Wed, Aug 12, 2020 at 11:04 AM Gregory Nutt wrote: > We probably should also include all Github Issues that are listed as > enhancements. > If we use a Github Project Board like Brennan suggested this would be pretty easy to link them there. -adam -- Adam Feuer
Re: Roadmap?
Brennan, Re: needing an Apache CWiki account, ok, I get it. So something like this? Github's public roadmap: https://github.com/github/roadmap/projects/1 Seems doable. Does anyone have any objections to me creating a board like this for NuttX? -adam On Wed, Aug 12, 2020 at 10:54 AM Brennan Ashton wrote: > On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > > > Folks, > > > > I made a wiki page with the raw list of things that people are asking for > > in this thread: > > > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap > > > I am thinking this might be easier to manage as GH tickets with a label, > and then link on a project board if we want an overview. The thing I really > don't like about the wiki is you need an Apache account to add things which > creates an unfortunate barrier to it and it is even harder to then link to > PRs and code. > > In a couple other projects we had a process where people could bring > forward something like a NuttX Feature Proposal (NFP) where it would be > outlined and the details sorted possibly some PoC done if it was large and > then it could be accepted and executed on. This is a slow process that is > not a bad thing for major changes that have a lot of implications. > -- Adam Feuer
Re: Roadmap?
a similar mechanism for OS level code, which is compiled as if it > >> were a subdirectory of nuttx/. > >> > >> Best, > >> Matias > >> > >> > Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao < > >> > xiaoxiang781...@gmail.com>: > >> > > >> > > I would see the automation test on the roadmap, thanks. > >> > > > >> > > > -Original Message- > >> > > > From: Matias N. > >> > > > Sent: Wednesday, August 5, 2020 4:59 AM > >> > > > To: dev@nuttx.apache.org > >> > > > Subject: Re: Roadmap? > >> > > > > >> > > > Having a (public) roadmap is very good idea, it guides and > >> > > > organizes > >> > > efforts over time and also gives indication to existing or > >> > > potential > >> > > > users about which features which are not currently but might as > >> > > > well > >> be > >> > > there soon. > >> > > > > >> > > > I personally would like to see support for Bluetooth/WiFi on > widely > >> used > >> > > hardware platforms. > >> > > > I'm currently working on getting BLE on nRF working so it is a > >> matter of > >> > > time. I hope that also Alan might steer Espressif into > >> > > add > >> > > > support for ESP32. LoRaWAN stack would also be interesting. > >> > > > I would also add the current documentation effort as part of the > >> roadmap. > >> > > > > >> > > > I think with a Roadmap laid out it would be possible to create > >> > > > GitHub > >> > > milestones (major and minor) and organize issues into each, > >> > > > depending on how disruptive the change is. This would help to have > >> for > >> > > example a 10.x series more or less stable while holding > >> > > bigger > >> > > > changes towards 11.0 or even 12.0. > >> > > > > >> > > > Just my two cents. > >> > > > > >> > > > Best, > >> > > > Matias > >> > > > > >> > > > On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote: > >> > > > > One of the things that I think we are missing is a Roadmap to > >> > > > > guide > >> > > > > and prioritize new feature development. Other RTOS' (like > >> > > > > Zephyr) > >> do > >> > > > > have such published roadmaps and are responsive to needs and > >> requests > >> > > > > of users and sponsors. I have even seen web pages where the > >> > > > > Zephyr > >> > > > > team has laid out what new features on the roadmap will be > >> available > >> > > > > in future releases. > >> > > > > > >> > > > > While I think it would be essentially impossible for us to > manage > >> such > >> > > > > a thing with our loose organiation, I think we should have a > >> roadmap > >> > > > > that identifies the important directions that operating system > >> > > > > will > >> > > take. > >> > > > > > >> > > > > For me, the important thing is to stay relevant and contemporary > >> and > >> > > > > not get lost in some aging niche architecture or toolset. I > >> > > > > think > >> > > > > that the best way to predict where NuttX needs to be is to look > >> > > > > at > >> the > >> > > > > SoCs in use just above the upper end of the NuttX market. I > >> > > > > think > >> > > > > over time, those features will trickle down into embedded > systems > >> > > > > (albeit with some twists and modifications for the embedded > >> market). > >> > > > > The Cortex-M7 introduces I-Cache and L1 D-Cache, for example. A > >> few > >> > > > > years ago, those were higher end features not available on MCUs. > >> > > > > > >> > > > > I think that SMP and AMP are key technologies to get us a leg up > >> > > > > on > >> > > > > future mutli-core MCUs. KERNEL mode places us in a position to > >> > > > > support MCUs with MMUs. A proper TrustZone model for all ARM > >> parts is > >> > > > > needed too (the multi-core TrustZone model is pretty well in > >> > > > > place, > >> > > > > but what do we do with TrustZone on a single CPU?). > >> > > > > > >> > > > > Security, especially IoT security is very important. Some > >> > > > > security > >> > > > > topics are addressed by PROTECTED mode. So although PROTECTED > >> > > > > and > >> > > > > KERNEL build modes are not commonly used, I believe that they > >> > > > > are > >> > > > > important parts of the roadmap. > >> > > > > > >> > > > > Other thoughts? We should collaborate and define a meaningful > >> > > > > roadmap that will keep the OS healthy well into the future. We > >> should > >> > > > > publish that roadmap somewhere so that anyone can see where we > >> > > > > are > >> > > > > going and can offer insights for other directions. > >> > > > > > >> > > > > > >> > > > > > >> > > > >> > > > >> > > >> > > > -- Adam Feuer
Re: IP Clearance
Xiang introduced me to Peter from Xiaomi, and he is going to help gather some overview data so we can see how many files and authors we're going to be dealing with in different areas of the code. We'll be updating the wiki page here: https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing We'll report back when we have some more information. -adam On Tue, Jul 28, 2020 at 5:38 PM Adam Feuer wrote: > A focused effort to do the IP clearing sounds good. If we can get funding > to do it quicker, that would be great too. It's a good idea. > > I did the stats that are on the wiki page for the 9.0 release. I'll see if > I can run this process on the rest of the project and post the numbers to > the wiki. I'll update this thread when I have some results. I'll also see > if I can make PR with the scripts Brennan and I were using so that the > tools can be in the main repo and anyone can use them. > > -adam > > On Sun, Jul 26, 2020 at 8:39 PM 张铎(Duo Zhang) > wrote: > >> OK, there is a sub page, about the status of a module at March >> >> https://cwiki.apache.org/confluence/display/NUTTX/Analysis+March+2020 >> >> Let's try to do this on the whole project to get some numbers? >> >> Thanks. >> >> 张铎(Duo Zhang) 于2020年7月27日周一 上午11:32写道： >> >> > IMO we should at least have some numbers about the current status first, >> > i.e, how many files can be cleared directly, how many can not, etc. >> > >> > With the numbers in hand, then we can decide whether it is possible for >> us >> > to finish the work, and how to finish the work. Even if we want to reach >> > out for help from a 3rd party, we still need these numbers so we can >> decide >> > how much money we should pay... >> > >> > What I can see on the wiki page >> > >> > https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing >> > >> > is just a rough plan, there are no numbers about the current status >> yet. >> > >> > Thanks. >> > >> > Gregory Nutt 于2020年7月27日周一 上午10:43写道： >> > >> >> We have talked a little about IP clearance on the NuttX podling project >> >> but I am not sure if anyone really appreciates the magnitude of this >> >> effort: There is 13 years of commits, possibly 50,000 total commits, >> >> many hundreds of contributors, 1000's of files, 1.5 million lines of >> >> code, and transitions through 3 different configuration management >> >> systems. There is no contact information for the majority of the >> >> contributors and there is no reason to believe that all contributors >> >> will be cooperative. >> >> >> >> I think that anyone who believes that this can be done properly with >> the >> >> part time, now-and-then effort of a couple of people is sorely >> >> mistaken. I think it will require a fully dedicated, team with some >> >> specialized expertise and a substantial amount of time to do. >> >> >> >> The only way that I can conceive of this happening is if we were to >> >> contract a 3rd party software CM/QA/IV house to to do the job. That >> >> would, of course require a serious investment of money. I am wondering >> >> if we could motivate some corporate sponsors to fund such an effort. I >> >> appreciate that that is a long shot but we should consider it. In the >> >> past, Xiaomi, for example, as committed to supporting the licensing/IP >> >> clearance effort. But I don't think that anyone really appreciated the >> >> effort required at that time. >> >> >> >> We do have to make this happen and I don't blame anyone on the PPMC for >> >> not wanting to take this on. It would cost you the next year of your >> >> life .. full time. I wouldn't make that commitment and I would not >> >> expect any other individual to do so either. >> >> >> >> We some need a plan. With no plan, the project will not graduate. >> Even >> >> with a plan in hand, I would not expect graduation to be possible >> within >> >> the next year or more. >> >> >> >> Greg >> >> >> >> >> >> >> > > > -- > Adam Feuer > -- Adam Feuer
Re: Changing headers
Thanks Justin. Can you provide links to the files that had their headers changed (or PRs)? We can correct the header changes. We're trying to follow the license clearing process as outlined on this wiki page: https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing Maybe we need to add a check for PR reviewers to note that license headers for existing files should not be changed outside of this process? -adam On Mon, Aug 3, 2020 at 11:42 PM Justin Mclean wrote: > Hi, > > I noticed a couple of times recently 3rd party headers have been changed. > Please stop doing this. No one on the project can change the headers on a > file without the correct process being followed. Doing so will just make IP > province harder and graduating the project much more difficult. > > In order to change 3rd party headers, for large numbers of files that > generally means we would need a software grant, ICLAs from all contributors > and IP clearance. > > If it's a small number of files and owned by a single owner then we need > documented evidence on this mailing list that the license can be changed. > That doesn’t mean that the files are now "Licensed to the Apache Software > Foundation (ASF) under one or more contributor license agreements.“. > > The Apache license doesn’t change copyright so we would still need to > clearly indicate the copyright owner of the files and use the 3rd party ASF > header shown below. > > Copyright [] [name of copyright owner] > > Licensed under the Apache License, Version 2.0 (the "License"); > you may not use this file except in compliance with the License. > You may obtain a copy of the License at > > http://www.apache.org/licenses/LICENSE-2.0 > > Unless required by applicable law or agreed to in writing, software > distributed under the License is distributed on an "AS IS" BASIS, > WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > See the License for the specific language governing permissions and > limitations under the License. > > Thanks, > Justin -- Adam Feuer
Re: new documentation
Alin and Alan, Regarding showing clear status of the NuttX support for each board– yes, good idea. Matias and I already talked about some ways to do that. We just didn't want to work on that without getting some show of support for this direction. cheers adam On Mon, Aug 3, 2020 at 1:01 AM Jerpelea, Alin wrote: > Hi Adam, > the new documentation looks good and I found it structured and easy to > follow. > I like Alan's suggestion with the status of each board so that people can > know what the status of each board is and set the proper expectation > Best Regards > Alin > > > Från: Alan Carvalho de Assis > Skickat: den 1 augusti 2020 21:34 > Till: dev@nuttx.apache.org > Ämne: Re: new documentation > > Hi Adam, > > It is already getting a very good shape! This is a great improvement to > NuttX! > > In the Supported Boards I think we could implement some table showing > the supported status of each board, similar to this: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.postmarketos.org_wiki_Devices=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=W5J6Fu44S6B8l5kjBrq0VIctd4MfVrBMufGYk2rhMiM=NZhumqoq022xPnYUJi5awErtVlI4mp4ZVmG2CXbsnaY= > > Some RTOSes claim to support some boards, but when you try to use it > you discover only some basic features are supported. I think it is > good for NuttX to make things clear from start. > > Just my 2 cents. > > BR, > > Alan > > On 8/1/20, Adam Feuer wrote: > > Thanks Xiang. > > > > Does anyone else have feedback or improvement ideas? > > > > cheers > > adam > > > > On Sat, Aug 1, 2020 at 1:28 AM Xiang Xiao > > wrote: > > > >> I looked at the content last week, but forget to send my feedback email, > >> sorry. I definitely support the idea: the document is > >> managed and released as the source code and collect all documents in one > >> place. This step is very important to keep the consistent > >> between the implementation and the documentation. It also encourage the > >> contributor improve the document just like the code. > >> > >> > -Original Message- > >> > From: Matias N. > >> > Sent: Saturday, August 1, 2020 1:01 AM > >> > To: dev@nuttx.apache.org > >> > Subject: Re: new documentation > >> > > >> > Hi again, > >> > I was wondering if you have checked the demo for the new documentation > >> that Brennan, Adam and me have put together. I'm really > >> > looking forward to see this part of the official repo. If we can get > >> some validation on the this we can start building a PR to > >> finish > >> > migrating the HTMLs and link existing READMEs as a first step. We can > >> continue working on the content in iterations after that. > >> > > >> > Best, > >> > Matias > >> > > >> > On Thu, Jul 23, 2020, at 11:22, Matias N. wrote: > >> > > Hi, > >> > > I started a new thread since the "Markdown READMEs" one was already > >> too long and it is probably best to leave that one for the > >> > Markdown conversion effort on its own. > >> > > The last couple of days Brennan, Adam and me managed to build a > >> > > working demo of the proposed documentation system. We used a > separate > >> > > repo since the CI jobs we're using (GitHub pages based) are not > >> > > compatible with the main repo (I believe) and to build up something > >> > > worth showing before opening a PR. You can see the result at: > >> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__v01d.github.io_incubator-2Dnuttx_docs_index.html=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=W5J6Fu44S6B8l5kjBrq0VIctd4MfVrBMufGYk2rhMiM=yFE3cZxzxfbrbKhWV6D-3u8p2vzDdKk8Ri7HpdooNQ8= > >> > > > >> > > Summary: > >> > > 1. documentation is under doc/ directory although probably once the > >> > > migration is done we would again use Documentation/ 2. on each push > >> documentation is built using CI and sent to gh-pages branch. > >> > code related jobs do not run for changes under doc/ to speed up PR > >> reviewing. > >> > > 3. most of the pages are stubs indicating its intended purpose, this > >> > > is to be filled later 4. the two sections worth pointing out are > >> "Introduction" and "C coding standard" under "
Re: new documentation
Thanks Xiang. Does anyone else have feedback or improvement ideas? cheers adam On Sat, Aug 1, 2020 at 1:28 AM Xiang Xiao wrote: > I looked at the content last week, but forget to send my feedback email, > sorry. I definitely support the idea: the document is > managed and released as the source code and collect all documents in one > place. This step is very important to keep the consistent > between the implementation and the documentation. It also encourage the > contributor improve the document just like the code. > > > -Original Message- > > From: Matias N. > > Sent: Saturday, August 1, 2020 1:01 AM > > To: dev@nuttx.apache.org > > Subject: Re: new documentation > > > > Hi again, > > I was wondering if you have checked the demo for the new documentation > that Brennan, Adam and me have put together. I'm really > > looking forward to see this part of the official repo. If we can get > some validation on the this we can start building a PR to > finish > > migrating the HTMLs and link existing READMEs as a first step. We can > continue working on the content in iterations after that. > > > > Best, > > Matias > > > > On Thu, Jul 23, 2020, at 11:22, Matias N. wrote: > > > Hi, > > > I started a new thread since the "Markdown READMEs" one was already > too long and it is probably best to leave that one for the > > Markdown conversion effort on its own. > > > The last couple of days Brennan, Adam and me managed to build a > > > working demo of the proposed documentation system. We used a separate > > > repo since the CI jobs we're using (GitHub pages based) are not > > > compatible with the main repo (I believe) and to build up something > > > worth showing before opening a PR. You can see the result at: > > > https://v01d.github.io/incubator-nuttx/docs/index.html > > > > > > Summary: > > > 1. documentation is under doc/ directory although probably once the > > > migration is done we would again use Documentation/ 2. on each push > documentation is built using CI and sent to gh-pages branch. > > code related jobs do not run for changes under doc/ to speed up PR > reviewing. > > > 3. most of the pages are stubs indicating its intended purpose, this > > > is to be filled later 4. the two sections worth pointing out are > "Introduction" and "C coding standard" under "Contributing". > These are > > the result of automatic conversion and then manual editing of NuttX.html > (done by Adam) and NuttXCCodingStandard.html (done by > > me), respectively. The "details" part of "supported platforms" is not > yet fixed since we wanted to get feedback before continuing. > The > > coding standard should be completely converted. > > > > > > As for CI, Brennan mentioned that once integrated on the final repo we > would probably have a job on nuttx repo that triggers the > > website repo rebuild. Thus, it would be the website repo that does the > build and deploy itself. The nuttx repo can still do the > build for > > checking on PRs but it would not make the deploy. > > > > > > What do you think? It would be nice to receive confirmation that this > is also pleasing by other users before continuing with the > effort. > > Also, in that case we can clean up these changes and start a PR on the > main repo and start trying the final CI approach. After > that we > > could finalize migration of the most important parts of the previous > docs (mainly the HTMLs). > > > > > > Best, > > > Matias > > -- Adam Feuer
Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once
I didn't know this, but storing artifacts for 90 days is free for open source projects on Github. This action can be used to upload the artifact: https://github.com/actions/upload-artifact Looks like there is a REST API for listing and downloading artifacts: https://developer.github.com/v3/actions/artifacts/ And the Github CLI can probably use those APIs: https://cli.github.com/ So as Brennan says, one way to do it would be to store the artifact and some metadata about it after every run. Then have something that would download metadata, compare, and report. -adam On Thu, Jul 30, 2020 at 1:17 PM Brennan Ashton wrote: > On Thu, Jul 30, 2020, 1:13 PM Gregory Nutt wrote: > > > > > > > > >>> It is a simple matter to see the cost of a PR if we add bloaty > > >>> (https://github.com/google/bloaty) to ci. > > >>> > > >> Great please file the simple PR to add it. This is not trivial as we > > >> need > > >> to manage the artifacts from previous builds to do the comparison or > > >> double > > >> the build time. We heard you last time, but someone has to do to the > > >> actual > > >> work. > > >> > > > The absolute size of a build by itself is not so useful. You would > > > need the size BEFORE the change (on the same base) for comparison > > > with the size AFTER the change. I assume that bloaty does not have > > > this A to B comparison built in? > > > > I am not a bloaty user so I might not be properly informed. But from > > what I see, it is used to determine the cause of code bloat by analyzing > > the .elf files. I think that would be a second step. A first, more > > trivial step would be to simply detect the size increase, perhaps just > > running 'size nuttx' and comparing to ... what? I imagine we would have > > to keep some artifacts from a previous nightly built to find the A size > > for the A-to-B comparison. If we detect a size increase, then bloaty > > should tell use why. > > > It will do both so might as well just save the output of it. Basically on > the CI job on merge into master we would generate the size/bloaty report > and save these artifacts next to the build (we do this for the source > bundle already) > > Then when the PR runs it would fetch this data from the master build and > pass it to bloaty to run the comparison report for the given build and > report it in the comments or something. > -- Adam Feuer
Re: AMD64 arch
Robert, I think the answer is yes x86_64 is supported. I haven't used it myself, but here's the NuttX x86_64 status blurb: https://cwiki.apache.org/confluence/display/NUTTX/About#80x86 -adam On Tue, Jul 28, 2020 at 8:32 AM Robert Faron wrote: > I am looking for a RTOS to replace the current RTOS we use. We are > currently using FreeDOS, however since it is 16bit it have found it almost > impossible to access a new device, PCIe mmio. While searching the web for > a RTOS I found Nuttx. > > Does Nuttx support x86-64 processors? I thought it might however the more > I read the less I am convinced of it. Basically I only need one > application to run that will need network access and access to locally > stored files along with PCIe MMIO. The PCIe device is a FPGA that has > GPIO, Isolated GPIO, Quadrature decoders, 16bit AO, and 10 CTs. > > Am I barking up the wrong tree with Nuttx? If I am, no biggie. If not and > Nuttx can do what I need can anyone point me in the right direction to get > started? > > Thanks in advance. > NOTICE: This e-mail message and all attachments transmitted with it may > contain trade secrets and confidential information intended solely for the > use of the addressee. If the reader of this message is not the intended > recipient, you are hereby notified that any reading, dissemination, > distribution, copying, or other use of this message or its attachments is > strictly prohibited. If you have received this message in error, please > notify the sender immediately by telephone at 407-679-9716, and delete this > message and all copies and backups thereof. Thank you > -- Adam Feuer
Re: Integrating Nuttx to a firmware project.
Fotis,
The debug.h file defines a lot of debug log settings that can be set or
unset to see debug logging for different functional areas within NuttX. To
use the settings, you first need to set the level you are interested in,
one or more of:
CONFIG_DEBUG_ERROR=yCONFIG_DEBUG_WARN=yCONFIG_DEBUG_INFO=y
The debug.h file has documentation in it explaining how to use the
functions. If I'm working in an area, I search the files I'm working
in for log messages. Typically you'll see something like mcerr("Some
message\n"); Then you know that's what that area is using for logging.
Then look in debug.h to find the CONFIG_DEBUG_ variable that you need
to set to turn on this logging. For the memory card area it's
CONFIG_DEBUG_MEMCARD_ERROR.
You can also define your own custom logging statements
<https://nuttx-companion.readthedocs.io/en/latest/user/debugging.html#custom-debug-logging>
if you want information that doesn't come along with that area's
logging.
You'll need to turn on both switches: the general one (for instance
CONFIG_DEBUG_ERROR) and the one for the area you're interested in
(CONFIG_DEBUG_MEMCARD_ERROR). I had to search the code of the area I'm
working in to understand its particular debug settings.
Does that help?
cheers
adam
On Sat, Jul 25, 2020 at 4:09 AM Fotis Panagiotopoulos
wrote:
> Perfect! kconfig-tweak is what I was looking for. I will give it a try
> later today.
>
> However at this point I would like to ask. How is a debug build defined for
> NuttX?
> Surely there are configs that can be changed. But is there any system-wide
> debug option?
> Is NDEBUG defined in any case?
>
> For example I see CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG which is
> active when CONFIG_DEBUG_SYMBOLS is also active.
> So, I guess CONFIG_DEBUG_SYMBOLS is our general "debug" macro?
>
> My application will most probably need to know whether this is a debug
> build or not.
>
>
>
> Στις Σάβ, 25 Ιουλ 2020 στις 7:44 π.μ., ο/η Adam Feuer
> έγραψε:
>
> > I wrote up the kconfig-tweak usage here:
> >
> >
> >
> https://nuttx-companion.readthedocs.io/en/latest/user/debugging.html#changing-debug-settings-quickly
> >
> > -adam
> >
> > On Fri, Jul 24, 2020 at 3:24 PM Matias N. wrote:
> >
> > > I'm thinking in implementing it in my nuttx workspace manager as well
> =)
> > >
> > > On Fri, Jul 24, 2020, at 17:32, Nathan Hartman wrote:
> > > > On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote:
> > > > >
> > > > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt >
> > > wrote:
> > > > >
> > > > > > a dumb script like that one Abdelatif demonstrated
> > > > > > will multiple calls to kconfig-tweak can be used to turn on all
> of
> > > the
> > > > > > configuration options that you need.
> > > > > >
> > > > >
> > > > > Cool!
> > > >
> > > > I didn't know I could do this. Now that I know, I think I'll convert
> > > > my configs to work this way. It will be much more convenient to have
> > > > just one config for "release" builds and then a script to add or
> > > > remove debugging.
> > > >
> > > > Glad we had this conversation. :-)
> > > >
> > > > Nathan
> > > >
> > >
> >
> >
> > --
> > Adam Feuer
> >
>
--
Adam Feuer
Re: Integrating Nuttx to a firmware project.
I wrote up the kconfig-tweak usage here: https://nuttx-companion.readthedocs.io/en/latest/user/debugging.html#changing-debug-settings-quickly -adam On Fri, Jul 24, 2020 at 3:24 PM Matias N. wrote: > I'm thinking in implementing it in my nuttx workspace manager as well =) > > On Fri, Jul 24, 2020, at 17:32, Nathan Hartman wrote: > > On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote: > > > > > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt > wrote: > > > > > > > a dumb script like that one Abdelatif demonstrated > > > > will multiple calls to kconfig-tweak can be used to turn on all of > the > > > > configuration options that you need. > > > > > > > > > > Cool! > > > > I didn't know I could do this. Now that I know, I think I'll convert > > my configs to work this way. It will be much more convenient to have > > just one config for "release" builds and then a script to add or > > remove debugging. > > > > Glad we had this conversation. :-) > > > > Nathan > > > -- Adam Feuer
Re: Integrating Nuttx to a firmware project.
On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt wrote: > a dumb script like that one Abdelatif demonstrated > will multiple calls to kconfig-tweak can be used to turn on all of the > configuration options that you need. > Cool! -adam -- Adam Feuer
Re: Integrating Nuttx to a firmware project.
If no tool exists for this, we could easily write one– it could look through a file with the debug settings, and turn them on or off in a config. It would help me too. I often want to quickly turn on or off particular debug settings while doing testing. Is this something that's wanted? -adam On Fri, Jul 24, 2020 at 12:18 PM Fotis Panagiotopoulos wrote: > > I keep two config files, one for debug, one for release. Very similar > > except for the kinds of debugging options you mentioned. > > This is exactly what I want to avoid. I will have to support 3 different > boards, with maybe 3 different build types. Thus 9 configurations. > > This will be very difficult to maintain. > If I want to make a change unrelated to the build or the boards (say for > example something in the network system), I will have to manually apply the > change to all these configurations! > And the worst is that there will be no guarantee that all configurations > are in sync (apart from manually checking the diffs between them). > > Στις Παρ, 24 Ιουλ 2020 στις 9:47 μ.μ., ο/η Nathan Hartman < > hartman.nat...@gmail.com> έγραψε: > > > On Fri, Jul 24, 2020 at 12:26 PM Fotis Panagiotopoulos < > > f.j.pa...@gmail.com> > > wrote: > > > > > Hello, > > > > > > So, I have set up my workspace now, and I have NuttX running properly > on > > my > > > custom board. > > > I have another question though, regarding how to set things up for > > > development. > > > > > > Usually I have at least 2 build configurations: one for debugging, one > > for > > > releases etc. > > > > > > Debug builds have assertions enabled, optimizations disabled, various > > > checks enabled etc etc, while release builds the do the opposite. > > > > > > How is this best to be handled by NuttX? Should I have various > > > configuration files to load each time, or is there a better way? > > > > > > I keep two config files, one for debug, one for release. Very similar > > except for the kinds of debugging options you mentioned. > > > > Nathan > > > -- Adam Feuer
Re: About license headers
Duo, Great idea about using the issue. I put a link to the wiki page there. Justin, Regarding getting the copyright owner's permission, it sounds like we need to add a step in the license clearing process <https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing> to find out where the file came from– was it written by the author, or was it contributed from somewhere else? If that's the case, we should initially only work to change the headers of files actually written by the authors. -adam On Thu, Jul 23, 2020 at 11:49 PM 张铎(Duo Zhang) wrote: > I think we could use this issue > > https://github.com/apache/incubator-nuttx/issues/128 > > To track the progress. First I think we should have a full image about the > current status, and then we split the work into several pieces and try to > finish them one by one. > > Thanks. > > Adam Feuer 于2020年7月24日周五 上午12:39写道： > > > Duo, > > > > Hi, yes there is a plan– and we could use your help! > > > > The plan so far involves clearing the licenses (verifying that all files > > have appropriate licenses) and then changing the headers for those we can > > to APL 2.0; or leaving in place the headers that are appropriate; or > > removing files that we don't have grants for. You can see what we have > > here: > > > > https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing > > > > This has a draft process that we are following, and links to some tools > to > > investigate authors and mass-change header files for files that have been > > cleared. > > > > We did some of this for the 9.0 and 9.1 releases. Our idea is do some > files > > or functional areas for each release, until the entire codebase has been > > cleared. > > > > We don't yet have a plan of attack for the next group of files– but with > > 9.2 release coming up we should probably work to come up with an > organized > > system to make sure we make progress each release. > > > > Does that make sense? Do you have any improvements or comments to the > plan? > > Are you willing to help us clear licenses and fix headers? So far it's > just > > been Brennnan and me working on this (If I missed anyone, please let me > > know!) > > > > cheers > > adam > > > > On Thu, Jul 23, 2020 at 1:42 AM 张铎(Duo Zhang) > > wrote: > > > > > First, congratulations on the 9.1.0 release! Our community has done a > > great > > > job. > > > > > > To be honest, it is not easy to get enough votes from IPMC for a OS > > project > > > in ASF, so I asked help from some members I know(yes, all Chinese, you > > can > > > see their name format). > > > > > > They all mentioned that the license header is a problem. I know that > this > > > is not easy, as we have tons of files, and there are some files with > > > copyright other than our Greg Nutt. So I do not mean that we must clean > > up > > > all the license headers before the next release, but I still want to > know > > > that, do we have a plan on it? > > > > > > Thanks. > > > > > > > > > -- > > Adam Feuer > > > -- Adam Feuer
Re: About license headers
Duo, Hi, yes there is a plan– and we could use your help! The plan so far involves clearing the licenses (verifying that all files have appropriate licenses) and then changing the headers for those we can to APL 2.0; or leaving in place the headers that are appropriate; or removing files that we don't have grants for. You can see what we have here: https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing This has a draft process that we are following, and links to some tools to investigate authors and mass-change header files for files that have been cleared. We did some of this for the 9.0 and 9.1 releases. Our idea is do some files or functional areas for each release, until the entire codebase has been cleared. We don't yet have a plan of attack for the next group of files– but with 9.2 release coming up we should probably work to come up with an organized system to make sure we make progress each release. Does that make sense? Do you have any improvements or comments to the plan? Are you willing to help us clear licenses and fix headers? So far it's just been Brennnan and me working on this (If I missed anyone, please let me know!) cheers adam On Thu, Jul 23, 2020 at 1:42 AM 张铎(Duo Zhang) wrote: > First, congratulations on the 9.1.0 release! Our community has done a great > job. > > To be honest, it is not easy to get enough votes from IPMC for a OS project > in ASF, so I asked help from some members I know(yes, all Chinese, you can > see their name format). > > They all mentioned that the license header is a problem. I know that this > is not easy, as we have tons of files, and there are some files with > copyright other than our Greg Nutt. So I do not mean that we must clean up > all the license headers before the next release, but I still want to know > that, do we have a plan on it? > > Thanks. > -- Adam Feuer
Re: Markdown READMEs?
Matias, Yes, I have the NuttX.html file partially converted. I'll see if I can get that a little close today and submit a PR to your branch. -adam On Tue, Jul 21, 2020 at 11:23 AM Matias N. wrote: > Ok, got it sooner than expected. The docs are published to: > https://v01d.github.io/incubator-nuttx/ < > https://v01d.github.io/incubator-nuttx/docs/index.html> > Right now as we're working on a "docs" branch in this fork, you can see it > generated here: > https://v01d.github.io/incubator-nuttx/docs/index.html > On pull-requests it only does the build and not the publish (not tested > this yet). Would be cool to have PRs viewable somewhere but that is more > complex. > > Now we could work a bit on the content. I would iterate on a proposed > structure and put some placeholders. > Adam, you mentioned you wanted to convert on HTML file for demonstration > purposes. Do you want to do that? > > Best, > Matias > > On Tue, Jul 21, 2020, at 15:11, Matias N. wrote: > > Hi, > > yes, we have CI building sphinx already. I'm now trying to get this be > published via GitHub pages using a subdirectory per version (version would > be "master" or the tip of each release or the tag name). Anyways, this is > not how it would work exactly in the end since the website repo would take > care of this. But probably some components of the CI system would be > similar. Also, this allows to have something to show when by put a bit of > content there for demonstration purposes. > > > > Will let you know when I get something to show. > > > > Best, > > Matias > > > > On Tue, Jul 21, 2020, at 15:02, Adam Feuer wrote: > >> Brennan, > >> > >> Cool, that's awesome. I didn't know that discussion was going on in the > PR. > >> :) > >> > >> -adam > >> > >> On Tue, Jul 21, 2020 at 10:55 AM Brennan Ashton < > bash...@brennanashton.com> > >> wrote: > >> > >> > On Tue, Jul 21, 2020, 10:51 AM Adam Feuer wrote: > >> > > >> > > Matias, Maciej, > >> > > > >> > > Ok, I looked into doing a Sphinx build of RST and Markdown via > Github and > >> > > publishing to Github pages automatically. People have done it, but > it's a > >> > > bit more complicated than I thought. I'll see if I can get it > worked out > >> > in > >> > > my repo first and then we can go from there. It will take me a few > days > >> > > because I have other stuff going on too. > >> > > > >> > > -adam > >> > > > >> > > >> > Hey Adam yesterday I submitted the PR for doing the build via GitHub > >> > Actions and it generates the artifacts. I would not worry too much > about > >> > GitHub pages since we need to get it attached to the Apache system. > >> > > >> > You can see some of the discussion here > >> > https://github.com/v01d/incubator-nuttx/pull/1#issuecomment-661952429 > >> > > >> > --Brennan > >> > > >> > >> > >> -- > >> Adam Feuer > >> > > > -- Adam Feuer
Re: Markdown READMEs?
On Mon, Jul 20, 2020 at 4:32 PM Justin Mclean wrote: > That's a great idea, but it may have some impact on teh LICENSE file > depending on what libraries, fonts etc are bundled with the documentation. > You may need to make sure that nothing with an incomparable license sneaks > in. > The current docs are pure HTML and text, so I don't think there are any fonts in there. -adam -- Adam Feuer
Re: Markdown READMEs?
I also love having the docs in the repository and releases, and versioned along with the code. It makes things so much easier. If I had to pick between the current docs (HTML/txt) and the wiki, I would pick the current docs! -adam On Mon, Jul 20, 2020 at 4:17 PM Nathan Hartman wrote: > On Mon, Jul 20, 2020 at 7:07 PM Gregory Nutt wrote: > > > For those really opposed to HTML, another option is to simply use the > > Confluence versions of the documents here: > > https://cwiki.apache.org/confluence/display/NUTTX/Documentation > > > > These are the same documents that are currently in nuttx/Documentation. > > They are read-only now (since the master is in the repository), but > > imagine that could change. > > > I think there is an advantage to documentation being in the repository (and > by extension in the releases): Longevity of the documents. If someone has a > copy of the tarball and no Internet, they have the docs. I suppose this > might be less of a concern today than it was in the past, but I think > there's some legitimacy to it still. > > Nathan > -- Adam Feuer
Re: Markdown READMEs?
Thanks Matias. Following Matias' proposal, here's a separate repo with just one page of the HTML docs partially converted: https://github.com/adamfeuer/nuttx-docs The files here could also be copied into a directory in the nuttx source tree too, for instance under Documentation/sphinx-docs instead of living in a separate repo. You can see the docs rendered using the Sphinx Read the Docs Theme here: https://nuttx-docs.readthedocs.io I converted this with pandoc and some Vim macros– the supported boards table didn't get done right, so needs more work, and pandoc also messed up the internal links, so they need to be fixed. But this gives the idea about how the docs would look, at least. I'll add an example Markdown file here so we can look at how the mixed ReStructuredText / Markdown stuff looks together. -adam On Mon, Jul 20, 2020 at 2:26 AM Xiang Xiao wrote: > Can we keep the doc and nuttx in one git? The major of document is > normally couple with the code. The separation make the > synchronization between code and document more harder. Other similar > project(e.g. Linux and Zephyr) use the same git manage both > code and document: > https://github.com/torvalds/linux/tree/master/Documentation > https://github.com/zephyrproject-rtos/zephyr/tree/master/doc > Other propose looks good to me. Maybe we can integrate wiki into the new > document structure later. > > Thanks > Xiang > > > -Original Message- > > From: Matias N. > > Sent: Monday, July 20, 2020 11:39 AM > > To: dev@nuttx.apache.org > > Subject: Re: Markdown READMEs? > > > > Hi, > > after reading all responses I would propose to: > > > > 1. use Markdown for all READMEs: the syntax is simple and perfectly > readable in pure text > > > > 2. start a doc-specific repo using RST format (has nice support for > writing API descriptions, among other things useful for > technical docs) > > which would generate the documentation using Sphinx on GitHub CI and > make that available somewhere in the website. Using > > GitHub CI to build docs using Sphinx appears also very easy: > https://github.com/marketplace/actions/sphinx-build. The > "readthedocs" > > theme looks very nice also: > https://sphinx-rtd-theme.readthedocs.io/en/stable/ > > > > For (1) I can start by porting the main README and maybe then we could > distribute the task for all other READMEs. > > Regarding (2), this repository would follow versioning of NuttX as well > as mater. On the website one can choose which version of > the > > documentation to display. > > > > Best, > > Matias > > -- Adam Feuer
Re: Markdown READMEs?
Version documentation is quite useful, specially for such a dynamic project > as NuttX. I'm not sure it would require to have everything in a single > repo, since it is not really necessary to tie every single code commit to a > doc commit. I think a doc for master, updated as the code evolves, while > having doc tagged with the same version numbers as the codebase, could be > already enough and simple enough. That works– what I was trying to say was that the docs need to have the same version as the release numbers, so you can know you're reading accurate docs for that version. As long as we have process to keep them in sync, we're good. Having separate repos will also simplify dealing with doc PRs vs code PRs, > can have different maintainers, requirements, CI system, etc. (imagine > having a doc update triggering a full CI rebuild). > To me, it's a preference– with most CI systems you can set it to watch certain directories or types of files. Again, I would encourage you to think in a scenario where you have a > specific repo holding all documentation which describes how to use and work > with NuttX, starting from simple "quickstart", to advanced technical > information and even an API reference. Agreed. This is also my vision. > In that case, READMEs throughout the repo would not need to have a lot of > the information that today exists there, sprinkled in all of the READMEs. > For that reason, I don't think it is worth it using something richer than > Markdown for READMEs. > As long as we can mix Markdown and RST (or whatever we use for the richer documentation) then Markdown is ok with me. Where this would come in handy is something like the Supported Boards tree you've been describing. In Zephyr each board doc is a seamless part of the main docs. > Anyways, if it comes down to "use the same for everything, or leave it as > is" I would indeed vote for the first option Likewise. But if we use Sphinx we can mix Markdown and RST. However, Zephyr went with "everything the same" and just uses RST (Zephyr supported boards <https://docs.zephyrproject.org/latest/boards/index.html>; example board Nitrogen <https://docs.zephyrproject.org/latest/boards/arm/96b_nitrogen/doc/index.html>; example board nitrogen RST on github <https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/96b_nitrogen/doc/index.rst> ). -adam -- Adam Feuer
Re: Markdown READMEs?
A few comments: - It would be great to have the documentation in the same repository, to make synchronizing a particular documentation version with the code. - Or if we don't do that, have some other explicit versioning that matches the code, and do simultaneous releases. Code and docs synchronized will make peoples' lives a lot easier. - RST is as readable in plain text format as Markdown, and is also rendered automatically by Github (example rendered by Github <https://github.com/adamfeuer/nuttx-companion/blob/master/docs/user/install.rst>; raw version <https://raw.githubusercontent.com/adamfeuer/nuttx-companion/master/docs/user/install.rst> ). - The main difference between RST and Markdown formatting is the way links are handled. RST has a different link format and also has support for internal linking– in my opinion that's what makes RST really good for technical documentation. - Converting READMEs to RST or Markdown can be done manually or semi-manually, it's not that hard. We could design a system that included both text and RST or Markdown to support the transition. - Sphinx supports generating documentation using both RST and Markdown (recommonmark) <https://www.sphinx-doc.org/en/master/usage/markdown.html>so you can mix them. I think getting our docs and READMEs into a single system using RST or RST/Markdown would be great. -adam On Fri, Jul 17, 2020 at 9:23 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > It would be great to have READMEs in Markdown, as said before, it's > still plain text and can be rendered by other tools/websites. Because > it was brought out, VIM also has plugins for syntax highlighting, > instant rendering, etc. > It was also suggested to use Markdown for release notes. > > On Fri, Jul 17, 2020 at 5:12 PM Matias N. wrote: > > > > No problem, just wanted to clear any possible confusion when considering > the idea. > > > > On Fri, Jul 17, 2020, at 13:09, Maciej Wójcik wrote: > > > Sure, Matias. I was not addressing your proposition in any way. I was > just > > > commenting on existing format of READMEs. > > > > > > I am neutral regarding separate repository with documentation. At > least at > > > the moment, I need to sleep with the idea (more). > > > > > > Some if not all READMES will stay in the repository and I was > suggesting > > > reformatting them. > > > > > > Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. : > > > > > > > > > > > > What I think would be great, is to pick any of this two standards. > > > > > > > > What I was trying to convey in my previous e-mail is that we can > choose > > > > Markdown for READMEs (the prefered choice, IMHO) and either > Markdown, RST, > > > > or anything else for the eventual doc-repo. These are independent > choices, > > > > one does not have to affect the other. In fact, maybe RST is better > for the > > > > doc-repo, since it supports richer syntax more apropriate for > building > > > > documentation. > > > > > > > > Best, > > > > Matias > > > > -- Adam Feuer
Re: [nuttx][avr] Issues while building avr (atmega) board example.
Could we put the compilers in a private repository or web server? Maybe Apache has solved this problem before. -adam On Thu, Jul 16, 2020 at 12:21 PM Pavel Ionut < pavel.ionut.catalin...@gmail.com> wrote: > Also, regarding the CI stuff. > > Seems like Microchip has the official compiler(s) download links under a > (login) wall. > What would be the approach in this case (so that the compilers could be > downloaded by the CI scripts)? > There are various binaries scattered across the internet, but I guess the > official releases would be desirable. > > Regards. > > On Thu, Jul 16, 2020 at 8:15 PM Pavel Ionut < > pavel.ionut.catalin...@gmail.com> wrote: > > > Hello, > > > > I created a PR for the build issue. > > Will have a go at the CI stuff. > > > > Regards. > > > > On Thu, Jul 16, 2020 at 5:48 PM Xiang Xiao > > wrote: > > > >> > >> > >> > -Original Message- > >> > From: Pavel Ionut > >> > Sent: Wednesday, July 15, 2020 6:48 PM > >> > To: dev@nuttx.apache.org > >> > Subject: [nuttx][avr] Issues while building avr (atmega) board > example. > >> > > >> > Hello, > >> > > >> > Basically I'm trying to build the moteino-mega board example and I > >> found some issues. > >> > I have prepared a fix for all of these issues, but first of all I want > >> your opinion on one of the issues. > >> > > >> > >> It will be great if you can take some time to enable the build check for > >> AVR, so we can avoid the build break in the feature. Only three files > need > >> to change: > >> > >> > https://github.com/apache/incubator-nuttx-testing/blob/master/testlist/all.dat > >> > https://github.com/apache/incubator-nuttx-testing/blob/master/cibuild.sh > >> > >> > https://github.com/apache/incubator-nuttx-testing/blob/master/docker/linux/Dockerfile > >> > >> > Seems like the linux avr-gcc does not include double_t as a type > inside > >> the compiler provided , and double_t is used inside > >> > the libs and the build fails. > >> > > >> Yes, the change Is made in the recent commit: > >> commit d17b963bcab98e2d2f641623547837a8d3fe94cd > >> Author: Xiang Xiao > >> Date: Sun Jun 28 14:04:30 2020 +0800 > >> > >> libc: Move double_t typedef from sys/types.h to math.h > >> > >> specified here: > >> > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/math.h.html > >> > >> Signed-off-by: Xiang Xiao > >> Change-Id: I3497a73908301d999cf1cfc4a66552a7ca4868c6 > >> Before this commit, double_t is defined in include/sys/types.h, but we > >> found that this definition may different from the toolchain's one, so > this > >> patch move the definition into include/nuttx/lib/math.h. Both case work > >> correctly(no mismatch) until your case: > >> 1.double_t come from include/nuttx/lib/math.h when we enable NuttX's > libm > >> 2.double_t come from toolchain's math.h when we enable toolchain's libm > >> > >> > One possible fix (currently using) is to typedef it inside compiler.h > >> (for the AVR compiler), however, I don't know if this would be > >> > correct since I see no other typedefs inside that file. > >> > > >> > >> Another place is arch/avr/include/types.h, all arch specific types > >> definition come from here. > >> > >> > Regards > >> > >> > -- Adam Feuer
Re: Markdown READMEs?
I like the idea of doing a ReStructured Text build in CI. I'd help convert READMEs and other docs to RST. And I'd be willing to contribute the RST docs I have already as a starting place if people are interested. They are already Apache 2.0 Licensed. -adam On Thu, Jul 16, 2020 at 6:45 AM Matias N. wrote: > Documenting boards using the README's in each subdirectory (by converting > them to Markdown and having them rendered somewhere) is indeed to most > direct approach. Although I would say it is an intermediate solution. > > I think having an explicit repo holding documentation written in something > more powerful (ReStructured text, or whatever) would probably allow to get > better results. In this repo a CI system could use python or whatever > dependency necessary. No need to add build-dependencies to NuttX codebase > for that. > > In that scenario, I would try to move most of the user-friendly > documentation towards that repo away from the board READMEs, leaving them > only with technical details that are better described there. I would still > use Markdown in that case, due to how GitHub renders them. > > So, until something like that is done I think it would be appropriate to > move all READMEs to Markdown and have them available somewhere, but as I > mentioned, I think having a doc.nuttx.org site or something similar to > Zephyr's would really increase the user-friendliness of NuttX. > > That said, I can help in both efforts, this is something I've been meaning > to work on for sometime and there was simply no infrastructure available at > the moment (that is why I worked on the NuttX GitBook but such effort is > definitely not for just one person). > > Best, > Matias > > On Thu, Jul 16, 2020, at 01:20, Adam Feuer wrote: > > Zephyr uses Sphinx <https://www.sphinx-doc.org/en/master/> and > ReStructured > > Text (RST) <https://docutils.sourceforge.io/rst.html>for their docs. > I'm a > > fan obviously, it's great for writing hyperlinked technical > documentation. > > Sphinx requires Python, though. > > > > The board list with pictures is a great idea, and I'd be willing to help > > with it. > > > > -adam > > > > On Wed, Jul 15, 2020 at 9:11 PM Maciej Wójcik wrote: > > > > > > what do you think about using Markdown for README files? > > > > > > Since the project was very conservative so far, I used regular > expression > > > to parse some existing files into Markdown. Although it is not > completely > > > reliable. I also think that markdown in repository would be great. > > > > > > Even trying to sneak in some first Markdown file already :D > > > > > > > https://github.com/apache/incubator-nuttx-apps/blob/2fdd7529251919315bce62ceb0b130d7f135c506/graphics/lvgl/README.md > > > > > > > One of the reasons I really like the Zephyr docs... > > > > > > Yes, it is also my impression. This is why I am trying to create > > > interactive documentation right now. > > > > > > Kconfig NuttX data is extracted using the same library as Zephyr does. > > > > > > Here are some existing READMES parsed into markdown > > > http://nuttx-config.nxtlabs.pl/#/apps. To be more specific > > > apps/*/README.txt files. > > > > > > I would like to add boards section as well in form of tiles with > pictures > > > and board configuration support comparison inspired by this > > > https://node.green. > > > > > > Complete tree of READMEs with a search is also in my mind > > > https://gitlab.com/nuttx-upm/kconfig-browser/web-ui/-/issues/25 > > > > > > How it works: currently there is a pipeline which runs for multiple > > > tags/branches (master, releases/9.1, releases/9.0, ...) and extracts > data > > > into static JSON. Then Vue.js application is trying to render it. > Pipeline > > > triggers automatically weekly to keep the master fresh. > > > > > > > > > Am Do., 16. Juli 2020 um 03:55 Uhr schrieb Matias N. : > > > > > > > On Wed, Jul 15, 2020, at 22:45, Brennan Ashton wrote: > > > > > I would be huge fan of this. It makes it a lot more approachable, > I > > > had > > > > > started converting the main readme in particular but I did not get > very > > > > > far. It's a lot of work. > > > > > > > > I can help with that if you want > > > > > > > > > Did you see Adams work here > > > > > https://nuttx-companion.readthedocs.io/en/latest/ > > > > > >
Re: Markdown READMEs?
Zephyr uses Sphinx <https://www.sphinx-doc.org/en/master/> and ReStructured Text (RST) <https://docutils.sourceforge.io/rst.html>for their docs. I'm a fan obviously, it's great for writing hyperlinked technical documentation. Sphinx requires Python, though. The board list with pictures is a great idea, and I'd be willing to help with it. -adam On Wed, Jul 15, 2020 at 9:11 PM Maciej Wójcik wrote: > > what do you think about using Markdown for README files? > > Since the project was very conservative so far, I used regular expression > to parse some existing files into Markdown. Although it is not completely > reliable. I also think that markdown in repository would be great. > > Even trying to sneak in some first Markdown file already :D > > https://github.com/apache/incubator-nuttx-apps/blob/2fdd7529251919315bce62ceb0b130d7f135c506/graphics/lvgl/README.md > > > One of the reasons I really like the Zephyr docs... > > Yes, it is also my impression. This is why I am trying to create > interactive documentation right now. > > Kconfig NuttX data is extracted using the same library as Zephyr does. > > Here are some existing READMES parsed into markdown > http://nuttx-config.nxtlabs.pl/#/apps. To be more specific > apps/*/README.txt files. > > I would like to add boards section as well in form of tiles with pictures > and board configuration support comparison inspired by this > https://node.green. > > Complete tree of READMEs with a search is also in my mind > https://gitlab.com/nuttx-upm/kconfig-browser/web-ui/-/issues/25 > > How it works: currently there is a pipeline which runs for multiple > tags/branches (master, releases/9.1, releases/9.0, ...) and extracts data > into static JSON. Then Vue.js application is trying to render it. Pipeline > triggers automatically weekly to keep the master fresh. > > > Am Do., 16. Juli 2020 um 03:55 Uhr schrieb Matias N. : > > > On Wed, Jul 15, 2020, at 22:45, Brennan Ashton wrote: > > > I would be huge fan of this. It makes it a lot more approachable, I > had > > > started converting the main readme in particular but I did not get very > > > far. It's a lot of work. > > > > I can help with that if you want > > > > > Did you see Adams work here > > > https://nuttx-companion.readthedocs.io/en/latest/ > > > > > > I thought it would be really nice to integrate the board list with the > > > readme content into it. (While keeping the content readable in the > source > > > control). > > > > Yes, I was actually imagining some sort of CI command on the website (not > > sure the wiki handles that) that could build a list with all boards > > containing a README, link to it and display it there nicely formatted. > > Something like readthedocs could possibly do it already, not sure. > > > > One of the reasons I really like the Zephyr docs is because of this, you > > can see how they present their supported boards there: > > https://docs.zephyrproject.org/latest/boards/index.html > > Even further, each board description has a nice picture, specification > > list, etc. I thank that would be really useful and easy to do (the > picture > > could be stored in some stable location and the README simply link to > it). > > > > Best, > > Matias > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
I pushed a PR for the SAMA5D27 SDMMC support: https://github.com/apache/incubator-nuttx/pull/1393 After this is done, I plan to work on NuttX support for ACME RoadRunner <https://www.acmesystems.it/roadrunner> and Groboard's GiantBoard <https://groboards.com/giant-board/>. Both are SAMA5D27 boards I would like to use in some projects. -adam On Thu, Jul 2, 2020 at 10:17 PM Adam Feuer wrote: > Hi, > > I pushed a cleaned-up working SAMA5 SDMMC driver to this branch: > > > https://github.com/starcat-io/incubator-nuttx/tree/feature/sama5d27-sdmmc-support > > It's ported from imxrt_usdhc.c, there were some differences but the > structure is largely the same. This driver works with DMA, and can do > widebus (4-bit) transfers in UHS_DDR50 mode (double data-rate 50MHz, so one > transfer each on the rising and falling of the SD clock); up from the > ixmrt's default of UHS_SDR25 (single data rate 25MHz). > > I haven't run nxstyle on it, I will try to do that this weekend, update > the formatting, and get a PR submitted for review. > > cheers > adam > > > > On Wed, Jun 17, 2020 at 9:19 PM Adam Feuer wrote: > >> Thanks Nathan. It's been interesting learning how to port and debug NuttX >> drivers. Hopefully I will be able to write something about it when I get >> the code accepted. >> >> It was helpful that I could port a driver used by the same chip >> peripheral IP block on other NuttX supported chips. I didn't have to write >> it from scratch. Takeyoshi suggested doing the port and he was right about >> it. >> >> -adam >> >> >> On Wed, Jun 17, 2020 at 5:46 PM Nathan Hartman >> wrote: >> >>> On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: >>> >>> > SDMMC write is working now too. So the driver can do the following: >>> > >>> >- Non-DMA read and write >>> >- DMA read and write in SDMA mode >>> >- 1 bit bus >>> >- 4 bit bus (widebus) >>> >- up to 25Mhz >>> > >>> > I'm going to work on cleanup, documentation, and PR next. I'll post a >>> > branch here when I get it somewhat cleaned up. >>> >>> >>> That's exciting! Thanks for your hard work and for posting updates in the >>> meantime. >>> >>> Cheers, >>> Nathan >>> >> >> >> -- >> Adam Feuer >> > > > -- > Adam Feuer > -- Adam Feuer
Re: driver question about memory and calloc
The problem was that the interrupts the driver was waiting for (wait interrupts) did not include SDMMC_INT_DINT, the DMA Boundary Pause interrupt. The calloc() / kmm_memalign() memory allocation put the buffer in a place where the SDMA Buffer Boundary was not encountered, so the SDMA Boundary Pause didn't happen. When I removed the extra memory allocation, the SDMA Boundary Pause happened, but: 1. The interrupts that the driver was waiting for didn't include the DMA Boundary Pause interrupt, so the driver never got a signal to wake up and restart the SDMA transfer 2. The driver wasn't handling SDMA Boundary Pause interrupts, so I had to add handling code for it. Just writing this here in case it helps anyone looking for how this was solved. I'm back on track. -adam On Wed, Jul 8, 2020 at 2:22 PM Adam Feuer wrote: > The kmm_malloc() also has the same effect of making it work. > > I think what's going on is that the transfer is passing a SDMA Buffer > Boundary— they are 4kb (configurable, but that's the default). SDMA pauses > when passing one, and needs to be reenabled by software. I can see the > SDMMC_INT_DINT being fired when I dump the SDMMC registers, but that > interrupt is not enabled for some reason... I'm trying to track it down now. > > -adam > > On Tue, Jul 7, 2020 at 9:09 PM Adam Feuer wrote: > >> Greg, >> >> Thanks. I'll change the call to kmm_malloc() or kmm_memalign() and see if >> that works too. >> >> cheers >> adam >> >> On Tue, Jul 7, 2020 at 9:03 PM spudaneco wrote: >> >>> I don't know anything about the DMA, but you should not call calloc() >>> from within the OS. That does not work in all configurations.Instead >>> include nuttx/kmalloc,h and call kmm_malloc(). If you want aligned memory, >>> call kmm_memalgn().Sent from Samsung tablet. >>> Original message From: Adam Feuer >>> Date: 7/7/20 9:40 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: >>> driver question about memory and calloc Hi,I am getting the SAMA5D27 SDMMC >>> SD Card driver pull request ready. There'sone small issue I'm working on, >>> though. There's a place in the driverinitialization where I calloc() some >>> memory– 466 bytes. DMA data transferswhile reading from files times out if >>> I don't have the calloc() in there.With the memory allocated, everything >>> works fine. Nothing writes to thisblock of memory– I memset it and examined >>> it before, during, and aftertransfers using GDB. It's just an unused block >>> of memory.I'm trying to find out if other amounts of memory work– smaller >>> than about100 bytes doesn't work, and I know it works reliably at 466 >>> bytes. I'lltrack the exact number down tomorrow.But my question is, why >>> does this work? The driver datasheets< >>> http://ww1.microchip.com/downloads/en/devicedoc/ds60001476b.pdf>don'tmention >>> that the chip needs aligned memory for its buffers, and the Atmeland U-Boot >>> drivers don't use aligned memory. And since nothing isoverwriting the >>> memory, what is the calloc() doing to prevent the SDMMC DMAengine from >>> completing the transfer?If anyone has seen behavior like this, I'd love to >>> know it. I'd like totake this otherwise useless code out, or at least know >>> why I need it.Link to the specific line of code in sam_sdmmc.c< >>> https://github.com/starcat-io/incubator-nuttx/blob/feature/sama5d27-sdmmc-support/arch/arm/src/sama5/sam_sdmmc.c#L3737>cheersadam-- >>> Adam Feuer >> >> >> >> -- >> Adam Feuer >> > > > -- > Adam Feuer > -- Adam Feuer
Re: driver question about memory and calloc
The kmm_malloc() also has the same effect of making it work. I think what's going on is that the transfer is passing a SDMA Buffer Boundary— they are 4kb (configurable, but that's the default). SDMA pauses when passing one, and needs to be reenabled by software. I can see the SDMMC_INT_DINT being fired when I dump the SDMMC registers, but that interrupt is not enabled for some reason... I'm trying to track it down now. -adam On Tue, Jul 7, 2020 at 9:09 PM Adam Feuer wrote: > Greg, > > Thanks. I'll change the call to kmm_malloc() or kmm_memalign() and see if > that works too. > > cheers > adam > > On Tue, Jul 7, 2020 at 9:03 PM spudaneco wrote: > >> I don't know anything about the DMA, but you should not call calloc() >> from within the OS. That does not work in all configurations.Instead >> include nuttx/kmalloc,h and call kmm_malloc(). If you want aligned memory, >> call kmm_memalgn().Sent from Samsung tablet. >> Original message From: Adam Feuer >> Date: 7/7/20 9:40 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: >> driver question about memory and calloc Hi,I am getting the SAMA5D27 SDMMC >> SD Card driver pull request ready. There'sone small issue I'm working on, >> though. There's a place in the driverinitialization where I calloc() some >> memory– 466 bytes. DMA data transferswhile reading from files times out if >> I don't have the calloc() in there.With the memory allocated, everything >> works fine. Nothing writes to thisblock of memory– I memset it and examined >> it before, during, and aftertransfers using GDB. It's just an unused block >> of memory.I'm trying to find out if other amounts of memory work– smaller >> than about100 bytes doesn't work, and I know it works reliably at 466 >> bytes. I'lltrack the exact number down tomorrow.But my question is, why >> does this work? The driver datasheets< >> http://ww1.microchip.com/downloads/en/devicedoc/ds60001476b.pdf>don'tmention >> that the chip needs aligned memory for its buffers, and the Atmeland U-Boot >> drivers don't use aligned memory. And since nothing isoverwriting the >> memory, what is the calloc() doing to prevent the SDMMC DMAengine from >> completing the transfer?If anyone has seen behavior like this, I'd love to >> know it. I'd like totake this otherwise useless code out, or at least know >> why I need it.Link to the specific line of code in sam_sdmmc.c< >> https://github.com/starcat-io/incubator-nuttx/blob/feature/sama5d27-sdmmc-support/arch/arm/src/sama5/sam_sdmmc.c#L3737>cheersadam-- >> Adam Feuer > > > > -- > Adam Feuer > -- Adam Feuer
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC2 release
+1 Thanks Brennan! I used the checkrelease.sh script to check hashes, signatures, required files, and that sim:nsh builds. See below for output. Manually built and ran the release for sama5d2-xult:nsh on the SAMA5D2-Xplained Ultra board. -adam ./tools/checkrelease.sh --gpg-output --release 9.1.0-RC2 Downloading release files from https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC2/ Checking apache-nuttx-9.1.0-incubating.tar.gz sha512... OK: apache-nuttx-9.1.0-incubating.tar.gz sha512 hash matches. Checking apache-nuttx-9.1.0-incubating.tar.gz GPG signature: gpg: Signature made Tue 07 Jul 2020 05:06:27 PM PDT gpg:using RSA key 66C4832A165ECC9354895A209750ED7E692B99E2 gpg: Good signature from "Brennan Ashton " [unknown] gpg: aka "Brennan Ashton " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3554 D784 58CE B695 4B02 0E12 E1B6 E30D B05D 6280 Subkey fingerprint: 66C4 832A 165E CC93 5489 5A20 9750 ED7E 692B 99E2 OK: apache-nuttx-9.1.0-incubating.tar.gz gpg signature matches. Checking apache-nuttx-9.1.0-incubating.tar.gz for required files: OK: all required files exist in nuttx. Checking apache-nuttx-apps-9.1.0-incubating.tar.gz sha512... OK: apache-nuttx-apps-9.1.0-incubating.tar.gz sha512 hash matches. Checking apache-nuttx-apps-9.1.0-incubating.tar.gz GPG signature: gpg: Signature made Tue 07 Jul 2020 05:06:27 PM PDT gpg:using RSA key 66C4832A165ECC9354895A209750ED7E692B99E2 gpg: Good signature from "Brennan Ashton " [unknown] gpg: aka "Brennan Ashton " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3554 D784 58CE B695 4B02 0E12 E1B6 E30D B05D 6280 Subkey fingerprint: 66C4 832A 165E CC93 5489 5A20 9750 ED7E 692B 99E2 OK: apache-nuttx-apps-9.1.0-incubating.tar.gz gpg signature matches. Checking apache-nuttx-apps-9.1.0-incubating.tar.gz for required files: OK: all required files exist in apps. Trying to build nuttx sim:nsh... OK: we were able to build sim:nsh On Wed, Jul 8, 2020 at 8:41 AM Alan Carvalho de Assis wrote: > Great work Brennan! > > My vote: +1 > > $ ls -l nuttx* > -rwxrwxr-x 1 alan alan 176192 Jul 8 12:33 nuttx > -rwxrwxr-x 1 alan alan 69792 Jul 8 12:33 nuttx.bin > -rw-rw-r-- 1 alan alan 196384 Jul 8 12:33 nuttx.hex > > > $ arm-none-eabi-size nuttx >textdata bss dec hex filename > 69688 1042484 72276 11a54 nuttx > > BR, > > Alan > > On 7/8/20, Nathan Hartman wrote: > > On Tue, Jul 7, 2020 at 8:40 PM Brennan Ashton > wrote: > >> Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time > >> to vote on accepting it for release. If approved we will seek final > >> release approval from the IPMC. Voting will be open for 72hr. > >> > >> This RC replaces RC1 which was never released due to files that were > >> being stripped out by the releases process breaking the sim and z80 > >> targets. > > > > Summary: > > +1 to release > > > > Development system: Linux > > > > Verified: > > * Signatures > > * SHA-512 sums > > * Tarball contents match nuttx-9.1.0-RC2 tags, (except for expected > > differences: removal of asf.yaml, .gitignore, .github, and addition > > of.version). In particular, confirmed the asm files for sim and z80 > > targets that were missing in RC1 are present in RC2. > > * Incubating in artifact names > > * LICENSE, NOTICE, README.txt, DISCLAIMER-WIP present in both tarballs > > * Successfully build and run b-g474e-dpow1:nsh configuration (NEW in > > NuttX-9.1) > > > > Dependencies: > > * gcc-arm-none-eabi-7-2017-q4-major > > * kconfig-conf from NuttX tools repository > > > > Other dependencies from Debian packages: > > * binutils-dev 2.31.1-16 > > * bison 2:3.3.2.dfsg-1 > > * flex 2.6.4-6.2 > > * gperf 3.1-1 > > * libelf-dev 0.176-1.1 > > * libgmp-dev 2:6.1.2+dfsg-4 > > * libisl-dev 0.20-2 > > * libmpc-dev 1.1.0-1 > > * libmpfr-dev 4.0.2-1 > > * libncurses5-dev 6.1+20181013-2+deb10u2 > > * libusb-1.0-0-dev 2:1.0.22-2 > > * libusb-dev 2:0.1.12-32 > > * texinfo 6.5.0.dfsg.1-4+b1 > > > > Thanks to everyone for making this release (candidate) possible! > > > > Cheers, > > Nathan > > > -- Adam Feuer
Re: driver question about memory and calloc
Greg, Thanks. I'll change the call to kmm_malloc() or kmm_memalign() and see if that works too. cheers adam On Tue, Jul 7, 2020 at 9:03 PM spudaneco wrote: > I don't know anything about the DMA, but you should not call calloc() from > within the OS. That does not work in all configurations.Instead include > nuttx/kmalloc,h and call kmm_malloc(). If you want aligned memory, call > kmm_memalgn().Sent from Samsung tablet. > Original message ----From: Adam Feuer > Date: 7/7/20 9:40 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: > driver question about memory and calloc Hi,I am getting the SAMA5D27 SDMMC > SD Card driver pull request ready. There'sone small issue I'm working on, > though. There's a place in the driverinitialization where I calloc() some > memory– 466 bytes. DMA data transferswhile reading from files times out if > I don't have the calloc() in there.With the memory allocated, everything > works fine. Nothing writes to thisblock of memory– I memset it and examined > it before, during, and aftertransfers using GDB. It's just an unused block > of memory.I'm trying to find out if other amounts of memory work– smaller > than about100 bytes doesn't work, and I know it works reliably at 466 > bytes. I'lltrack the exact number down tomorrow.But my question is, why > does this work? The driver datasheets< > http://ww1.microchip.com/downloads/en/devicedoc/ds60001476b.pdf>don'tmention > that the chip needs aligned memory for its buffers, and the Atmeland U-Boot > drivers don't use aligned memory. And since nothing isoverwriting the > memory, what is the calloc() doing to prevent the SDMMC DMAengine from > completing the transfer?If anyone has seen behavior like this, I'd love to > know it. I'd like totake this otherwise useless code out, or at least know > why I need it.Link to the specific line of code in sam_sdmmc.c< > https://github.com/starcat-io/incubator-nuttx/blob/feature/sama5d27-sdmmc-support/arch/arm/src/sama5/sam_sdmmc.c#L3737>cheersadam-- > Adam Feuer -- Adam Feuer
driver question about memory and calloc
Hi, I am getting the SAMA5D27 SDMMC SD Card driver pull request ready. There's one small issue I'm working on, though. There's a place in the driver initialization where I calloc() some memory– 466 bytes. DMA data transfers while reading from files times out if I don't have the calloc() in there. With the memory allocated, everything works fine. Nothing writes to this block of memory– I memset it and examined it before, during, and after transfers using GDB. It's just an unused block of memory. I'm trying to find out if other amounts of memory work– smaller than about 100 bytes doesn't work, and I know it works reliably at 466 bytes. I'll track the exact number down tomorrow. But my question is, why does this work? The driver datasheets <http://ww1.microchip.com/downloads/en/devicedoc/ds60001476b.pdf>don't mention that the chip needs aligned memory for its buffers, and the Atmel and U-Boot drivers don't use aligned memory. And since nothing is overwriting the memory, what is the calloc() doing to prevent the SDMMC DMA engine from completing the transfer? If anyone has seen behavior like this, I'd love to know it. I'd like to take this otherwise useless code out, or at least know why I need it. Link to the specific line of code in sam_sdmmc.c <https://github.com/starcat-io/incubator-nuttx/blob/feature/sama5d27-sdmmc-support/arch/arm/src/sama5/sam_sdmmc.c#L3737> cheers adam -- Adam Feuer
checkrelease.sh script
Hi, I added a sim:nsh build to the new checkrelease.sh script, the PR is here: https://github.com/apache/incubator-nuttx/pull/1382 If you're interested, you can try this out on the new 9.1.0-RC2 candidate when it comes out. cheers adam -- Adam Feuer
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release
Hi, I need to change my vote to -1 for 9.1.0-RC1. I updated the checkrelease.sh script to build sim:nsh as suggested by Xiang. (No PR yet, but here's the script on my branch: checkrelease.sh.) I discovered that the RC1 release candidate appears to be missing this file: boards/sim/sim/sim/src/etc/init.d/rcS The script can build a git checkout from HEAD just fine. On the release candidate, it doesn't build, and gives this error: make[2]: Entering directory '/home/adam/src/nuttx/nuttx-sama5d3-xplained/nuttx/tools/tmp1/ dist.apache.org/nuttx/boards/sim/sim/sim/src' make[2]: *** No rule to make target 'etc/init.d/rcS', needed by 'etctmp/etc/init.d/rcS'. Stop. make[2]: Leaving directory '/home/adam/src/nuttx/nuttx-sama5d3-xplained/nuttx/tools/tmp1/ dist.apache.org/nuttx/boards/sim/sim/sim/src' Makefile:326: recipe for target '.depend' failed make[1]: *** [.depend] Error 2 make[1]: Leaving directory '/home/adam/src/nuttx/nuttx-sama5d3-xplained/nuttx/tools/tmp1/ dist.apache.org/nuttx/arch/sim/src' tools/Makefile.unix:441: recipe for target 'pass2dep' failed make: *** [pass2dep] Error 2 If you add the file, the build is ok. This seems to indicate a problem with the release candidate— for some reason the rcS file is not being included properly. Or am I getting something wrong...? -adam On Thu, Jul 2, 2020 at 11:25 AM Nathan Hartman wrote: > On Thu, Jul 2, 2020 at 1:12 PM Nathan Hartman > wrote: > > Summary: > > +1 to release > > > > Development system: Linux > > > > Verified: > > * Signatures (note GPG reports the key is expired) > > Correction, follow-up: I re-imported the key. GPG no longer reports > the key as expired. My vote remains +1. > > Cheers, > Nathan > -- Adam Feuer
Re: [OT] WebAssembly Micro Runtime
I'd be willing to help get this running on NuttX. This would be useful to a lot of people. -adam On Mon, Jul 6, 2020 at 12:36 PM Alan Carvalho de Assis wrote: > Hi Nathan, > > On 7/6/20, Nathan Hartman wrote: > sic > >> More info: > >> > >> https://bytecodealliance.org/articles/announcing-the-bytecode-alliance > > > > I don't know anything about it, but it would be nice if NuttX were > > listed among the supported platforms. We need to get our name out > > there as much as possible, to increase adoption and the size of the > > developer base. > > > > Exactly! A project with a broad audience will get more > contributors/developers. > > BR, > > Alan > -- Adam Feuer
Re: SVD -> header generator
Greg, I agree with your point here– that these files are another kind of data sheet, and that it is ok to generate header files and other code from them. -adam On Fri, Jul 3, 2020 at 4:52 PM Gregory Nutt wrote: > > > I just looked at that header and looks like a "no warranty" disclaimer. > Does not impose any restriction on generation code based on that file. > > I am not an attorney and not qualified to give a legal opinion. But that > has never stopped me before. > > A copyright covers the presentation of a materials, not the content of > materials. If using the same definitions as are provided by one header > file in another header file were a breach of some copyright, the whole > world would be in trouble. 'Wine' duplicates windows definitions for > compatibility. Linux duplicates some BSD definitions for compatibility > for BSD and POSIX definitions compatibility. NuttX duplicates some > Linux definitions for compatibility. > > There was a a lawsuit about this several decades ago when when Unix > claimed that it owned all of the Unix interface definitions. That suit > failed and it was ruled that you cannot copyright an interface. So we > are free to define compatible interfaces without concern for copyright > issues. > > Another related case had to do with bitmap fonts of traditional fonts > like Times Roman. Scalable fonts can be protected because the scaling > is an algorithm; custom bit map fonts can be protected because they are > original artwork. But bitmaps of traditional fonts cannot be protected > because they are neither. > > In my "legal opinion", I would think that that all of these apply. > Register definitions define an interface and that interface is openly > documented in various sources. We know that creating header files from > those openly documented specs is acceptable (we do that all of the > time). So I cannot see that there could be a legal issue with > automatically generating Apache 2.0 header files from those XML files. > > You might ask the position of the person that claims ownership of those > XML files, but I cannot see how the license on the XML files that > contain a public interface definition could limit our freedom to > generate our own header files for that public interface provided that we > do not re-distribute the copyrighted XML files. Justin certainly will > have a different opinion. > > Greg > > > > -- Adam Feuer
Re: SVD -> header generator
Brennan, Ah, I see. The data files all have their own individual licenses, yes, some are not open source. Ugh. Yeah, I wouldn't use a tool to generate it unless the data file was using a compatible license... -adam On Fri, Jul 3, 2020 at 3:30 PM Brennan Ashton wrote: > They are not all Apache 2.0. The NXP ones are a mixed bag, some call > out BSD, some just liability disclaimer, looks like the example I gave > was not the best one. > > For STM this file is restricted in a way that is not compatible. > Personally I think that is a mistake on the part of STM, but here we > are... > > https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html > > TI is another example with further restrictions. > > https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd > > --Brennan > > On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer wrote: > > > > Brennan, > > > > All the files in this repo are Apache 2.0 licensed: > > > > https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE > > > > Doesn't that cover the license issue? The header is only a liability > > disclaimer. > > > > -adam > > > > > > > > On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton > > > wrote: > > > > > Just a warning on generating code from these files. Many of the have > > > explicit restrictions on using them which may not be compatible with > BSD or > > > Apache. For example NXP > > > > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > > > > > I'm not sure on the legal side about this but it is why I have avoiding > > > using them to generate headers. Maybe Apache Legal could give us > guidance. > > > > > > --Brennan > > > > > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > > > > > Hi, > > > > I thought about doing this for a long time and I just did it, wasn't > > > > really hard. > > > > If you're not aware, CMSIS-SVD file format is an XML based > definitions of > > > > peripherals and registers available in a given MCU. This is typically > > > used > > > > for debugging but it is quite useful for generating header > definitions. I > > > > wrote a quick python script that is able to generate register > definitions > > > > and base addresses of peripherals. It is based on > > > > https://github.com/posborne/cmsis-svd which includes both the SVD > python > > > > parser and a really complete database of SVD files. > > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen > (be > > > > sure to check the README on how to use) > > > > > > > > Example output (the console output properly tabulates data, format > may > > > > look broken in the email): > > > > > > > > Generate memory map: > > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > > > ... etc > > > > > > > > Register definitions: > > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > > > > > /* Register offsets > > > > */ > > > > > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > > > mode.*/ > > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > > > mode.*/ > > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > > > ... etc > > > > > > > > /* Register definitions > > > > */ > > > > > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_START_OFFSET) > > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_STOP_OFFSET) > > > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > > > ... etc > > > > > > > > Best, > > > > Matias > > > > > > > > > -- > > Adam Feuer > -- Adam Feuer
Re: SVD -> header generator
Brennan, All the files in this repo are Apache 2.0 licensed: https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE Doesn't that cover the license issue? The header is only a liability disclaimer. -adam On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton wrote: > Just a warning on generating code from these files. Many of the have > explicit restrictions on using them which may not be compatible with BSD or > Apache. For example NXP > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > I'm not sure on the legal side about this but it is why I have avoiding > using them to generate headers. Maybe Apache Legal could give us guidance. > > --Brennan > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > Hi, > > I thought about doing this for a long time and I just did it, wasn't > > really hard. > > If you're not aware, CMSIS-SVD file format is an XML based definitions of > > peripherals and registers available in a given MCU. This is typically > used > > for debugging but it is quite useful for generating header definitions. I > > wrote a quick python script that is able to generate register definitions > > and base addresses of peripherals. It is based on > > https://github.com/posborne/cmsis-svd which includes both the SVD python > > parser and a really complete database of SVD files. > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > > sure to check the README on how to use) > > > > Example output (the console output properly tabulates data, format may > > look broken in the email): > > > > Generate memory map: > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > ... etc > > > > Register definitions: > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > /* Register offsets > > */ > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > mode.*/ > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > mode.*/ > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > ... etc > > > > /* Register definitions > > */ > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_START_OFFSET) > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_STOP_OFFSET) > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > ... etc > > > > Best, > > Matias > -- Adam Feuer
Re: SVD -> header generator
Matias, This looks like it would be a lot of help bringing NuttX up on a new microprocessor. Thanks! -adam On Fri, Jul 3, 2020 at 1:46 PM Matias N. wrote: > Hi, > I thought about doing this for a long time and I just did it, wasn't > really hard. > If you're not aware, CMSIS-SVD file format is an XML based definitions of > peripherals and registers available in a given MCU. This is typically used > for debugging but it is quite useful for generating header definitions. I > wrote a quick python script that is able to generate register definitions > and base addresses of peripherals. It is based on > https://github.com/posborne/cmsis-svd which includes both the SVD python > parser and a really complete database of SVD files. > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > sure to check the README on how to use) > > Example output (the console output properly tabulates data, format may > look broken in the email): > > Generate memory map: > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > ... etc > > Register definitions: > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > /* Register offsets > */ > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > mode.*/ > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > mode.*/ > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > ... etc > > /* Register definitions > */ > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_TXEN_OFFSET) > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RXEN_OFFSET) > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_START_OFFSET) > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_STOP_OFFSET) > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_DISABLE_OFFSET) > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > ... etc > > Best, > Matias -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Hi, I pushed a cleaned-up working SAMA5 SDMMC driver to this branch: https://github.com/starcat-io/incubator-nuttx/tree/feature/sama5d27-sdmmc-support It's ported from imxrt_usdhc.c, there were some differences but the structure is largely the same. This driver works with DMA, and can do widebus (4-bit) transfers in UHS_DDR50 mode (double data-rate 50MHz, so one transfer each on the rising and falling of the SD clock); up from the ixmrt's default of UHS_SDR25 (single data rate 25MHz). I haven't run nxstyle on it, I will try to do that this weekend, update the formatting, and get a PR submitted for review. cheers adam On Wed, Jun 17, 2020 at 9:19 PM Adam Feuer wrote: > Thanks Nathan. It's been interesting learning how to port and debug NuttX > drivers. Hopefully I will be able to write something about it when I get > the code accepted. > > It was helpful that I could port a driver used by the same chip peripheral > IP block on other NuttX supported chips. I didn't have to write it from > scratch. Takeyoshi suggested doing the port and he was right about it. > > -adam > > > On Wed, Jun 17, 2020 at 5:46 PM Nathan Hartman > wrote: > >> On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: >> >> > SDMMC write is working now too. So the driver can do the following: >> > >> >- Non-DMA read and write >> >- DMA read and write in SDMA mode >> >- 1 bit bus >> >- 4 bit bus (widebus) >> >- up to 25Mhz >> > >> > I'm going to work on cleanup, documentation, and PR next. I'll post a >> > branch here when I get it somewhat cleaned up. >> >> >> That's exciting! Thanks for your hard work and for posting updates in the >> meantime. >> >> Cheers, >> Nathan >> > > > -- > Adam Feuer > -- Adam Feuer
script to validate NuttX release candidates
Hi, In case anyone's interested, I created a script to validate NuttX release candidates, it automates some of the steps described in Validating a staged release <https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release>. It downloads the files, checks the SHA512 and GPG signatures, and checks required files. You still need to manually configure, build, and install the release. https://github.com/apache/incubator-nuttx/pull/1349 -adam -- Adam Feuer
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release
+1 Ran through the release checklist, SHAs ok, GPG sigs ok, required files there. I built nuttx for SAMA5D2-XULT (SAMA5D27) and loaded it, it boots and works ok. -adam On Wed, Jul 1, 2020 at 4:41 AM Jerpelea, Alin wrote: > Hi, > > +1 from me > > * > hashes match > * > LICENSE, DISCLAIMER and NOTICE exist > * > build spresense board and seems ok > > > > Från: Abdelatif Guettouche > Skickat: den 1 juli 2020 14:35 > Till: dev@nuttx.apache.org > Ämne: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release > > Hi, > +1 for me, I checked: > - Incubating in name > - Signatures and hashes for both TARs are OK > - LICENSE, DISCLAIMER and NOTICE exist > - Can build from source. > > Thank you for your work, Brennan! > > On Tue, Jun 30, 2020 at 6:58 AM Brennan Ashton > wrote: > > > > Hello all, > > Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time > > to vote on accepting it for release. If approved we will seek final > > release approval from the IPMC. Voting will be open for 72hr. This RC > > replaces RC0 which was never released due to several bugs found durring > > the voting period. > > > > Because this project targets embedded systems there is more complexity > > involved in the build process. Two starting points: > > * README.txt -- This is found in the Apache NuttX source and is > > extensive. > > * Unofficial NuttX Companion -- Located at [3], this is a currently > > unofficial > >opinionated guide maintained by some of the project committers. > > > > A minimum of 3 binding +1 votes and more binding +1 than binding -1 > > are required to pass. > > > > The Apache requirements for approving a release can be found here [4] > > "Before voting +1 [P]PMC members are required to download the signed > > source code package, compile it as provided, and test the resulting > > executable on their own platform, along with also verifying that the > > package meets the requirements of the ASF policy on releases." > > > > A document to walk through some of this process has been published on > > our project wiki and can be found here [5]. > > > > [ ] +1 accept (indicate what you validated - e.g. performed the non-RM > > items in [5]) > > [ ] -1 reject (explanation required) > > > > Thank you all, > > Brennan Ashton > > > > SCM Information: > > Release tag: releases/9.1.0-RC1 > > Hash for the release incubating-nuttx tag: > > 201f920c3b5de64e0eb8c8a76a50ae2fcc4f6a2e > > Hash for the release incubating-nuttx-apps tag: > > d483748923d4ad77e0d1f98158548b75f65b9a77 > > > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__dist.apache.org_repos_dist_dev_incubator_nuttx_9.1.0-2DRC1_=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=Y0tSVm2CF-YebYBa823UNd7hJ2Vi2A5SUAyhWnv7Gdw= > > [2] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_apache_incubator-2Dnuttx_nuttx-2D9.1.0-2DRC1_ReleaseNotes=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=kEH1URCIGyAHMk5iogYe3ClMSPUc9tZeH3Itlo6qoec= > > [3] > https://urldefense.proofpoint.com/v2/url?u=https-3A__nuttx-2Dcompanion.readthedocs.io_en_latest_=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=iQ6KKFX9DmtiP-AEudIAsYhxIJScMFaP4WIMfF1PL08= > > [4] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.apache.org_dev_release.html-23approving-2Da-2Drelease=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=g0xT5Mh8tFdW2MrZsQqjGDm15xIH7hxFJuVD1BZXQjg= > > [5] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NUTTX_Validating-2Ba-2Bstaged-2BRelease=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=VeCYBTgAJpnIOqLZJYfNtIinMUYYiApT3UWeP91kuxs= > > > -- Adam Feuer
Re: [DISCUSS] NuttX 9.1 RC1
More time sounds good, I'll retest on Saturday. -adam On Fri, Jun 26, 2020 at 3:47 PM Nathan Hartman wrote: > On Fri, Jun 26, 2020 at 1:48 PM Brennan Ashton > wrote: > > > Hey everyone, > > There were several bugs found on the RC0 so we will not be moving forward > > with that release candidate and will be creating RC1. I had suggested a > > few days ago creating the release today, but as we merged some changes > > yesterday that seems to be rushed. > > > > I'm proposing that we move forward cutting the RC1 on Sunday 28th. I > would > > encourage everyone to test with the fixes that have been backported > already > > to the releases/9.1 branch. I know there is an outstanding bug report > that > > was sent to the list but this is not even in master yet. > > > > > > > https://lists.apache.org/x/thread.html/rbb1f85b5f2dba9ee221548fcc5f99d49ef55522c487b99c1549c3a52@%3Cdev.nuttx.apache.org%3E > > > > > Yes, more time for testing sounds good to me. > > Thanks, > Nathan > -- Adam Feuer
Re: NuttX supported boards web page?
Greg, Thank you! That is exactly what I was looking for! -adam On Fri, Jun 26, 2020 at 3:02 PM Gregory Nutt wrote: > On 6/26/2020 3:43 PM, Adam Feuer wrote: > > Hi, > > > > There used to be a web page that listed NuttX supported boards– but I > can't > > find it on the new nuttx.apache.org website. Does anyone know where that > > page is? > > > > cheers > > adam > > Got https://cwiki.apache.org/confluence/display/NUTTX/Nuttx > > Follow the link "Complete List". > > -- Adam Feuer
NuttX supported boards web page?
Hi, There used to be a web page that listed NuttX supported boards– but I can't find it on the new nuttx.apache.org website. Does anyone know where that page is? cheers adam -- Adam Feuer
Re: MCU only booting from reset via SWD when compiled without optimizations?
Do you have GPIO available? If so you can do the equivalent of printf debugging by using GPIO... for instance outputting a binary number using 5 GPIOs would give you 32 possible points to mark your code with. Or just use unary and change a different GPIO for every point you want to mark. -adam On Sun, Jun 21, 2020 at 2:23 PM Matias N. wrote: > I have the serial console enabled, but this is very early in the boot. > > On Sun, Jun 21, 2020, at 18:02, Adam Feuer wrote: > > (printf debugging only works if you can get far enough through the boot > > sequence to initialize a serial console. But that can happen pretty > early.) > > > > > > On Sun, Jun 21, 2020 at 2:01 PM Adam Feuer wrote: > > > > > Do you have a serial console available? If so, you could use printf > > > debugging <https://www.cs.colostate.edu/~fsieker/misc/debug/DEBUG.html > > > > > to determine where in the boot sequence it fails. I've done this with > NuttX > > > successfully on the SAMA5. > > > > > > -adam > > > > > > On Sun, Jun 21, 2020 at 12:13 PM Matias N. wrote: > > > > > >> I've been having a very weird problem and I thought to ask if anyone > else > > >> suffered this by any chance. I have a board with reset line with > pull-up > > >> and a switch to tie the line to ground (with a capacitor in parallel) > as > > >> per typical STM32 circuit. This line also is exposed to the SWD > connector. > > >> When I build without size optimizations, the board works as expected: > it > > >> comes up normally and can be reset with the button. SWD also is able > to > > >> reset it for debugging. When I disable optimizations, the board does > not > > >> boot again even when pressing the reset button. It only boots > normally if I > > >> start debugging with OCD, which issues the reset from there. Since > with the > > >> debugger it boots normally this is impossible to debug. > > >> Any similar experience? > > >> > > >> Best, > > >> Matias > > > > > > > > > > > > -- > > > Adam Feuer > > > > > > > > > -- > > Adam Feuer > > > -- Adam Feuer
Re: MCU only booting from reset via SWD when compiled without optimizations?
(printf debugging only works if you can get far enough through the boot sequence to initialize a serial console. But that can happen pretty early.) On Sun, Jun 21, 2020 at 2:01 PM Adam Feuer wrote: > Do you have a serial console available? If so, you could use printf > debugging <https://www.cs.colostate.edu/~fsieker/misc/debug/DEBUG.html> > to determine where in the boot sequence it fails. I've done this with NuttX > successfully on the SAMA5. > > -adam > > On Sun, Jun 21, 2020 at 12:13 PM Matias N. wrote: > >> I've been having a very weird problem and I thought to ask if anyone else >> suffered this by any chance. I have a board with reset line with pull-up >> and a switch to tie the line to ground (with a capacitor in parallel) as >> per typical STM32 circuit. This line also is exposed to the SWD connector. >> When I build without size optimizations, the board works as expected: it >> comes up normally and can be reset with the button. SWD also is able to >> reset it for debugging. When I disable optimizations, the board does not >> boot again even when pressing the reset button. It only boots normally if I >> start debugging with OCD, which issues the reset from there. Since with the >> debugger it boots normally this is impossible to debug. >> Any similar experience? >> >> Best, >> Matias > > > > -- > Adam Feuer > -- Adam Feuer
Re: MCU only booting from reset via SWD when compiled without optimizations?
Do you have a serial console available? If so, you could use printf debugging <https://www.cs.colostate.edu/~fsieker/misc/debug/DEBUG.html> to determine where in the boot sequence it fails. I've done this with NuttX successfully on the SAMA5. -adam On Sun, Jun 21, 2020 at 12:13 PM Matias N. wrote: > I've been having a very weird problem and I thought to ask if anyone else > suffered this by any chance. I have a board with reset line with pull-up > and a switch to tie the line to ground (with a capacitor in parallel) as > per typical STM32 circuit. This line also is exposed to the SWD connector. > When I build without size optimizations, the board works as expected: it > comes up normally and can be reset with the button. SWD also is able to > reset it for debugging. When I disable optimizations, the board does not > boot again even when pressing the reset button. It only boots normally if I > start debugging with OCD, which issues the reset from there. Since with the > debugger it boots normally this is impossible to debug. > Any similar experience? > > Best, > Matias -- Adam Feuer
Re: QuickLogic Open Source MCU + FPGA
- 80 MHz ARM Cortex M4-F - UART only, no USB - FPGA has 2400 logic cells - Open Source software for development It's pretty low-power, but that last part is amazing– it would be great to have an RTOS+FPGA that was programmable by all open source software. I will have to think of something I can do with it. My next project will probably have an largish FPGA on it... this one is too small for that. -adam On Thu, Jun 18, 2020 at 2:11 AM Erdem MEYDANLI wrote: > It looks like a promising platform, but the shipping cost to the EU is > unbelievable. :). I want to support porting efforts, but let's see first if > I can receive it via a freight-forwarder service. > > Erdem > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Thanks Nathan. It's been interesting learning how to port and debug NuttX drivers. Hopefully I will be able to write something about it when I get the code accepted. It was helpful that I could port a driver used by the same chip peripheral IP block on other NuttX supported chips. I didn't have to write it from scratch. Takeyoshi suggested doing the port and he was right about it. -adam On Wed, Jun 17, 2020 at 5:46 PM Nathan Hartman wrote: > On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: > > > SDMMC write is working now too. So the driver can do the following: > > > >- Non-DMA read and write > >- DMA read and write in SDMA mode > >- 1 bit bus > >- 4 bit bus (widebus) > >- up to 25Mhz > > > > I'm going to work on cleanup, documentation, and PR next. I'll post a > > branch here when I get it somewhat cleaned up. > > > That's exciting! Thanks for your hard work and for posting updates in the > meantime. > > Cheers, > Nathan > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
SDMMC write is working now too. So the driver can do the following: - Non-DMA read and write - DMA read and write in SDMA mode - 1 bit bus - 4 bit bus (widebus) - up to 25Mhz I'm going to work on cleanup, documentation, and PR next. I'll post a branch here when I get it somewhat cleaned up. -adam On Mon, Jun 15, 2020 at 9:14 PM Adam Feuer wrote: > SDMMC DMA read is working now too. I'll work on DMA write next. > > -adam > > On Fri, Jun 12, 2020 at 2:45 PM Adam Feuer wrote: > >> I got the SDMMC write to work as well. This is in non-DMA mode. I'm going >> to work on the DMA mode next. >> >> -adam >> -- >> Adam Feuer >> > > > -- > Adam Feuer > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
SDMMC DMA read is working now too. I'll work on DMA write next. -adam On Fri, Jun 12, 2020 at 2:45 PM Adam Feuer wrote: > I got the SDMMC write to work as well. This is in non-DMA mode. I'm going > to work on the DMA mode next. > > -adam > -- > Adam Feuer > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
I got the SDMMC write to work as well. This is in non-DMA mode. I'm going to work on the DMA mode next. -adam -- Adam Feuer
Re: [nuttx] Apache and BSD license compatibility
I'm sorry about using the wrong address, that was my mistake. Justin, thanks for the quick response about the BSD-licensed code. That sounds workable. When I get close to implementation I'll send an email here (to the right list!) to give an update on how it would work. cheers adam On Thu, Jun 11, 2020 at 7:22 PM Gregory Nutt wrote: > I just noticed that this conversation was occurring on > nu...@googlegroups.com. Not sure how we got there. Moving back to > dev@nuttx.apache.org where I thought we were all along. > >> There is one big difference. I have spoken (via email) with all of the > authors and copyright holders and each has given their support and > encouragement to bring the code into NuttX. > > Is being developing a branch of Nutt is one obvious one. Sure if you > want go and merge it but at some point before graduation it will need to be > sorted. > > Yes, this is a custom port that was developed specifically for use in > NuttX. The primary authors of the port are Peter Van Der Perk (NXP) and > myself and is based on a common SocketCAN core stack by Oliver Hartkopp > (VW): "... that's a cool idea and I definitely support your idea to > support SocketCAN for NuttX!" I have worked through this with all > players include Peter's supervisor. > > Corporate legal is the bottleneck. I doubt that corporate legal sees > any benefit to the corporation by conforming to ASF expectations. I > think they believe that the BSD license is sufficient. > > I will start looking into what is needed to re-verify the branch and > merge it into master next week after we branch off for the 9.1 release. > > It will be so good to have this resolved. Thanks for your help. > > Greg > > -- > You received this message because you are subscribed to the Google Groups > "NuttX" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to nuttx+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/nuttx/e997fdca-9bec-f93b-70a4-3ea9804e4b45%40gmail.com > . > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Thanks, I'll check it out! -adam On Thu, Jun 11, 2020 at 3:40 PM Gregory Nutt wrote: > > > I'm talking about using drivers from the OpenBSD or FreeBSD projects, > > not the driver on Github. :) > > There is a partial port of the OpenBSD IEEE802.11 SoftMAC stack that I > did a long time ago here too: > https://github.com/gregory-nutt/nuttx_ieee80211 > > > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
> The SocketCAN project on a branch is all BSD code and we have been given > the verbal blessing to take the code into the repository. But not clear > support or direction from anyone... only obstacles. > > If you can confirm that, then SocketCAN can come onto master immediately. > That would be awesome. I will get clarification on that if I get some replies to my other email to the mentors about the BSD driver layer. -adam -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Thanks, I see the SPDX code now. It's GPL. So I'm not psyched about using that. :) I'd rather have something I can borrow from directly. -adam On Thu, Jun 11, 2020 at 3:18 PM Gregory Nutt wrote: > > 54 Mbps would work for me. But I didn't see a LICENSE file or any text > about it in the README file either in that repo. So I'm assuming this is > not a driver that can be used. Or else it needs some work with Microchip to > get them to clarify the license. > > Re: using a BSD driver, I didn't get what you mean about bringing in 3rd > party code– it's BSD licensed, my understanding is that it can be brought > in. Is that wrong? > > I see this in all of the files I looked at: > > // SPDX-License-Identifier: GPL-2.0 > > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
I'm talking about using drivers from the OpenBSD or FreeBSD projects, not the driver on Github. :) -adam On Thu, Jun 11, 2020 at 3:19 PM Gregory Nutt wrote: > > > This page on the Apache website > <https://www.apache.org/legal/resolved.html#category-a> is pretty clear > that BSD licensed code may be included in an Apache project. > > But, unfortunately, that driver on github is GPL. > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Cool, I'll take it up the Apache folks before I start that project. This page on the Apache website <https://www.apache.org/legal/resolved.html#category-a> is pretty clear that BSD licensed code may be included in an Apache project. -adam On Thu, Jun 11, 2020 at 3:13 PM Gregory Nutt wrote: > > > Re: using a BSD driver, I didn't get what you mean about bringing in > > 3rd party code– it's BSD licensed, my understanding is that it can be > > brought in. Is that wrong? > > You will need to discuss with Justin. We have talked about this > numerous times and still don't have any idea what is required. You will > never get an ICLA or an SGA from business that have now no financial > reason to do such a legal thing. No good attorney would every recommend > that. There is no defined criterion for documenting what "getting > permission from the copyright holder means." > > So as far as I know projects like SocketCAN which a good contributor has > worked so hard on is stuck in limbo. And other people are circumventing > the requirements by downloading code at build time. > > You guess is as good as mine how and open source project is supposed to > use fully compatible code. I wish I knew and I wish I could help people > who want to make contributions. But I don't. > > > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Greg, 54 Mbps would work for me. But I didn't see a LICENSE file or any text about it in the README file either in that repo. So I'm assuming this is not a driver that can be used. Or else it needs some work with Microchip to get them to clarify the license. Re: using a BSD driver, I didn't get what you mean about bringing in 3rd party code– it's BSD licensed, my understanding is that it can be brought in. Is that wrong? I'll check out the driver you're enclosing... yes, I would need some other stuff besides the driver, but if I can get the userland stuff from BSD also... maybe that would work... -adam On Thu, Jun 11, 2020 at 2:54 PM Gregory Nutt wrote: > > That looks like a cool module. The issue for me is that I need high speed > Wifi connectivity (20 Mbps+, ideally 50Mbps+) for my upcoming projects. > SPI/UART modules like this one usually have much lower throughput. > > The WiFi interface is SDIO. So we would need your SD/MMC driver (plus a > couple of SDIO extensions). > > SPI and I2C are not used on the WiFi chip. The WiFi component is SDIO and > Bluetooth component is UART So I don't see any Wifi performance limitation > do to interface constraints. > > Radio performance is addressed in Table 4.4 here for various conditions > http://ww1.microchip.com/downloads/en/DeviceDoc/70005327A.pdf Under > certain conditions it can do 54Mbps > > This module does have a 50Mhz SDIO interface, so if it can use 4 bit mode, > it could work. However, the ATWIL3000 Linux driver on Github > <https://github.com/linux4wilc/driver> does not appear to have an open > license– all the code is marked "All rights reserved". Is this the driver > you were referring to? > > All of the NuttX files with BSD headers say "All rights reserved" too. > That is usually part of all copyright statements. You should look at the > LICENSE file if there is one. Bringing 3rd party code into NuttX is > basically impossible with the current state of things unless you can NXP to > provide you some written confirmation that they approve of you taking a > snapshot of the code. They will not sign an SGA or ICLA but if they are > like NXP, they will freely give consent otherwise > > And we can always download it on the fly at build time as we have done for > other 3rd party code. > > I am looking at porting a USB Wifi driver from FreeBSD... The thing about > porting a USB driver from FreeBSD that attracts me is that I could at least > have access to a whole family of fast Wifi hardware that way. And in the > best case scenario, if I can create a compatibility layer, then we could > use a variety of FreeBSD wifi drivers. > > There is a RTL8187 Wifi USB driver for NuttX that you can look at here > attached. This was ported from Linux years ago and is GPL so you can't > bring it into NuttX, but you can look at it. It is kind of useless with no > ieee802.11 SoftMAC stack anyway. > > > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
Hey Greg, That looks like a cool module. The issue for me is that I need high speed Wifi connectivity (20 Mbps+, ideally 50Mbps+) for my upcoming projects. SPI/UART modules like this one usually have much lower throughput. This module does have a 50Mhz SDIO interface, so if it can use 4 bit mode, it could work. However, the ATWIL3000 Linux driver on Github <https://github.com/linux4wilc/driver> does not appear to have an open license– all the code is marked "All rights reserved". Is this the driver you were referring to? I am looking at porting a USB Wifi driver from FreeBSD... The thing about porting a USB driver from FreeBSD that attracts me is that I could at least have access to a whole family of fast Wifi hardware that way. And in the best case scenario, if I can create a compatibility layer, then we could use a variety of FreeBSD wifi drivers. cheers adam On Thu, Jun 11, 2020 at 1:43 PM Gregory Nutt wrote: > Hey, SAMA5D2 guys, > > I have been looking at the ATSAMA5D27-WLSOM1 Evaluation Kit. I am > impressed. It is based on the SAMAD27C and the ATWIL3000 wireless > module. I am tempted to buy one. > > The ATWIL3000 has an SDIO interface to the Wifi (like the Broadcom > chips) and UART interface to the Bluetooth. It runs $150 USD at > Mouser. An open Microchip driver is for the ATWIL3000 is available in > github. Anyone interesting in a fun Wifi project? > > Greg > > Refs: > https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/DM320117 > https://www.microchip.com/wwwproducts/en/ATWILC3000 > > https://www.mouser.com/development-tools-center/embedded-processor-development-kits/development-boards-kits-arm/microchip-atsama5d27wlsom1-eval-kit/n-cxd2tZ34u2t9 > > On 6/11/2020 2:33 PM, Adam Feuer wrote: > > Takeyoshi, > > > > Hey, in case you are interested, I got the SDMMC driver port working for > > reading data today. It's quite a mess, and on a private branch. I will > try > > to get it working for writing, clean it up, and push it to this branch > in a > > few days. > > > > Thanks so much for your help!! > > > > cheers > > adam > > > > On Mon, May 4, 2020 at 3:29 PM Adam Feuer wrote: > > > >> Takeyoshi, > >> > >> Hi, I've been working on the SDMMC driver off and on. I still haven't > got > >> it working, but I am making some progress. Here's a log of register > reads > >> and writes captured from U-Boot on the SAMA5D27: > >> index usecs op (bytes) register value value > >> binary register long description > >>0 0 read (4): [0x0040: HTCAPBLT0] 0x27ec0c8c0010 > 0111 > >> 1110 1100 1100 1000 1100 Host Controller Capabilities 0 Register > >>1 4983 read (2): [0x00fe:HOST_VERSION] 0x1502 > > >> 0001 0101 0010 Host Controller Version Register > >>2 10101 read (4): [0x0044: HTCAPBLT1] 0x00200f77 > > >> 0010 0111 0111 Host Controller Capabilities 1 Register > >>3 15225 write (1): [0x002f: SRR]w 0x0001 > > >> 0001 Software Reset Register > >>4 20428 write (1): [0x0029: PCR]w 0x000f > > >> Power Control Register > >>5 25629 write (4): [0x0034: IRQSTATEN]w 0x027f003b > 0010 > >> 0111 0011 1011 Interrupt Status Enable Register > >>6 30833 write (4): [0x0038:IRQSIGEN]w 0x > > >> Interrupt Signal Enable Register > >>7 44875 read (4): [0x0040: HTCAPBLT0] 0x27e80c8c0010 > 0111 > >> 1110 1000 1100 1000 1100 Host Controller Capabilities 0 Register > >>8 49848 read (2): [0x00fe:HOST_VERSION] 0x1502 > > >> 0001 0101 0010 Host Controller Version Register > >>9 54966 read (4): [0x0044: HTCAPBLT1] 0x00200070 > > >> 0010 0111 Host Controller Capabilities 1 Register > >> 10 60088 write (1): [0x002f: SRR]w 0x0001 > > >> 0001 Software Reset Register > >> 11 66296 write (1): [0x0029: PCR]w 0x000f > > >> Power Control Register > >> 12 71353 write (4): [0x0034: IRQSTATEN]w 0x027f003b > 0010 > >> 0111 0011 1011 Interrupt Status Enable Register > >> 13
Re: SAMA5D27 SDMMC support branch
Takeyoshi, Hey, in case you are interested, I got the SDMMC driver port working for reading data today. It's quite a mess, and on a private branch. I will try to get it working for writing, clean it up, and push it to this branch in a few days. Thanks so much for your help!! cheers adam On Mon, May 4, 2020 at 3:29 PM Adam Feuer wrote: > Takeyoshi, > > Hi, I've been working on the SDMMC driver off and on. I still haven't got > it working, but I am making some progress. Here's a log of register reads > and writes captured from U-Boot on the SAMA5D27: > index usecs op (bytes) register value value > binary register long description > 0 0 read (4): [0x0040: HTCAPBLT0] 0x27ec0c8c0010 0111 > 1110 1100 1100 1000 1100 Host Controller Capabilities 0 Register > 1 4983 read (2): [0x00fe:HOST_VERSION] 0x1502 > 0001 0101 0010 Host Controller Version Register > 2 10101 read (4): [0x0044: HTCAPBLT1] 0x00200f77 > 0010 0111 0111 Host Controller Capabilities 1 Register > 3 15225 write (1): [0x002f: SRR]w 0x0001 > 0001 Software Reset Register > 4 20428 write (1): [0x0029: PCR]w 0x000f > Power Control Register > 5 25629 write (4): [0x0034: IRQSTATEN]w 0x027f003b 0010 > 0111 0011 1011 Interrupt Status Enable Register > 6 30833 write (4): [0x0038:IRQSIGEN]w 0x > Interrupt Signal Enable Register > 7 44875 read (4): [0x0040: HTCAPBLT0] 0x27e80c8c0010 0111 > 1110 1000 1100 1000 1100 Host Controller Capabilities 0 Register > 8 49848 read (2): [0x00fe:HOST_VERSION] 0x1502 > 0001 0101 0010 Host Controller Version Register > 9 54966 read (4): [0x0044: HTCAPBLT1] 0x00200070 > 0010 0111 Host Controller Capabilities 1 Register > 10 60088 write (1): [0x002f: SRR]w 0x0001 > 0001 Software Reset Register > 11 66296 write (1): [0x0029: PCR]w 0x000f > Power Control Register > 12 71353 write (4): [0x0034: IRQSTATEN]w 0x027f003b 0010 > 0111 0011 1011 Interrupt Status Enable Register > 13 76557 write (4): [0x0038:IRQSIGEN]w 0x > Interrupt Signal Enable Register > 14 88990 read (4): [0x0024: PRSSTAT] 0x01ff 0001 > Present State Register > 15 94080 write (2): [0x002c: SYSCTL]w 0x > System Control Register, or Clock Control > Register/Timout Control Register > 16 99285 read (1): [0x0028: PROCTL] 0x > Protocol Control Register > 17 106408 read (4): [0x0024: PRSSTAT] 0x01ff 0001 > Present State Register > 18 111377 write (2): [0x002c: SYSCTL]w 0x > System Control Register, or Clock Control > Register/Timout Control Register > 19 116582 read (1): [0x0028: PROCTL] 0x > Protocol Control Register > 20 121704 read (4): [0x0024: PRSSTAT] 0x01ff 0001 > Present State Register > 21 126818 write (2): [0x002c: SYSCTL]w 0x > System Control Register, or Clock Control > Register/Timout Control Register > 22 132150 write (2): [0x002c: SYSCTL]w 0x57a1 > 0101 0111 1010 0001 System Control Register, or Clock Control > Register/Timout Control Register > 23 138235 write (2): [0x002c: SYSCTL]w 0x57a7 > 0101 0111 1010 0111 System Control Register, or Clock Control > Register/Timout Control Register > 24 143292 read (1): [0x0028: PROCTL] 0x > Protocol Control Register > 25 148410 write (1): [0x0028: PROCTL]w 0x > Protocol Control Register > 26 154620 read (4): [0x0024: PRSSTAT] 0x01ff 0001 > Present State Register > 27 159583 write (4): [0x0030: IRQSTAT]w 0x > Interrupt Status Register > 28 164
Re: [DISCUSS] requirements for commit messages and PRs
Or we can say that between the reviewer and the submitter the fields need to be filled out? That way it can be a collaboration, and over time submitters will gain skill in filling the fields out themselves. +1 for a simple template. -adam On Thu, Jun 4, 2020 at 10:19 AM Gregory Nutt wrote: > >> Yes. Simplicity is single most important thing. The entire template > >> should fit entirely within the PR comment window. It should not be a > >> punishment to contributors to the project. We will get a better > >> response if it is simple and usable. No inline instructions, please. > >> > >> There should not be no more then 3 or possible 4 sections. Users should > >> be able to fill out the template with what they already know. > >> > >> I would be better to have no template at all than that ugly, repulsive > >> one that has been proposed. I like you idea fine. I think Summay, > >> changes, Release Notes are all trying to get to the same thing. A > >> simple function description is what is needed... that answers all of > those. > >> > >> Impact is optional, but it is nice to know if anything else is affected > >> by the change. You gotta admit: > >> > >> ## Summary > >> ## Impact > >> ## Testing > >> > >> Is pretty damn good! Perhaps "Functional Description of Change" is > >> better. Perhaps "Affected Behaviors" is better than "Impact". Testing > >> is intentionally vagues. > > Yes, it is pretty good! > > > > I'd like to make it very clear that I do *NOT* advocate creating some > > big monster of a PR template!! > > > > If we take a step back for a moment, the issue that started this > > discussion is how to make it easier to write Release Notes. Currently > > we have many PRs that don't explain what they do, so Release Notes > > writers have to dive into the code to try to find out, so writing > > Release Notes is a nightmare. The release notes for 9.0 were not so > > good. I'm trying to improve the 9.1 release notes to make them helpful > > for our users. > > > > Maybe it's enough to keep the current Summary, Impact, Testing > > template, but come to an agreement that PR reviewers need to enforce > > that these sections are filled in. At minimum Summary needs to explain > > the change well enough that Release Notes can be written easily > > without looking at the code. > > Why don't we require that the reviewer fill in those sections. The main > reason that they are not filled in now is language barrier issues, not > willingness to contribute. Forcing someone who has marginal English > skills to write prose to your requirements is not a very kind thing to > do to our good, honest, well-meaning contributors. Let's help them. > Let's not make life difficult for them. > > Also, if the reviewer fills out those sections we can (1) assure a > constsistent quality of prose, and (2) it is proof that the reviewer > understands the issues will enough and did, in fact, do a real review. > > I have always tried to help contributors by meeting them half way. In > the past, only I ran nxstyle and only I fixed the style errors on > submitted code. That was a courtesy and an act that showed my thanks > for the contributions (I still force push nxstyle fixes to contributors > branches on occasion). Let's go that extra mile rather than be some > kind of an oppressive organization that berates and hassles contributors > who are just trying to do the right thing. > > We don't all have to be assholes. > > Greg > > > -- Adam Feuer
Re: Organising Release Notes for 9.1
Brennan, that board is awesome. +1. Nathan, +1 for the [DISCUSS] thread to talk about PR descriptions/templates. -adam On Thu, Jun 4, 2020 at 7:45 AM Nathan Hartman wrote: > On Thu, Jun 4, 2020 at 10:07 AM David Sidrane > wrote: > > I had this in the original PR I submitted for the templates. That got > > changed due to lack of working project experience and vision. The Apache > way > > is not being followed here: the PMC is not voting on things we should be. > > > > Can we work on process? > > We should. Would you like to start a [DISCUSS] thread to talk about > requirements for commit messages and PR descriptions? > > Nathan > -- Adam Feuer
Re: Release 9.1
Abdelatif, I haven't tried my instructions on macOS... when I was first starting out, I got stuck, and switched to Linux. But I will give macOS a try again in the next few days, and update the instructions if I succeed. Good idea. Re: the release notes, maybe we can start using a template for PR text? That would make going through them easier. For instance: ### Bug or Feature? ### One line summary ### Impact ### Limitations / TODO ### Detail ### Testing If we had this filled out for every PR, it would make creating the Release Notes a lot easier. -adam On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > For the licensing, we are taking baby steps by changing only the files > that we know won't cause any issue. > I think we will continue to do that until we get the necessary ICLAs > then we can do a massive substitution. > But as have been said in the very beginning, this should not stop us > from making releases. > The most important part is that we make progress with each release. > We are definitely making progress technically, what Brennan is > referring to is the fact that IPMC members found it hard to build from > source. I think most of their issues came from not > installing/configuring kconfig-frontends which is in a separate > repository. > BTW, Adam, have you tried the steps of your companion in a fresh > installation of, say, macOS? That might be all we need. > > Generating release notes is the part that has the most painful work, > it took 4 of us last time to get it done. I still wonder if there is > a way to automate that, maybe with good PR summaries and consistent > labeling. > Nathan created a confluence page to prepare release notes for the 9.1 > ahead of time. > > On Wed, Jun 3, 2020 at 4:58 PM Adam Feuer wrote: > > > > Brennan, > > > > What, in your opinion, needs to be done to improve the onboarding > process? > > > > And what would you like to see happen to improve the licensing issues? > > Another pass through the files of another section (like we did with > sched) > > and updating headers? Or...? > > > > -adam > > > > On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton > > > wrote: > > > > > On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt wrote: > > > > > > > Hi, all > > > > > > > > If we are serious about getting on a two month release cycle again, > now > > > > is the time to begin thinking about the 9.1 release. We created the > 9.0 > > > > release branch sometime before the 15th of April. We signed the > > > > release on April 23rd. So we have some time, but also we need to > start > > > > get some plans and organization in place. And we need to think about > > > > doing everything we can to make the master stable for that branch. > We > > > > should hold off large, sweeping changes until we get past that point. > > > > > > > > Duo... you mentioned that you were interested with assisted with the > > > > releases? Abdelatif was the point man last time. Perhaps you would > > > > want to discuss his experiences with him? > > > > > > > > Greg > > > > > > > > > > I would agree, but we have made zero progress on improving the > onboarding > > > process in terms of build and documentation, nor have we made progress > on > > > the licensing process. I'm not confident that the release would pass. > > > > > > I am also happy to share more on the steps of the actual release > process > > > outside of the release notes and branching (thank you Abdelatif that > was a > > > lot of work) if someone wants to take that on, or I can offer to do > that > > > portion again. I am happy to do it. It's a lot of little steps but > none of > > > them are that complicated. > > > > > > --Brennan > > > > > > > > > > > > > > > > -- > > Adam Feuer > -- Adam Feuer
Re: Release 9.1
Brennan, What, in your opinion, needs to be done to improve the onboarding process? And what would you like to see happen to improve the licensing issues? Another pass through the files of another section (like we did with sched) and updating headers? Or...? -adam On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton wrote: > On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt wrote: > > > Hi, all > > > > If we are serious about getting on a two month release cycle again, now > > is the time to begin thinking about the 9.1 release. We created the 9.0 > > release branch sometime before the 15th of April. We signed the > > release on April 23rd. So we have some time, but also we need to start > > get some plans and organization in place. And we need to think about > > doing everything we can to make the master stable for that branch. We > > should hold off large, sweeping changes until we get past that point. > > > > Duo... you mentioned that you were interested with assisted with the > > releases? Abdelatif was the point man last time. Perhaps you would > > want to discuss his experiences with him? > > > > Greg > > > > I would agree, but we have made zero progress on improving the onboarding > process in terms of build and documentation, nor have we made progress on > the licensing process. I'm not confident that the release would pass. > > I am also happy to share more on the steps of the actual release process > outside of the release notes and branching (thank you Abdelatif that was a > lot of work) if someone wants to take that on, or I can offer to do that > portion again. I am happy to do it. It's a lot of little steps but none of > them are that complicated. > > --Brennan > > > > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
NuttX, and compare; and maybe try to replay the U-Boot sequence under NuttX to see if I can get signals on the SDMMC bus. If you have more ideas, I would love to hear them. cheers adam On Mon, Apr 13, 2020 at 5:38 PM Adam Feuer wrote: > Takeyoshi, > > I finally got the new sama5 sam_sdmmc.c driver to compile. I haven't > tested it yet, so I don't know if it actually works... I pushed the code to > the branch, I am attaching the config I used. > > -adam > > On Thu, Apr 2, 2020 at 3:23 PM Adam Feuer wrote: > >> Takeyoshi, >> >> No worries– I had to work on other things too. >> >> -adam >> >> On Thu, Apr 2, 2020 at 3:22 PM Takeyoshi Kikuchi < >> kiku...@centurysys.co.jp> wrote: >> >>> Adam, >>> >>> Sorry, I am currently busy working and have no progress. >>> I want to check tomorrow. >>> >>> Takeyoshi Kikuchi >>> >>> On 2020/04/02 9:48, Adam Feuer wrote: >>> > Takeyoshi, >>> > >>> > I did some work on the SDMCC driver today, it compiles now and I >>> pushed the >>> > code to the branch. I will try it and let you know how it goes. I am >>> still >>> > not sure everything is right, for instance why do I have to specify >>> > SDMMC0_SIZE? The sama5d2x_memorymap.c file seems to need it. But it >>> should >>> > not be operating in memory-mapped mode, so I'm confused. >>> > >>> > Here are the config settings I used: >>> > >>> > # >>> > # This file is autogenerated: PLEASE DO NOT EDIT IT. >>> > # >>> > # You can use "make menuconfig" to make any modifications to the >>> installed >>> > .config file. >>> > # You can then do "make savedefconfig" to generate a new defconfig file >>> > that includes your >>> > # modifications. >>> > # >>> > # CONFIG_AUDIO_FORMAT_MP3 is not set >>> > # CONFIG_DISABLE_OS_API is not set >>> > # CONFIG_NSH_ARGCAT is not set >>> > # CONFIG_NSH_CMDOPT_HEXDUMP is not set >>> > # CONFIG_NSH_CMDPARMS is not set >>> > # CONFIG_SAMA5_UART0 is not set >>> > CONFIG_ARCH="arm" >>> > CONFIG_ARCH_BOARD="sama5d2-xult" >>> > CONFIG_ARCH_BOARD_SAMA5D2_XULT=y >>> > CONFIG_ARCH_BUTTONS=y >>> > CONFIG_ARCH_CHIP="sama5" >>> > CONFIG_ARCH_CHIP_ATSAMA5D27=y >>> > CONFIG_ARCH_CHIP_SAMA5=y >>> > CONFIG_ARCH_CHIP_SAMA5D2=y >>> > CONFIG_ARCH_INTERRUPTSTACK=2048 >>> > CONFIG_ARCH_IRQBUTTONS=y >>> > CONFIG_ARCH_LOWVECTORS=y >>> > CONFIG_ARCH_STACKDUMP=y >>> > CONFIG_AUDIO=y >>> > CONFIG_AUDIO_NUM_BUFFERS=8 >>> > CONFIG_BOARD_LOOPSPERMSEC=65775 >>> > CONFIG_BOOT_RUNFROMSDRAM=y >>> > CONFIG_BUILTIN=y >>> > CONFIG_DEBUG_FEATURES=y >>> > CONFIG_DEBUG_FULLOPT=y >>> > CONFIG_DEBUG_SYMBOLS=y >>> > CONFIG_DEV_LOOP=y >>> > CONFIG_DEV_ZERO=y >>> > CONFIG_EXAMPLES_HELLO=y >>> > CONFIG_EXAMPLES_PARTITION=y >>> > CONFIG_EXAMPLES_TCPBLASTER=y >>> > CONFIG_EXAMPLES_TCPECHO=y >>> > CONFIG_EXAMPLES_WGET=y >>> > CONFIG_EXAMPLES_WGET_URL="http://10.0.0.1/; >>> > CONFIG_FAT_LCNAMES=y >>> > CONFIG_FAT_LFN=y >>> > CONFIG_FS_FAT=y >>> > CONFIG_FS_PROCFS=y >>> > CONFIG_FS_PROCFS_EXCLUDE_VERSION=y >>> > CONFIG_FS_ROMFS=y >>> > CONFIG_HAVE_CXX=y >>> > CONFIG_HAVE_CXXINITIALIZE=y >>> > CONFIG_HIDKBD_POLLUSEC=8 >>> > CONFIG_I2S=y >>> > CONFIG_INTELHEX_BINARY=y >>> > CONFIG_IOB_NBUFFERS=72 >>> > CONFIG_IOB_THROTTLE=16 >>> > CONFIG_MAX_TASKS=16 >>> > CONFIG_MAX_WDOGPARMS=2 >>> > CONFIG_NETINIT_NETLOCAL=y >>> > CONFIG_NETINIT_NOMAC=y >>> > CONFIG_NETUTILS_NETLIB_GENERICURLPARSER=y >>> > CONFIG_NETUTILS_TELNETC=y >>> > CONFIG_NETUTILS_WEBCLIENT=y >>> > CONFIG_NET_ARP_IPIN=y >>> > CONFIG_NET_ARP_SEND=y >>> > CONFIG_NET_BROADCAST=y >>> > CONFIG_NET_CDCECM=y >>> > CONFIG_NET_ETH_PKTSIZE=1514 >>> > CONFIG_NET_ICMP=y >>> > CONFIG_NET_ICMP_SOCKET=y >>> > CONFIG_NET_ROUTE=y >>> > CONFIG_NET_STATISTICS=y >>> > CONFIG_NET_TCP=y >>> > CONFIG_NET_TCPBACKLOG=y >>> > CONFIG_NET_TCP_NOTIFIER=y >&
Re: [VOTE] Apache NuttX 9.0.0 (incubating) RC1 release
+1 Ran the Validating a Staged Release procedure <https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release>, all ok. Compiles and runs on SAMA5D3-Xplained board. -adam On Tue, Apr 28, 2020 at 9:22 AM Alan Carvalho de Assis wrote: > +1 > > On 4/28/20, Brennan Ashton wrote: > > Hello all, > > Apache NuttX (Incubating) 9.0.0 has been staged under [1] and it's time > to > > vote > > on accepting it for release. If approved we will seek final release > > approval > > from the IPMC. Voting will be open for 72hr. > > > > This release includes fixes on top of 9.0.0-RC0 mostly around > documentation > > as well as some important build system fixes for Windows with Cygwin. > Thank > > you all who gave feedback for the RC0. Full release notes can be found > at > > [2] > > > > Because this project targets embedded systems there is more complexity > > involved > > in the build process. We have tried to make some improvements around > this > > for > > new people to the project and are in the process of updating our sites > and > > wiki > > to simplify the getting started process. > > Two starting points: > > * README.txt -- This is found in the Apache NuttX source and is > extensive. > > * Unofficial NuttX Companion -- Located at [3], this is a currently > > unofficial > >opinionated guide maintained by some of the project committers. > > > > A minimum of 3 binding +1 votes and more binding +1 than binding -1 > > are required to pass. > > > > The Apache requirements for approving a release can be found here [4] > > "Before voting +1 [P]PMC members are required to download the signed > source > > code package, > > compile it as provided, and test the resulting executable on their own > > platform, along > > with also verifying that the package meets the requirements of the ASF > > policy on releases." > > > > A document to walk through some of this process has been published on our > > project wiki > > and can be found here [5]. I did try to walk through this document, but > > please comment > > if you find anything not clear. > > > > [ ] +1 accept (indicate what you validated - e.g. performed the non-RM > > items in [5]) > > [ ] -1 reject (explanation required) > > > > Thank you all, > > Brennan Ashton > > > > SCM Information: > > Release tag: releases/9.0.0-RC1 > > Hash for the release incubating-nuttx tag: > > 725bdfb0e8c704823669d20931fd0a824c462212 > > Hash for the release incubating-nuttx-apps tag: > > 9d4872780f095d7af7414501ccf34ea23d4d565b > > > > [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.0.0-RC1/ > > [2] > > > https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.0.0-RC1/ReleaseNotes > > [3] https://nuttx-companion.readthedocs.io/en/latest/ > > [4] https://www.apache.org/dev/release.html#approving-a-release > > [5] > > > https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release > > > -- Adam Feuer
Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0
Brennan, Cool, thanks for doing that check on Cygwin and WSL. I merged your PR. -adam On Sun, Apr 26, 2020 at 5:40 PM Brennan Ashton wrote: > Adam > I have a PR for the Windows documentation now as well and was able to do a > build both using Cygwin and WSL using the docs. > > Greg, > I did run into an issue with sim:nsh with Cygwin that I opened and issue > on. Did I do something wrong or do we have a bug to fix in the > releases/9.0 branch? > https://github.com/apache/incubator-nuttx/issues/886 > > I think with this I would feel comfortable cutting the 9.0.0-RC1 release > tonight if there are no objections. > > --Brennan > -- Adam Feuer
Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0
Brennan, Awesome, thanks. I merged the PR. Re: incorporating this into the website– sounds great. Ideally we'd add the Companion to the NuttX documentation tree in the repo, and then generate HTML to put on the website. It's great to have docs that are versioned with the source code, so they match up together and people can see the exact docs for the version they're using. I'm happy to talk more about making this happen. cheers adam On Sun, Apr 26, 2020 at 2:57 PM Brennan Ashton wrote: > On Sun, Apr 26, 2020 at 12:20 PM Adam Feuer wrote: > > > Re: quickstart examples, I'm willing to do some for macOS and Linux. > Zephyr > > has those and they are helpful as long as they are kept up to date. I > could > > do them for next release. > > > > Adam, I just sent you a PR mostly around adding macOS to the installation, > but also updating the reference to Apache NuttX and including some minor > toolchain related content. > > I don't personally have a mac outside of work (which I don't mix with > open source contributions) so I am relying on what we do in the CI system. > > I just created a Windows 10 PRO VM, so I can try to help test, document > the Windows side. I know for me I have used WSL in the past so I was > going to give that a go. Cygwin I have not used in years, but I think it > is > what Greg uses so I imagine it is in good shape. > > Maybe in the next release we should consider integrating this into the > project website directly? We probably need to consolidate some of the > info across the wiki, docs in the source and external sites so there is > less documentation rott. > > --Brennan > -- Adam Feuer
Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0
Re: quickstart examples, I'm willing to do some for macOS and Linux. Zephyr has those and they are helpful as long as they are kept up to date. I could do them for next release. What would be a couple of good, well-supported boards? Ideally boards that have USB 2.0 connectivity. I have a Sony Spresence board but I think I bricked it trying to install NuttX on it. -adam On Sat, Apr 25, 2020 at 7:20 PM Nathan Hartman wrote: > On Sat, Apr 25, 2020 at 7:18 PM Brennan Ashton > wrote: > > > The one concern I have is we did not do much to send someone totally new > > in the right direction with regards to building the code. I know some of > > it can be addressed outside > > of the release code, but do we need to have a really short guide to send > > someone on the right track to > > build the SIM or something like the STM32DISCOVERY4? Something that gets > > you to shell from 0 in 10min. > > > Maybe a "quickstart for the impatient" section at the top of the top level > README, after "introduction" and "community" and before "environments?" > > The only bad thing is that such a quickstart might have to assume a > particular development system and a particular target board, otherwise the > number of permutations gets out of hand and it's no longer a short > quickstart. > > Hmmm... > > Maybe three quickstart examples, on macOS, Linux, Windows, and choose a > board for each of those that demonstrates some customization or something > instructive? > > Just thinking out loud here > > Nathan > -- Adam Feuer
Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0
Brennan, All the files in the NuttX Companion have Apache 2.0 License, so we can use them in NuttX if we need them. Let me know if you want to pursue that. -adam On Fri, Apr 24, 2020 at 6:38 PM Brennan Ashton wrote: > On Fri, Apr 24, 2020, 6:28 PM Justin Mclean > wrote: > > > I think mentioning a common well tested platform in the README would > help. > > Remember to get +1 votes a IPMC member will need to be able to compile it > > and some needed votes may need to come from people who are not familiar > > with your project. > > > > Thanks, > > Justin > > > Adam did a really good job here with that, I wonder if there is a way we > could incorporate this somehow. The README files in the board configuration > folders are a trove of good information, but the guide he started is really > nice coming in fresh. > > https://nuttx-companion.readthedocs.io/en/latest/ > > --Brennan > -- Adam Feuer
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
porting imxrt/cxd5602 SD Card driver to sama5 - questions
Hi, I'm trying to port the imxrt SD Card driver (imxrt_usdhc.c) to the sama5d27. Both chips appear to use similar Cadence IP blocks... the registers appear to be almost identical. I know the SDMMC peripheral and the SD Card both work since I can boot from it using U-Boot on the SAMA5D2-XULT board. I have the driver compiling and I can get SDMMC peripheral reset and the clock started and stabilized. (I think.) However, I can't seem to receive command responses from the SD Card... I just receive timeouts. See below for some debug logging. Source code is here on this branch <https://github.com/starcat-io/incubator-nuttx/tree/feature/sama5d27-sdmmc-support>. Here's the sam_sdmmc.c driver file, which corresponds to the imxrt_usdhc.c file. Does anyone have any tips about how to debug this driver? Did anyone do a port of this driver? If so how did you debug it or get it working? I know the Sony cxd5602 and imxrt family both use this driver. cheers adam -- Adam Feuer [0.00] sam_rng_initialize: Initializing TRNG hardware [3.45] nsh_main: custinfo: Entry [3.45] nsh_main: mcinfo: Entry [3.46] nsh_initialize: Entry [3.46] nsh_initialize: about to mount romfs [3.47] board_app_initialize: custinfo: Here 0.1 [3.47] board_app_initialize: mcinfo: Here 0.2 [3.48] sam_sdmmc_initialize: Entry. [3.48] sam_sdmmc_sdio_initialize: sdio init [3.49] sam_reset: Reset complete [3.49] sam_clock: DISABLED, SYSCTRL: [3.50] sam_reset: SYSCTL: PRSSTAT: 01ff IRQSTATEN: 117f01ff [3.50] sam_dumpsample: SDMMC Registers: After reset [3.51] sam_dumpsample:DSADDR[]: 040e [3.52] sam_dumpsample: BLKATTR[0004]: 0010040e [3.52] sam_dumpsample:CMDARG[0008]: 0020040e [3.53] sam_dumpsample:XFERTY[000c]: 00300416 [3.53] sam_dumpsample: CMDRSP0[0010]: 00400416 [3.54] sam_dumpsample: CMDRSP1[0014]: 00500416 [3.55] sam_dumpsample: CMDRSP2[0018]: 00600416 [3.55] sam_dumpsample: CMDRSP3[001c]: 00700416 [3.56] sam_dumpsample: PRSSTAT[0024]: [3.56] sam_dumpsample:PROCTL[0028]: [3.57] sam_dumpsample:SYSCTL[002c]: [3.58] sam_dumpsample: IRQSTAT[0030]: [3.58] sam_dumpsample: IRQSTATEN[0034]: [3.59] sam_dumpsample: IRQSIGEN[0038]: [3.59] sam_dumpsample: AC12ERR[003c]: [3.60] sam_dumpsample: HTCAPBLT[0040]: [3.60] sam_dumpsample: WML[0044]: [3.61] sam_dumpsample:ADMAES[0054]: [3.62] sam_dumpsample: ADSADDR[0058]: [3.62] sam_dumpsample:VENDOR[00c0]: [3.63] sam_dumpsample: MMCBOOT[00c4]: [3.63] sam_sdmmc_sdio_initialize: sdio init complete [3.64] mmcsd_slotinitialize: minor: 0 [3.64] mmcsd_slotinitialize: in mmcd_slotinitnitialize [3.65] mmcsd_slotinitialize: about to mmcd_hwinitialize [3.66] mmcsd_hwinitialize: in mmcsd_hwinitialize [3.66] mmcsd_hwinitialize: DMA supported: 0 [3.67] mmcsd_hwinitialize: Attached MMC/SD interrupts [3.67] sam_registercallback: Register 0x2007374c(0x200ad880) [3.68] sam_status: cdstatus=01 [3.68] mmcsd_probe: type: 0 probed: 0 [3.69] sam_status: cdstatus=01 [3.69] mmcsd_removed: type: 0 present: 1 [3.70] sam_clock: DISABLED, SYSCTRL: [3.70] sam_status: cdstatus=01 [3.71] sam_status: cdstatus=01 [3.71] sam_clock: IDMODE [3.73] sam_clock: Waiting for SDMMC clock to stablize. [3.73] sam_clock: SYSCTRL: 8003 [3.74] mmcsd_cardidentify: About to mmcsd_sendcmdpoll 1... [3.74] sam_sendcmd: in sendcmd[3.75] sam_sendcmd: cmd: arg: regval: mcrval: 8000 [3.75] sam_sendcmd: sendcmd complete. [3.86] sam_waitresponse: ERROR: Timeout cmd: IRQSTAT: [3.86] mmcsd_sendcmdpoll: ERROR: Wait for response to cmd: failed: -116 [3.87] mmcsd_cardidentify: About to mmcsd_sendcmdpoll 2... [3.88] sam_sendcmd: in sendcmd[3.88] sam_sendcmd: cmd: arg: regval: mcrval: 8000 [3.99] sam_sendcmd: ERROR: Timeout (waiting CIHB) cmd: PRSSTAT: 01ff0001
Re: SAMA5D27 SDMMC support branch
Takeyoshi, I finally got the new sama5 sam_sdmmc.c driver to compile. I haven't tested it yet, so I don't know if it actually works... I pushed the code to the branch, I am attaching the config I used. -adam On Thu, Apr 2, 2020 at 3:23 PM Adam Feuer wrote: > Takeyoshi, > > No worries– I had to work on other things too. > > -adam > > On Thu, Apr 2, 2020 at 3:22 PM Takeyoshi Kikuchi > wrote: > >> Adam, >> >> Sorry, I am currently busy working and have no progress. >> I want to check tomorrow. >> >> Takeyoshi Kikuchi >> >> On 2020/04/02 9:48, Adam Feuer wrote: >> > Takeyoshi, >> > >> > I did some work on the SDMCC driver today, it compiles now and I pushed >> the >> > code to the branch. I will try it and let you know how it goes. I am >> still >> > not sure everything is right, for instance why do I have to specify >> > SDMMC0_SIZE? The sama5d2x_memorymap.c file seems to need it. But it >> should >> > not be operating in memory-mapped mode, so I'm confused. >> > >> > Here are the config settings I used: >> > >> > # >> > # This file is autogenerated: PLEASE DO NOT EDIT IT. >> > # >> > # You can use "make menuconfig" to make any modifications to the >> installed >> > .config file. >> > # You can then do "make savedefconfig" to generate a new defconfig file >> > that includes your >> > # modifications. >> > # >> > # CONFIG_AUDIO_FORMAT_MP3 is not set >> > # CONFIG_DISABLE_OS_API is not set >> > # CONFIG_NSH_ARGCAT is not set >> > # CONFIG_NSH_CMDOPT_HEXDUMP is not set >> > # CONFIG_NSH_CMDPARMS is not set >> > # CONFIG_SAMA5_UART0 is not set >> > CONFIG_ARCH="arm" >> > CONFIG_ARCH_BOARD="sama5d2-xult" >> > CONFIG_ARCH_BOARD_SAMA5D2_XULT=y >> > CONFIG_ARCH_BUTTONS=y >> > CONFIG_ARCH_CHIP="sama5" >> > CONFIG_ARCH_CHIP_ATSAMA5D27=y >> > CONFIG_ARCH_CHIP_SAMA5=y >> > CONFIG_ARCH_CHIP_SAMA5D2=y >> > CONFIG_ARCH_INTERRUPTSTACK=2048 >> > CONFIG_ARCH_IRQBUTTONS=y >> > CONFIG_ARCH_LOWVECTORS=y >> > CONFIG_ARCH_STACKDUMP=y >> > CONFIG_AUDIO=y >> > CONFIG_AUDIO_NUM_BUFFERS=8 >> > CONFIG_BOARD_LOOPSPERMSEC=65775 >> > CONFIG_BOOT_RUNFROMSDRAM=y >> > CONFIG_BUILTIN=y >> > CONFIG_DEBUG_FEATURES=y >> > CONFIG_DEBUG_FULLOPT=y >> > CONFIG_DEBUG_SYMBOLS=y >> > CONFIG_DEV_LOOP=y >> > CONFIG_DEV_ZERO=y >> > CONFIG_EXAMPLES_HELLO=y >> > CONFIG_EXAMPLES_PARTITION=y >> > CONFIG_EXAMPLES_TCPBLASTER=y >> > CONFIG_EXAMPLES_TCPECHO=y >> > CONFIG_EXAMPLES_WGET=y >> > CONFIG_EXAMPLES_WGET_URL="http://10.0.0.1/; >> > CONFIG_FAT_LCNAMES=y >> > CONFIG_FAT_LFN=y >> > CONFIG_FS_FAT=y >> > CONFIG_FS_PROCFS=y >> > CONFIG_FS_PROCFS_EXCLUDE_VERSION=y >> > CONFIG_FS_ROMFS=y >> > CONFIG_HAVE_CXX=y >> > CONFIG_HAVE_CXXINITIALIZE=y >> > CONFIG_HIDKBD_POLLUSEC=8 >> > CONFIG_I2S=y >> > CONFIG_INTELHEX_BINARY=y >> > CONFIG_IOB_NBUFFERS=72 >> > CONFIG_IOB_THROTTLE=16 >> > CONFIG_MAX_TASKS=16 >> > CONFIG_MAX_WDOGPARMS=2 >> > CONFIG_NETINIT_NETLOCAL=y >> > CONFIG_NETINIT_NOMAC=y >> > CONFIG_NETUTILS_NETLIB_GENERICURLPARSER=y >> > CONFIG_NETUTILS_TELNETC=y >> > CONFIG_NETUTILS_WEBCLIENT=y >> > CONFIG_NET_ARP_IPIN=y >> > CONFIG_NET_ARP_SEND=y >> > CONFIG_NET_BROADCAST=y >> > CONFIG_NET_CDCECM=y >> > CONFIG_NET_ETH_PKTSIZE=1514 >> > CONFIG_NET_ICMP=y >> > CONFIG_NET_ICMP_SOCKET=y >> > CONFIG_NET_ROUTE=y >> > CONFIG_NET_STATISTICS=y >> > CONFIG_NET_TCP=y >> > CONFIG_NET_TCPBACKLOG=y >> > CONFIG_NET_TCP_NOTIFIER=y >> > CONFIG_NET_TCP_WRITE_BUFFERS=y >> > CONFIG_NET_UDP=y >> > CONFIG_NFILE_DESCRIPTORS=8 >> > CONFIG_NFILE_STREAMS=8 >> > CONFIG_NSH_ARCHINIT=y >> > CONFIG_NSH_BUILTIN_APPS=y >> > CONFIG_NSH_FILEIOSIZE=512 >> > CONFIG_NSH_PROMPT_STRING="nsh> " >> > CONFIG_NSH_QUOTE=y >> > CONFIG_NSH_READLINE=y >> > CONFIG_NSH_ROMFSETC=y >> > CONFIG_NXPLAYER_DEFAULT_MEDIADIR="/mnt/sdcard" >> > CONFIG_NXPLAYER_INCLUDE_SYSTEM_RESET=y >> > CONFIG_NXPLAYER_RECURSIVE_MEDIA_SEARCH=y >> > CONFIG_PREALLOC_MQ_MSGS=4 >> > CONFIG_PREALLOC_TIMERS=4 >> > CONFIG_PREALLOC_WDOGS=16 >> &
Re: debugging a NuttX linker problem
Thanks Greg. I found out that this resulted from an error in my Kconfig file. I was providing those functions, but they weren't getting compiled or linked due to my config settings. I corrected that Kconfig file, reran 'make menuconfig' and now my files are being compiled and linked. There's still problems compiling some stuff that I ported from the imxrt SD Card driver... working on that now... -adam On Thu, Apr 9, 2020 at 11:42 AM Gregory Nutt wrote: > > >> arm-none-eabi-ld: > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/arch/arm/src/board/libboard.a(sam_bringup.o): > >> in function `sam_bringup': > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_bringup.c:149: > >> undefined reference to `sam_sdmmc_sdio_initialize' > >> arm-none-eabi-ld: > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_bringup.c:166: > >> undefined reference to `sam_sdmmc_set_sdio_card_isr' > >> arm-none-eabi-ld: > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/arch/arm/src/board/libboard.a(sam_sdmmc.o): > >> in function `sam_sdmmc_cardetect': > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_sdmmc.c:152: > >> undefined reference to `sdio_mediachange' > >> arm-none-eabi-ld: > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/arch/arm/src/board/libboard.a(sam_sdmmc.o): > >> in function `sam_sdmmc_initialize': > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_sdmmc.c:239: > >> undefined reference to `sam_sdmmc_sdio_initialize' > >> arm-none-eabi-ld: > >> > /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_sdmmc.c:263: > >> undefined reference to `sdio_mediachange' > > These are ALL functions that must be provided in your board-specific > logic. Look for example a: > > $ cd boards/arm/sama5/ > $ grep -r sdio_mediachange * > sama5d2-xult/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd); > sama5d2-xult/src/sam_hsmci.c: sdio_mediachange(state->hsmci, state->cd); > sama5d3x-ek/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd); > sama5d3x-ek/src/sam_hsmci.c: sdio_mediachange(state->hsmci, state->cd); > sama5d3-xplained/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd); > sama5d3-xplained/src/sam_hsmci.c: sdio_mediachange(state->hsmci, > state->cd); > sama5d4-ek/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd); > sama5d4-ek/src/sam_hsmci.c: sdio_mediachange(state->hsmci, state->cd); > > > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Ok, I went through PRs 466-764 for bugfixes, and added a few to the wiki page. Many of the improvements were changes to conform to style, or small fixes that would not be relevant for release notes. I think we're done summarizing. Are we ready to create a PR for the Release Notes? In other words, get them into the text file form? cheers adam On Fri, Apr 10, 2020 at 11:58 AM Alan Carvalho de Assis wrote: > No problem, I didn't realize that you didn't include the previous > commit after reviewing all PRs. > > I think now we have a better picture about all improvements and > bugfixes from 8.2 to 9.0. > > BR, > > Alan > > On 4/10/20, Adam Feuer wrote: > > Ok thanks Alan. I'm sorry I wasn't clear about what we had done. > > > > -adam > > > > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis < > acas...@gmail.com> > > wrote: > > > >> Hi Adam, > >> > >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > >> tag. But I didn't checked for improvements because I thought you, > >> Nathan and Abdelatif did it. > >> > >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > >> problem. > >> > >> BR, > >> > >> Alan > >> > >> On 4/10/20, Adam Feuer wrote: > >> > Alan, > >> > > >> > Next we need to check for features/improvements and bugfixes between > 23 > >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the > 16 > >> > November 2019, the date of NuttX release 8.2. The main source of info > >> > for > >> > this would be commit messages in the current master branch. > >> > > >> > Would you be willing to look through those? Or figure out a way to > >> > divide > >> > them up among you, me, Nathan, and Abdelatif? > >> > > >> > -adam > >> > > >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < > >> acas...@gmail.com> > >> > wrote: > >> > > >> >> Hi guys, > >> >> > >> >> I finished including the apps/ improvements and bugfixes. > >> >> > >> >> Is there anything else we need to take care? > >> >> > >> >> BR, > >> >> > >> >> Alan > >> >> > >> >> On 4/10/20, Abdelatif Guettouche > >> wrote: > >> >> >> Speaking about the branch, Brennan is suggesting to have a > >> >> >> different > >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY > >> >> >> (the > >> >> >> reasons behind this are here: > >> >> >> https://github.com/apache/incubator-nuttx/pull/757) > >> >> > > >> >> > Is everyone okay with changing the branches naming convention? > >> >> > I personally do not mind. > >> >> > > >> >> > For that PR, I asked Brennan on how to proceed with signing the > >> >> > tarballs. > >> >> > The original flow was: > >> >> > 1. Generate the tarballs > >> >> > 2. Sign the tarballs and create the hashes. > >> >> > 3. Then upload everything (tarballs, hashes, signatures) > >> >> > Everything was done locally and then uploaded. > >> >> > With the PR757 the release tarballs are generated with a push to > the > >> >> > release branch. > >> >> > Do we download them, sign and then upload the signatures? > >> >> > We need at least one way to check the downloads before signing, > like > >> >> > by creating the hashes with the tarballs. > >> >> > > >> >> > > >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer > wrote: > >> >> >> > >> >> >> Xiang, > >> >> >> > >> >> >> Ok, thanks. It's great that this doesn't block the release! > >> >> >> > >> >> >> -adam > >> >> >> > >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > >> >> >> >> > > >> >> >> wrote: > >> >> >> > >> >> >> > This build error happen for several special config only, and > >> already > >> >> >> > exist > >> >>
Re: Start of the NuttX 9.0 release cycle
Ok thanks Alan. I'm sorry I wasn't clear about what we had done. -adam On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis wrote: > Hi Adam, > > Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > tag. But I didn't checked for improvements because I thought you, > Nathan and Abdelatif did it. > > I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > problem. > > BR, > > Alan > > On 4/10/20, Adam Feuer wrote: > > Alan, > > > > Next we need to check for features/improvements and bugfixes between 23 > > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 > > November 2019, the date of NuttX release 8.2. The main source of info for > > this would be commit messages in the current master branch. > > > > Would you be willing to look through those? Or figure out a way to divide > > them up among you, me, Nathan, and Abdelatif? > > > > -adam > > > > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < > acas...@gmail.com> > > wrote: > > > >> Hi guys, > >> > >> I finished including the apps/ improvements and bugfixes. > >> > >> Is there anything else we need to take care? > >> > >> BR, > >> > >> Alan > >> > >> On 4/10/20, Abdelatif Guettouche > wrote: > >> >> Speaking about the branch, Brennan is suggesting to have a different > >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > >> >> reasons behind this are here: > >> >> https://github.com/apache/incubator-nuttx/pull/757) > >> > > >> > Is everyone okay with changing the branches naming convention? > >> > I personally do not mind. > >> > > >> > For that PR, I asked Brennan on how to proceed with signing the > >> > tarballs. > >> > The original flow was: > >> > 1. Generate the tarballs > >> > 2. Sign the tarballs and create the hashes. > >> > 3. Then upload everything (tarballs, hashes, signatures) > >> > Everything was done locally and then uploaded. > >> > With the PR757 the release tarballs are generated with a push to the > >> > release branch. > >> > Do we download them, sign and then upload the signatures? > >> > We need at least one way to check the downloads before signing, like > >> > by creating the hashes with the tarballs. > >> > > >> > > >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: > >> >> > >> >> Xiang, > >> >> > >> >> Ok, thanks. It's great that this doesn't block the release! > >> >> > >> >> -adam > >> >> > >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > > >> >> wrote: > >> >> > >> >> > This build error happen for several special config only, and > already > >> >> > exist > >> >> > > >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer > wrote: > >> >> > > > >> >> > > Xiang, > >> >> > > > >> >> > > Do the parallel build failures block our release? If so, what can > >> >> > > we > >> >> > > do > >> >> > > >> >> > Shouldn't, because: > >> >> > 1.The build error already exist for a long time > >> >> > 2.Only several seldom used configs(all related to binfmt/module/so) > >> >> > hit this issue > >> >> > 3.The single thread build can always finish successfully > >> >> > > >> >> > > temporarily to unblock it? Or is there a fix in the works that > >> >> > > will > >> >> > > be > >> >> > > ready soon? > >> >> > > > >> >> > > >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the > >> >> > recent > >> >> > month, some issue get fixed, but some need more time to > investigate. > >> >> > > >> >> > > -adam > >> >> > > > >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < > >> xiaoxiang781...@gmail.com> > >> >> > wrote: > >> >> > > > >> >> > > > At least, the parallel build still fail randomly which block > our > >> >> > > > nightly checker. > >> >> > > >> >> > >> >> > >> >> -- > >> >> Adam Feuer > >> > > >> > > > > > > -- > > Adam Feuer > > > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
P.S. I think this would have to be done for both nuttx and nuttx-apps. On Fri, Apr 10, 2020 at 10:43 AM Adam Feuer wrote: > Alan, > > Next we need to check for features/improvements and bugfixes between 23 > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 > November 2019, the date of NuttX release 8.2. The main source of info for > this would be commit messages in the current master branch. > > Would you be willing to look through those? Or figure out a way to divide > them up among you, me, Nathan, and Abdelatif? > > -adam > > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis > wrote: > >> Hi guys, >> >> I finished including the apps/ improvements and bugfixes. >> >> Is there anything else we need to take care? >> >> BR, >> >> Alan >> >> On 4/10/20, Abdelatif Guettouche wrote: >> >> Speaking about the branch, Brennan is suggesting to have a different >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the >> >> reasons behind this are here: >> >> https://github.com/apache/incubator-nuttx/pull/757) >> > >> > Is everyone okay with changing the branches naming convention? >> > I personally do not mind. >> > >> > For that PR, I asked Brennan on how to proceed with signing the >> tarballs. >> > The original flow was: >> > 1. Generate the tarballs >> > 2. Sign the tarballs and create the hashes. >> > 3. Then upload everything (tarballs, hashes, signatures) >> > Everything was done locally and then uploaded. >> > With the PR757 the release tarballs are generated with a push to the >> > release branch. >> > Do we download them, sign and then upload the signatures? >> > We need at least one way to check the downloads before signing, like >> > by creating the hashes with the tarballs. >> > >> > >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: >> >> >> >> Xiang, >> >> >> >> Ok, thanks. It's great that this doesn't block the release! >> >> >> >> -adam >> >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao >> >> wrote: >> >> >> >> > This build error happen for several special config only, and already >> >> > exist >> >> > >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: >> >> > > >> >> > > Xiang, >> >> > > >> >> > > Do the parallel build failures block our release? If so, what can >> we >> >> > > do >> >> > >> >> > Shouldn't, because: >> >> > 1.The build error already exist for a long time >> >> > 2.Only several seldom used configs(all related to binfmt/module/so) >> >> > hit this issue >> >> > 3.The single thread build can always finish successfully >> >> > >> >> > > temporarily to unblock it? Or is there a fix in the works that will >> >> > > be >> >> > > ready soon? >> >> > > >> >> > >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent >> >> > month, some issue get fixed, but some need more time to investigate. >> >> > >> >> > > -adam >> >> > > >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < >> xiaoxiang781...@gmail.com> >> >> > wrote: >> >> > > >> >> > > > At least, the parallel build still fail randomly which block our >> >> > > > nightly checker. >> >> > >> >> >> >> >> >> -- >> >> Adam Feuer >> > >> > > > -- > Adam Feuer > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Alan, Next we need to check for features/improvements and bugfixes between 23 December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 November 2019, the date of NuttX release 8.2. The main source of info for this would be commit messages in the current master branch. Would you be willing to look through those? Or figure out a way to divide them up among you, me, Nathan, and Abdelatif? -adam On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis wrote: > Hi guys, > > I finished including the apps/ improvements and bugfixes. > > Is there anything else we need to take care? > > BR, > > Alan > > On 4/10/20, Abdelatif Guettouche wrote: > >> Speaking about the branch, Brennan is suggesting to have a different > >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > >> reasons behind this are here: > >> https://github.com/apache/incubator-nuttx/pull/757) > > > > Is everyone okay with changing the branches naming convention? > > I personally do not mind. > > > > For that PR, I asked Brennan on how to proceed with signing the tarballs. > > The original flow was: > > 1. Generate the tarballs > > 2. Sign the tarballs and create the hashes. > > 3. Then upload everything (tarballs, hashes, signatures) > > Everything was done locally and then uploaded. > > With the PR757 the release tarballs are generated with a push to the > > release branch. > > Do we download them, sign and then upload the signatures? > > We need at least one way to check the downloads before signing, like > > by creating the hashes with the tarballs. > > > > > > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: > >> > >> Xiang, > >> > >> Ok, thanks. It's great that this doesn't block the release! > >> > >> -adam > >> > >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > >> wrote: > >> > >> > This build error happen for several special config only, and already > >> > exist > >> > > >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: > >> > > > >> > > Xiang, > >> > > > >> > > Do the parallel build failures block our release? If so, what can we > >> > > do > >> > > >> > Shouldn't, because: > >> > 1.The build error already exist for a long time > >> > 2.Only several seldom used configs(all related to binfmt/module/so) > >> > hit this issue > >> > 3.The single thread build can always finish successfully > >> > > >> > > temporarily to unblock it? Or is there a fix in the works that will > >> > > be > >> > > ready soon? > >> > > > >> > > >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent > >> > month, some issue get fixed, but some need more time to investigate. > >> > > >> > > -adam > >> > > > >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < > xiaoxiang781...@gmail.com> > >> > wrote: > >> > > > >> > > > At least, the parallel build still fail randomly which block our > >> > > > nightly checker. > >> > > >> > >> > >> -- > >> Adam Feuer > > > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Xiang, Ok, thanks. It's great that this doesn't block the release! -adam On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao wrote: > This build error happen for several special config only, and already exist > > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: > > > > Xiang, > > > > Do the parallel build failures block our release? If so, what can we do > > Shouldn't, because: > 1.The build error already exist for a long time > 2.Only several seldom used configs(all related to binfmt/module/so) > hit this issue > 3.The single thread build can always finish successfully > > > temporarily to unblock it? Or is there a fix in the works that will be > > ready soon? > > > > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent > month, some issue get fixed, but some need more time to investigate. > > > -adam > > > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao > wrote: > > > > > At least, the parallel build still fail randomly which block our > > > nightly checker. > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Xiang, Do the parallel build failures block our release? If so, what can we do temporarily to unblock it? Or is there a fix in the works that will be ready soon? -adam On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao wrote: > At least, the parallel build still fail randomly which block our > nightly checker.
Re: [DISCUSS] Release Notes
Alan, Thank you! We just need bugfixes now, Abdelatif, Nathan, and I did all the features. I think Abdelatif did bugfixes too. So just go through and summarize bugfixes, probably only ones that rise to the level of needing to be in the release notes. -adam On Thu, Apr 9, 2020 at 5:14 PM Alan Carvalho de Assis wrote: > I want to help: > > - Abdelatif: PRs: 1-232 > - Nathan: PRs: 233-465 > - Adam: PRs: 466-697 > - Alan : PRs: 697-928 > > BR, > > Alan > > On 4/2/20, Adam Feuer wrote: > > Ok, so let's split up the PRs with the three people we have now, > Abdelatif, > > Nathan, and me. As new people join, we can give them ranges to look at. > > > > Let's do features first: > > > >- Abdelatif: PRs: 1-232 > >- Nathan: PRs: 233-465 > >- Adam: PRs: 466-697 > > > > Read the PRs, take notes as a bulleted list, and add to the wiki here > under > > 2b Features: > > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0 > > > > Greg noted that we need to also look at commits from Bitbucket, they will > > be in the git log on the main repo. We can do that next. Then we'll do > > bugfixes. Then we'll prioritize and edit. > > > > We could use help! If you have some time to help, respond to this email, > > and we'll give you a range or PRs or commits to summarize. > > > > -adam > > > > On Thu, Apr 2, 2020 at 2:32 PM Abdelatif Guettouche < > > abdelatif.guettou...@gmail.com> wrote: > > > >> At the time of writing we've got 1124 commits since nuttx-8.2 for > >> nuttx/ and 230 for apps/. I'm expecting to see a lot of style fixes > >> but also a lot of features and bug fixes. > >> > >> > We need a few more volunteers. > >> > >> I can get some done, whether it's features or bug fixes. > >> > >> > >> On Thu, Apr 2, 2020 at 10:11 PM Adam Feuer wrote: > >> > > >> > I can't download all the PR descriptions due to rate limiting. Back to > >> the > >> > plan suggested by Nathan. We need a few more volunteers. > >> > > >> > -adam > >> > > >> > On Thu, Apr 2, 2020 at 11:55 AM Adam Feuer wrote: > >> > > >> > > I have an improvement to the process. I just made a scrapy > >> > > <https://scrapy.org/> script that can download the PR title and > >> > > description from Github. (Yeah that should be accessible via the > >> Github API > >> > > but I couldn't figure out how.) > >> > > > >> > > So I can make a spreadsheet or an HTML doc that has all the PR > >> > > descriptions in it. Seems like this would be faster to than clicking > >> > > on > >> > > them but I don't know. I'll give that a shot and post it here. > >> > > > >> > > -adam > >> > > > >> > > On Thu, Apr 2, 2020 at 11:35 AM Nathan Hartman < > >> hartman.nat...@gmail.com> > >> > > wrote: > >> > > > >> > >> On Thu, Apr 2, 2020 at 1:01 PM Adam Feuer wrote: > >> > >> > > >> > >> > Bumping this up. It seems like we need a plan to tackle going > >> through > >> > >> the > >> > >> > 613 closed PRs and summarizing (only merged ones need to be > >> summarized). > >> > >> > This would be easier with a team of people... anyone want to > help? > >> > >> > > >> > >> > One way we could do this is one group take bug fixes, and another > >> take > >> > >> > features, and then make a list for each. Then we put them > together > >> in a > >> > >> > document. > >> > >> > >> > >> So that we don't duplicate work, I think we should also stick to a > >> range > >> > >> of > >> > >> PRs. > >> > >> > >> > >> For example I could go through PRs 1 through 200 looking for new > >> features > >> > >> -- architectures, drivers, boards, etc -- but *not* bug fixes per > >> Adam's > >> > >> suggestion and make a list of those. Another volunteer could look > at > >> PRs > >> > >> 201 through 400, etc. > >> > >> > >> > >> So we need 3 volunteers to look for features, I'm 1 so we need 2 > >> > >> more. > >> > >> > >> > >> And we need the same thing for bug fixes, 3 volunteers. > >> > >> > >> > >> Any takers? > >> > >> > >> > >> Nathan > >> > >> > >> > > > >> > > > >> > > -- > >> > > Adam Feuer > >> > > > >> > > >> > > >> > -- > >> > Adam Feuer > >> > > > > > > -- > > Adam Feuer > > > -- Adam Feuer
Re: [DISCUSS] Release Notes
I didn't track bugfixes when I looked through the PRs, I'll go back and look at them, should be able to do it tomorrow. -adam On Thu, Apr 9, 2020 at 5:02 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > I don't know how you and Nathan proceeded, but I went through all the > PRs and kept those with significant changes. > Only the "Major Changes to Core OS" bullet has a "bugfixes" list. > The other have "significant improvements" lists, so I put everything > other than "new" or "removed" there. > > On Fri, Apr 10, 2020 at 12:33 AM Adam Feuer wrote: > > > > Abdelatif, > > > > Looks good to me. Thanks! > > > > Are we ready to work on summarizing the bugfixes now? > > > > -adam > > > > On Thu, Apr 9, 2020 at 4:09 PM Abdelatif Guettouche < > > abdelatif.guettou...@gmail.com> wrote: > > > > > The list of the PRs where all under "Features Added" so we lost some > > > organization in the page. I guess this is what you referred to when > > > you said that we want them in order. > > > Here how it looked before: > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148645728 > > > > > > I tried to put everything in the right place and added other notes > > > from my range of PRs. > > > Please take a look. > > > > > > Also, I didn't want to remove the PRs number, maybe Nathan still needs > > > them. > > > > > > On Thu, Apr 9, 2020 at 10:11 PM Adam Feuer wrote: > > > > > > > > Ok, I categorized the features to try to add some meaning to them: > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0 > > > > > > > > What do you think? If this is good, we can go on to listing bugs, and > > > split > > > > the PRs up... > > > > > > > > -adam > > > > > > > > On Thu, Apr 9, 2020 at 12:39 PM Adam Feuer wrote: > > > > > > > > > I think putting them in some kind of order is helpful, to give them > > > > > meaning... that's helpful for users. I would rather not look > through a > > > > > 20-point list to have to pick out the important things... I want > > > someone > > > > > else to do that for me, or at least try. :) > > > > > > > > > > -adam > > > > > > > > > > On Thu, Apr 9, 2020 at 12:29 PM Abdelatif Guettouche < > > > > > abdelatif.guettou...@gmail.com> wrote: > > > > > > > > > >> > It would be a GREAT help if in the future all contributors fill > out > > > the > > > > >> PR > > > > >> > description with a little bit of info. Most PRs had nothing or > very > > > > >> little, > > > > >> > which meant I was going by title or looking at code which was > hard. > > > > >> I had the exact same experience, having to go through the code to > > > > >> determine what the PR was actually about was no fun. Maybe it's > time > > > > >> to put in a PR_TEMPLATE. > > > > >> > > > > >> > Now for features, now we need to prioritize the features by > > > importance. > > > > >> Who > > > > >> > can do that? > > > > >> Why do we want to prioritize them? > > > > >> I guess we can just pick them as they arrived. > > > > >> > > > > >> > > > > >> On Thu, Apr 9, 2020 at 8:05 PM Adam Feuer > wrote: > > > > >> > > > > > >> > I did PRs 466-761. Lots of bugfixes, not many true added > features. I > > > > >> added > > > > >> > the feature info to the 9.0 release notes wiki page > > > > >> > <https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0>. > > > > >> > > > > > >> > It would be a GREAT help if in the future all contributors fill > out > > > the > > > > >> PR > > > > >> > description with a little bit of info. Most PRs had nothing or > very > > > > >> little, > > > > >> > which meant I was going by title or looking at code which was > hard. > > > > >> > > > > > >> > Now for features, now we need to prioritize the features by > > >
