Date: Tue, 24 Aug 2021 18:35:16 +0200 From: Tomasz CEDRO <tomek@cedro.info> To: "Brian McGovern (bmcgover)" <bmcgover@cisco.com> Cc: FreeBSD Questions Mailing List <freebsd-questions@freebsd.org> Subject: Re: Arduino Development on aarch64? Message-ID: <CAM8r67AScPvNMtpbcPKaPO-tUfcxQNejb8h5%2Bx651Bs_WTmSpg@mail.gmail.com> In-Reply-To: <BN6PR11MB1650A07F245F409C9E72089AC5C59@BN6PR11MB1650.namprd11.prod.outlook.com> References: <BN6PR11MB1650A23D206F5DA52E7B4013C5FA9@BN6PR11MB1650.namprd11.prod.outlook.com> <CAM8r67CT_5KcB8dGufNXNLGkahY3=iV%2Bk2SB1QsUFFs7xyWxuw@mail.gmail.com> <BN6PR11MB16501D4CDD82BE1B7C64D574C5C59@BN6PR11MB1650.namprd11.prod.outlook.com> <CAM8r67BNehyMExr=TTqnuUZLg%2BNTyYn7RpRgSwyPAOZ3t8%2BZhg@mail.gmail.com> <BN6PR11MB1650A07F245F409C9E72089AC5C59@BN6PR11MB1650.namprd11.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 24, 2021 at 6:09 PM Brian McGovern (bmcgover) wrote: > > > Please report that on https://bugs.freebsd.org/bugzilla/ maybe someone > > with proper hardware and some time may verify. I wonder if adding big > > swap (i.e. 8GB+) will fix the problem :-) > > Done. I suspect its a proportional issue - the smaller the RAM, the large= r the swap required. The flip side to this is that compile time goes WAY up= , and swap on some of the 64 bit arms is a bit unstable (leading to other c= rashes). Its one of the reasons I spent the extra $$ to get the 8GB variant= - almost makes it like a "real machine" =F0=9F=99=82 Yup :-) I also lack of more RAM in my AMD64 laptop and 8GB is really small in modern world.. but the RAM is soldered to the board.. I have IR Soldering Station and did some replacements of various components so I will try to perform RAM by hand hardware upgrade in my laptop to 16GB or 32GB I just need to find a replacement chips that will fit :-) This could be done also for ARM boards I guess :-) > > This seems upstream issue with the specific Target MCU and/or its > > particular variant? Can you please contact the OpenOCD mailing list to > > verify? Maybe you will fix the upstream :-) > > I don't have a ton of hardware variants, but this looks unique to FreeBSD= /aarch64. In /usr/include/machine/param.h, PAGE_SIZE_4K is defined thusly..= .. > > #define PAGE_SHIFT_4K 12 > #define PAGE_SIZE_4K (1 << PAGE_SHIFT_4K) > > It does not appear in FreeBSD/arm64, and unfortunately its not a "0". Mig= ht be worth making it a "#ifdef/#undef/#endif", but again, above my pay gra= de in the grand scheme to make that decision. > > I did not contact the openocd team, as I'm not sure they're the best "fir= st lookers", as its easy to simply state "Don't have your platform define t= hat value on this one platform variant..." > > I did send it to the openocd port maintainer, though, since I suspect tha= ts a better place to do the thinking as to whether this is more for FreeBSD= or openocd to fix. Ah, to its the OS specific not the MCU define, in that case the OpenOCD Port would be the best place to patch it conditionally on ARM build until a better solution is found :-) As far as I remember I have created initial OpenOCD port for FreeBSD.. and created initial generic SWD transport for OpenOCD :-) I was using it a lot with UrJTAG. But the upstream did not accept my LibSWD part as dedicated standalone module also I tried to make OpenOCD design more modular and coherent, proposed switch from TCL to Python, also some guys from Amontec just copied my work with no attribution, it was a bit mess back then, so I stopped using it at all circa 2013, not sure how it looks nowadays :-) Currently I am using pyOCD that is written as Python module so you can "just use it" on any platform with Python VirtualEnv and I really like that :-) Also Chris "flit" Reed the main developer and project owner is a very nice well organized open guy to work with when some tuning and/or platform specific and/or dependencies needs to be tuned/fixed so "thing just work out of the box"^TM on FreeBSD. It supports both SWD and JTAG transport, although focused on ARM, other targets/architectures may be added as well.. I guess that would be also good candidate to develop for RISC-V :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM8r67AScPvNMtpbcPKaPO-tUfcxQNejb8h5%2Bx651Bs_WTmSpg>