From nobody Mon Apr 15 11:00:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VJ42W06gmz5G5Ss for ; Mon, 15 Apr 2024 11:00:19 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao202.oxsus-vadesecure.net (mta-232b.oxsus-vadesecure.net [15.204.3.7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJ42V1NRTz46kQ for ; Mon, 15 Apr 2024 11:00:18 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=dhsrNbOs; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 15.204.3.7 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; arc=pass ("oxsus-vadesecure.net:s=arc-202309-rsa2048:i=1") ARC-Seal: i=1; a=rsa-sha256; d=oxsus-vadesecure.net; s=arc-202309-rsa2048; t=1713178813; cv=none; b=jQPl+HRy5OwV1/B8wRA+GpTdb/qdP9lFpdEU/G/Wr79jjLNy4tFgHGQdyB2hDuU6MaYkaVQtx/pNrrrBKIlpD30dZwmmM/V4xxWtGi2sCG85fFXuoa3H/lDN/gXp6YdPlVMI7RwaOd84WrM2B2YDo9yxGUuC8fdDou/yf0IhlBpQjwrCQYgpYRiOP8khkFvEqmAJeRPuqcPkBRHoGS9exvl2ril0siNzWLWrD91/UoQg7tlcTOzftY4AyDinP34nAPfd0RDV+xHlxS1spDxkkesdxDbYMx3g96fK26ehNyXqa9cDT49NtmhJh1rRh0oSKMGIRINyUSH6IZs7QdteJA== ARC-Message-Signature: i=1; a=rsa-sha256; d=oxsus-vadesecure.net; s=arc-202309-rsa2048; t=1713178813; c=relaxed/relaxed; h=from:reply-to:subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to:references:list-id:list-help:list-unsubscribe:list-subscribe:list-post:list-owner:list-archive; bh=S3pvNzfwOtLaJZA+HnVJBa9S5rsKD0bpcyCAnoqJJO8=; b=jHI+dzrYL+V4bvr8egE4Er4EFqg4+M4X91w77JX5MhRpEUFIkKfhOGnw4NdZZVbWqcJpn38TI4Dat1fff2dUeBsHP3zl2kAbWqKaB9eYTXY0olmi5H+U/oChn5QMkk3a6ayIpPAGL4XYjm+SL23Vw6Lix00IWMOQLXHwlCgLvtLdoiz6O6uy2JKEGL25QTtEXIMYiyT90Y3OD3+nqTyS4iCmDToG342DfrGKBN0+hpSSl4wIygFqoaPczwxcUlhR674HmlAVqRA4gItiSXmGulWhWp034+yYBe7IumQbhJ06BzZxoCRD8vKu4neWeHuwdYJDCx2+oiVVRXuGfSMSJg== ARC-Authentication-Results: i=1; DKIM-Signature: v=1; a=rsa-sha256; bh=S3pvNzfwOtLaJZA+HnVJBa9S5rsKD0bpcyCAno qJJO8=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1713178813; x=1713783613; b=dhsrNbOsWrC22VR07iPmtL9RLvrfZC+1eO1ldJc2M IbYXwE94R8ZuXH7u1ylKefBEaz38NsDGtUXsEyLDnXw3TrHJmkF62wCXbzdg4rpbgsPDo/5 HRrryK5GPvaTmd74re/v2EASUJ9P2Q+ctzwjZ3MVW61XX2nGyIEiM7by+prDVAcXY2topp+ pRmje7YtbI4hVeFktUxpXLuGbnrK/iQ1PLGl8Hg6wRHfwKyYUNTBLrzBXtHvkKX7g7QQYBr NQBSqerZpLW3Q47fV6Y7sEpbYDVAraM9F4dYNjlLN4cPV59fRpEB9BWNiMtPTUKMthePQ5f mfB9RDBztYoF4kb7g== Received: from proxy-13.proxy.cloudus.ewr.xion.oxcs.net ([76.14.243.145]) by oxsus2nmtao02p.internal.vadesecure.com with ngmta id d4385940-17c66f0daf3ffb58; Mon, 15 Apr 2024 11:00:13 +0000 From: "Fred L. Finster" Subject: Re: Loading vmm JTAG Board FLIRC JEFF PROBE or Tigard Probe To: freebsd-arm@freebsd.org Cc: "fredfinster58@gmail.com" Message-ID: Date: Mon, 15 Apr 2024 04:00:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; FAKE_REPLY(1.00)[]; ARC_ALLOW(-1.00)[oxsus-vadesecure.net:s=arc-202309-rsa2048:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:15.204.3.4/30]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:16276, ipnet:15.204.0.0/17, country:FR]; FREEMAIL_CC(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[15.204.3.7:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[15.204.3.7:from]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+] X-Rspamd-Queue-Id: 4VJ42V1NRTz46kQ > From: John F Carr > Date: Sun, 14 Apr 2024 12:17:22 UTC > > See bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277559. It was suspected to be specific to the heterogenous Rockchip RK3399 but perhaps it is more widespread. > > When I first hit the bug there was a 30-50% chance that the first kldload vmm would hang the system so hard I couldn't even invoke the debugger with break on a serial console. Later, with no relevant changes to source code, it would take about 2,000 load/unload pairs to hang the system. If that 1-in-2000 chance is typical this bug could affect all systems. Give it a try on your 128 core system: > > # while kldload vmm ; do echo -n . ; kldunload vmm ; done > > If anybody can tell me how to debug at the hardware level using JTAG, I can give it a try on my RockPro64 and see where the kernel is stuck. I have used hardware level debugging tools, but they were always black boxes my employer bought with instructions included. I hope hardware debugging finds the problem and solution to your kldload vmm issue Here i share a JTAG circuit board to purchase for interfacing with Raspberry Pi 4B, 3B, 400 with OpenOCD and aarch64-gdb JTAG Hardware post at forums.freebsd.org https://forums.freebsd.org/threads/debugging-arm64-booting-of-freebsd-ghostbsd-kernel-for-raspberry-pi-4-what-tool-do-you-use-any-jtag-hardware-kernel-debug.90436/ From reading the specifications I like the FLIRC JEFF Probe that can be bought from Amazon or AliExpress. It has a TTL UART Serial Port to USB and a TTL JTAG to USB that can be connected with OPENOCD.org and GDB or LLDB connected to the OpenOCD https://flirc.tv/products/flirc-jeffprobe?variant=43085036585192 https://macoy.me/blog/programming/RaspberryPi5Debugging Using a Raspberry Pi PICO board or RP2040 for SWD Serial Wire Debug for Raspberry Pi 5 hardware. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have used the Black Magic Probe (BMP) 3.3V TTL Serial UART for connecting to UART0 for the serial console boot up messages. The BMP JTAG port interfaces with 32bit ARM and not 64 bit ARM, except for supporting OPENOCD onto the JTAG port of the BMP. I also am presently using an orange colored Tigard Board from CrowdSupply.com My Blogpost about connecting this up to Tigard Board. Should be the same or similar for a FLIRC Jeff Probe https://ghostbsd-arm64.blogspot.com/2024/02/tigard-ft232h-board-connectons-to.html I welcome your questions, suggestions and improvements to my blogpost and other materials shared. I, too, am starting blind and learning how to put all this together to be usable for debugging through JTAG software on the Raspberry Pi 4B hardware. Your feedback helps me too and make better documentation for others to use in the future. https://ghostbsd-arm64.blogspot.com/2024/03/compile-gdb-for-aarch64-target-to-use.html Compiling GDB for aarch64 target. I need to add Python built into GDB. Will update this blog post to include Python language. Very useful for one tool that I found and wish to use, that requires the --with-python and --with-python-libdir configuration of GDB. https://forums.raspberrypi.com/viewtopic.php?t=364475 To keep the mailing list clean reading, I turn off the HTML So you copy a URL and paste into your open browser window or use Lynx (links) browser for a quick easy view of a text URL link. Hope, I did not forget a URL link to share while I was recompiling aarch64-gdb with python enabled. Here is aarch64 GDB QEMU UEFI debugging explanation: https://krinkinmu.github.io/2020/12/26/position-independent-executable.html https://surma.dhev/postits/arm64/ Bootstrapping Arm64 hardware, QEMU https://www.vinnie.work/blog/2020-11-06-baremetal-rpi4-setup/ Very good explanations and setup of OpenOCD, aarch64-gdb https://macoy.me/blog/programming/RaspberryPi5Debugging Raspberry Pi 4B JTAG hardware debug setup , Raspberry Pi 5 SWD serial wired debug setup Sending this email now Fred L. Finster https://ghostbsd-arm64.blogspot.com http://ghostbsdarm64.hopto.org/packages/ https://ghostbsd-arm64.blogspot.com/2024/01/january-19-2024-howto-download.html Create your own bootable USB Flash drive stick. > >> On Apr 14, 2024, at 04:50, tuexen@freebsd.org wrote: >> >> Dear all, >> >> using the sources for kernel/world of yesterday running >> kldload vmm >> on a 128 core Ampere system runs just fine: >> >> CPU 0: ARM Neoverse-N1 r3p1 affinity: 18 0 0 >> Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG,IDC> >> Instruction Set Attributes 0 = >> Instruction Set Attributes 1 = >> Instruction Set Attributes 2 = <> >> Processor Features 0 = >> Processor Features 1 = >> Memory Model Features 0 = >> Memory Model Features 1 = >> Memory Model Features 2 = >> Debug Features 0 = >> Debug Features 1 = <> >> Auxiliary Features 0 = <> >> Auxiliary Features 1 = <> >> AArch32 Instruction Set Attributes 5 = >> AArch32 Media and VFP Features 0 = >> AArch32 Media and VFP Features 1 = >> >> However, doing the same on a 32 core Ampere system results in >> the system becoming unresponsive. No reaction on the console, >> no message there, no response over the network. >> >> CPU 0: APM eMAG 8180 r3p2 affinity: 0 0 >> Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >> Instruction Set Attributes 0 = >> Instruction Set Attributes 1 = <> >> Instruction Set Attributes 2 = <> >> Processor Features 0 = >> Processor Features 1 = <> >> Memory Model Features 0 = >> Memory Model Features 1 = <8bit VMID> >> Trying to mount root from ufs:/dev/ada0p2 [rw]... >> Memory Model Features 2 = <32bit CCIDX,48bit VA> >> Debug Features 0 = >> Debug Features 1 = <> >> Auxiliary Features 0 = <> >> Auxiliary Features 1 = <> >> AArch32 Instruction Set Attributes 5 = >> AArch32 Media and VFP Features 0 = >> AArch32 Media and VFP Features 1 = >> >> Any idea, what is going wrong? >> >> Best regards >> Michael > -- Fred Finster GhostBSD-Arm64.blogspot.com t.me/ghostbsd Telegram Channel GhostBSD.org website ghostbsdarm64.hopto.org/packages