Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to ChibiOS 17.6.3 #2025

Open
wants to merge 43 commits into
base: next
Choose a base branch
from
Open

Conversation

glowtape
Copy link
Member

@glowtape glowtape commented Jan 5, 2018

Posting this for first comments, whenever someone's bored. Or if someone wants to compile and test this.

Currently all F4 targets compile, except BrainRE1, where the newer HAL complains about some PLL stuff. Seems some mcuconf.h values aren't considered correct (anymore).

C:/Dev/Chibi/dRonin/flight/PiOS/Common/Libraries/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld.h:1647:2: error: #error "STM32_PLLI2SVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)"
C:/Dev/Chibi/dRonin/flight/PiOS/Common/Libraries/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld.h:1772:2: error: #error "STM32_PLLSAIVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)"

Benchtested on Seppuku, Revolution and OG Brain. They seem to last a while without rebooting, so I guess things are probably OK.

Quick memory check on the Revo, it loses 2124 bytes on the heap, gains 56 bytes on the fast heap. Former is probably additional code and memcore. Latter is due to the mainthread stuff from old ChibiOS disappearing, which sat in CCM. I cant force the new struct, that contains that, the readylists and so on, into CCM, though. Probably due to the extremely unique name of "ch".

I bet the loss of heap is probably going to cause grief for me, trying to get SPRF3E to link.

@glowtape
Copy link
Member Author

glowtape commented Jan 5, 2018

Also, I need to eventually cull all the other compiler/ports crap. +1.5M lines lulz.

@glowtape
Copy link
Member Author

glowtape commented Jan 6, 2018

OK, all targets compile.

F1: I don't have the pipXtreme.

F3: Benchtested the SPRF3e and it works. The others should probably, too.

F4: Benchtested the Seppuku, Revo and OG Brain, they work. The others should probably, too.

BrainRE1: It seems like there's more rigorous checks on the mcuconf.h settings in the new ChibiOS HAL that break compilation. I've added a bunch of simple bypasses to get it to compile. Untested, my RE1 is kaputt.

@glowtape glowtape changed the title Upgrade to ChibiOS 17.6.3 (preview/WIP) Upgrade to ChibiOS 17.6.3 (WIP) Jan 6, 2018
@tracernz
Copy link
Member

tracernz commented Jan 6, 2018

It would be better to rewrite the commit bringing new chibi sources in to remove all the unused files. As-is this will inflate the repo size with objects that will never be used.

@@ -11,7 +11,8 @@ else ifneq "$(findstring STM32F40,$(CHIP))" ""
OPENOCD_JTAG_CONFIG ?= stlink-v2.cfg
OPENOCD_CONFIG := stm32f4x.cfg
MCU := cortex-m4
STM32_TYPE := STM32F40_41xxx
STM32_TYPE := STM32F405xx
STM32_SUBTYPE := STM32F40_41xxx
Copy link
Member Author

@glowtape glowtape Jan 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been looking at it some more, and it'd involve including ChibiOS' stm32_registry.h header in the different StdPeriphs. I'd figure an unsuitably named define in the makefile is the lesser evil option.
--edit: Actually, I'm going to it anyway. It's not like we're going to move from ChibiOS anytime soon, or keep updating the StdPeriph.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, no, trying to work stm32_registry.h into it creates more drama around the bootloaders and flightlib, considering that I somehow have to stick it into pios.h for some situations.

@glowtape
Copy link
Member Author

Mempools requires a function typedef called memgetfunc_t that's encapsulated within the memcore feature flag #ifdef in this version of ChibiOS. I moved it outside said section in the header, so we can disable memcore again and keep rocking the simple allocator (it works just fine).

@tracernz
Copy link
Member

It would be good to report such things upstream and get them fixed rather than carrying them ourselves.

@glowtape
Copy link
Member Author

glowtape commented Jan 11, 2018

I've been digging around ChibiOS some more, looks like it's unnecessary. I wanted it disabled in case something in the OS would start using it in unexpected places. But it appears only ChibiOS' heap allocator uses CoreAlloc, and we don't use their heap allocator, and some syscall (_sbrk_r) ChibiOS specifies, which fails with ENOMEM anyway when there's no memcore (does the same in 2.6.6 already).

They'd probably not accept it upstream for those reasons, anyway.

@glowtape
Copy link
Member Author

Rebased. Reordered the commits topically (which Github doesn't really care 100% for apparently).

@glowtape glowtape changed the title Upgrade to ChibiOS 17.6.3 (WIP) Upgrade to ChibiOS 17.6.3 Jan 11, 2018
@glowtape
Copy link
Member Author

We're losing 2140 bytes on the heap with this one. There's a bunch of more abstractions within ChibiOS, that seem to responsible for this. Maybe I should eventually spend some time figuring out where it goes to. We can make 1024 bytes back running the initTask stuff on main() as suggested elsewhere. CPU usage appears to be same between the two.

@tracernz tracernz added this to the Post-Wired milestone Jan 19, 2018
@mlyle
Copy link
Member

mlyle commented Feb 26, 2018

jenkins, test this please

@glowtape
Copy link
Member Author

Meh, SPRF3E flash overflow. Tonight, I'm gonna cherrypick those changes from the inverse mixer and LQG branches to slim it down, and see if it compiles and still runs.

@glowtape
Copy link
Member Author

Pulled in two patches to remove Light Telemetry and HoTT Bridge. As well as the UI options (including Mavlink, which was already disabled). SPRF3e compiles now and boots fine. Also tried BrainFPV, Revo and Seppuku again.

@glowtape
Copy link
Member Author

I just came to think of it... This would probably need to be tested on a PikoBLX with CharOsd (I don't have one). Trying to run the LQG branch on one of these with autotune and MSP enabled sent it over the edge into a boot loop. Given that the new ChibiOS uses a little bit more memory for internal stuff, the same might happen. If so, this should be postponed until an eventual deprecation of F3 at some later release.

@mlyle
Copy link
Member

mlyle commented Feb 27, 2018

PikoBLX doesn't have OSD, does it?

@glowtape
Copy link
Member Author

I don't know. Both @jhitesma and @ufoDziner tried the LQG stuff on their PikoBLX based 2" quads, and one was out of RAM and the other not. It seemed to involve CharOsd IIRC.

I'm not sure what specific MCU the pipXtreme uses to fix it properly, but STM32F10X_MD needs to be defined anyway for the older CMSIS, so there's a need to touch that header anyway.
@glowtape
Copy link
Member Author

Rebased on latest next, fixed up pios_thread renaming a ChibiOS function in WrapCurrentThread which's new, reworded the target-specific F3 commits because of the mcuconf.h consolidation. Otherwise still the same.

Tested on Seppuku, Revo, OG Brain and SPRF3e.

@glowtape
Copy link
Member Author

I just notice that per task running time doesn't work. Wonder if that broke in the rebase or before.

@glowtape
Copy link
Member Author

Jenkins, test this please.

@glowtape
Copy link
Member Author

I don't know why ef_omnibusf3 fails, compiles fine here. Logs are pretty vague.

@glowtape
Copy link
Member Author

I'm also having a bunch of random crashes. Sometimes things work for like 8-10 minutes, sometimes it crashes after 16 seconds. Given the TaskInfo.StackRemaining values are completely different between next and this, there's probably something with memory.

@glowtape
Copy link
Member Author

Yeah, I'm pretty sure I made changes to pios_heap.c and they're gone. WTF.

Fixes CPU time accounting for modules in TaskInfo.RunningTime.
…cation.

ChibiOS 17 moved the thread_t structure from the top of the stack to the bottom. Need to know where stack starts for PIOS_Thread_Get_Stack_Usage. Fixes TaskInfo.StackRemaining.
This is fixed upstream apparently.
@@ -52,6 +52,15 @@
/* Module pre-compile time settings. */
/*===========================================================================*/

/* dRonin: This if fixed upstream apparently, remove on upgrade to 18.x. */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can never be fixed because we will always have old bootloaders around.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the CRT0_FORCE_MSP_INIT thing. It's not set at all in this ChibiOS release. It's been set to TRUE by default in 18.x.

@mlyle mlyle modified the milestones: Inconceivable, Ludicrous Apr 18, 2018
@glowtape
Copy link
Member Author

Note to self: MemManage_Handler in loadable.c doesn't overwrite the weak alias of ChibiOS for whatever reason (noticed while poking around with objdump yesterday).

@glowtape
Copy link
Member Author

glowtape commented Jun 30, 2018

Seems like a thread struct gets overwritten somewhere at some random point, and when the RTOS wants to switch to the respective thread, shit goes sideways. With ChibiOS 17, the thread struct moved to the other side of the stack memory allocation, so that's probably why it's happening here but not with old ChibiOS. Seems to happen with the Battery module enabled only for now, on Seppuku and SPRF3e. Gonna be a fun one to track down.

--edit: Definitely not the ADC stuff, since it appears to be always running.

@mlyle
Copy link
Member

mlyle commented Jul 1, 2018

Does battery module need a bigger stack?

@glowtape
Copy link
Member Author

glowtape commented Jul 1, 2018

Doesn't look like it. There isn't that much happening in it (from what it looks like to me). I bumped stack from 624 to 800 bytes and it still happens.

What's most irritating is that the time to the event varies a lot. Sometimes it happens at like 15 seconds, other times it takes like 300+ seconds. The only thing I noticed this round of poking at it, is that disabling the battery module, I can repeatedly go up to 1800 seconds without issues, where I usually stop.

I have to figure out how to track this. Probably hack up ChibiOS' context switching to store a pointer of the thread it's switching away from, which hopefully will be responsible for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants